Why Gas Still Matters When Transaction Fees Are Zero
A transaction on a blockchain with no transaction fees failed with an “out of gas” error. If nobody has to pay, what has run out?
The previous article, on what rolls back and what survives a failed transaction, ended with an observation: even when a transfer rolls back, records and costs of processing the transaction can remain. This time, we will separate those costs further. How much execution to allow and how much to charge for it are different decisions.
The ZERO fee policy in nigo-protocol sets the monetary transaction fee to zero. It leaves the processing rules and execution limits in place. We can follow the same transfer of 20 X to see the distinction.
Execution needs a stopping point, even without a fee
A holds 100 X, and B holds none. X is a different asset from NIGO, the asset used for fees, and A wants to send 20 X. There is no minting or burning of X. Each success or failure scenario below starts independently from this initial state.
First, suppose A uses an EVM application contract, P. As in the previous article, a separate transaction authorizing P to spend 30 X from A has already been finalized. P checks the payment conditions, then sends 20 X of that allowance to B.
Suppose the transaction has a gas limit of 100,000 and its successful result records 60,000 gas. These numbers are illustrative, not measurements of an actual transfer or recommended settings. The result is A = 80 X, B = 20 X, and a remaining allowance of 10 X. Under ZERO, the transaction fee is zero.
What if P gets stuck in a faulty loop? Letting execution continue merely because no fee is charged could leave one transaction running indefinitely, denying other transactions a chance to be processed. A gas limit makes execution stop within a defined budget. If the outer EVM transaction exhausts its limit and fails, its application changes roll back: the X balances remain 100/0, and the allowance remains 30. The amount charged can still be zero even though execution fails.
Gas is not a stopwatch measuring the milliseconds a computer actually used. It accumulates costs for operations, state access, and other work according to a defined schedule. Nodes applying the same execution rules to the same state and inputs must agree on the limits and outcome. A faster computer does not get to allow more execution for the same transaction.
Reading the limit, usage, price, and settlement separately
The successful transaction above involves four distinct values and steps.
- Limit: The transaction is allowed a maximum of 100,000 gas.
- Usage: After applying the metering rules, its final result records 60,000 gas.
- Price: Under ZERO, the price that converts gas into money is zero.
- Settlement: The applicable fee policy and execution result determine the actual NIGO amounts recorded in the ledger.
A zero fee describes the price and monetary settlement. The limit and usage still matter. Conversely, a large gas limit does not mean the entire limit will always be charged.
Gas schedules also differ between execution paths. The general EVM path in nigo-protocol currently uses a schedule aligned with Osaka execution rules. Native programs and Direct Cell use their respective schedules. Gas numbers from different paths are not direct comparisons of CPU time or processing speed.
The same transfer under a paid fee policy
Now suppose the same EVM transfer runs under FIXED. FIXED means a fixed price per unit of gas, not a fixed amount per transaction. Fees settled under the current FIXED policy are burned.
For this calculation, set the price to 2 of NIGO's smallest units per gas. All monetary amounts below use that unit; they are not proposed production prices. Assume there are no other NIGO transfers and A provides exactly 200,000 in NIGO inputs for the fee.
A gas limit of 100,000 multiplied by a price of 2 gives a maximum fee of 200,000. Before execution, inputs sufficient to cover that amount are secured. But reserving the maximum fee is different from burning it all. The execution result determines the final charge and the amount returned.
| Outcome | Gas in the receipt | Burned / returned |
|---|---|---|
| Success | 60,000 | 120,000 / 80,000 |
| Full REVERT after a payment condition fails | 40,000 | 80,000 / 120,000 |
| Outer transaction exhausts its gas limit | 100,000 | 200,000 / 0 |
Each row is a separate execution, and the gas values are illustrative assumptions. The receipt values include the transaction's intrinsic cost, execution costs, and applicable EVM gas refund rules. “Returned” means the reserved NIGO left after deducting the final charge.
In the successful row, the X balances become 80/20 and the allowance becomes 10. In both failure rows, the X balances return to 100/0 and the allowance to 30, but the fee for the failed transaction processed in the ledger remains. Rolling back the application changes does not erase the work already performed to reach that outcome. In all three cases, the burned and returned amounts add up to the original fee input of 200,000.
This table compares included results after valid EVM transactions have executed. It does not mean the same charges apply to requests rejected before execution because of invalid signatures or inputs, or to simulations.
Does the same formula apply to Direct Cell and Native?
The common asset model allows an asset to be handled through Direct Cell or program execution. That does not let an owner bypass the rules and choose a cheaper path. The asset's current controls and permissions must allow that path.
Direct Cell does not execute a VM program, but it still processes transaction data and verifies ownership and quantity conservation. Its gas is currently calculated from factors such as the length of the transaction data serialized in its prescribed format. This transaction data is called the envelope. Skipping VM execution does not make gas usage zero. If a Direct Cell transaction's gas limit is below this basic processing requirement, validation rejects it before execution.
Native programs meter program execution as well as envelope processing. Multiple modules in a composed policy share the transaction's execution budget; adding a module does not provide a fresh, unlimited budget. These budgets and protocol caps still apply under ZERO.
However, the total gas currently recorded in a Native receipt covers more work than the gas used to calculate its fee.
| Execution path | Gas recorded in the receipt | Current monetary fee basis |
|---|---|---|
| Direct Cell | Envelope processing | Envelope gas and price |
| Native Program | Envelope plus program execution; failure metering rules apply | Envelope gas and price |
| EVM | Total transaction gas under EVM rules | Final EVM gas and price |
Native determines its monetary fee from the envelope before execution, while program usage contributes to limit checks and the receipt. More program execution therefore does not mean the current charge increases in the same proportion. Included Native failures caused by policy rejection or exhausted execution budgets also use the envelope-based fee. When a composed policy exhausts its budget, it records the execution budget determined by the signed limit and the protocol cap as used. Copying the EVM out-of-gas row directly to Native and saying “the entire signed gas limit is burned” would be incorrect.
This describes the current implementation. How execution usage and charges should align under a paid Native policy remains a separate design review item. Being able to explain why execution is metered does not mean every path already has one fully unified charging model.
There is a further distinction when P calls a Native asset policy from inside EVM execution. As in the example connecting Native approval with EVM use, executing the policy does not add a second fee for a separate Native transaction. The internal policy's execution cost contributes to the outer EVM gas budget, and the outer EVM transaction handles monetary settlement.
Nodes processing the same block must apply the same price
If node operators could arbitrarily choose ZERO or FIXED each time, they could calculate different change amounts and supplies for the same transaction. nigo-protocol commits the fee policy and its activation-height schedule to genesis, the ledger's initial state. A node opening an existing ledger checks that the stored policy matches its expected configuration.
An application's fee quote must therefore be distinguished from the settlement rules of the block that actually includes the transaction. Final execution follows the policy applicable to that block. The current FIXED policy should also be distinguished from Ethereum's fee market, which adjusts prices with congestion.
Gas limits execution under shared rules, but it does not measure every cost of running a server. Re-execution to verify the same transaction and the actual work performed by storage do not correspond one-to-one with receipt gas. Setting a transaction limit and making the entire service able to handle every workload are separate concerns.
A zero price still leaves work for the ledger
Following the transfer of 20 X shows that the amount of the asset the user wanted to send, the gas allowed for execution, the gas recorded in the result, and the NIGO actually charged are all different values. ZERO keeps transaction fees at zero while allowing the ledger to meter and limit execution.
This article describes the scope of the design documents, implementation, and regression tests reviewed on October 28, 2026. The example's gas and monetary amounts are assumptions used to explain the mechanism, not product performance figures or measured fees.
That leads to the next question. When fees from multiple FIXED transactions are burned, how do we keep the block's total NIGO supply correct? Must every transaction update the same supply record directly, or can we collect and verify the economic effects that ultimately survive? The next article connects transaction settlement to supply accounting across the block.