EIP-8037 Increase in gas cost for state creation (State Creation Gas Cost Increase)

Declined for Inclusion · Fees & gas · EIP status Last Call · created 2025-10-01

Raises and unifies the gas cost of operations that grow Ethereum state, such as new accounts, new storage slots, and contract code, to a standard of 1530 gas per byte of state, and counts this cost separately from execution gas.

Why it is needed

Ethereum nodes keep every account and all storage data in a database called the state. Raising the block gas limit lets the network process more transactions, but state grows just as fast. According to the source, as of January 2026 the state database of a Geth node is about 390 GiB, and after the gas limit rose from 30M to 60M, new state created per day more than tripled from about 105 MiB to about 326 MiB, so state is growing by about 116 GiB per year. At a 200M limit, it would grow by about 387 GiB per year and cross the 650 GiB line, where node performance starts to degrade, within a year. Moreover, today the same amount of state costs different amounts depending on how it is created. Contract deployment costs about 200 gas per byte, while a storage slot costs about 313 gas per byte, and even when already existing code is deployed again, clients do not store it twice, yet the cost is the same. This proposal sets a single cost per byte of state, applies the same yardstick to every state-creating operation, and counts state creation cost separately so that the block gas limit can be raised further.

What changes

Today

After EIP-8037

Who is affected

In depth

How the per-byte cost CPSB 1530 was derived

CPSB is a constant chosen so that annual state growth is 120 GiB (128,849,018,880 bytes) at a reference block gas limit of 150M. With a 12 second slot time there are 2,628,000 blocks per year, and under multidimensional metering the base fee converges to the target (half of the limit), so it is assumed that 50% of block gas can be spent on state gas. The state gas available per year is then 75,000,000 x 2,628,000 = 1.971 x 10^14, and dividing this by the target number of bytes gives about 1530 gas per byte. 150M is a midpoint between the current 60M and the expected 300M, chosen so that costs are neither raised too much at once nor need to be raised substantially again later. In the worst case where a block is filled with state creation alone, state growth is 80 GiB at 100M, 120 GiB at 150M, 160 GiB at 200M, and 240 GiB at 300M. If the gas limit changes substantially and the expected growth rate shifts, CPSB can be derived again in a follow-up EIP.

New parameters and changed costs

The new parameters are CPSB 1530, STATE_BYTES_PER_STORAGE_SET 64, STATE_BYTES_PER_NEW_ACCOUNT 120, STATE_BYTES_PER_AUTH_BASE 23, SYSTEM_MAX_SSTORES_PER_CALL 16, and TX_MAX_TOTAL_GAS_LIMIT 4,294,967,295 (2^32 - 1). The byte counts come from the sizes actually written to disk. A new account is 120 bytes: key hash 32 + nonce 8 + balance 16 + code hash 32 + storage root 32. A new storage slot is 64 bytes: key hash 32 + value 32. An EIP-7702 delegation indicator is 23 bytes: 3 bytes of 0xef0100 + 20 bytes of address. Accordingly, GAS_CREATE (32,000), GAS_NEW_ACCOUNT (25,000), and PER_EMPTY_ACCOUNT_COST (25,000) become 120 x CPSB, GAS_STORAGE_SET (20,000) becomes 64 x CPSB, GAS_CODE_DEPOSIT (200 per byte) becomes CPSB per byte, and PER_AUTH_BASE_COST (12,500) becomes 23 x CPSB, all as state gas. Separate execution gas is added on top, such as CREATE_ACCESS, ACCOUNT_WRITE, the code hash cost 6 x ceil(len/32), and EXECUTION_PER_AUTH_BASE_COST, as set by EIP-8038. EXECUTION_PER_AUTH_BASE_COST is the sum of calldata 1,616 (101 bytes x 16) + PRECOMPILE_ECRECOVER + COLD_ACCOUNT_ACCESS + 2 x WARM_ACCESS. The values on the EIP-8038 side are not yet finalized.

Two gas dimensions and the reservoir model

Gas is split into two dimensions: execution gas (execution-gas) and state gas (state-gas). Because a transaction has only one gas limit value, tx.gas, the reservoir model divides it between the two. In the pre-execution phase, evm_gas = tx.gas - intrinsic_gas and execution_gas_budget = TX_MAX_GAS_LIMIT - intrinsic_gas are set, and gas_left = min(execution_gas_budget, evm_gas) and state_gas_reservoir = evm_gas - gas_left are initialized. In other words, gas above the EIP-7825 limit goes into the reservoir. Execution gas is drawn only from gas_left, while state gas is drawn from the reservoir first and, once it runs out, from gas_left, which increases state_gas_from_gas_left. On revert, gas is refilled in the opposite order (LIFO), starting with gas_left. There are four new counters: evm_state_gas_used (total state gas of the transaction), state_gas_from_gas_left (per frame, state gas borrowed from gas_left), state_gas_baseline (the reservoir value at frame entry), and state_gas_committed (used only by the top-level frame, the portion that must not be reverted). The reservoir is passed entirely to child frames, and the 63/64 rule applies only to gas_left. The GAS opcode returns only gas_left, and the SSTORE GAS_CALL_STIPEND check also looks only at gas_left.

State gas rules for SSTORE, account creation, and SELFDESTRUCT

SSTORE is evaluated against the original value at the start of the transaction. Writing a nonzero value to a slot whose original value was 0 deducts 64 x CPSB as state gas, and clearing a slot whose original value was 0 back to 0 refills the same amount. For a slot whose original value was not 0, there is no state gas adjustment however it is changed. The account creation cost is deducted conditionally. When a value-bearing CALL* goes to a nonexistent account, 120 x CPSB is deducted just before the child frame, and it is refilled if the call fails before the frame is entered or the child reverts or halts with an exception. CREATE/CREATE2 read the destination address only after passing the balance, nonce, and depth checks, following EIP-7928, and this single read also serves as the EIP-684 collision check. If the destination does not exist, 120 x CPSB is deducted in the creating frame before the 63/64 split, and if it is an existing address that only holds a balance, nothing is deducted. The code storage cost L x CPSB is deducted at code storage time as usual. Here an existing account, per EIP-161, is one with a nonzero nonce or balance or with code. SELFDESTRUCT does not refund state gas, whether it deletes an account created in the same transaction or only moves the balance of a previously existing account. This is in the same direction as EIP-6780.

Reverts, exceptional halts, and frame merging

When a frame reverts or halts with an exception, state gas is restored to the baseline instead of being refilled. net_state_gas = state_gas_baseline - state_gas_reservoir + state_gas_from_gas_left is subtracted from evm_state_gas_used, state_gas_from_gas_left is added to gas_left and then set to 0, and the reservoir is reset to the baseline. On a revert, the restored gas_left is returned to the parent, and on an exceptional halt, gas_left is consumed down to 0. Only the top-level frame can have a baseline that differs from its entry value, and that happens when there are EIP-7702 authorizations. Authorizations applied in the pre-execution phase are not undone even if the top-level frame reverts, so their state gas is bound up as state_gas_committed and not reverted, and the baseline is taken after the authorization cost and before the account creation cost of the transaction target. When a child frame succeeds, the remaining gas_left and state_gas_from_gas_left are merged into the parent, and d = min(state_gas_reservoir, state_gas_from_gas_left) is moved from the reservoir to gas_left. This is because the original value of SSTORE is based on the start of the transaction, so state gas deducted in one frame can be refilled in another. This move does not cancel any state creation, so evm_state_gas_used does not change.

Transaction gas used, block accounting, and receipts

When a transaction ends, tx_gas_used_before_refund = tx.gas - gas_left - state_gas_reservoir is computed, and the refund is left as is up to 20% (// 5) of usage. Then the EIP-7623 calldata floor (calldata_floor_gas_cost) is applied with max, giving tx_gas_used, which goes into the receipt's cumulative_gas_used. At the block level there are two counters. tx_state_gas = evm_state_gas_used, and tx_execution_gas = max(tx_gas_used_after_refund - tx_state_gas, calldata_floor_gas_cost). The calldata floor is compared only against the execution gas side to prevent a transaction filled with state creation from getting its calldata into a block more cheaply than the floor. As a result, the sum aggregated across the two dimensions can be larger than the gas the sender paid, which is intended. The gas_used in the block header is max(block_execution_gas_used, block_state_gas_used), this value must be at most block.gas_limit, and it is also used for gas_used_delta in the base fee update. Unlike the refunds described in EIP-7778, the state gas refill concerns state that was never actually created, so even when applied together with EIP-7778 it is reflected as is in evm_state_gas_used, and only the execution gas side changes to the pre-refund value.

System calls, backward compatibility, and security considerations

The gas limit for the system contracts called at the start of each block (EIP-2935, 4788, 7002, 7251) grows from 30M to 30,000,000 + 64 x 1530 x 16, and the added portion goes into state_gas_reservoir. System calls are not subject to the EIP-7825 limit or the block gas limit, and they are not added to the block counters. On backward compatibility, because refills are taken from gas_left first, the GAS value can be larger than before the work, both within a single frame and across a sub-call. In the order SSTORE(k, 1); GAS; SSTORE(k, 0); GAS, the difference between the two GAS values is negative. Contracts that are already deployed and measure gas this way cannot be fixed. Bundlers that measure sub-call consumption by the difference in gasleft(), as the ERC-4337 EntryPoint does, cannot see the state gas that was drawn from the reservoir, so they must compute state gas explicitly. Presigned deployment transactions with a hardcoded 100,000 gas limit, such as the Nick's method factory, fail on the new network, so they must be predeployed in genesis or the transaction must be rebuilt. A workaround that exploits the gap between new account creation at 183,600 and a simple transfer at 21,000, by first creating the account with a transfer, is blocked because EIP-2780 adds the account creation cost to the intrinsic gas of value-bearing transfers. Block builders should fill blocks while watching both dimensions, but the simple approach of filling until one dimension is full is also considered sufficient in most cases.

Document status and core developer call decisions

The source status is Last Call, with a deadline of 2026-11-01. In the core developer calls, ACDT #87 on 07.13 included in Devnet 7 a fix for a floor cost bug that allowed blocks to be inflated to 8 times the expected maximum, and ACDT #89 on 07.27 agreed without objection to put the terminology cleanup renaming 'regular gas' to 'execution gas' into Devnet 8. At ACDE #243 on 08.13, the gas repricing numbers were finalized and the 200M gas limit for Glamsterdam was confirmed. At ACDC #186 on 09.03, a fix for the cross-frame state gas bug was approved and all EL clients agreed to ship it in DevNet 8, and at ACDT #96 on 09.14, PR EIPs#12311, which specifies the total state gas limit, was merged. On the other hand, the request to revive the SELFDESTRUCT state gas refund (EIPs PR #12249) was deferred at ACDE #244 on 08.27 to be handled in Hegotá rather than included in Glamsterdam, was declined for inclusion at ACDT #94 on 08.31 because of implementation complexity and the direction of deprecating SELFDESTRUCT, and was closed at ACDT #95 on 09.07. As a result of this decision, the pattern of creating a temporary account and using SELFDESTRUCT in the same transaction pays state gas even though it does not grow state.

Original EIP · ← EIPs