EIP-8358 Net gas metering for account changes

Hegota Declined for Inclusion · Fees & gas · EIP status Draft · created 2026-07-26

Changes the transfer cost rules for sending ether within one transaction so that each account is charged only the first time it changes, already changed accounts are cheap, and accounts that return to their original balance receive a gas refund.

Why it is needed

Today every call that sends ether (CALL) carries an effective fixed charge of 9000 gas. The basis for this charge is the cost of writing account state at the end of the block, but that write happens only once per account whose balance changed, not once per transfer. So when ether moves back and forth between the same accounts several times within one transaction, the transaction repeatedly pays for state writes that will not actually happen. Contract storage has had net metering since EIP-2200, where changing a value is expensive only the first time and restoring the original value earns a refund, yet ether balances have no such rule. Ether is thus the only asset for which each repeated movement is billed like an independent state write. This cost works against common composition patterns such as relay and router contracts that pass received ether straight on, refund patterns that return the excess, and batch transfers that split funds among many recipients.

What changes

Today

After EIP-8358

Who is affected

In depth

Per-account decomposition of the transfer cost

The current CALL_VALUE under EIP-8038 is ACCOUNT_WRITE + CALL_STIPEND = 11300, and if the unused stipend of 2300 is returned the effective cost is 9000. This EIP decomposes it into CALL_VALUE_BASE_GAS = 4000 and a per-account CLEAN_BALANCE_CHANGE_GAS = (ACCOUNT_WRITE - CALL_VALUE_BASE_GAS) / 2 = 2500. The base of 4000 is close to 4056, the combined cost of the stipend and the EIP-7708 transfer log. Since CALL_VALUE_BASE_GAS + 2 × CLEAN_BALANCE_CHANGE_GAS = ACCOUNT_WRITE, a call that changes two clean accounts consumes the same 9000 as today, and if both accounts are dirty it costs only 4000. A transfer to oneself and a CALLCODE with value do not change balances, so they pay only the base of 4000. The EIP-2929 account access cost, the memory expansion cost, the base call cost and the EIP-8037 new account cost are unchanged.

Clean and dirty determination and the baseline

The original balance and original nonce are the values at the start of the transaction, reflecting the sender's upfront gas deduction and nonce increment, and the transaction-level value transfer. Changes made by EIP-7702 authorizations are not included. If the current balance and nonce both equal the original values the account is clean, and if either differs it is dirty. The baseline includes the transaction-level transfer because otherwise the sender and recipient would look dirty without ever having paid this EIP's clean charge, or could return to the baseline and receive a refund without a prior charge. Conversely, authorization processing is excluded so that a nonce raised by an authorization keeps appearing as dirty to later calls.

Balance change charge and refund rules

For an account whose balance actually changes, CLEAN_BALANCE_CHANGE_GAS (2500) is charged if it is clean and nothing is charged if it is dirty. If a dirty account's new balance equals its original balance and its current nonce is also the original value, BALANCE_RESET_REFUND (2500) is added to the refund counter. This counter is the same transaction-wide counter that SSTORE refunds use, so it is rolled back together if the call frame reverts. The total refund at the end of the transaction is subject to the EIP-3529 cap. The nonce is part of the dirtiness test because an account leaf holds the balance and nonce together. CREATE or an EIP-7702 authorization can raise only the nonce without changing the balance, and in that case the leaf must still be written even if the balance returns to the original, so the refund must be blocked. Every refund is preceded by a charge of at least the same amount on the same account, so no over-refund occurs.

Switching the stipend from an addition to a minimum guarantee

Today, for a call with value, a stipend of 2300 is added to the gas the caller provides. Under this EIP, if the gas limit after applying the 63/64 rule is at least CALL_STIPEND, execution proceeds as is, and if it is lower the callee's gas limit is raised to 2300. The gas raised this way was prepaid by the base charge and is not returned, and on success or revert the caller gets back only min(callee_gas_remaining, original gas limit). If the call fails before entering the sub-frame because of insufficient balance or the depth limit, the original gas limit is returned. This prevents the cost of repeated transfers from falling as low as 1700, which could happen if the additive approach were kept. As a compatibility impact, a call given an explicit gas limit receives up to 2300 less gas than before, so an execution that used to succeed may fail, and a contract that reads gasleft() before and after a value transfer may observe different values. The 2300 guarantee for patterns that pass no gas, such as Solidity's transfer and send, is preserved.

Interaction of EIP-7702 authorizations with other account-modifying operations

Applying a valid EIP-7702 authorization increments the authority's nonce and sets its code. Because the original value excludes authorization processing, an account with an applied authorization is dirty on later calls, and since the nonce cannot return to its original value within the transaction, it cannot receive a refund either. The charge for the authorization itself follows the first-write ACCOUNT_WRITE rule of EIP-2780 unchanged. Dirtiness is determined only by comparing balance and nonce, regardless of how the change happened, so value sent by CREATE or CREATE2, balance movement by SELFDESTRUCT, and nonce changes also make the account dirty. However, the gas costs of CREATE, CREATE2, and SELFDESTRUCT themselves are left unchanged to minimize the scope of the change. DELEGATECALL and STATICCALL do not move value and are unaffected.

Security: preventing stipend amplification and transfer log blowup

Gas beyond what the caller supplied arises only when the gas limit is below 2300. It is capped at 2300, prepaid by the base charge, and not returned. Even the cheapest value transfer costs CALL_VALUE_BASE_GAS = 4000 > 2300, so a self-propagating chain, in which a callee running on floor gas recursively triggers another value transfer, is impossible, and a transaction with gas limit G cannot cause execution beyond G. Future cost changes must also keep CALL_VALUE_BASE_GAS > CALL_STIPEND. For EIP-7708 transfer logs as well, the cheapest transfer that emits a log pays 4000, which is more than the 1756 cost of a LOG3 with 32 bytes of data. Every refund is preceded by a charge on the same account, so the per-log cost never falls below this floor, and the worst-case log volume per block is still determined by the LOG opcodes themselves.

Gas estimation and economic effects

There are two effects unrelated to consensus. First, contracts that used the value transfer cost as an implicit rate limit on repeated deposits and withdrawals within one transaction will find themselves in an environment where repetition is cheaper. Second, gas estimation becomes order-dependent, like warm and cold access in EIP-2929. Because the cost of a value transfer depends on earlier account changes within the transaction, wallets and RPC providers must estimate based on the transaction's actual starting state. The price of transaction-level value transfer is covered by TX_VALUE_COST in EIP-2780, and this EIP extends net metering only to transfers during execution.

Status and Fork Decisions

This EIP is in Draft status, so the numbers and rules in the specification may still change. In the core developer calls, it was accepted as a Hegotá candidate (PFI) at ACDE #243 on 08.13, but at ACDE #245 on 09.10 it was declined (DFI) for Hegotá along with EIP-8188 and EIP-8115, citing a low rating.

Original EIP · ← EIPs