Glamsterdam gas changes may break millions of Ethereum contracts

The Ethereum Foundation has proposed a repricing schedule called Glamsterdam that realigns gas charges to match the resources operations consume and to create headroom for higher block gas limits. Two candidate changes, EIP-8037 and EIP-8038, would raise the cost of creating and accessing persistent state. Replays of 929,731,274 historical transactions indicate the repricing could break or require fixes for millions of smart contracts and wallets.

EIP-8037 focuses on state creation and adds a common charge of 1,530 gas per byte of new state plus a separate state-specific gas dimension. EIP-8038 raises selected costs for accessing and writing existing state. Both proposals are in Review status and are being tested on stable devnets, followed by the Sepolia and Hoodi testnets. The Ethereum roadmap targets a mainnet upgrade in the fourth quarter of 2026, with dates to be finalized after testing.

The repricing responds to recent state growth. The Geth state database measured about 390 GiB in January 2026. After the network gas limit rose from 30 million to 60 million, average daily new state grew from about 105 MiB to 326 MiB, an annualized pace near 116 GiB. The EIP-8037 analysis scales that response to a 200 million gas-limit scenario and estimates a possible 387 GiB of annual growth, which the proposal says could cross a cited 650 GiB threshold. At a 150 million block limit the proposal’s parameters aim for roughly 120 GiB of annual growth.

Candidate charge examples from client benchmarks include creating a new account rising from 25,000 gas to about 183,600 gas; creating a new storage slot from 20,000 to about 97,920 gas; and deploying 24 KiB of code plus a new account from about 4.95 million to nearly 37.78 million gas. At the transaction level, users would pay both execution gas and separate state gas.

Researchers replayed 929,731,274 transactions across 4 million blocks dated Dec. 3, 2024, through June 15, 2026. Each transaction was replayed against its canonical pre-transaction state under the current schedule and under each candidate schedule. Replays used the transaction’s original gas limit, then allowed ceilings up to 10 times that limit. Under EIP-8037, 174,473,898 replays failed at the original limit but succeeded with more gas; 2,687,652 fell into a “potentially broken” category that a 10x ceiling did not rescue. Under EIP-8038, 84,708,228 were fixable with higher limits and 3,036,537 were potentially broken. The report defines “potentially broken” as transactions that succeeded before repricing but failed under the candidate schedule even with much higher submitted limits.

Many of the fixable failures can be addressed by frontends, bundlers and infrastructure providers increasing submitted gas limits, improving simulation, and updating gas estimation. The hard-to-fix failures arise from assumptions that more top-level gas cannot repair: hardcoded 2,300-gas stipends, fixed gas forwarded to internal calls, contract logic that branches on gasleft(), and presigned transactions with fixed limits. Immutable contracts are the most expensive to remediate; durable fixes could require new EntryPoint contracts, account factories, validator implementations and user migrations.

The public outreach materials say wallets, RPC providers, indexers, node tooling and gas estimators must incorporate the new rules. Bundlers and account-abstraction stacks, including ERC-4337 EntryPoint implementations and commercial stacks such as ZeroDev and Alchemy, need to distinguish failures resolvable by better simulation and higher limits from those that require protocol changes or migration. A plain ETH transfer to an existing account remains 21,000 gas; a transfer that creates an account at runtime would incur the new state-creation charge.

Activation of the proposals would create capacity headroom for larger block gas limits but would not instantly triple mainnet throughput. Builders that rely on current gas assumptions have a testing window to resimulate transactions, audit fixed stipends and internal call limits, and test affected paths against the candidate schedule before parameters and deployment dates are finalized.