Ethereum Postpones Glamsterdam on Hoodi After Gas Repricing Put 13 Live Contracts at Risk

Ethereum's core developers spent Thursday taking a scheduled upgrade back off the calendar. Four days before Glamsterdam was due to activate on the Hoodi testnet — 26 October at 17:42:48 UTC, epoch 132,352 — the Ethereum Foundation published a notice saying the fork would not happen. No replacement date was offered, and no new activation epoch was written into the network configuration.

The reason was not a bug in a client, a broken test, or a bad block. It was a security review showing that a planned change to how Ethereum charges for storage could turn a certain class of temporary smart contract failure into a permanent one, on contracts nobody is going to rewrite in the next four days.

Developers pulled the fork four days before activation

The decision was taken at the All Core Developers Execution call on 22 October and announced the same day. The Foundation's notice is precise about what changed: the Amsterdam execution-layer activation and the Gloas consensus-layer activation are both removed from Hoodi's schedule, along with the gas-limit schedule that would have raised the testnet's limit to 200 million at the same epoch.

What it does not do is rewrite Hoodi's history. Existing blocks stay where they are; the change rolls back a future configuration, not past state. Hoodi was the second public rehearsal, after Sepolia, which activated the same upgrade on 6 October and has been running blocks near a 200 million gas limit — more than three times mainnet's roughly 60 million — since then.

The Foundation also drew a line around the blast radius. This announcement sets no mainnet date, and ordinary mainnet users and ether holders need to take no action. Nothing in the record suggests the live network has been exploited, or is exposed today.

The trigger is gas that comes back after a failure

The analysis behind the delay came from ChainSecurity, which published a review on 13 October examining how two proposals interact with contracts that already handle failure. At the time of that review, EIP-8037 and EIP-8038 both carried Last Call status and were scheduled for Glamsterdam.

Contracts routinely catch a failed call to a contract they depend on, so they can record the failure, skip a step, or try something else. The problem is that a failed call does not say whether it failed because of a logic error or because it ran out of gas. That distinction matters enormously when the next line of code writes something permanent, like marking an ID as failed or removing a user's option to retry. A malicious caller can deliberately underfund an otherwise valid call while leaving enough gas for the contract to record the failure — a pattern known as insufficient gas griefing.

Defenders have three standard tricks. Check the gas budget before the call. Check what is left afterwards and revert if the remainder looks like underfunding. Or rely on the failure handler itself running out of gas, so the whole transaction unwinds instead of recording a failure. Glamsterdam changes what is left over, and therefore breaks the second and third.

Why the reservoir changes the arithmetic

EIP-8037 splits gas in two. A transaction still sets one gas limit, but everything above 16,777,216 — the transaction cap — goes into a separate state-gas reservoir, and state creation draws from that pool first. The reservoir travels with calls in full, while the classic 63/64 forwarding rule applies only to execution gas. The `GAS` opcode, and therefore Solidity's `gasleft()`, reports only the execution side.

So a contract that sees a small remainder after a failed call can no longer conclude that nothing expensive is possible. There may be a full reservoir behind it. If the callee reverts, its reservoir usage is restored, meaning gas the target consumed can come back to the caller's failure handler.

The same effect arrives from another direction. Under the old rules, clearing a storage slot allocated earlier in the transaction produced a refund at the end, subject to the 20% cap — useless for paying the next instruction. Under EIP-8037, undoing that creation triggers an immediate state-gas refill worth up to 97,920 gas, which can land in execution gas and fund a failure handler that would previously have run out.

ChainSecurity's conclusion is blunt: even with unchanged contract code, a failure path that previously reverted can now complete.

The number to remember is 110,020

The other half of the problem is simpler. Repricing makes some operations dramatically more expensive, so a budget that used to be comfortable can become too small.

Under EIP-8037, creating a new storage slot is charged as 64 bytes at 1,530 gas per byte, or 97,920 state gas, on top of execution charges. When the reservoir pays, the execution side of a cold fresh-slot write is about 12,100 gas. When the reservoir is empty or insufficient, that same write costs 12,100 plus 97,920 — 110,020 execution gas, against 22,100 under the current Osaka schedule.

EIP-8038 adds smaller but equally awkward increases: a first change to an existing non-zero slot rises from 2,900 to 10,100 gas when warm and from 5,000 to 12,100 when cold, cold account access goes from 2,600 to 3,000, and the value-transfer charge on calls that send ether rises from 9,000 to 11,300.

Put together, a pre-call gas check can still guarantee delivery of the requested amount while that amount is no longer enough for the target's work. The failure that follows looks like an application error when it is really an out-of-gas condition, and the contract takes the wrong branch.

What the 13 contracts actually count

The number in most headlines needs care. ChainSecurity said on 22 October that its investigation had already found 13 real-world examples in deployed contracts, and that it was running responsible disclosure with the affected projects, according to CryptoSlate. The firm did not name the protocols or addresses.

Thirteen counts examples of affected contracts, not thirteen separate vulnerabilities. ChainSecurity's public write-up describes four mechanisms — a gas budget that is no longer sufficient, a post-call check that reads only `gasleft()`, a slot-clearing refill, and a reverting intermediary that returns state charges to its parent frame — and it publishes no list of thirteen named findings. Nothing released so far says thirteen DeFi protocols are sitting on a known exploit.

What the firm did say is that the pattern shows up in applications handling withdrawals, batched transactions and automated failure recovery. Its advice is to stop relying on post-call checks altogether: inferring a cause from remaining gas only holds if the callee halted directly and nothing returned gas before the check, and both conditions can now break. Relying on an implicit revert is weaker still, because that protection is a side effect of a gas schedule later forks will change again.

The risk was flagged in August, in a different shape

This is not a surprise from nowhere. On 24 August the Foundation published an analysis replaying historical mainnet transactions under the new schedule. It sorted every transaction into four outcomes: identical, succeeds with differences, fixable with a higher gas limit, and potentially broken even with a substantially raised limit. The last group relied on hardcoded gas assumptions, and the post said outreach to the most affected builders was already underway, alongside a public tool for checking whether a contract address is affected.

Most flagged issues, the Foundation said then, are fixed with a gas-limit increase. What October added was a narrower and more uncomfortable question: not whether a contract runs out of gas, but what it does with the gas it gets back.

What Glamsterdam was supposed to deliver

The upgrade matters because it is the throughput step. Glamsterdam bundles enshrined proposer-builder separation and block-level access lists, two changes to how blocks are built and validated, with a gas schedule meant to make state costs track real resource use. Raising the gas limit without repricing state operations would push state growth faster than node operators can absorb, which is why the two are packaged together. The Foundation has described the new schedule as derived from a performance target supporting roughly a 3x increase in base throughput. State gas prices were last adjusted in the Berlin fork in 2021.

What happens to the December window

Mainnet was never scheduled. The 22 October meeting agenda listed 1, 8 and 9 December as possible mainnet dates for discussion, explicitly as preliminary candidates, with developers aiming to fix a date at a later consensus-layer call if Hoodi went smoothly. That sequence now has a hole in it, and nobody has said how long the investigation will take.

Until a revised Hoodi schedule and a formal mainnet date are published, teams should treat every December reference as provisional.

What node operators should do now

Anyone running Hoodi infrastructure has work to do before the old activation time, because software that still schedules Glamsterdam at 26 October will disagree with the revised configuration. The Foundation has begun listing releases that incorporate the postponement, covering every major consensus and execution client from Lighthouse v8.3.2 and Prysm v7.3.1 to go-ethereum v1.17.10, Nethermind 2.2.1 and Reth v2.8.1. The warning attached to that list is worth repeating: a version number is not proof. Besu 26.10.1 exists mainly to remove the Amsterdam activation time from Hoodi's configuration, and Lodestar's notes flag that v1.50.0 still carries the old Gloas activation. Operators should read release notes until they find an explicit statement that the 26 October activation is gone, and keep their pre-Gloas builder and relay settings until the fork is rescheduled. At the 22 October call, a Lido representative was recorded as coordinating that rollback with Lido operators — a reminder that staking providers, not just solo operators, are reconfiguring.

The harder lesson for Ethereum's scaling story

Glamsterdam's headline features get the attention, but the postponement is about the least glamorous part of any blockchain: the price list.

A gas schedule is a compatibility layer with an installed base nobody has fully mapped. Contracts embed its numbers in ways their authors forget — a stipend here, a threshold there, a branch that only makes sense because a write used to cost 22,100 gas. Repricing is a prerequisite for raising throughput, and every repricing is a compatibility event across every deployed contract on the chain, including the ones that will never be updated.

The signals to watch are a revised Hoodi date, client notes that reflect it, and a mainnet decision at a future All Core Developers Consensus call. Until those land, the most accurate description of Ethereum's next upgrade is the one the Foundation used: postponed, with no new date set.