EIP-8037: State Creation Gas Cost Increase

Harmonization, increase and separate metering of state creation gas costs to mitigate state growth and unblock scaling

Abstract

This proposal increases the cost of state creation operations, thus avoiding excessive state growth under increased block gas limits. It introduces a new variable,CPSB (cost per state byte), and sets this unit of gas costs per new state byte by targeting an average state growth of 100 GiB per year at a reference block gas limit of 96M gas units. It also introduces an independent metering for state creation costs, thus allowing for increased throughput and for larger contract deployments without being limited by the single transaction gas limit.

Motivation

State creation does not have a harmonized cost, with different methods incurring varied costs for creating the same size of new state. For instance, while contract deployment only costs 202 gas units per new byte created, new storage slots cost 625 gas units per new byte created. Also, deploying duplicated bytecode costs the same as deploying new bytecode, even though clients don’t store duplicated code in the database. This proposal establishes a standard to harmonize all state creation operations.

Additionally, state growth will become a bottleneck for scaling under higher block limits. As of May 2025, the current database size in a Geth node dedicated to state is ~340 GiB. After the increase in gas limit from 30M to 36M gas units, the median size of new state created each day doubled, from ~102 MiB to ~205 MiB. This results in an annual growth of ~73 GiB per year.

The state-growth response we observe is not linear in the gas limit increase: a 1.2x bump (30M → 36M) produced a roughly 2x jump in daily new state, suggesting a one-off shift in user behavior rather than a steady-state ratio. Treating the post-bump rate as the new baseline and extrapolating proportionally to the new gas limit, at a 60M gas limit we would see a daily state growth of ~349 MiB and a yearly state growth of ~124 GiB. Similarly, at a 100M gas limit, the state would grow at a rate of ~553 MiB per day and ~197 GiB per year. Starting from 340 GiB, this rate would breach the 650 GiB threshold (at which point nodes begin experiencing performance degradation) in under 1.6 years.

Specification

New parameters

Parameter changes

Upon activation of this EIP, the following parameters of the gas model are updated. The “New State Gas” column shows the state gas cost (charged to the state-gas dimension), while the “New Regular Gas” column shows additional regular gas costs that accompany the state gas charge.

SELFDESTRUCT_NEW_ACCOUNT is removed and replaced by GAS_NEW_ACCOUNT.

The values assigned to regular gas will be updated based on EIP-8038.

The PER_AUTH_BASE_COST regular gas of 7,500 is derived from EIP-7702’s cost analysis, excluding the code deployment cost (now charged as state gas):

• Calldata cost: ~1,616 (101 bytes × 16)
• Recovering authority address (ecrecover): 3,000
• Reading nonce and code of authority (cold access): 2,600
• Storing values in already warm account: 200
• Code deployment cost: 4,600 (200 × 23) → now in state gas

Total regular gas: 1,616 + 3,000 + 2,600 + 200 ≈ 7,500s

Multidimensional metering for state creation costs

Besides the parameter changes, this proposal introduces an independent metering for state creation costs. Two gas dimensions are introduced, regular-gas and state-gas. For state creation operations, the “new state costs” are charged to state-gas, while the “new regular costs” are charged to regular-gas. The costs of all other operations are charged to regular-gas.

At transaction level, the user pays for both regular-gas and state-gas. The total gas cost of a transaction is the sum of both dimensions. In addition, the transaction gas limit set in EIP-7825 only applies to regular-gas, while state-gas is only capped by tx.gas.

At the block level, only the gas used in the bottleneck resource is considered when checking if the block is full and when updating the base fee for the next block. This gives a new meaning to the block’s gas limit and the block’s gas target: each now bounds the bottleneck resource (the dimension with the highest cumulative gas used) rather than a single combined gas counter.

Transaction validation

Before transaction execution, inclusion of a transaction in a block requires that:

1. The transaction’s intrinsic costs are not higher than EIP-7825’s transaction cap. Concretely, max(intrinsic_regular_gas, calldata_floor_gas_cost) <= TX_MAX_GAS_LIMIT, where intrinsic_regular_gas includes all the intrinsic costs not associated with state created (i.e., base transaction cost, calldata, access lists, authorization base costs).
2. For each gas dimension, the cumulative gas used of all previous transactions added to the transaction’s contribution does not exceed the block gas limit. Concretely, min(TX_MAX_GAS_LIMIT, tx.gas) <= regular_gas_available and tx.gas <= state_gas_available, where regular_gas_available = block_env.block_gas_limit - block_output.block_regular_gas_used and state_gas_available = block_env.block_gas_limit - block_output.block_state_gas_used.

This check is performed before transaction inclusion in a block.

intrinsic_regular_gas is the sum of:

• Transaction base cost
• Calldata cost
• Access list gas cost
• Authorizations regular gas cost (the regular gas portion of PER_AUTH_BASE_COST)
• Create transaction regular gas cost (the regular gas portion of GAS_CREATE)

intrinsic_state_gas is the sum of:

• Authorizations state gas cost (PER_EMPTY_ACCOUNT_COST + the state gas portion of PER_AUTH_BASE_COST)
• Create transaction state gas (the state gas portion of GAS_CREATE)

Transaction-level gas accounting (reservoir model)

Since transactions have a single gas limit parameter (tx.gas), gas accounting is enforced through a reservoir model, in which gas_left and state_gas_reservoir are initialized as follows:

intrinsic_gas = intrinsic_regular_gas + intrinsic_state_gas
execution_gas = tx.gas - intrinsic_gas
regular_gas_budget = TX_MAX_GAS_LIMIT - intrinsic_regular_gas
gas_left = min(regular_gas_budget, execution_gas)
state_gas_reservoir = execution_gas - gas_left

This means that the state_gas_reservoir holds gas that exceeds EIP-7825’s budget. Additionally, two new counters are introduced:

• execution_regular_gas_used encodes the total regular-gas used by the transaction, and it is initialized as execution_regular_gas_used = 0.
• execution_state_gas_used encodes the total state-gas used by the transaction, and it is initialized as execution_state_gas_used = 0.

The gas counters operate as follows:

• Regular-gas charges deduct from gas_left only and increment execution_regular_gas_used.
• State-gas charges deduct from state_gas_reservoir first. When the reservoir is exhausted, state-gas charges deduct from gas_left. State-gas charges increment execution_state_gas_used.
• If a state creation is undone during execution, the corresponding amount of state-gas is refilled back to the reservoir. State-gas refills decrement it execution_state_gas_used.
• The GAS opcode returns gas_left only (excluding the reservoir).
• State-gas is metered at the end of all state-mutating opcodes, call-frame boundaries (in case of exceptional halts and reverts) and at the end of the transaction.

Gas accounting for SSTORE (opcode-level)

State-gas accounting for SSTORE is performed at the end of the opcode execution.

Gas accounting for new accounts

State-gas accounting for CALL* and CREATE/CREATE2 operations is performed at the end of successful call frames. The respective call frame reverts or halts exceptionally, no state-gas is charged for the new account.

Charges for account creation with SELFDESTRUCT are charged at the point where it executes.

State gas refills for SELFDESTRUCT

SELFDESTRUCT does not produce a state-gas refills at the point in which it executes. Its accounting is deferred to the end of the transaction. For each account that was created during the transaction, SELFDESTRUCTed, and is now being removed:

• The state gas previously charged for the account creation (STATE_BYTES_PER_NEW_ACCOUNT × CPSB), the code deposit (L × CPSB where L is the deployed code length), and every storage slot that was charged as new on that account during the transaction (STATE_BYTES_PER_STORAGE_SET × CPSB per slot) is refunded directly to state_gas_reservoir and the execution_state_gas_used decreases by the same amount.
• These refunds are not subject to the 20% refund cap.

For an account that existed before the transaction, SELFDESTRUCT only transferred its balance and the account is not removed; no state-gas refund applies and no changes to execution_state_gas_used. This is consistent with the behavior of EIP-6780

Gas accounting for halts and reverts

After a revert, all state changes performed on the child frame are rolled back and all state-gas charged on the child frame is refunded to the parent frame’s state_gas_reservoir and the remaining gas_left of the child frame is given back to the parent frame (added to gas_left), consistent with existing EVM semantics. execution_state_gas_used is decreased consistently, while execution_regular_gas_used is updated according to the regular gas consumed by the child frame before the revert.

After an exceptional halt, state_gas_reservoir is reset back to its value at the start of the child frame (i.e., all state-gas charges on the child frame are refunded to the parent frame) and the gas_left initially given to the child is consumed (set to zero), consistent with existing EVM semantics. execution_state_gas_used and execution_regular_gas_used are updated accordingly.

Pre-state and post-state gas validation

EIP-7928 defines two-phase gas validation for state-accessing opcodes: pre-state costs (determinable without state access) and post-state costs (requiring state access). Under this EIP, the regular-gas portion of these opcodes follows the EIP-7928 rules unchanged and is charged at opcode time against gas_left. The state-gas portion is also charged at the opcode level; it is computed and deducted at the end of the opcode execution, drawing first from state_gas_reservoir and then from gas_left.

For SSTORE, the GAS_CALL_STIPEND pre-state check (EIP-7928) applies to gas_left only, excluding the state_gas_reservoir.

Transaction gas used

At the end of transaction execution, the gas used before and after refunds is defined as:

tx_gas_used_before_refund = tx.gas - tx_output.gas_left - tx_output.state_gas_reservoir
tx_gas_refund = min(tx_gas_used_before_refund // 5, tx_output.refund_counter)
tx_gas_used_after_refund = tx_gas_used_before_refund - tx_gas_refund

The refund cap remains at 20% of gas used.

Block-level gas accounting

At block level, instead of tracking a single gas_used counter, we keep track of two counters, one for state-gas and one for regular-gas:

tx_regular_gas = intrinsic_regular_gas + tx_output.execution_regular_gas_used
tx_state_gas = intrinsic_state_gas + tx_output.execution_state_gas_used

tx_gas_used = max(tx_gas_used_after_refund, calldata_floor_gas_cost)
block_output.block_regular_gas_used += max(tx_regular_gas, calldata_floor_gas_cost)
block_output.block_state_gas_used += tx_state_gas

Note: tx_gas_used applies the EIP-7623 calldata floor after refunds, so the floor can effectively negate part of a refund when calldata_floor_gas_cost > tx_gas_used_after_refund. The receipt cumulative_gas_used uses this post-floor value.

The block header gas_used field is set to:

gas_used = max(block_output.block_regular_gas_used, block_output.block_state_gas_used)

The block validity condition uses this value:

assert gas_used <= block.gas_limit, 'invalid block: too much gas used'

The base fee update rule is also modified accordingly:

gas_used_delta = parent.gas_used - parent.gas_target

EIP-7702 authorizations

For EIP-7702 authorizations, the intrinsic state-gas assumes account creation for each authorization: (STATE_BYTES_PER_NEW_ACCOUNT + STATE_BYTES_PER_AUTH_BASE) × CPSB per authorization. This mirrors EIP-7702’s own intrinsic charge of PER_EMPTY_ACCOUNT_COST per authorization, which assumes the authority is empty. When the authority is not empty (i.e., non-zero nonce, non-zero balance, or non-empty code), the STATE_BYTES_PER_NEW_ACCOUNT × CPSB portion is refunded directly to state_gas_reservoir during authorization processing. execution_state_gas_used decreases by the corresponding amount.

Receipt semantics

Receipt cumulative_gas_used tracks the cumulative sum of tx_gas_used (post-refund, post-floor) across transactions, instead of the block’s gas_used. This means receipt[i].cumulative_gas_used - receipt[i-1].cumulative_gas_used equals the gas paid by transaction i.

System contracts and system transactions

The gas limit of system contracts (e.g., EIP-2935, EIP-4788, EIP-7002, EIP-7251) that are invoked at the start of every block via a system call is updated from 30M to:

SYSTEM_CALL_GAS_LIMIT = 30_000_000 + STATE_BYTES_PER_STORAGE_SET × CPSB × SYSTEM_MAX_SSTORES_PER_CALL

This ensures preservation of the existing execution margin for system contracts under higher state creation costs.

Here, SYSTEM_MAX_SSTORES_PER_CALL = 16 is the upper bound on the number of new storage slots a single system call is expected to write. This value matches MAX_WITHDRAWAL_REQUESTS_PER_BLOCK (EIP-7002), the largest per-block bound across the existing system contracts.

The additional STATE_BYTES_PER_STORAGE_SET × CPSB × SYSTEM_MAX_SSTORES_PER_CALL is placed in state_gas_reservoir while the rest of the system call’s execution gas is placed in gas_left. System calls remain not subject to the EIP-7825 TX_MAX_GAS_LIMIT cap, do not count against the block gas limit, and do not contribute to either block_regular_gas_used or block_state_gas_used.

Rationale

Deriving the cost per state byte (CPSB)

CPSB is a fixed parameter derived from a reference block gas limit. The derivation pins the cost so that, at the reference block gas limit and under expected average utilization, total state growth stays at the target rate. If a future block gas limit increase materially changes the expected state growth rate, CPSB can be re-derived in a subsequent EIP.

Inputs

• Target state growth: 100 GiB per year, i.e., 100 × 2^30 = 107,374,182,400 bytes.
• Reference block gas limit: 96M gas units.
• Slot time: 12 seconds, giving 86400 / 12 = 7,200 blocks per day and 7,200 × 365 = 2,628,000 blocks per year.
• Average state-gas utilization: 50% of the block gas limit. Under multidimensional metering, the base fee equilibrates around the target, which is half of the gas limit. On average, half of each block’s gas budget can therefore be consumed by state-gas charges before the base fee starts pushing back.

Derivation

The total state gas available for state creation in a year is:

total_state_gas_per_year = (gas_limit / 2) × blocks_per_year
                         = (96,000,000 / 2) × 2,628,000
                         = 48,000,000 × 2,628,000
                         = 1.26144 × 10^14 gas

Dividing by the target byte count gives the cost per state byte:

CPSB = total_state_gas_per_year / target_state_growth
     = 1.26144 × 10^14 / 107,374,182,400
     ≈ 1174 gas/byte

Harmonization across state creation

With the current pricing, the gas cost of creating 1 byte of state varies depending on the method used. The following table shows the various methods and their gas cost per byte. The calculation ignores the transaction intrinsic cost (21k gas units) and the costs of additional opcodes and scaffolding needed to execute such a transaction.

To harmonize costs, we first set the gas cost of a single state byte, CPSB, as explained above. Now that we have a standardized cost per byte, we can derive the various costs parameters by multiplying the unit cost by the increase in bytes any given operation creates in the database (i.e., 32 bytes per slot, 112 bytes per account and 23 bytes per authorization).

Note that the fixed cost GAS_CREATE for contract deployments assumes the same cost as a new account creation.

Multidimensional metering

EIP-7825 limit on contract size

EIP-7825 introduces TX_MAX_GAS_LIMIT (16.7M) as the maximum gas for a single transaction, in particular stipulating tx.gas < TX_MAX_GAS_LIMITas a validity condition. Were we to continue enforcing this validity condition, with CPSB = 1174, this proposal would limit the maximum contract size that can be deployed to roughly 9.9kB. Assuming a representative constructor execution budget of 5M regular gas on top of the 21,000 base transaction cost and the STATE_BYTES_PER_NEW_ACCOUNT × CPSB account-creation cost, the remaining budget for code-deposit state gas yields $\frac{16,777,216 - 21,000 - 5,000,000 - 112 \times 1174}{1174} \approx 9{,}902$ bytes. This maximum size would only decrease if CPSB is re-derived upward in a future EIP.

To solve this issue, we only apply this gas limit to regular gas, not state gas. Doing so does not weaken the intended scaling effect of EIP-7825, because regular gas meters all resources that benefit from parallelization. In particular, state growth does not: growing the state always requires writing to disk, a parallelizable operation, but crucially this part of the cost of a state growth operation has to be metered in regular gas, not state gas. In other words, any operation that grows the state should consume both regular gas and state gas, and the regular gas should fully account for all costs other than the long term effect of growing the state.

However, we cannot statically enforce a regular gas consumption of TX_MAX_GAS_LIMIT, while still allowing a higher state gas consumption, because transactions only have a single gas limit parameter, tx.gas. This is solved through a reservoir model: at transaction start, execution gas is split into gas_left (capped at TX_MAX_GAS_LIMIT - intrinsic_regular_gas) and a state_gas_reservoir (the overflow). State gas charges draw from the reservoir first, then from gas_left when the reservoir is empty. Regular gas charges draw from gas_left only. Exceeding the regular gas budget behaves identically to running out of gas — no special error is needed.

Higher throughput

Another advantage of metering contract creation separately is that increasing the cost of state creation operation in line with the block limit will not affect the available gas for other operations. This allows for higher throughput, as explained in the original multidimensional gas metering introduced in EIP-8011.

Backwards Compatibility

This is a backwards-incompatible gas repricing that requires a scheduled network upgrade.

Wallet developers and node operators MUST update gas estimation handling to accommodate the new state creation costs and the two-dimensional metering model. Specifically:

• Wallets: Wallets using eth_estimateGas MUST be updated to ensure they correctly account for the updated state creation costs and report tx.gas covering both the regular-gas and state-gas dimensions. Failure to do so could result in underestimating gas, leading to failed transactions.
• Node Software: RPC methods such as eth_estimateGas MUST incorporate the new state-gas charges, the reservoir-model accounting, and the two-dimensional block accounting when computing gas estimates.

Users can maintain their usual workflows without modification, as wallet and RPC updates will handle these changes.

Estimated price impacts

Users and dApp developers will experience an increase in transaction costs associated with creating a new state. The next table summarizes the state creation costs for common operations under the proposed CPSB of 1,174.

Security Considerations

Increasing the cost of state creation operations could impact the usability of certain applications. More analysis is needed to understand the potential effects on various dApps and user behaviors.

Mispricing with respect to ETH transfers

One potential concern is the cost of creating a new account (STATE_BYTES_PER_NEW_ACCOUNT × CPSB gas units, e.g., 131,488 at a 100M gas limit), compared to transferring ETH to a fresh account (21,000 gas units). With this mismatch, users wishing to create new account are incentivized to first send a normal transaction (costing 21k) to this account to create it, thus avoiding the GAS_NEW_ACCOUNT charge.

EIP-2780 solves this mispricing by adding a new component to the intrinsic gas cost of transactions. If a non-create transaction has value > 0 and targets a non-existent account, the GAS_NEW_ACCOUNT is added to intrinsic cost.

Added complexity in block building

Optimal block construction becomes more complex, since builders must now balance resource usage across multiple dimensions rather than a single gas metric. Sophisticated builders may gain an advantage by applying advanced optimization techniques, raising concerns about further builder centralization. However, practical heuristics (e.g., greedily filling blocks until one resource dimension saturates) remain effective for most use cases. These heuristics limit centralization pressure by keeping block construction feasible for local and less sophisticated builders.

Interaction with ERC-4337 bundles

The GAS opcode returns gas_left only and cannot observe state_gas_reservoir. Bundling protocols that meter sub-call consumption via gasleft() deltas (e.g., the ERC-4337 EntryPoint) therefore cannot accurately attribute state-gas usage when it is funded by the reservoir. Because all user operations in a bundle share the transaction’s reservoir, one user operation’s state-gas refunds can subsidize another’s state-gas charges without appearing in either’s gasleft() delta. Bundlers and EntryPoint implementations MUST account for state-gas charges and refunds explicitly rather than relying on gasleft() differences alone.

Copyright

Copyright and related rights waived via CC0.

Citation

Please cite this document as:

Maria Silva (@misilva73), Carlos Perez (@CPerezz), Jochem Brouwer (@jochem-brouwer), Ansgar Dietrichs (@adietrichs), Łukasz Rozmej (@LukaszRozmej), Anders Elowsson (@anderselowsson), Francesco D'Amato (@fradamt), "EIP-8037: State Creation Gas Cost Increase [DRAFT]," Ethereum Improvement Proposals, no. 8037, October 2025. Available: https://eips.ethereum.org/EIPS/eip-8037.