Ethereum Pauses Glamsterdam Test – Some Contracts at Risk
Ethereum core developers have postponed Glamsterdam’s October 26 Hoodi testnet activation to investigate how EIP-8037’s gas accounting interacts with smart contracts already running on mainnet.
Developers made the decision on All Core Devs Execution call #248, the Ethereum Foundation said in its October 22 announcement.
The last testnet step before mainnet is on hold
Glamsterdam was due to activate on Hoodi on October 26 at 17:42:48 UTC. The postponement removes both the Amsterdam execution-layer and Gloas consensus-layer activations, along with the schedule that would have raised Hoodi’s gas limit to 200 million at the same time. It changes the testnet’s future configuration without reverting its history, and no replacement date has been set.
In Fusaka, the previous upgrade, Hoodi was the third and final testnet to fork before mainnet, and the Foundation said mainnet would follow at least 30 days later, according to The Block. Glamsterdam has already passed a 200-million-gas rehearsal on Sepolia, where the fix was a Prysm update to validator defaults, a client configuration issue. This time the question is how contracts that are already deployed behave. The Foundation has not set a Glamsterdam mainnet date and says mainnet users and ETH holders do not need to act.
A storage price rise that cuts execution gas on some writes
EIP-8037 exists to slow the growth of Ethereum’s state, the data every node must store. Its authors put that state at about 390 GiB in January 2026. They estimate that under today’s pricing, a 200-million gas limit could push it past 650 GiB, the level at which nodes start to slow down, in under a year. Their answer is to charge 1,530 gas per byte of new state, raising the state cost of a new storage slot from 20,000 gas to 97,920 and of a new account from 25,000 to 183,600.
To keep large contract deployments possible, the proposal splits gas into two pools. Execution gas covers computation, and state gas covers new storage. Any gas a transaction supplies above 16,777,216 goes into a separate state-gas reservoir, which state charges draw on first. That reservoir is passed in full to every sub-call, and contracts cannot see it through the standard gasleft() reading.
Cold write to a new storage slot, execution gas required
Today: 22,100
Glamsterdam, reservoir pays the 97,920 state charge: 12,100
Glamsterdam, reservoir empty: 110,020
Source: ChainSecurity, using EIP-8037 and EIP-8038 figures.
Gas can also flow back during execution. Clearing a slot created earlier in the same transaction immediately refills up to 97,920 gas, and a sub-call that reverts can hand back the state charges it paid. A contract’s visible gas balance can therefore rise mid-execution. The EIP itself warns that contracts measuring work as the difference between two gas readings can get a negative result, and that contracts already deployed with that design cannot be fixed.
How an attacker could use the new rules
Security firm ChainSecurity set out the risk in an October 13 analysis. Contracts often catch a failed call and record the result, which lets a malicious caller deliberately supply too little gas so that a valid operation fails while the contract still has enough gas to save that failure. The technique is known as insufficient gas griefing, and it can permanently block a retry or remove a user’s claim.
For contracts that rely on the failure handler itself running out of gas:
STEP 1
Attacker sends a call with too little gas.
STEP 2
The target operation runs out of gas.
TODAY
The handler runs out too, everything reverts and the user can retry.
GLAMSTERDAM
Reservoir or refilled gas lets the handler finish and save the failure permanently.
Contracts that check remaining gas after a failed call can be fooled when refills or a reverting intermediary push the balance back above their threshold. Fixed gas budgets can also fall short, because EIP-8038 raises the cost of touching existing state: the first change to an existing warm slot rises from 2,900 gas to 10,100.
Not every defence breaks. ChainSecurity says a check made before the call still guarantees delivery of the requested gas, as long as the budget covers every execution path under the new prices without counting on the reservoir. It advises against relying on post-call gas checks at all. The Foundation’s notice names only EIP-8037 and does not cite the firm’s work, which also covers EIP-8038.
What operators and developers need to do
Hoodi operators must update execution and consensus clients before October 26, using releases whose notes explicitly confirm that the old activation has been removed. Version tables from the original announcement do not count as confirmation. As of October 23, the Foundation had listed updated releases for two clients, and said others would be added as they are confirmed.
| Layer | Client | Release |
|---|---|---|
| Execution | Besu | 26.10.1 |
| Consensus | Lodestar | v1.50.1 |
Validators must update both the beacon node and the validator client, and anyone running external block-building infrastructure should follow their provider’s instructions. Application teams should stop planning Hoodi tests around that date.
For contract developers, ChainSecurity’s checklist starts with every call that lets execution continue after failure. It covers tracing the full path, including proxies; finding slots set and cleared in the same transaction, and intermediaries that revert; re-checking fixed budgets; and forcing sub-calls to fail and comparing the outcome under both rule sets. Where possible, a failed call should revert the whole operation. Wallets and node software must also update gas estimation for the two-pool model, according to the EIP.
The next decisions sit with the core developers. EIP-8037’s Last Call review closes on November 1, the investigation may lead to specification changes, and a revised Hoodi date will be set on a future call.
This article is provided for informational purposes only and does not constitute financial or investment advice. Ethereum upgrade schedules and technical specifications may change during testing.
Kosta has reported on cryptocurrency markets and blockchain infrastructure since 2020, bringing over six years of hands-on experience in the crypto industry built through daily tracking of markets, trends, and emerging blockchain developments. Specializing in Bitcoin on-chain analysis, institutional ETF flows, and digital asset price action, his work at Coindoo has been cited by other news agencies and consistently covers market developments with a focus on data-driven reporting across Bitcoin, Ethereum, Solana, and XRP. Over the years, Kosta has contributed to multiple crypto media outlets in different regions, authoring over 6,000 articles across the sector. His reporting spans cryptocurrency markets and the broader fintech industry, tracking not only price action but also the technological and regulatory forces shaping the ecosystem. To support his analysis, Kosta actively leverages on-chain data and metrics from leading platforms such as Santiment, Glassnode, and CryptoQuant, enabling deeper, evidence-based market insights. He believes in the power of transparency and the data that underpins the blockchain ecosystem. His academic background in Marketing Management from Denmark further complements his analytical approach, adding a strong understanding of communication strategy and content positioning to his work.
