Ethereum’s next upgrade, Glamsterdam, is stuck, and the main reason is EIP-8037. In a blog post by Marius van der Wijden published on November 6, 2026, the Ethereum Foundation explained that the new gas accounting in EIP-8037 and EIP-8038 breaks eight assumptions that existing smart contracts rely on. During testing, the audit firm ChainSecurity has already found projects that would be vulnerable after Glamsterdam. Core developers have therefore decided not to fork the Hoodi testnet until the issues are resolved. At the same time, the Foundation is calling on developers and auditors to check their own code.
ETH holders do not need to do anything, and there is no mainnet date for Glamsterdam anyway. For teams running contracts, bots, relayers or wallets, however, the call to action is very concrete.
What EIP-8037 and EIP-8038 change
Both proposals target a scaling problem: the growth of Ethereum’s state, meaning all the balances, contract code and storage slots every node has to keep. EIP-8037 puts numbers on it. In January 2026, the state in a Geth node took up about 390 GiB. After the gas limit rose from 30 to 60 million, the amount of new state created each day more than tripled, from about 105 MiB to about 326 MiB, or roughly 116 GiB per year. At a gas limit of 200 million, the EIP projects about 387 GiB per year.
EIP-8037 therefore introduces a single price per newly created state byte, targeting average growth of 120 GiB per year at a reference gas limit of 150 million. It also adds separate metering: the cost of creating state (“state gas”) is tracked on its own and can be paid from a dedicated pool, the “reservoir”. EIP-8038 additionally raises the cost of accessing existing state, for example cold account access and writes.
How big the impact is shows in the table in the Foundation’s new invariants repository, measured on the pinned Amsterdam specification:
- SSTORE to a new storage slot (cold): 22,100 gas today, 110,020 gas in future, of which 97,920 is state gas.
- SSTORE to an existing slot: warm/cold 2,900/5,000 today, 10,100/12,100 gas in future.
- ETH transfer to an empty address (new account): 25,000 today, 183,600 state gas plus execution in future.
- CREATE/CREATE2 to an empty address: 32,000 today, 195,600 gas in future.
- Code deposit: 200 today, 1,530 gas per byte in future.
- EIP-7702 authorization for an empty account: 25,000 today, 235,606 gas in future.
The reservoir only exists when a transaction’s gas limit is above 224 (16,777,216). Below that, all state gas comes out of gasleft() as usual.
The eight broken assumptions
The repository splits the problems into two types: “price” invariants that any price change would break, and “accounting” invariants that follow from EIP-8037’s new way of tracking gas. In short:
- INV-1: Until now, running out of gas in a call made the whole transaction fail. With a reservoir, code after a failed call can still write storage and record the failure permanently.
- INV-2: Setting a storage slot from zero and clearing it in the same transaction returns its 97,920 state gas immediately, which matters for locks and flags around external calls.
- INV-3: A reverting call hands back the state gas it used, and a failed contract creation returns 183,600 gas. Code that infers the cause of failure from the remaining gas may get it wrong.
- INV-4: Hard-coded gas amounts are no longer enough. Creating state costs five to eight times more, and updating existing slots costs about 7,200 more gas per write.
- INV-5:
gasleft()can go up during a call. Billing based on the difference between twogasleft()readings becomes unreliable. - INV-6: At the new prices, the 1/64 of gas left after an out-of-gas call can be enough to record a failure.
- INV-7: Gas reserves and stipends sized for today are no longer enough; the 2,300 gas stipend of
transfer/sendcannot create a storage slot. - INV-8: An EIP-7702 delegation that runs out of gas is rolled back, but its transaction is still mined, so the signed delegation can be reused.
According to the repository, most findings so far involved INV-4 and INV-7, so teams should check those two first.
Why EIP-8037 is also a security issue
ChainSecurity already described the problem on October 13 under the title “When Spent Gas Comes Back”. The core point: many contracts catch failed external calls so they can record an error or move on to the next item. If an attacker deliberately supplies too little gas, a retryable operation can become a permanent failure (“insufficient gas griefing”). Existing protections rely on assumptions about how much gas is left after a failure. Glamsterdam shifts exactly that calculation, even when the contract code stays the same.
On-chain contracts are not the only concern. The repository explicitly notes that off-chain components can break too, for example through changes to transaction receipts, and it mentions bots, relayers and signed messages with hard-coded gas values. INV-8 is about wallets: instead of treating a mined transaction as proof that a 7702 delegation worked, wallets should check the account’s code after the transaction.
Timeline: Hoodi on hold, Hegota continues
Glamsterdam on Hoodi was originally scheduled for October 26, 2026 at 17:42:48 UTC (epoch 132,352). On October 22, the Foundation had already called off the activation after the ACDE #248 core developer call in order to investigate how EIP-8037 interacts with mainnet contracts. That also removed the plan to raise Hoodi’s gas limit to 200 million at the same time. No new date has been set.
The November 6 post adds detail: the Foundation has engaged the auditors ChainSecurity and Dedaub and is running internal audits, but cannot cover every project. Work on Hegota, the upgrade that follows Glamsterdam, continues in parallel “in full force”. Depending on the feedback, EIP-8037 and EIP-8038 might be changed slightly, or not at all. A decision is expected in one of the next All Core Devs calls.
What developers should do now
- Check code against the eight invariants, starting with INV-4 and INV-7. The repository provides explanations, examples and instructions for AI coding agents that search your code locally.
- Make hard-coded gas values adjustable in contracts, configuration, signed messages and bots, and re-estimate them under the new rules.
- Report findings privately: by email to glamsterdam@ethereum.org rather than in a public issue, so problems can be fixed before they become widely known.
For another example of how Ethereum handles long-term security questions, see EIP-8450 and its quantum-safe backup keys for validators. The case of the hijacked DeFi sites that sent visitors to a wallet drainer shows how quickly attackers exploit weaknesses around contracts and wallets. And the Blast layer-2 shutdown is a reminder that changes in the Ethereum ecosystem often hit applications first.
The delay is frustrating for anyone waiting for higher gas limits. But it is also a sign that the testnet process works: the problems are surfacing in testnet testing and audits, not on mainnet.
