Is the Ethereum Glamsterdam upgrade cancelled? No. Ethereum developers postponed its planned October 26, 2026 activation on the Hoodi testnet to investigate how proposed gas-accounting changes could affect existing smart contracts. A replacement Hoodi date has not been set, and Glamsterdam had no confirmed mainnet activation date to cancel.
That distinction is central to the Ethereum roadmap in 2026. Glamsterdam already activated on the Sepolia testnet on October 6. The paused step is a further public-network test, not a rollback of Ethereum mainnet or the abandonment of the upgrade’s scaling goals. The Ethereum Foundation says the pause concerns interactions between EIP-8037 and deployed contracts; the October 22 core-developer agenda also discusses security concerns involving EIP-8038.
What Changed on October 22?
The Ethereum Foundation’s earlier announcement had scheduled the Hoodi activation for October 26 at 17:42:48 UTC. On October 22, it superseded that schedule: the Amsterdam execution-layer activation, the Gloas consensus-layer activation, and a planned increase of Hoodi’s gas limit to 200 million were removed from the scheduled configuration. No replacement epoch or timestamp was announced.
This is a scheduling change, not a reversal of Hoodi’s chain history. It also creates an operational task: Hoodi node and validator operators must follow their client teams’ revised instructions. Software that still contains the old October 26 activation setting needs an appropriate update so operators do not follow conflicting schedules. The Foundation states that mainnet users and ETH holders need take no action because of this Hoodi announcement.
| Network | Status as of October 23, 2026 | What the status means |
|---|---|---|
| Sepolia | Glamsterdam activated October 6 | One public testnet activation has occurred |
| Hoodi | October 26 activation postponed; new date unset | Further testing and revised client releases are needed |
| Ethereum mainnet | Activation date not set | No scheduled mainnet fork was cancelled |
The dates and statuses above come from the Ethereum Foundation’s testnet announcements and October 22 postponement notice.
Why Can a Gas Change Become a Security Concern?
“Gas repricing” sounds like a change to transaction costs. For some contracts, however, gas is also part of program behavior. A contract may call another contract, observe whether that call succeeded, and decide whether to retry, revert, or permanently record a failure. That decision can depend on assumptions about how much gas the call consumes and how much remains afterward.
EIP-8037 proposes separate accounting for some state-creation costs; EIP-8038 changes the cost of accessing state. ChainSecurity’s analysis explains the compatibility concern: under the proposed rules, a failed subcall could leave—or restore—enough usable gas for an outer contract’s failure handler to finish when that same path previously would have reverted. A contract whose safety depends on the old behavior could then record an outcome its developers did not intend.
This does not mean that every Ethereum smart contract has a vulnerability, that ETH has been compromised, or that a mainnet exploit has occurred. The proposals are being reviewed before Glamsterdam activates on mainnet. The Ethereum Foundation’s earlier developer guidance said the large majority of contracts were unaffected by the repricing cases it had identified, while urging affected teams to test their assumptions and update where needed. The subsequent security review is precisely why those assumptions deserve closer examination.
The publicly described risk paths
The following are risk patterns described in ChainSecurity’s analysis, not a fabricated list of 13 distinct findings:
- An old gas budget may no longer be sufficient. A contract may successfully forward the amount of gas its developer requested, yet the called operation could need more gas under the proposed pricing rules. A check that once seemed safe can therefore lead to an unexpected out-of-gas failure.
- A low remaining-gas reading may no longer tell the full story. EIP-8037’s proposed state-gas reservoir changes what can be paid for after a call. Code that interprets
gasleft()alone as proof that a failure handler cannot complete may reach the wrong conclusion. - Clearing newly created state may replenish gas during a failure path. In the circumstances ChainSecurity describes, that refill can allow code to finish after a failed call instead of reverting. Whether it affects a specific application depends on its call path and accounting assumptions.
- A reverting intermediary may return more gas than expected. With multiple contracts in a call chain, a middle contract’s revert can alter the gas available to the original caller. A post-call threshold that appeared to detect an out-of-gas failure may no longer do so reliably.
- Failure handling can become an application-level problem. The consequence is not merely a different fee estimate. In a susceptible design, treating an underfunded attempt as a permanent application failure could remove a retry or record the wrong result. This is the outcome developers need to test, rather than assuming every changed gas value is itself an exploit.
What Does the Reported “13” Actually Count?
Some coverage describes 13 major DeFi projects with potentially affected contracts. That is materially different from saying researchers disclosed 13 independent security vulnerabilities. ChainSecurity’s public technical article explains several mechanisms, but does not publish 13 individually named findings or a verified list of 13 affected projects. Disclosure and investigation are still part of the story.
For a publishable ETH security risks article, the safest formulation is therefore: “Reports say researchers identified potentially affected projects; publicly available technical documentation describes gas-accounting and failure-handling risk patterns, not a complete 13-item vulnerability register.” Readers should not be invited to infer that 13 live Ethereum protocols have been exploited.
Which Glamsterdam Improvements Are Still Planned?
The pause does not erase the upgrade’s intended benefits. Glamsterdam’s two headline features are enshrined proposer-builder separation and block-level access lists. The first brings aspects of how block proposers and builders coordinate into Ethereum’s consensus protocol. The second records the accounts and storage locations a block accesses, creating opportunities for clients to process parts of validation work more efficiently. These are proposed capabilities, not a promise of a particular fee reduction or transactions-per-second figure for users.
Gas-pricing changes form another part of the package. Their purpose is to make charges better reflect the resources Ethereum uses as it scales. The Hoodi pause illustrates the trade-off: improving how the network accounts for resource costs must be reconciled with the behavior of contracts already deployed under earlier assumptions. The question for developers is not just “Can clients run the new rules?” It is also “What will existing applications do under those rules?”
What Should Developers and ETH Holders Watch Next?
Application developers should review calls that catch failures and continue execution, especially where code uses fixed gas budgets, remaining-gas thresholds, or assumptions that a failure handler will itself run out of gas. ChainSecurity recommends testing the outcome of those paths under both the earlier and proposed gas schedules—not simply increasing a numeric limit and assuming the application is safe.
Hoodi operators should look for client releases whose notes explicitly remove the previously scheduled October 26 activation. The Ethereum Foundation cautions against assuming that a version listed in an older announcement already includes the postponement.
ETH holders do not need to convert their ETH, install software, or take any mainnet action in response to this testnet delay. For anyone following the investment implications, the meaningful milestones are a published mitigation or specification decision, a new Hoodi schedule, successful testing, and—only then—a confirmed mainnet date. The delay alone does not establish a measurable effect on ETH’s future price.
Frequently Asked Questions
Is Ethereum Glamsterdam upgrade cancelled?
No. The Ethereum Foundation postponed the October 26 Hoodi testnet activation and has not set a replacement date. It did not announce cancellation of Glamsterdam as a whole.
Has Glamsterdam been delayed on Ethereum mainnet?
There was no confirmed mainnet activation date in the Foundation’s schedule. Losing the planned Hoodi test date can affect the route to mainnet, but it would be inaccurate to say that a specific, officially scheduled mainnet date was missed.
Did researchers find 13 separate Glamsterdam vulnerabilities?
The public technical analysis does not enumerate 13 separate vulnerabilities. The “13” in some reporting refers to projects with potentially affected contracts. The verified technical concern centers on how proposed gas changes could alter existing contracts’ failure-handling behavior.
Are Ethereum users’ funds at risk because Hoodi was postponed?
The postponement notice does not report a mainnet compromise and says mainnet users and ETH holders need take no action. Developers are investigating compatibility and security implications before scheduling the upgrade on mainnet; that is not a guarantee that every application has already been assessed.
Bottom line: Glamsterdam’s Hoodi rehearsal has stopped for a specific reason: developers need to understand how new gas rules interact with existing smart-contract logic. The most useful next update will not be a speculative launch date. It will be evidence that the identified failure paths have been assessed and that a revised test schedule is ready.
