Glamsterdam upgrade: 174M fixable transactions, 2.7M potentially broken
In brief
- Glamsterdam upgrade aims to triple Ethereum base throughput via gas repricing mechanisms
- 174M transactions fixable with higher gas limits; 2.7M require code changes or migration
- EIP-8037 and EIP-8038 repricing schemes analyzed across 929M transactions, 4M blocks
- Developers gain visibility into affected transactions; preparation timelines remain uncertain
What Glamsterdam repricing entails
The Ethereum Foundation's Glamsterdam upgrade is designed to align gas charges with network resources more precisely. Two core proposals, EIP-8037 and EIP-8038, retain formal Review status ahead of the upgrade.
EIP-8037 proposes a common cost of 1,530 gas for every byte of new state and a separate state-gas dimension. At a reference block limit of 150 million, that parameter targets average growth of 120 GiB a year. EIP-8038 tackles access to and writes of existing state, raising selected account and storage costs from client benchmarks.
The repricing reflects a real problem. After Ethereum's gas limit rose from 30 million to 60 million, average new state created each day increased from roughly 105 MiB to 326 MiB. The state portion of a Geth database was about 390 GiB in January 2026, and unchecked growth threatens node operator economics.
The transaction impact split
Researchers replayed 929.7 million transactions across 4 million blocks from December 2024 through June 2026 to model the repricing impact. The results reveal a stark divide.
Under EIP-8037, 174.5 million transaction replays failed at their original limit but succeeded with more gas, while 2.7 million entered the potentially broken group. Under EIP-8038, 84.7 million transactions were fixable with a higher limit, and 3 million were potentially broken.
The potentially broken group includes out-of-gas cases and transactions that reverted for another reason after the new costs changed execution behavior. These require code changes or migration, not just higher limits.
The much larger fixable cohort chiefly shifts work to frontends, bundlers and infrastructure providers, which must submit limits that reflect the new schedule. This is an operational burden—tooling changes, testing, and redeployment—but not a structural break.
Visibility and uncertainty
Developers and infrastructure operators now have visibility into which transactions will be affected. Repeated activity from a busy application can dominate the transaction count, so the figures do not describe millions of separate contracts at risk. Whether sufficient time and tooling exist to prepare the bulk of the ecosystem remains uncertain. Fixed Sepolia, Hoodi, and mainnet fork dates have not yet been announced.
