# Ethereum developers delay Glamsterdam's Hoodi testnet fork after ChainSecurity finds gas changes break eight contract assumptions

The Ethereum Foundation has asked contract teams and auditors to check whether their code depends on gas behavior that EIP-8037 and EIP-8038 will change, and the fix may require a revised specification.

- Published: 2026-11-07T05:47:17.298Z
- Canonical: https://polylog.news/crypto/2026-11-07/ethereum-developers-delay-glamsterdam-s-hoodi-testnet-fork-a
- Publisher: Polylog (Crypto desk)
- Section: crypto
- Sources: [Ethereum Foundation Blog](https://blog.ethereum.org/2026/11/06/glamsterdam-8037-8038), [Cointelegraph](https://cointelegraph.com/news/ethereum-devs-fork-glamsterdam-hoodi-smart-contract-risks), [Blockonomi](https://blockonomi.com/ethereum-pauses-glamsterdam-hoodi-fork-over-eip-8037-and-eip-8038-gas-risks)

Ethereum core developers will not fork the Hoodi test network to Glamsterdam, the network's next upgrade, until they fix a compatibility problem that testing exposed. On November 6 the [Ethereum Foundation said](https://blog.ethereum.org/2026/11/06/glamsterdam-8037-8038) that the auditing firm ChainSecurity had found projects that would become vulnerable after Glamsterdam. Those projects rely on assumptions that must always hold true, known as invariants, which two Ethereum Improvement Proposals (EIPs), EIP-8037 and EIP-8038, will break. [Cointelegraph reported](https://cointelegraph.com/news/ethereum-devs-fork-glamsterdam-hoodi-smart-contract-risks) that developers will hold the Hoodi fork until the risks are resolved, and that the fix may need coordination between teams or changes to the specification.

Both proposals change the price of state. EIP-8037 raises the gas cost of creating new state, and EIP-8038 raises the cost of reading and writing existing state, [according to Blockonomi](https://blockonomi.com/ethereum-pauses-glamsterdam-hoodi-fork-over-eip-8037-and-eip-8038-gas-risks). The scaling roadmap depends on this kind of repricing. When state growth costs more, the network can raise its gas limit with less risk that the chain's database grows faster than node operators can store it. The side effect is that gas accounting stops behaving the way some deployed contracts expect. Reporting on ChainSecurity's October analysis says that gas already spent can now be refunded partway through a transaction. A contract that reads its remaining gas through the `gasleft()` function can therefore see that number go up during execution. Contracts that hard-code gas costs, or that make decisions based on how much gas is left after an external call fails, can then end up in states their authors never tested.

The Foundation published a repository, ethereum/glamsterdam-gas-invariants, that lists the eight broken invariants with examples and prompts to help teams check their own code. Reports disagree on how many live projects are exposed. Blockonomi cites 13 real-world cases. Other outlets cite only the eight invariants, and the figure of 13 may be the October 13 date of ChainSecurity's report. Teams should rely on the Foundation's repository, not secondary counts.

The exposure is concentrated on Ethereum's base layer. DeFiLlama data shows $43.38 billion of the $81.08 billion in total decentralized finance (DeFi) deposits on Ethereum. The layer-2 networks that settle there, led by Base at $14.05 billion in value secured according to L2Beat, will face the same question if they adopt the new gas schedule.

## What this means

The mechanism is a trade-off that Ethereum cannot avoid. Repricing state is the main tool for raising throughput safely, and every repricing changes gas rules that old contracts silently depend on. The parties exposed are protocols with gas-sensitive logic, such as meta-transaction forwarders, relayers, smart wallets and contracts that use fallback paths after failed calls, along with anyone pricing a fixed Glamsterdam date. The market reads this as a short delay. The real choice is whether to weaken the repricing, which slows scaling, or to ship it and push the migration work onto application teams. There are precedents for both. In January 2019, ChainSecurity found that EIP-1283 opened reentrancy attacks in Constantinople, and developers postponed that fork by about six weeks and removed the change. Later in 2019, Istanbul shipped the EIP-1884 repricing even though it broke some contracts. The likelier outcome is a narrow amendment to the specification that keeps most of the repricing but restores the invariant easiest to exploit, such as remaining gas never rising during execution. The Hoodi fork would then slip by weeks, and the mainnet date would move back by at least one test cycle. That read depends on ChainSecurity's cases including at least one with real funds at risk. It would be wrong if developers schedule the Hoodi fork with the specification unchanged at their next call.

## What to watch

- The next All Core Developers call, and whether it amends EIP-8037 and EIP-8038 or leaves them unchanged with a migration deadline for contract teams. An amendment would mean developers are prioritizing backward compatibility over faster scaling.
- Whether named protocols publish patches or ask users to migrate funds. Public fixes would show how much value sits in contracts that depend on the broken invariants.
- Whether layer-2 networks that copy Ethereum's gas rules say they will adopt the same repricing on the same schedule, which would extend the same exposure to their users.