Ethereum can leave a smart contract’s code untouched and still change what happens when it fails. That is a better reason to postpone an upgrade test than any deadline is a reason to rush one.
The Glamsterdam Hoodi testnet postponement puts an uncomfortable question in front of Ethereum’s upgrade process: how much existing application behaviour depends on the gas rules underneath it? The issue is not simply whether an operation becomes dearer, but whether a contract takes a different path when another contract call fails.
This is a postponed testnet upgrade, not a known production exploit. The governance story is the decision to stop the clock while compatibility is examined, rather than treating a published activation time as an obligation to proceed.
A scheduled test, not a mainnet emergency
In its 22 October announcement, the Ethereum Foundation said core developers at All Core Developers Execution meeting #248 had delayed Hoodi’s Glamsterdam upgrade to investigate interactions between EIP-8037 and mainnet smart contracts.
Hoodi had been scheduled to activate on 26 October 2026 at 17:42:48 UTC, epoch 132,352. That activation is no longer scheduled, and no replacement epoch, timestamp or date has been set.
The associated increase in Hoodi’s gas limit to 200 million has also been removed from the schedule. This changes a future upgrade configuration; it does not rewind Hoodi’s chain history.
CoinDesk reports that Glamsterdam activated on Sepolia on 6 October, with Hoodi next in the planned public-testnet sequence. A successful earlier test is useful evidence, but it cannot settle every compatibility question.
Why gas can change how failure behaves
Gas is Ethereum’s way of metering computational work and other resources. A contract calling another contract passes along a limited gas budget; if that external call fails, the calling contract may have logic for handling the failure.
Whether that fallback logic completes can depend on the gas still available. Change the accounting, and unchanged instructions may produce a different outcome.
ChainSecurity’s technical analysis examines EIP-8037’s separate state-gas accounting alongside EIP-8038’s state-access gas update. Broadly, the former separates accounting for creating persistent state, while the latter changes prices for accessing state.
The researchers’ warning is precise: “Even with unchanged contract code, a failure path that previously reverted can now complete.” In plain English, a route that used to run out of room and roll back might instead finish under the proposed rules.
Completion is not automatically a vulnerability. The question is whether an application relied on the previous failure behaviour, and whether the new outcome violates its intended safeguards. ChainSecurity identifies potential compatibility effects, not proof that a production protocol has been exploited.
The striking gas number needs its conditions
One example makes the Ethereum EIP-8037 gas accounting risk tangible, but also shows how easily a technical finding can become a misleading headline.
For a cold, fresh storage-slot write with the separate state-gas reservoir empty or insufficient, ChainSecurity gives 22,100 gas under Osaka. Under the proposed schedule, its example charges 12,100 execution gas plus 97,920 state-creation gas: 110,020 in total.
That is a large difference for that particular operation under those assumptions. It is not evidence that every Ethereum transaction becomes roughly five times more expensive.
With a funded reservoir, the state-creation charge comes from that separate pool. The important compatibility issue is how these accounting arrangements affect gas availability and smart contract gas failure handling, not a universal multiplier for transaction fees.
The pause is useful; the evidence must follow
The strongest defence of Ethereum’s process is straightforward: investigating this before the next public test is what staged upgrades are for. Postponement is not, by itself, proof of either catastrophic design or flawless governance.
But the decision exposes a real responsibility. Protocol developers alter the environment in which existing applications operate, including applications whose authors made assumptions about how failure works. Unchanged bytecode is not a guarantee of unchanged behaviour.
The next useful disclosure would explain which contract patterns are affected, how the proposed rules will be tested against them, and what changes, if any, follow. Those are questions for the investigation, not conclusions already established by the delay.
The Foundation’s immediate instruction is narrower: “no action is required from Ethereum mainnet users or ETH holders as a result of this update.” Its notice concerns Hoodi and does not set a Glamsterdam mainnet activation date.
Calling the Ethereum Glamsterdam upgrade delayed is fair only if that scope stays visible. The substantive test is whether developers can explain the compatibility boundary clearly enough for application teams to assess it, rather than replacing one unexplained date with another.
The sensible deadline is the one that survives scrutiny of what existing contracts actually do.
