Ethereum Gas Fee Accounting: EIP-1559, Burns and Failures

Ethereum gas fee accounting is where protocol mechanics become bookkeeping mechanics. A transaction fee is not merely a dollar expense copied from a block explorer. It is an ETH quantity outflow, and the amount actually consumed comes from the transaction receipt and block data.

Part of the fee can be burned, part can be credited to a fee-recipient address, the fee can remain payable even when the transaction fails, and paying the fee in ETH can itself consume an accounting or tax lot.

That creates five separate questions:

1. How much ETH actually left?
2. What caused the outflow?
3. Did the underlying transaction succeed?
4. Does the cost attach to another asset or transaction, or stand alone?
5. Which ETH lot supplied the quantity consumed?

This article separates protocol fact from accounting and tax consequence, because Ethereum gas fee accounting depends on that distinction. The fact that the base fee is burned is protocol law. It does not by itself answer capitalisation, deductibility, proceeds, revenue, or loss recognition.

Part I: how Ethereum gas actually works

Gas used is not the same as the gas limit

Suppose Ben controls an address holding 2.080089470632 ETH and sends 1.85000000 ETH to an exchange. He does not simply subtract 1.85 from a balance. He signs a transaction that specifies, among other fields, the destination, the value to transfer, and two limits on what he is willing to pay for the computation.

Ethereum meters computation in units of gas. Every operation the network performs has a fixed gas price list. A transaction that just moves ETH, with no data attached, to an ordinary address holding no code uses exactly 21,000 gas: the Yellow Paper's fee schedule records Gtransaction 21000 Paid for every transaction, and ethereum.org's gas documentation says "A standard ETH transfer requires a gas limit of 21,000 units of gas".

Treat that as a floor, not a constant. The gas actually used is that base cost plus whatever code runs at the destination. If the recipient is a contract, its receiving code runs and the cost is higher. If the recipient is an ordinary address that has had code attached to it (possible since 2025 under EIP-7702), the cost is also higher: a live mainnet transfer on 25 August 2026 to such an address, with empty data, used 21,058 gas, in transaction 0x6a47586d23316035624c11205bc4aab3a650b3680faf758d9d508d74bed842b1, in block 25,830,102 at 05:24:35 UTC, which moved 0.01 ETH to an address whose code begins 0xef0100. The extra 58 gas is the delegate's own dispatcher running as far as a STOP. Read gasUsed from the receipt. Never assume it.

Gas is a quantity of work. The price of that work in ETH is set two ways at once, and this is the part most ledgers get wrong. Since the network upgrade known as London, every block carries a base fee per gas that the protocol calculates from the previous block. Nobody sets it and nobody receives it. EIP-1559, the specification that introduced it, states: "The base fee is always burned (i.e. it is destroyed by the protocol)." On top of that the sender offers a priority fee (a tip), which does reach someone. The Yellow Paper: "Ether used to satisfy the priority fee is delivered to the beneficiary address, the address of an account typically under the control of the validator."

The arithmetic is exact and worth memorising, because it is the only way to compute what actually left an account:

effective gas price = base fee per gas + min(max fee per gas − base fee per gas,
                                             max priority fee per gas)

total fee           = gas used × effective gas price
burned              = gas used × base fee per gas          → destroyed, no payee
priority fee        = gas used × (effective gas price − base fee per gas)
                                                           → paid to the block's fee recipient

One carve-out. A blob-carrying transaction pays a second fee on top of that arithmetic, blobGasUsed × blobGasPrice, which EIP-4844 says "is deducted from the sender balance before transaction execution and burned, and is not refunded in case of transaction failure". It is entirely burned and it sits outside gasUsed × effectiveGasPrice, so a ledger that computes the cost from the formula above alone will understate what left.

Take a real mainnet transaction, a plain transfer of 0.02132269396513888 ETH, hash 0xb7b79f12b3c2baa82fde38a3b69f96029a417f453ed43b962e5bb5c66a3baded. Its receipt shows gasUsed 21,000 and effectiveGasPrice 2,079,491,923 wei. The sender had authorised a maximum fee of 500 gwei per gas and a tip of 2 gwei. The block's base fee was 79,491,923 wei per gas, so the min() above resolved to the 2 gwei tip and the effective price became 2,079,491,923 wei. The fee was therefore:

21,000 × 2,079,491,923 wei =  43,669,330,383,000 wei = 0.000043669330383 ETH
  of which burned:           1,669,330,383,000 wei = 0.000001669330383 ETH
  of which to the proposer: 42,000,000,000,000 wei = 0.000042           ETH

The "proposer" in that last line is whoever the block names as its fee recipient, which under MEV-Boost is normally the builder rather than the validator.

The sender's balance fell by 0.02136636329552188 ETH, the transfer plus the fee. One instruction, two economically distinct outflows on top of the payment: value destroyed, and value paid to a counterparty the sender never chose, never contracted with and cannot name.

Two traps live in that example. First, the sender authorised up to 0.025 ETH of fee (a gas limit of 50,000 at a maximum of 500 gwei per gas), 572 times what was actually charged. The authorised maximum is a solvency check, not an expense. A ledger that imports gasLimit × maxFeePerGas overstates the cost by whatever the sender's safety margin happened to be. Second, the burn-to-tip ratio is not stable. In this transaction the tip was twenty-five times the burn. When the network is busy the relationship reverses. Neither component can be inferred from the other, and neither can be inferred from the total. Both come from the receipt and the block header.

Included and failed transactions still consume ETH

This is the single most under-recorded ETH event. ethereum.org's gas documentation states it directly: "The fee is paid regardless of whether a transaction succeeds or fails", and "if a transaction runs out of gas during execution … the EVM will revert any changes, but all the gas provided will still be consumed for the work performed".

When a transaction fails, EIP-140 specifies that "The effect of REVERT is that execution is aborted, considered as failed, and state changes are rolled back". Its motivation section, written to describe the position before the REVERT opcode, a single instruction in Ethereum's virtual machine, existed, put the same point more bluntly: "reverting an EVM execution means that all changes, including LOGs, are lost". Four things are not rolled back: the fee, any nonce increment (an EIP-7702 authorisation increments the authority's nonce as well as the sender's, and the authority may be a different address), the blob fee on a blob-carrying transaction (a blob is a bulk data attachment used mainly by layer-2 networks, priced in its own separate fee market), and, since the Pectra upgrade, a processed delegation indicator. The Yellow Paper is explicit that the debit happens first: "The execution of a valid transaction begins with an irrevocable change made to the state: the nonce of the account of the sender, S(T), is incremented by one and the balance is reduced by part of the up-front cost." Read EIP-140 carefully, though, because it describes the execution frame and not the transaction: "In the same way as all other failures, the calling opcode returns 0 on the stack following a REVERT opcode in the callee." A REVERT in a sub-call that its caller handles leaves the transaction with status 1, so a transaction that succeeded can still contain reverted internal frames, which matters when a trace is read as a list of things that happened.

Success or failure is recorded in a single field. EIP-658 added "a status code, 0 indicating failure … and 1 indicating success" to the transaction receipt. A real example: transaction 0xc5d3b5a5cc90cb2b2df088ba120b6727317a6a716b09a2ef7c4af17b6c60f209 has status 0, gasUsed 45,980, an effective gas price of 125,842,175 wei, a transferred value of zero and no logs. It cost 5,786,223,206,500 wei, about 0.0000057862 ETH, and achieved nothing.

Distinguish this from a transaction the network never accepted. A transaction rejected before inclusion costs nothing and leaves no trace: "It will be rejected before being included in a block, and no gas will be consumed." A transaction that was included and then failed is a real outflow with a real hash. A subledger that filters on status == 1, or on value > 0, drops these silently. The correct population is every transaction with the entity's address in the from field, whatever the status and whatever the value.

Part II: the accounting hinge, fee quantity first, classification second

Before deciding how to book gas, build the quantity record from protocol evidence.

For a normal EIP-1559 transaction, retain at minimum:

Do not substitute gasLimit × maxFeePerGas. Those are ceilings and authorisation parameters, not the amount consumed.

Once the exact wei outflow is established, accounting follows the purpose of the transaction.

IFRS: gas follows what the transaction was for

No IFRS located addresses gas. The analysis has to be built from the standards, and the answer differs by purpose:

The two hooks in the first row are not equal. IAS 2 paragraph 11 names "other costs directly attributable to the acquisition of finished goods, materials and services" expressly. IAS 38 paragraph 27(b) speaks of preparing the asset for its intended use, and paragraph 28's examples (employee benefits, professional fees, testing) are costs of bringing an asset to working condition rather than transaction costs. ETH arrives ready. That is why the only interpretive support located for the row is doing real work: EY's statement that the cost of acquiring cryptoassets "would typically include the purchase price … and the related transaction costs, which could include blockchain processing fees." Everything else in that table is this article's application of the cited paragraphs, and it is offered as reasoning, not as a rule.

The burned base fee has no counterparty at all. That does not change the IFRS answer. The ETH is gone and no future economic benefits are expected from its use or disposal, so it is derecognised under paragraph 112(b). But it does mean no party anywhere recognises corresponding income, and it can also matter under the jurisdiction-specific tax rules discussed in the tax articles.

US GAAP: ASC 350-60 does not supply a complete gas model

Gas paid to acquire crypto is capitalised, and that is this article's own reading of a chain of codified paragraphs, not an answer ASC 350-60 gives. The Subtopic does not address transaction costs, the exposure draft proposed the opposite answer, and the Board then decided not to give one at all. ASU 2023-08 BC33 records the proposal: "The Board proposed that transaction costs to acquire crypto assets … should be expensed as incurred unless an entity capitalizes those costs in accordance with industry-specific guidance (for example, investment companies within the scope of Topic 946)". The proposal was never absolute, and its carve-out was industry-specific. BC36 records where it landed: "the Board decided not to provide guidance on how to recognize or present transaction costs to acquire crypto assets." Capitalisation comes instead from that chain (ASC 350-30-15-4(e) into ASC 350-30-30-1 into ASC 805-50-30-1) and from the two interpreters that read it that way. The AICPA practice aid answers the question directly, and KPMG is explicit that "'gas fees' and other similar costs are transaction costs and should, therefore, be capitalized as part of the initial measurement of a crypto asset". The effect is usually short-lived: KPMG notes that "capitalized transaction costs … will generally be immediately written off" at the first remeasurement, because fair value does not include them.

Gas paid in ETH is a disposal of the ETH used. ASC 350-60 does not say how to measure that disposal; ASC 350-60-05-2 sends the entity to other GAAP, which for a disposal that is not a sale to a customer means ASC 350-10-40-1 and ASC 610-20. ASC 350-10-40-3(d), added by ASU 2023-08, directs the entity to "recognize gains and losses from remeasurement", but it governs the case where the transfer contract fails ASC 606-10-25-1 and the asset is therefore not yet derecognised; it is not the measurement rule for an ordinary disposal. And the route has a limit the article should state rather than hide: ASC 610-20 presupposes a contract and a counterparty, and a burned base fee has neither, so the codified chain runs out exactly where the jurisdiction-specific tax rules can also run out. What is prevailing firm interpretation rather than codified rule is the narrower step used here: remeasure the departing units to fair value immediately before derecognition, then derecognise at that fair value, with the result that a disposal at the principal-market price generally produces no separate gain. ASC 350-60-50-4(a) expressly names "use as payment for services" as a disposition for rollforward purposes.

Gas paid on anything else (an own-wallet transfer, a native staking deposit, a failed transaction) has no specific guidance identified. Nor is there a stand-alone gas-fee policy paragraph in any filing reviewed. The treatment has to be inferred from cost-basis wording, from transaction-expense component lists, from an MD&A sentence netting gas against staking revenue, and in one case from a cash-flow line reading "Blockchain network fees (non-cash)". Ethereum Accounting Under US GAAP develops the framework treatment in full.

Ethereum gas fee accounting by context

The following matrix keeps the mechanics constant and changes only the economic context.

Gas on an own-wallet transfer

This is a good example of why the principal and the fee must never be summarised together.

The principal ETH can move from one address controlled by the entity to another without an economic disposal. The gas ETH nevertheless leaves the entity's holdings. The book lot supplying that gas must be reduced even though the principal simply moved between locations.

Under US federal tax rules, the same two-part structure is explicit. The transfer between the taxpayer's own wallets or accounts is generally non-taxable, except for the digital assets used or withheld to pay transaction services. The newer IRS digital-asset transaction-cost rules also state that amounts paid merely to move digital assets between the taxpayer's own wallets or accounts are not treated as digital-asset transaction costs that add to basis or reduce amount realized. Both statements must stay together.

For jurisdiction-specific treatment, use Ethereum Tax in the United States and Ethereum Tax in Canada rather than generalizing one country's answer. No general EU-wide direct-tax rule on gas was identified, and Ethereum Tax in the European Union sets out where EU law stops and Member State law takes over.

Gas on a failed transaction

A failed included transaction is not "nothing happened".

From the accounting system's perspective:

• the intended state change may have reverted;
• the sender's nonce advanced;
• the execution fee was consumed;
• any applicable blob fee was consumed; and
• the entity has fewer wei than before.

There may be no acquired asset, no successful disposal, and no service result to capitalise into. That is why failed gas deserves its own event code in the subledger rather than being filtered out with failed business transactions.

The burned base fee is a named guidance gap

Protocol fact:

The base-fee portion of the execution fee is removed from the sender and burned.

What does not automatically follow:

• that a service provider received it;
• that it is consideration paid to a counterparty;
• that it is deductible;
• that it reduces proceeds;
• that it is an operating expense;
• or that it is treated the same way as the priority-fee component.

For IFRS and US GAAP, the asset quantity is clearly gone. The precise classification still depends on the economic context and the applicable authoritative model. For tax, the answer is jurisdiction-specific and can be genuinely unresolved.

The United States illustrates the difficulty. The regulations define digital-asset transaction costs in terms broad enough to include property paid to effect a sale, disposition, or acquisition, while a neighbouring provision of the same regulations calls the use of digital assets to pay a fee "a disposition of the digital assets for services", and the IRS FAQ wording narrows that further to services provided by another party. A protocol burn has no recipient. The source set reviewed through 31 August 2026 did not identify an IRS ruling resolving that EIP-1559-specific tension. That is a guidance gap, not an invitation to invent a rule.

Lot consumption

Ethereum has no accounting lots: Why the Ethereum Blockchain Is Not an Accounting Ledger sets out why the chain can never supply one. The gas payment therefore has to be linked to a book lot under the entity's financial-reporting policy and, separately, to the applicable tax-basis method.

If an address contains 10 ETH from three acquisitions and spends 0.004 ETH on gas, the chain proves the 0.004 ETH quantity outflow. It does not say whether that quantity came from the oldest acquisition, the newest acquisition, an average-cost pool, or a specifically identified lot.

That second step belongs to:

• the applicable reporting framework for book carrying amount; and
• the relevant jurisdiction for tax basis.

Do not force the two ledgers to use the same lot rule.

Gas reconciliation control

For every address that can originate transactions:

1. ingest all included outgoing transactions, including status = 0;
2. read gasUsed and effectiveGasPrice from the receipt;
3. calculate or independently verify the total execution fee;
4. separately capture blob fees where applicable;
5. reduce the wei quantity ledger;
6. assign the quantity to a book lot and tax lot under their respective policies;
7. classify the cost by economic purpose;
8. reconcile the ending address balance to finalized chain state.

Materiality can simplify presentation. It should not break quantity correctness. That control is where Ethereum gas fee accounting actually lives, and our crypto accounting guide covers the wider close workflow it sits inside.

How Tokenbooks helps with gas fees

Tokenbooks builds the gas record this control describes. The fee is read off the transaction as gas used times effective gas price, never derived from the gas limit or the max fee, so the quantity that left the address is the quantity that reaches the books. Failed and reverted transactions are ingested and their gas is booked as an expense, which is the case this article treats as the test of a ledger: dropping them overstates the native balance and hides a real cost.

Gas then carries two selectable treatments per portfolio. It can be capitalised into cost basis, with the fee treated as a disposal of the fee asset, or it can be expensed. Either way the fee asset leaves an accounting lot, so the lot-consumption step is not left to a spreadsheet.

The Ethereum integration page describes how fees are captured.

More in this series

Accounting Token Anatomy: Native ETH. This article stands alone, but the series builds in order.

Previous (01.2.3): Why the Ethereum Blockchain Is Not an Accounting Ledger

Next (01.2.5): How to Account for Ethereum Transactions

Sources and authority map

• ethereum.org, "Gas and fees". ethereum.org
• ethereum.org, "Transactions". ethereum.org
• EIP-1559. eips.ethereum.org
• EIP-658. eips.ethereum.org
• EIP-140. eips.ethereum.org
• EIP-4844, EIP-3529, EIP-6780, EIP-7623, EIP-2718. 4844
• Ethereum execution API specification. receipt schema
• IFRS Interpretations Committee, "Holdings of Cryptocurrencies", June 2019. ifrs.org
• IAS 38, IAS 36, IAS 2, IFRS 13, IFRS 15, IAS 8, IAS 21, IAS 7, IAS 12, IAS 1, IAS 10, IFRIC 23. IAS 38
• FASB ASU 2023-08 (ASC 350-60 and ASC 230-10-45-27A). storage.fasb.org
• AICPA, "Accounting for and auditing of digital assets" practice aid. aicpa-cima.com
• KPMG, "Crypto assets" handbook, April 2026, and "Accounting for staking activities", April 2026. handbook
• IRS frequently asked questions on digital-asset transactions (questions 47 to 111, added 15 December 2025), and the pre-2025 set. 2025 onward
• 26 CFR §1.1001-7, §1.1012-1 and §1.6045-1. §1.1001-7
• HMRC Cryptoassets Manual, staking, costs and pooling. CRYPTO21200

Research status. Protocol mechanics and published guidance were refreshed through 31 August 2026. Where a source is interpretive rather than authoritative, the text says so. This article is educational research, not accounting, tax, legal, valuation, or investment advice.