Ethereum Delays Glamsterdam Hoodi Test Over Smart Contract Gas Risk

Ethereum core developers have postponed the Glamsterdam upgrade on the Hoodi testnet. It was due to activate on October 26 at 17:42:48 UTC, at epoch 132,352. The Ethereum Foundation's announcement says the upgrade "has been postponed. A new activation date has not been set."

If you hold ETH, nothing changes for you today. The foundation says the update "does not set a Glamsterdam mainnet activation date, and no action is required from Ethereum mainnet users or ETH holders as a result of this update." The real cost is time. Hoodi was the next public test of Glamsterdam, and that test now has no date.

A Gas Rule Change Triggered the Delay

Developers made the call on the core developer meeting known as ACDE #248. The foundation's post gives the reason. The delay is meant "to allow for further investigation of interactions of EIP-8037 with mainnet smart contracts."

The postponement also cancels a second change on Hoodi. The post says it "removes the gas-limit schedule that would have raised Hoodi's gas limit to 200M at the same epoch."

Glamsterdam has already gone live on one test network. It activated on the Sepolia testnet on October 6.

How EIP-8037 Changes the Cost of Storage

The concern comes from a write-up by ChainSecurity, a smart contract auditing firm. It looks at how Glamsterdam changes gas, the fee unit Ethereum uses to price computation and storage.

Under EIP-8037, gas in a transaction above 16,777,216 is first placed in a separate "state-gas reservoir". When a transaction creates new state, such as writing to an empty storage slot, it draws from that reservoir first.

The change in price is large. ChainSecurity calculates that with an empty reservoir, a cold write to a fresh storage slot "costs 12,100 + 97,920 = 110,020 execution gas, compared with 22,100 gas under Osaka," the current ruleset. That is roughly five times the old cost.

Why Old Safety Checks May Stop Working

Many contracts check how much gas is left before they do something important. Those checks were written for today's prices. ChainSecurity says "gas refills and repricing can let failure handlers complete where they once reverted, undermining assumptions behind existing gas checks."

This matters because of a known attack called insufficient gas griefing. The firm describes it this way: "A malicious caller may deliberately supply too little gas for an otherwise valid operation to succeed, while leaving enough for the contract to record the failure."

In plain terms, under the old rules an attempt like this might have reverted completely, leaving no trace. Under the new rules, a failure handler could finish its work. A valid operation could then be recorded as failed, and that record would stay.

ChainSecurity does not say every contract is at risk. "Glamsterdam does not make every gas check ineffective. A correctly bounded pre-call check can still guarantee gas delivery," it writes.

Its advice to developers is direct: "Where possible, propagate call failures so that the whole operation reverts. If failure handling is required, preserve a recovery path rather than making an irreversible decision based only on the remaining gas."

What Has Not Been Shown Yet

It has not been shown publicly that any live production protocol can be exploited this way. No affected projects have been named.

The EF post also does not say whether EIP-8037 will be changed or dropped. When ChainSecurity reviewed it on October 13, both EIP-8037 and its companion EIP-8038 were scheduled for Glamsterdam, and their public pages showed Last Call status, the final review stage before a proposal is finalized.

In the meantime, people running Hoodi nodes and validators have work to do. The foundation tells them to "check both your execution and consensus layer clients for instructions reflecting the postponed activation before October 26."

The next thing to watch is a new Hoodi date. Until developers set one, any mainnet timeline for Glamsterdam remains unannounced.