Ethereum Block Gas Accounting: How EIP-7778 Treats Refunds

An Ethereum transaction can perform 100,000 units of work yet be charged for fewer units after a gas refund. Today, that refund can also reduce the amount counted against the block gas limit. EIP-7778 proposes to separate those two jobs: preserve an eligible refund for the user, but count the pre-refund work when enforcing block capacity. This guide connects that proposal to blockchain infrastructure without treating testnet plans as a mainnet guarantee.

As of September 27, 2026, the official EIP remains in Review. Ethereum's execution-specification repository targets EIP-7778 at Amsterdam, and its September 23 test-fixture release includes Amsterdam while targeting a Sepolia activation on October 6. The same release says follow-up fixtures are expected before mainnet. Those are strong testing signals, not proof that mainnet activation has already happened or that every field will remain unchanged.

What Ethereum block gas accounting means

Gas serves two related but different purposes. It prices a user's transaction, and it limits how much work a block can ask every validating node to process. The same number mostly serves both roles today, which makes refunds affect both the payer and block capacity.

Think of a warehouse with a customer invoice and a loading-dock capacity sheet. A recycling credit can lower the customer's bill. It should not make the boxes that workers already moved disappear from the dock sheet. EIP-7778 keeps the credit on the invoice while recording the performed work on the capacity sheet.

This is not a new token fee, a second payment, or a way for validators to charge the user twice. It is a consensus accounting change for deciding whether the transactions collected in a block fit under the block limit.

Why refunds can blur the block limit

Ethereum maintains a refund counter during transaction execution. One qualifying case is clearing a nonzero storage slot with SSTORE. EIP-3529 reduced the storage-clearing refund, removed the SELFDESTRUCT refund, and capped applied refunds at one fifth of gas spent. The incentive still exists, but its ability to expand post-refund block capacity is bounded.

The remaining mismatch is conceptual: a storage write was executed even when a later refund reduces the final charge. Under current accounting, the post-refund amount contributes to cumulative block gas usage. A block can therefore contain more pre-refund execution work than its nominal gas limit suggests.

EIP-7778 calls this block gas limit circumvention. Its motivating example points to Ethereum block 20,878,522: 28.5 million gas was recorded after about 4.01 million gas of refunds, while pre-refund work reached about 32.51 million gas. One historical block does not imply an active exploit. It demonstrates that the capacity meter and performed work can diverge.

How EIP-7778 creates two accounting views

The Review specification describes the split with two formulas. Names can evolve during implementation, but the distinction is the important part.

user gas charged = max(gas used before refund - eligible refund, calldata floor gas)
 
block gas counted = max(gas used before refund, calldata floor gas)

The user view keeps eligible refunds. The block view does not let those refunds create room for another transaction. The calldata floor from EIP-7623 remains relevant to both calculations.

Suppose a transaction uses 100,000 gas before refunds and receives an applied refund of 15,000 gas. Ignoring a higher calldata floor:

The user still receives the 15,000-unit benefit. The proposer cannot treat that benefit as evidence that validators avoided the 15,000 units of work.

What changes for receipts, builders, and users

Transaction receipts keep the payer-facing result

The EIP says a receipt's transaction gasUsed remains the post-refund value. That preserves the number applications commonly use with effectiveGasPrice to calculate the payer's execution fee. Read the Ethereum transaction receipt guide before assuming every gas field answers the same question.

Block validation, however, needs the pre-refund execution amount. Clients already track the refund while executing a transaction, so they can add it back for the block-limit calculation. Tooling that reconstructs capacity only by summing receipt gasUsed values may no longer reproduce the consensus block meter after activation.

Block builders get a stricter packing rule

Proposers and builders must select transactions using the pre-refund capacity contribution. A refund-heavy transaction can remain cheaper for its sender while consuming more of the block's admissible work budget than its receipt suggests. Transaction ordering and packing software must not assume that payer gas and capacity gas are interchangeable.

Wallet users do not choose between the ledgers

A normal user still supplies one transaction gas limit and fee parameters. Refunds are applied after execution, so a refund does not rescue a transaction whose gas limit was too low during execution. Wallets should continue to estimate the full path and display the likely fee; users do not toggle EIP-7778 or submit a second budget.

How EIP-7778 interacts with Glamsterdam gas work

EIP-8007 groups EIP-7778 with the broader Glamsterdam gas-repricing work. It also explains an important boundary when EIP-7778 is combined with EIP-8037's separate state-gas dimension.

An execution-gas refund rewards an action even though work occurred. EIP-7778 therefore excludes that refund from block execution-gas accounting. A state-gas refill is different: it reverses a charge when durable state was not ultimately created, such as state changes undone by a revert or a slot reset within the same transaction. The current design keeps those refills netted out because the metered state resource was not consumed permanently.

That distinction is subtle but useful: “refund” does not describe one universal bucket across the proposed multidimensional model. Developers should test the integrated fork rules rather than applying an EIP-3529 shortcut to every gas component. See the Glamsterdam state-gas guide for the execution-versus-state boundary.

A practical developer checklist

1. Name both quantities. Use explicit variables such as userGasCharged and blockGasCounted; avoid a generic gasUsed when the context can be ambiguous.
2. Audit receipt summations. Indexers, simulators, dashboards, and builder analytics should identify code that derives block capacity solely from receipt values.
3. Test refund-heavy paths. Include storage clearing, multiple refundable transactions in one block, reverts, calldata-floor edge cases, and transactions that combine refund sources.
4. Pin the fork and fixture release. Record the chain ID, client build, EIP revision, execution-spec fixture tag, and test date. Development networks and Review EIPs can change.
5. Keep fee estimates payer-facing. A stricter block contribution does not mean multiplying the user's fee by the pre-refund amount. Preserve the protocol's user refund in fee displays.
6. Recheck builder policies. Transaction selection must reserve pre-refund capacity even when a transaction appears inexpensive after its refund.

Risks and limitations

• Specification risk: EIP-7778 is in Review. Formula details, field semantics, interactions, or activation scope can change.
• Deployment risk: a test-fixture release and a scheduled Sepolia test do not prove mainnet activation. Verify the current fork configuration through official sources.
• Tooling mismatch: explorers and analytics may show payer-facing receipt gas while internal block-capacity accounting uses a larger number. Unlabeled charts can become misleading.
• Builder complexity: block construction must track another accounting view and its interactions with calldata floors and state gas.
• Fee-estimation confusion: the proposal does not remove the need for a transaction gas-limit buffer. Refunds arrive after work; they are not extra gas available to a running call.
• Congestion uncertainty: stricter capacity accounting can change how refund-heavy workloads fit into blocks, but it cannot predict inclusion time or future gas prices.
• Market risk: a protocol-accounting change is not an ETH price signal. Crypto assets remain volatile; never risk funds you cannot afford to lose.

Frequently asked questions

Does EIP-7778 remove Ethereum gas refunds?

No. The current proposal keeps eligible refunds in the user's transaction charge. It prevents those refunds from reducing the transaction's contribution to the block gas limit.

Will users pay the pre-refund amount?

Not under the Review specification. The payer-facing calculation still subtracts the eligible refund, subject to the calldata floor and existing refund rules.

Does a refund increase the gas available during execution?

No. Refunds are applied after execution. The transaction's declared gas limit must cover the execution path before any refund lowers the final charge.

Is EIP-7778 live on Ethereum mainnet?

Do not assume so. As of September 27, 2026, the EIP page is in Review. Official execution-spec fixtures include Amsterdam and target Sepolia testing, while their release notes still anticipate follow-up work before mainnet.

Why not just remove storage-clearing refunds?

EIP-3529 already reduced them and capped total applied refunds. The remaining refund preserves an incentive to clear storage. EIP-7778 addresses block-capacity accuracy while leaving the user incentive in place.

Primary sources

• EIP-7778: Block Gas Accounting without Refunds
• EIP-3529: Reduction in Refunds
• EIP-8007: Glamsterdam Gas Repricings
• Ethereum execution-specs: EIP-7778 implementation tracker
• Ethereum execution-specs: test-fixture releases

Bottom line

EIP-7778 turns one overloaded gas number into two explicit views. The user can keep an eligible refund, while the block limit counts the work performed before that refund. The result is a capacity limit that more closely represents validator workload without converting a storage-cleanup incentive into extra block room.

For users, the wallet flow should remain familiar. For developers, builders, and data teams, the important task is to label which gas quantity a system stores, sums, or displays—and to test the integrated Amsterdam rules instead of assuming a Review proposal is final.

This guide is educational, not financial advice. Verify the latest EIP, client, and network status through primary sources, test with funds you can afford to lose, and do your own research (DYOR/NFA).