EIP-8037: State Creation Gas Cost Increase

Abstract

This proposal increases the cost of state creation operations, thus avoiding excessive state growth under increased block gas limits. It dynamically sets the unit cost per new state byte at a given block gas limit, by targeting an average state growth of 100 GiB per year based on current network usage. 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 relationship we are seeing in this example is not linear as expected. This is likely due to other factors impacting user behavior. However, all else being equal, we expect a proportional increase in the number of new states created as gas limits increase. At a 60M gas limit (and a proportional increase in new state per day of 1.7x), 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. This level of state growth would give us less than 2.5 years until the size of the state database exceeds the threshold of 650 GiB, at which point nodes will begin experiencing a degradation in performance.

Specification

New parameters

Besides these fixed parameters, this EIP introduces a dynamic variable that controls the cost per byte of state created for a given block gas limit. The variable is cost_per_state_byte and is calculated as follows:

raw = ceil((gas_limit * 2_628_000) / (2 * TARGET_STATE_GROWTH_PER_YEAR))
shifted = raw + CPSB_OFFSET
shift = max(bit_length(shifted) - CPSB_SIGNIFICANT_BITS, 0)
cost_per_state_byte = max(((shifted >> shift) << shift) - CPSB_OFFSET, 1)

The raw value is the unquantized cost derived from targeting TARGET_STATE_GROWTH_PER_YEAR at 50% average gas utilization (see Deriving the cost per byte). Quantization retains the top CPSB_SIGNIFICANT_BITS significant bits after applying CPSB_OFFSET, producing a stepped function that avoids frequent small changes as the gas limit fluctuates (see Quantization).

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.

Where cpsb = cost_per_state_byte. The values assigned to regular gas will be updated based on EIP-8038.

<-TODO->

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,500

In addition, GAS_SELF_DESTRUCT_NEW_ACCOUNT is removed and replaced by GAS_NEW_ACCOUNT.

Multidimensional metering for state creation costs

Besides the parameter changes, this proposal introduces an independent metering for state creation costs. The specification is derived from EIP-8011. However, it only requires two dimensions, namely, 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 also 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, which now corresponds to the maximum gas that can be metered in the bottleneck resource.

Transaction validation

Before transaction execution, calculate_intrinsic_cost returns three values: intrinsic_regular_gas, intrinsic_state_gas, and calldata_floor_gas_cost. State gas components of intrinsic cost (e.g., account creation for contract deployment transactions, EIP-2780 charges, EIP-7702 authorization charges) are included in intrinsic_state_gas. All other intrinsic costs (base transaction cost, calldata, access lists, authorization base costs) are included in intrinsic_regular_gas.

validate_transaction rejects transactions where:

max(intrinsic_regular_gas, calldata_floor_gas_cost) > TX_MAX_GAS_LIMIT

validate_transaction also returns intrinsic_regular_gas, intrinsic_state_gas, and calldata_floor_gas_cost.

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

The state_gas_reservoir holds gas that exceeds the EIP-7825's budget. The two counters operate as follows:

• Regular gas charges deduct from gas_left only.
• State gas charges deduct from state_gas_reservoir first; when the reservoir is exhausted, from gas_left.
• The GAS opcode returns gas_left only (excluding the reservoir).
• The reservoir is passed in full to child frames (no 63/64 rule). Unused reservoir is returned to the parent on child completion.
• On exceptional halt, both gas_left and state_gas_reservoir are set to zero (all gas consumed), consistent with existing EVM out-of-gas semantics. This is not applied to system transactions.

The two counters are returned by the transaction output. Besides the two counters, the EVM also keeps track of execution_state_gas_used and execution_regular_gas_used during transaction execution. state_gas costs are added to execution_state_gas_used while regular_gas costs are added to execution_regular_gas_used. These two counters are also returned by the transaction output.

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 // 5, tx_output.refund_counter)
tx_gas_used_after_refund = tx_gas_used - 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

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

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

SSTORE refund for slot restoration

When a storage slot is set to a non-zero value and then restored to zero within the same transaction (0→X→0 pattern), the following are refunded via refund_counter:

• State gas: 32 × cost_per_state_byte (the state creation charge)
• Regular gas: GAS_STORAGE_UPDATE - GAS_COLD_SLOAD - GAS_WARM_ACCESS (2,800)

The net cost after refund is GAS_WARM_ACCESS (100), consistent with pre-EIP-8037 SSTORE restoration behavior. Refunds use refund_counter rather than direct gas accounting decrements, so that reverted frames do not benefit from the refund.

Revert behavior for state gas

State gas charged for account creation (CREATE, CALL to new account, and EOA delegation) is consumed even if the frame reverts — state changes are rolled back but gas is not refunded. This is consistent with pre-EIP-8037 behavior where GAS_NEW_ACCOUNT was consumed on revert.

EIP-2780 authorizations

For EIP-7702 authorizations, the intrinsic state gas assumes account creation for each authorization: (112 + 23) × cost_per_state_byte per authorization. When an authorization targets an existing account (no account creation needed), the 112 × cost_per_state_byte portion is subtracted from intrinsic_state_gas during authorization processing, before state changes begin.

Receipt semantics

Receipt cumulative_gas_used tracks the cumulative sum of tx_gas_used_after_refund (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.

Contract deployment cost calculation

When a contract creation transaction or opcode (CREATE/CREATE2) is executed, gas is charged differently based on whether the deployment succeeds or fails. Given bytecode B (length L) returned by initcode and H = keccak256(B):

1. When opcode execution starts: Always charge GAS_CREATE
2. During initcode execution: Charge the actual gas consumed by the initcode execution
3. Success path (no error, not reverted, and L ≤ MAX_CODE_SIZE):
   • Charge GAS_CODE_DEPOSIT * L and persist B under H, then link codeHash to H
   • Charge HASH_COST(L) where HASH_COST(L) = 6 × ceil(L / 32) to compute H
4. Failure paths (REVERT, OOG/invalid during initcode, OOG during code deposit, or L > MAX_CODE_SIZE):
   • Do NOT charge GAS_CODE_DEPOSIT * L or HASH_COST(L)
   • No code is stored; no codeHash is linked to the account
   • The account remains unchanged or non-existent

Important: The gas for code deposit (GAS_CODE_DEPOSIT * L) is checked before hash computation. This means that if a deployment runs out of gas, it will fail during the deposit gas check before the hash is computed. This maintains consistency with post-Homestead behavior where any deployment failure (including OOG) reverts all state changes - no account is created, and no gas is charged beyond GAS_CREATE and the actual initcode execution cost consumed.

Total gas formulas:

SUCCESS_PATH_TOTAL_GAS =
    GAS_CREATE
  + initcode_execution_cost
  + (GAS_NEW_ACCOUNT if account is new else 0)
  + GAS_CODE_DEPOSIT * L
  + HASH_COST(L)

FAILURE_PATH_TOTAL_GAS =
    GAS_CREATE
  + initcode_execution_cost

CREATE vs CREATE2

CREATE2 already charges for hashing the init code when deriving the address. That cost remains unchanged. The bytecode hash (keccak256(B)) must be computed on success to store the code, incurring HASH_COST(L) as specified above.

Rationale

Deriving the cost per byte

The variable cost_per_state_byte is a dynamic parameter that depends on the block gas limit. The idea is to have a cost that scales as the block gas limit increases, thus avoiding excessive state growth. To compute this variable, we target a specific state growth per year, which we set to 100 GiB. Then, we assume this growth rate is achieved at an average gas utilization.

With multidimensional metering, blocks can be filled up to 50% of the target for both regular gas and state gas. Thus, we consider that on average, blocks can use half of the entire available gas in the block for state creation. This leads to a total of (gas_limit/2) * 7200 * 365 gas units used for state creation in a year. Dividing this by the target state growth per year gives us the cost per byte of state created.

Quantization of cost_per_state_byte

Without quantization, cost_per_state_byte changes by 1 for every ~81,715 change in gas limit, which is 0.13% of the current block gas limit of 60M gas units. This creates unnecessary churn for tooling and gas estimation, since the cost can change almost every block even when the gas limit is relatively stable.

The quantization scheme retains the top 5 significant bits of (raw + CPSB_OFFSET), zeroes the remaining bits, then subtracts CPSB_OFFSET. This is equivalent to binary floating-point rounding: each power-of-2 band has exactly 16 distinct levels, and the step size doubles at each band boundary while remaining perfectly uniform within a band.

The offset (CPSB_OFFSET = 9578) shifts quantization boundaries away from common gas limit targets. It was chosen by brute-force search over 0–10000 to maximize the minimum distance from any quantization boundary to gas limits from 100M to 1000M (in 50M increments). This prevents cost_per_state_byte from flipping between adjacent values due to small gas limit fluctuations near popular targets. The following table shows the resulting boundary distances:

The worst-case minimum distance is 0.89% of the gas limit (at 350M and 800M). Since the gas limit can deviate from its parent by at most 1/1024, cost_per_state_byte remains stable for at least ~9 consecutive blocks of same-direction gas limit changes at any gas limit in the 100M–1000M range (in 50M increments).

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, cost_per_state_byte, as explained above. This is a dynamic parameter that depends on the block gas limit. 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

This proposal is consistent with EIP-8011. However, it only requires two dimensions, namely, regular_gas and state_gas. If EIP-8011 is not implemented, a two-dimensional version of EIP-8011 is still required.

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 a block limit of 100M gas units, this proposal would limit the maximum contract size that can be deployed to roughly 9.9kB ($\frac{16,777,216 - 21,000 - 5,000,000 - 112 \times 1174}{1174} = 9'902$). This maximum size would only decrease as we increase the gas limit and the cost_per_state_byte.

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 calldata cost rules. Specifically:

• Wallets: Wallets using eth_estimateGas MUST be updated to ensure that they correctly account for the updated gas parameters. Failure to do so could result in underestimating gas, leading to failed transactions.
• Node Software: RPC methods such as eth_estimateGas MUST incorporate the updated formula for gas calculation with the new floor cost values.

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

Estimated price impacts at various block gas limits

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 at different block gas limits.

We should note that as the block limit increases, the base fee is expected to reduce due to the higher capacity of the network. This reduction in base fee will offset, in part, the costs from state creation operations. Some analysis is needed to quantify this effect.

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 (112 × cost_per_state_byte 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.

Testing requirements for increasing block limits

With a dynamic cost per byte, every time the block gas limit is increased, clients and testing frameworks need to test for backward compatibility issues. This changes the testing framework for increasing the block limit. A way to mitigate this is to introduce a max cost per byte and do the analysis once on the impact of this max cost.

Copyright

Copyright and related rights waived via CC0.

Citation

Please cite this document as: