EIP-8037: State Creation Gas Cost Increase

Harmonization and increase 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 sets a unit cost per new state byte that targets an average state growth of 60 GiB per year at a block gas limit of 300M gas units and an average gas utilization for state growth of 30%. Contract deployments get a 10x cost increase while new accounts get a 8.5x increase. To avoid limiting the maximum contract size that can be deployed, it also introduces an independent metering for code deposit costs.

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.

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

Parameter changes

Upon activation of this EIP, the following parameters of the gas model are updated:

In addition, GAS_SELF_DESTRUCT_NEW_ACCOUNT is removed and replaced by GAS_NEW_ACCOUNT

Multidimensional metering for code deposit gas

Besides the parameter changes, this proposal introduces an independent metering for the code deposit costs. The specification is derived from EIP-8011. However, it only requires two dimensions, namely, gas and code_deposit_gas.

Contract deployment cost calculation

This proposal clarifies how gas is charged during contract deployment, ensuring that post-execution costs (account creation, hashing, code deposit) are only charged when the deployment succeeds.

Success vs Failure Gas Accounting

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 (212,800 gas)
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):
   • If the target account is new, charge GAS_NEW_ACCOUNT (212,800 gas)
   • 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_NEW_ACCOUNT, 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

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. This cost targets an average growth of 60 GiB per year at a block gas limit of 300M gas units and an average gas utilization for state growth of 30%. A recent empirical analysis has shown that, at current gas prices, state creation accounts for approximately 30% of all gas consumed. ** Additionally, on average, blocks use half of the entire available gas in the block. Thus, we are setting the unit gas cost of state creation based on the average case. Finally, we are targeting a 300M block limit to account for scaling optimizations expected in the short to medium term.

This capacity corresponds to an average of $\frac{60 \times 1024^3}{365} = 176,505,505$ bytes per day. With a 300M gas limit, Ethereum will process $150M \times 7,200 = 1,080,000M$ gas units per day, at block target. With a 30% consumption dedicated to state creation, the total gas units per day for state creation are $1,080,000M \times 0.3 = 324,000M$. Thus, the cost per byte is $\frac{324,000M}{176,505,505}=~1,835$. To provide a further buffer and simplify calculations, we round this number and set cost_per_state_byte to 1900.

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):

• GAS_CREATE = 112 x cost_per_state_byte= 212,800
• GAS_CODE_DEPOSIT = cost_per_state_byte = 1,900
• GAS_STORAGE_SET = 32 x cost_per_state_byte = 60,800
• GAS_NEW_ACCOUNT = 112 x cost_per_state_byte= 212,800
• GAS_SELF_DESTRUCT_NEW_ACCOUNT = 112 x cost_per_state_byte = 212,800
• PER_EMPTY_ACCOUNT_COST = 112 x cost_per_state_byte = 212,800
• PER_AUTH_BASE_COST = 23 x cost_per_state_byte = 43,700

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

Multidimensional metering

EIP-7825 introduces a limit of 16.7M gas units for a single transaction. With the proposed contract creation costs, this cap would limit the maximum contract size that can be deployed to roughly 6kb ($\frac{16,777,216 - 21,000 - 5,000,000 - 212,800}{1,900} = 6,075$). The limit by transaction was set in place to mitigate DoS attacks that result in uneven load distribution. This is not a concern for contract deployments, specially after the proposed 10x increase in costs.

An independent metering of the code deposit costs allows to lift this limit for contract creation transactions, while ensuring that users still pay the fair costs of contract deployment.

This proposal is consistent with the multidimensional gas metering introduced in EIP-8011. However, it only requires two dimensions, namely, gas and code_deposit_gas. If EIP-8011 is not implemented, a two-dimensional version of EIP-8011 is still required.

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

Users and dApp developers will experience an increase in transaction costs associated with creating a new state. Assuming an ETH price of 4000 USD, here is a comparison for some operations:

New account:

• OLD: 0.5 Gwei x 25,000 x 4,000 USD = 0.05 USD
• NEW: 0.5 Gwei x 212,800 x 4,000 USD = 0.425 USD

New slot:

• OLD: 0.5 Gwei x 20,000 x 4,000 USD = 0.04 USD
• NEW: 0.5 Gwei x 60,800 x 4,000 USD = 0.122 USD

24kB contract deployment (new account):

• OLD: 0.5 Gwei x (32,000 + 200 × 24,576) x 4,000 USD = 9.894 USD
• NEW: 0.5 Gwei x (212,800 + 4,608 + 1,900 × 24,576) x 4,000 USD = 93.824 USD

Note: The NEW calculation includes GAS_CREATE (212,800), HASH_COST (6 × 768 = 4,608 for 24,576 bytes), and GAS_CODE_DEPOSIT (1,900 × 24,576). We ignore transaction intrinsic costs (21k gas units), call data costs, and the costs of additional opcodes and scaffolding needed to execute such transactions.

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 (212,800 gas units), 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 PER_EMPTY_ACCOUNT_COST of 212,800 gas units.

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

Independent metering for code deposit costs

Contract creation now introduces a cost that is not accounted for in the traditional gas metering and thus doesn’t contribute to the block gas limit or the individual transaction limit. This could potentially be exploited by an attacker to create very large contracts that would stress the network. More benchmarking and analysis is needed to understand the potential risks and to determine if additional mitigations are necessary.

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), "EIP-8037: State Creation Gas Cost Increase [DRAFT]," Ethereum Improvement Proposals, no. 8037, October 2025. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-8037.