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 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 120 GiB per year at a reference block gas limit of 150M 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 ~200 gas units per new byte created, new storage slots cost ~313 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 January 2026, the current database size in a Geth node dedicated to state is ~390 GiB. After the increase in gas limit from 30M to 60M gas units, the average size of new state created each day more than tripled, from ~105 MiB to ~326 MiB. This results in an annual growth of ~116 GiB.

The state-growth response we observe is not linear in the gas limit increase: a 2x bump (30M → 60M) produced a roughly 3x 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 200M gas limit, the state would grow at a rate of ~387 GiB per year. Starting from 390 GiB, this rate would breach the 650 GiB threshold (at which point nodes begin experiencing performance degradation) in less than a year.

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.

The REGULAR_PER_AUTH_BASE_COST is defined as the sum of:

• Calldata cost: 1,616 (101 bytes × 16)
• Recovering authority address (ecRecover): PRECOMPILE_ECRECOVER (is updated by EIP-7904)
• Reading nonce and code of authority (cold access): COLD_ACCOUNT_ACCESS (is updated by EIP-8038)
• Storing values in an already warm account: 2 x WARM_ACCESS

COLD_ACCOUNT_ACCESS, ACCOUNT_WRITE and CREATE_ACCESS are defined and updated in EIP-8038. The values are not yet final.

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 (ACCOUNT_WRITE + REGULAR_PER_AUTH_BASE_COST per authorization)
• Create transaction regular gas cost (CREATE_ACCESS if it is a create tx)

intrinsic_state_gas is the sum of:

• Authorizations state gas cost ((STATE_BYTES_PER_NEW_ACCOUNT + STATE_BYTES_PER_AUTH_BASE) x CPSB per authorization)
• Create transaction state gas (STATE_BYTES_PER_NEW_ACCOUNT x CPSB if it is a create tx)

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 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 right before the respective call frame. If the respective call frame reverts or halts exceptionally, the charged state-gas is refilled back to the state_gas_reservoir and execution_state_gas_used decreases by the same amount.

The same applies to top-level contract-creation transactions. If the transaction reverts or halts, the STATE_BYTES_PER_NEW_ACCOUNT × CPSB portion of intrinsic_state_gas is refilled back to state_gas_reservoir and execution_state_gas_used decreases by the same amount.

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

Gas refills for SELFDESTRUCT

SELFDESTRUCT for accounts created in the same transaction does not produce increases in state size as the account, its data and its storage is not included in the state trie. However, this operation does not produce any state-gas refills and there are no changes to execution_state_gas_used.

For an account that existed before the transaction, SELFDESTRUCT only transfers its balance and the account is not removed. Thus, no state-gas refill 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.

The same rules apply when the top-level call frame reverts or halts. Here, state_gas_reservoir, execution_state_gas_used, and execution_regular_gas_used are updated as if the frame were a child of the transaction boundary. In particular, for address collisions in contract-creation transactions, gas_left is consumed in full, execution_regular_gas_used is incremented by the initial gas_left, and the new-account portion of intrinsic_state_gas is refunded per the rule above.

Gas accounting for EIP-7702 authorizations

While computing the intrinsic gas cost, EIP-7702 authorizations are charged the worst-case cost for each delegation. Then, during authorization processing, the following gas adjustments are made for each processed authorization:

• If the authority’s account leaf already exists (i.e., non-zero nonce, non-zero balance, or non-empty code), the STATE_BYTES_PER_NEW_ACCOUNT × CPSB portion is refilled directly to state_gas_reservoir and the ACCOUNT_WRITE portion is refunded to the refund counter.
• If the authority’s codeHash is not emptyHash (i.e., a prior authorization indicator already occupies the 23 bytes) or authorization.address is ZERO (the authorization is clearing the delegation), the STATE_BYTES_PER_AUTH_BASE × CPSB portion is also refilled directly to state_gas_reservoir.

execution_state_gas_used decreases by the corresponding amount of state-gas refills.

Because execution_state_gas_used is initialized to 0, this refill may bring it below zero before any execution-time charges. Implementations may equivalently track the refill separately and subtract it from tx_state_gas when accumulating block_state_gas_used.

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

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: 120 GiB per year, i.e., 120 × 2^30 = 128,849,018,880 bytes.
• Reference block gas limit: 150M 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
                         = (150,000,000 / 2) × 2,628,000
                         = 75,000,000 × 2,628,000
                         = 1.971 × 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.971 × 10^14 / 128,849,018,880
     ≈ 1530 gas/byte

Why target 150M block limit?

The reference block gas limit of 150M is chosen as a middle ground between the current 60M and the expected future 300M. This allows us to set a CPSB that is not too high (which would cause a large immediate increase in state creation costs) nor too low (which would require a more aggressive increase in a future EIP when the block limit increases further).

With this target, we expect state growth will slow down significantly compared to the current trajectory and then increase again as we slowly increase the block gas limit.

Why target 120 GiB per year?

By targeting a state growth of 120 GiB per year with a 150M block limit, we achieve the following worst-case growth rate at different block limits:

These rates are computed assuming blocks are fully utilized with state creation operations, which is a worst-case scenario. Assuming a smooth increase in block limit from 100M to 300M over the next year, we would expect a worst-case average growth rate of around 160 GiB per year, which is a significant improvement over the current trajectory.

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., 64 bytes per slot, 120 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.

Deriving byte size for new slots and accounts

The byte sizes used in this proposal correspond to the on-disk footprint of a new account or storage slot, taking into account both the leaf data and the key under which it is stored.

A new account adds 120 bytes:

A new storage slot adds 64 bytes:

For EIP-7702 authorizations on an already-existing account, no new account leaf is created. The only new state written is the delegation indicator stored in the authority’s code field. As specified in EIP-7702, this indicator is the 3-byte magic prefix 0xef0100 concatenated with the 20-byte delegate address, for a total of 23 bytes:

When the authorization targets a non-existent account, the full STATE_BYTES_PER_NEW_ACCOUNT is charged in addition to STATE_BYTES_PER_AUTH_BASE, since both a new account leaf and the delegation indicator are written.

These figures account only for the leaf payload and its keccak256 key. They do not include the additional trie overhead (intermediate nodes, encoding, etc.) incurred when the new entry is inserted. The values are therefore a lower bound on the actual state growth per operation.

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 = 1530, this proposal would limit the maximum contract size that can be deployed to roughly 7.5kB. 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 - 120 \times 1530}{1530} \approx 7{,}564$ 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-gas portion of state creation costs for common operations under the proposed CPSB of 1,530. Additional regular-gas charges (e.g., ACCOUNT_WRITE, STORAGE_WRITE, hash cost) defined in EIP-8038 apply on top.

The “Proposed cost (ETH)” column assumes a base fee of 0.08 Gwei, which corresponds to the average base fee observed after the 60M gas increase in December 2025 and January 2026.

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., 183,600 at the proposed CPSB), compared to transferring ETH to a fresh account (21,000 gas units). With this mismatch, users wishing to create a 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.