Must Every Transaction Update the Same Record to Track Total Supply?
The previous article, Why Gas Still Matters When Transaction Fees Are Zero, separated gas, which measures execution, from the NIGO actually charged. In its EVM example under a paid fee policy, reserving the maximum fee did not mean burning all of it. Settlement burns only the actual charge and returns the remainder.
Now suppose a block contains several such transactions. They may use different balances, but if every fee burn must directly update the same “total NIGO supply” record, they acquire a shared write. Can total supply remain exact without putting that shared record in every transaction's inputs and outputs?
nigo-protocol verifies each transaction's actual balance changes and charges, then collects the supply changes from the results finally included in the block to update the supply record. A small example can show how those two stages work.
What remains of 1,000 after three transactions?
Suppose the parent block—the finalized state immediately before this block—has a total supply of 1,000 NIGO. A, B, and C each hold 100, while all other owners together hold 700. D and E each hold zero.
This block includes three EVM transactions: T1, T2, and T3. All three are valid for inclusion, but their application outcomes differ. Each reserves 5 NIGO from its own holdings for fees. The amounts below are illustrative, not actual fees or gas measurements. There is no additional issuance and no burn other than fees.
| ID | Application outcome | Fee / returned |
|---|---|---|
| T1 | A sends 10 to D; execution succeeds | 2 / 3 |
| T2 | B attempts to send 20 to E, then the entire outer call reverts | 3 / 2 |
| T3 | C runs an operation with no monetary transfer; execution succeeds | 1 / 4 |
Every amount in the table is denominated in NIGO. T2 is more than a simple transfer. A program moves value to E, then fails a later condition and reverts the entire call. The 20 destined for E is rolled back, but the execution charge of 3 remains. This is the distinction between application changes and outer transaction settlement discussed in what survives a failed transaction.
The final balances are:
- A has 88, after subtracting the 10 sent to D and the fee of 2 from its initial 100. D has 10.
- B's transfer is rolled back, leaving only the fee of 3 to deduct. B has 97, and E has 0.
- C has 99 after its fee of 1. The other owners still hold 700 in total.
Together, these balances add up to 994 NIGO. The transactions reserved 15 for fees, but burned only 6 and returned 9. Reserving and returning funds neither creates nor destroys NIGO. The final charges of 2, 3, and 1 are what reduce supply.
Verify balances per transaction, and supply across the block
Each transaction handles balances and fees within its own execution state. T1's successful changes to A and D and T2's rollback of B and E take effect at that stage. Those execution rules must still hold when a later call reads a balance or another transaction depends on the same state.
Transaction accounting compares the NIGO inputs actually spent with the outputs created. Verified burn reasons must explain the difference exactly. A Cell that was only read cannot be counted as spent, and a temporary fee reservation cannot remain unsettled. Signature, authority, and asset-policy checks are also the responsibility of the preceding execution process. Getting the quantities to balance does not, by itself, make a transaction authorized.
Block preparation collects these results to update a supply checkpoint. This protocol-owned state Cell records NIGO's current total supply, its initial issuance, and cumulative burns separated by cause. Ordinary transactions cannot consume or recreate this Cell directly.
In the example, the sum of the final fee burns is subtracted from the parent's supply of 1,000:
Transaction results are verified and accumulated in order, while the changed supply checkpoint is applied to the block state once. The block's total supply must still agree with its actual balances, even though this shared Cell is absent from each transaction's write set.
Currently, NIGO permits no additional issuance after its initial genesis funding. The supply checkpoint accumulates fee burns separately from NIGO destroyed by surviving SELFDESTRUCT effects in verified EVM execution. Not every SELFDESTRUCT destroys supply, and destruction rolled back with execution is not counted. The example has no such destruction, so only the fee burn of 6 is recorded.
Count included failures, not discarded attempts
T2's application execution failed, but that failure is validly included in the block. Its fee of 3 therefore contributes to the supply reduction. A transaction excluded because its inputs are invalid, or one that does not make it into this block, does not contribute to this block's burn.
The same rule applies to re-execution. An execution engine may attempt a transaction, discard that result, and execute it again. Subtracting both the first attempt's charge and the final charge from supply would count it twice. The accounting input is the finally accepted transactions and their execution results, not the number of execution attempts.
For example, suppose a discarded attempt at T3 also calculated a fee of 1. Only the fee of 1 from the included T3 result counts, so supply remains 994. It does not fall to 993. This illustrates the accounting rule for retries; it does not assume that the three EVM transactions above actually execute in parallel.
Block preparation therefore checks that the included transaction list corresponds exactly to its execution receipts. Missing results, duplicate results, and results from transactions not included in the block cannot be mixed into the total. A verified burn of zero also differs from having no economic result at all. Missing results are not silently treated as zero.
The process does not stop at trusting the numbers in receipts. After checking conservation for each transaction, it compares the burn total with the net reduction in NIGO actually spent and created by the block. A Cell created during the block and spent by a later transaction cancels out of the final state change rather than being counted twice. Both the recorded reasons and the amounts in the final state must agree before a supply of 994 is accepted.
Supply is not a statistic reconciled after finalization
The order of supply accounting matters. After transaction execution, the burn totals are compared with the actual state, the supply checkpoint is applied, and then the state root is calculated. A state root is a hash committing to the block's resulting state. Because the checkpoint is included in that hash, supply is part of the committed state, rather than just a number a dashboard calculates afterward.
Other validating nodes re-execute the proposed block through the same preparation path. If the state, including transaction results and supply, differs, they have not reproduced the same block result. The process does not depend on someone separately reporting that “today's burn was 6.”
When the finalized result is stored, the supply checkpoint is not left to a separate follow-up job. The current storage paths apply state changes, transaction receipts, the state root, and related records together. This boundary prevents a verified supply of 994 from being stored while the balances or receipts remain at their previous state.
A block with zero burn preserves its parent's supply. It still undergoes verification. After checking the parent checkpoint and the current results, the process leaves that Cell unwritten if its economic values are unchanged. This does not mean that other balances or program state are unchanged.
Some supply checks must remain within each transaction
The design that includes NIGO in the same asset model provides a common structure for representing and executing assets. It does not give every asset the same issuance authority or supply rules.
If a custom asset has an issuance cap, whether to permit new issuance must be decided against the supply state at that transaction's position. Being able to add issuance amounts at the end of a block does not remove that check. An operation whose outcome depends on reading supply during the block also retains its dependency on the state produced by preceding transactions.
NIGO's block accounting avoids the shared write that would arise if every transaction had to update the total-supply Cell directly. Transactions using the same balances or policy state still depend on one another. Whether execution can run in parallel also depends on the transactions' reads and writes and the execution engine's rules.
This article draws on the design, implementation, and regression-test code reviewed on October 28, 2026. The evidence covers fees from included failures, excluded results, agreement between re-execution and final state, retries after storage failures, and normal reopening. No new product tests or performance measurements were run for this article.
A report saying “six was spent on fees” is not enough to explain why 1,000 becomes 994 after three transactions. The explanation must connect whether each execution was authorized, what was actually burned, which results survived into the block, and whether those results agree with the final state. Keeping supply as verifiable ledger state without requiring every transaction to update the same supply record is the purpose of this design.