EIP-8037

EIP-8037, titled “State Creation Gas Cost Increase,” is a proposed Ethereum core protocol change that would raise and standardize the gas costs of creating on-chain state while accounting for those costs separately from ordinary execution. Created on October 1, 2025, by Maria Silva, Carlos Perez, Jochem Brouwer, Ansgar Dietrichs, Łukasz Rozmej, Anders Elowsson, Francesco D’Amato, Dragan Rakita, Paweł Bylica, Spencer Taylor-Brown, and Gary Rong, it is intended to limit state growth as block gas limits rise while allowing greater transaction throughput and larger contract deployments. As of October 24, 2026, the EIP repository listed its status as “Last Call,” with a November 1, 2026, deadline, while the official specification said it was in the process of being peer-reviewed.^[1]​^[2]​^[3]​

Motivation

Ethereum charges for operations that add persistent state, but EIP-8037 describes the existing costs as inconsistent. Its proposal compares contract deployment, at about 200 gas per new byte, with the creation of a storage slot, at about 313 gas per new byte. It also notes that deploying bytecode already present in the database could cost the same as deploying new bytecode, despite clients not storing duplicate code. The proposal aims to price these operations according to the amount of state they add.^[1][2]

The proposal grounds its case in projected growth of Ethereum’s state database. It reports that a Geth node’s state database was about 390 GiB in January 2026. After the gas limit increased from 30 million to 60 million, average daily new state reportedly rose from about 105 MiB to 326 MiB, or roughly 116 GiB annually. The proposal characterizes the change as nonlinear and possibly associated with a one-time shift in user behavior. Extrapolating the post-increase rate to a 200-million gas limit, it estimates annual state growth of about 387 GiB; under that extrapolation, a state database starting at about 390 GiB would exceed 650 GiB in less than a year.^[1][4]

Design and Gas Accounting

EIP-8037 introduces a cost per state byte (CPSB), used to calculate charges for new state. The specification lists CPSB as 1,530 gas per byte, calibrated to target average state growth of 120 GiB per year at a reference block gas limit of 150 million gas. Its state-size parameters assign 64 bytes to a storage set, 120 bytes to a new account, and 23 bytes to an authorization base. It also sets a maximum of 16 system storage operations per call and a maximum total transaction gas limit of 4,294,967,295 (2³²−1).^[1][2]

The proposal’s design changed during development. An earlier draft calculated CPSB dynamically from the block gas limit, using a quantized formula intended to target 100 GiB of annual state growth. A revision merged on May 4, 2026, replaced that scheme with a fixed CPSB of 1,174, based on a 100-GiB annual target at a 96-million-gas reference limit. The EIP specification lists a different CPSB value and calibration, while retaining the general approach of assigning costs according to the amount of state created.^[5][6][1]

Under the specification’s proposed schedule, CREATE and CREATE2 charge state-gas for a new account and for each byte of deployed code; they also incur execution-gas costs, including a code-hashing charge. CALL and SELFDESTRUCT incur state-gas when they create a new account, while SSTORE charges state-gas for a new storage slot. EIP-7702 account delegation also separates state creation from execution costs: creating an empty account and recording an authorization base are priced in state-gas, while associated execution work remains in execution-gas. Several access and account-write costs are defined or updated by EIP-8038, whose values were not yet final in the proposal.^[1][4]

The central accounting change is to track execution-gas and state-gas as separate dimensions. Users pay for both, but the transaction gas limit introduced by EIP-7825 applies to execution-gas; state-gas is bounded separately by the transaction’s gas allowance. At block level, clients track cumulative use of each resource. The block’s gas_used is the greater of the two totals, and that bottleneck dimension determines whether the block is full and how the next block’s base fee is adjusted. The calldata gas floor under EIP-7623 applies to execution-gas, so state-gas cannot satisfy it.^[1][2]

The proposal uses a state-gas reservoir to support this separation within a transaction. State-creation charges draw on the reservoir before consuming the remaining execution gas, while ordinary operation costs use execution-gas. The proposal argues that separate metering would prevent the regular transaction gas cap from constraining large deployments in the same way as a single shared limit. It also acknowledges a trade-off: block builders would need to balance two resource dimensions, potentially favoring more sophisticated builders and increasing centralization pressure. Simpler strategies, such as filling blocks until one dimension is exhausted, are described as practical for many uses.^[1][4]

Compatibility and Security Considerations

EIP-8037 warns that the [GAS](https://iq.wiki/wiki/gas) opcode may report an increase in [gas](https://iq.wiki/wiki/gas)_left after some operations. A contract that estimates work by subtracting successive GAS readings could therefore calculate a negative difference, causing checked arithmetic to revert or unchecked arithmetic to wrap. The specification discusses a storage slot set from zero and then cleared in the same transaction: the state-gas refill can return gas to gas_left. Returning state-gas when a call frame merges can extend the effect across a call boundary.^[1][4]

The proposal also identifies a risk for ERC-4337 transaction bundles. Because GAS exposes gas_left but not the state-gas reservoir, bundlers and EntryPoint implementations cannot reliably attribute all state-gas costs from gasleft() differences alone. User operations in a bundle share the transaction reservoir, so one operation’s state-gas refunds may subsidize another’s charges without appearing in either operation’s measured gas difference. The proposal says bundlers and EntryPoint implementations must account explicitly for state-gas charges and refunds.^[1][4]

Proposal Status and Security

As of October 24, 2026, the EIP repository listed EIP-8037 as “Last Call,” with a November 1, 2026, deadline. The official specification said the EIP was in the process of being peer-reviewed.^[1][2]

On October 13, 2026, security firm ChainSecurity published an analysis of concerns involving EIP-8037 and EIP-8038. It warned of insufficient-gas griefing in contracts that use remaining gas to distinguish a genuine operation failure from an attempt supplied with too little gas and therefore eligible for retry. Under the proposed rules, a failed external call could return more gas to its caller than under the previous rules, potentially changing the result of existing checks. ChainSecurity said affected applications might treat a failed operation as final, delete a user’s claim, or prevent a retry; it identified bundled transactions and payouts as relevant cases. The firm reported finding 13 examples of the pattern in live contracts and said it was working confidentially with affected teams before public disclosure.^[7]

Testing and Deployment

EIP-8037 was included in the planned Glamsterdam upgrade. On October 6, 2026, Glamsterdam was activated on the Sepolia testnet with an increased gas limit. The upgrade also grouped EIP-8038 with EIP-8037 and included planned changes such as enshrined proposer-builder separation, which would move the separation of block proposers and block builders into the protocol, and block-level access lists, which identify data a block will access so clients can perform some work in parallel.^[7]

Ethereum developers had scheduled Glamsterdam’s Hoodi testnet activation for October 26, 2026, at 17:42:48 UTC, but cancelled it on October 22 after the ChainSecurity finding. The cancellation also removed planned activations of the Amsterdam execution-layer and Gloas consensus-layer upgrades, and withdrew a proposed increase of Hoodi’s gas limit to 200 million. The change affected future Hoodi configurations rather than blocks already recorded on the testnet; the Sepolia activation was unaffected. As of October 24, no replacement date had been set for Hoodi or mainnet. Developers had discussed December 1, 8, and 9, 2026, as possible mainnet dates, but none had been confirmed. The cancellation was intended to allow further investigation of how EIP-8037 and EIP-8038 would interact with contracts already live on mainnet; the mainnet continued to operate unchanged.^[7][8]

A separate execution-test-framework plan describes preparatory work for testing EIP-8037’s gas model. It calls for passing block-gas-limit context through gas-cost calculations, adjusting benchmarks for the state-gas model, and addressing static tests whose hardcoded gas limits were calibrated to earlier costs. The plan proposes testing at block gas limits of 30 million, 60 million, and 120 million, alongside test and continuous-integration changes; it is an implementation plan rather than evidence that all of those changes have landed.^[9]

EIP-8037 is also listed as an active Stateless Consensus protocol-change project. Its specification is released under CC0, waiving copyright and related rights.^[3][1][10]