The Ethereum Foundation has asked smart contract teams and auditors to check their code against eight gas-related assumptions that the planned Glamsterdam upgrade would break, after security firm ChainSecurity found live projects that could become vulnerable. Core developers have put the hard fork process on hold and will not fork the Hoodi testnet until the issues are resolved. The two proposals behind the problem, EIP-8037 and EIP-8038, could still be changed.
What the Ethereum Foundation asked for
In a blog post dated November 6, Ethereum Foundation developer Marius van der Wijden wrote that ChainSecurity had found “a few projects that would be vulnerable after Glamsterdam since they rely on certain invariants.” The All Core Developers group decided to delay the hard fork process as a result.
The foundation said it is working with ChainSecurity and Dedaub and running internal audits, but cannot review every project on Ethereum, including off-chain code. It published a GitHub repository listing the eight invariants, with examples and prompts teams can use to check their own contracts. Affected projects are asked to report privately to glamsterdam@ethereum.org rather than open public issues, so fixes can land before the problems are widely known.
Why gas accounting is the sticking point
EIP-8037 changes how Ethereum charges for creating new state, such as fresh storage slots, new accounts and contract code. It adds a separate “state gas reservoir” that only exists when a transaction’s gas limit exceeds 16,777,216. EIP-8038 reprices access to existing state. The aim is to price database growth closer to the load it puts on nodes as gas limits rise.
The repository’s own measurements show how large the jumps are. A cold write to a new storage slot costs 22,100 gas today but 110,020 under the Amsterdam spec, of which 97,920 is state gas. Sending value to an empty address rises from 25,000 gas to 183,600 in state gas plus execution. Code deposit goes from 200 gas per byte to 1,530.
Many contracts quietly depend on the old numbers. ChainSecurity’s analysis, based on the specs it reviewed on October 13, describes contracts that catch a failed external call and then record the failure. Developers often count on the leftover gas being too small for that step, so the transaction reverts and can be retried. Under Glamsterdam, gas used for state creation in a reverted call can come back to the caller, and the reservoir can pay for new storage writes. A failure path that used to revert can now complete, turning a retryable operation into a permanent one.
The eight invariants, in plain terms
The foundation splits the list into price changes and accounting changes. The price-related ones include fixed gas amounts hard-coded into contracts, signed messages, bots or relayers (INV-4), and gas reserves or stipends sized for today’s costs (INV-7). The 2,300-gas stipend used by Solidity’s transfer and send, for example, cannot create a storage slot under the new prices. The repository says most findings so far involve INV-4 and INV-7, and recommends checking those first.
The accounting-related ones are subtler. Gas left during a call can now go up, so code that bills users by subtracting two gasleft() readings may charge the wrong amount (INV-5). Locks set and cleared to zero inside one transaction release their state gas immediately (INV-2). And for EIP-7702 smart accounts, a delegation that runs out of gas is rolled back while its transaction is still mined, which means anyone can reuse the signed delegation (INV-8). EIP-7702 delegation was part of the attack path Binance described in its report on last month’s $6.34 billion theft.
How the delay unfolded
Glamsterdam activated on the Sepolia testnet on October 6. The Hoodi fork, which was also set to lift that testnet’s gas limit to 200 million, was due on October 26 but was called off at the October 22 execution-layer call, CoinDesk reported at the time. No new Hoodi date has been set, and there is still no confirmed mainnet date.
The November 6 post moves the issue from a developer-call decision to a public request for help. The repository says the team scanned contracts verified on Sourcify, and that off-chain components such as receipt parsers can also be affected. ChainSecurity said on LinkedIn that it had identified 13 real-world examples and was coordinating disclosure with the affected projects. Neither the foundation nor ChainSecurity has named those projects, and there is no sign that anything on mainnet is exploitable today, since the new rules are not live.
What to watch next
The foundation wants enough feedback to support “a well-founded discussion” at the next All Core Developers call, and the repository says “depending on the response we might decide to slightly change EIP-8037/8038 or not.” That leaves three broad outcomes: tweak the two EIPs, ship them as written and lean on projects to patch, or split them from the fork. For teams running contracts with hard-coded gas limits, relayers or EIP-7702 wallets, the practical step is the same in every case: check the code against the list now.
FAQ
Is Glamsterdam cancelled?
No. Developers have paused the hard fork process and will not fork the Hoodi testnet until the gas issues are resolved. Work on the following upgrade, Hegota, continues in parallel. No new Hoodi or mainnet date has been announced.
Are funds on Ethereum at risk right now?
The issues only apply once EIP-8037 and EIP-8038 are active, and they are not live on mainnet. The concern is that some existing contracts would behave differently after the upgrade, which is why the foundation wants them checked first.
Who should check their code?
Teams with hard-coded gas limits, fixed gas reserves, contracts that record failed calls, relayers that sign gas amounts, and wallets using EIP-7702 delegation. The foundation’s repository explains each invariant and asks affected projects to email glamsterdam@ethereum.org.
Disclaimer: This article is for informational purposes only and does not constitute financial advice.
