Ethereum's Glamsterdam Upgrade Hits a Roadblock: Gas Security Flaws Force Hoodi Testnet Fork Delay

Ethereum's path to its next major protocol upgrade has run into a significant obstacle. Security auditor ChainSecurity has identified critical vulnerabilities in the gas mechanism changes that form the core of the Glamsterdam hard fork, prompting Ethereum developers to call off the planned activation on the Hoodi testnet. With 13 real-world smart contracts already identified as potentially affected, the delay underscores how seriously the Ethereum ecosystem takes pre-mainnet security — and how the complexity of gas repricing can introduce attack surfaces that even well-reviewed code cannot anticipate.

In Brief

• Ethereum developers have cancelled the Glamsterdam hard fork activation on the Hoodi testnet after ChainSecurity flagged security vulnerabilities in the upgrade's gas mechanism changes

• The flaws could allow certain smart contracts to permanently record failed operations that their logic was designed to keep retryable — exposing them to a class of attack known as insufficient gas griefing

• ChainSecurity has already identified 13 real-world affected contracts and is conducting responsible disclosure with the relevant projects

• The Glamsterdam upgrade is already live on the Sepolia testnet, which activated on October 6 with a gas limit of nearly 200 million — more than three times Ethereum mainnet's current 60 million limit

• No new date has been set for the Hoodi testnet fork; the mainnet target of end-2026 now faces uncertainty

• The next upgrade in Ethereum's roadmap, Hegotá, is expected in 2027 and may introduce native privacy features to the protocol

What Is the Glamsterdam Upgrade?

Glamsterdam is the name given to Ethereum's current development-stage hard fork — a coordinated protocol upgrade that requires all network participants running Ethereum nodes to update their software simultaneously. Like all Ethereum upgrades, Glamsterdam bundles together a set of Ethereum Improvement Proposals (EIPs) that collectively change how the network operates at the protocol level.

The most consequential changes in Glamsterdam relate to gas — Ethereum's unit of computational cost. Two specific proposals, EIP-8037 and EIP-8038, modify how the network charges for creating and accessing stored data (state) on the blockchain. Together, they introduce a separate gas pool dedicated to state creation, a mechanism designed to make the costs of state-related operations more predictable and to give developers finer-grained control over how their contracts consume resources.

Glamsterdam also introduces two other significant features:

• Block-level access lists: A mechanism that allows nodes to check which state a transaction will touch before executing it, enabling parallel processing of non-conflicting transactions. This is a meaningful throughput improvement because it removes the sequential bottleneck that currently prevents Ethereum from executing independent transactions simultaneously.

• In-protocol block auction: Glamsterdam moves the auction mechanism that determines who assembles each block — a domain currently dominated by MEV (Maximal Extractable Value) infrastructure operating outside Ethereum's core rules — into the protocol itself. This is a step toward giving Ethereum native governance over how block production is organized, rather than leaving it to third-party relay networks.

Why Was the Hoodi Testnet Fork Postponed?

The delay was triggered by findings from ChainSecurity, a prominent smart contract security auditing firm, which identified a class of vulnerability introduced by Glamsterdam's gas changes.

On Thursday, ChainSecurity published its disclosure: "It has just been decided to delay the Glamsterdam hard fork on the Hoodi testnet because of security impacts we identified." The firm confirmed it had "already found 13 real-world examples" of affected contracts and stated it was engaged in responsible disclosure with the projects involved. The Ethereum Foundation is simultaneously assessing the full scope of contracts that may be exposed across the ecosystem.

Understanding the Vulnerability: Insufficient Gas Griefing

To understand what ChainSecurity found, it helps to understand what gas griefing is and why smart contract developers guard against it.

In Ethereum, when one smart contract calls another (an "external call"), the calling contract decides how much gas to forward to the called contract. This is a deliberate design: the caller can limit how much computational work the external call is permitted to do, protecting the caller from unexpected behavior.

Insufficient gas griefing is an attack in which a malicious actor deliberately provides too little gas to a legitimate external call — not enough for the call to succeed, but not so little that the entire transaction fails outright. The intended effect is to force the called function into a revert state, where its failure is recorded on-chain as a permanent outcome. If the calling contract's logic treats that recorded failure as final and irrecoverable, the attacker has effectively corrupted the state of the system with a trivial amount of effort.

To defend against this, many smart contract developers build in protective logic using gas checks — code that verifies enough gas is available before proceeding — or designs their systems so that failed operations automatically remain retryable rather than becoming permanent. This defensive architecture is widely used in bridges, multi-step financial protocols, and cross-chain messaging systems where the consequences of a permanently failed operation are severe.

How Glamsterdam Breaks These Defenses

ChainSecurity's analysis identifies the mechanism by which Glamsterdam's gas changes undermine these existing protections.

Under the current Ethereum protocol, once a call fails due to insufficient gas, the outcome is predictable and stable: the amount of gas available to a call is essentially fixed by what was forwarded, and the failure state is durable. Developers can reason about these constraints with confidence.

Under Glamsterdam, two things change that disrupt this reasoning:

1. Gas can be refilled or returned to a contract after a failed call. The new gas pool mechanics mean that gas which previously would have been permanently consumed can now be returned to the calling context, altering the available gas at subsequent points in execution in ways that prior contracts did not anticipate.

2. Repricing can change how much gas a specific operation requires. EIP-8037 and EIP-8038 change the cost of state-related operations. A contract that was written assuming a particular operation costs a certain amount of gas may now find that the same operation costs a different amount — and the gas-check logic it uses to defend against griefing attacks was calibrated for the old cost structure.

The result, as ChainSecurity summarized, is that "even with unchanged contract code, a failure path that previously reverted can now complete." In other words, Glamsterdam can transform what a developer designed as a safe, retryable failure state into a path that completes in an unintended way — without any change to the contract's source code. This is precisely the kind of silent behavioral change that can introduce exploitable vulnerabilities in deployed production systems.

ChainSecurity urged all projects to audit their contracts for these patterns, and confirmed that the Ethereum Foundation is working to quantify how many deployed contracts across the mainnet are affected.

What Node Operators Should Do Now

For operators running Ethereum nodes with Glamsterdam software already installed in anticipation of the Hoodi testnet activation, immediate action is required.

Ethereum researcher Christine Kim stated that node operators should either revert to an older software release that does not include the Glamsterdam upgrade scheduled for Hoodi, or wait for their execution client team to release an updated version that removes the Hoodi fork from the schedule.

Preston Van Loon, a developer on the Prysm consensus client — one of Ethereum's major client implementations — confirmed that a Prysm release removing the Glamsterdam activation from Hoodi's schedule would follow on the same day as the delay announcement.

Operators of other consensus and execution clients should monitor their respective client teams' release channels for equivalent updates. Running a client that still has the Hoodi Glamsterdam fork block scheduled after the network consensus has moved to delay it could cause the affected node to follow an orphaned chain branch.

Glamsterdam's Testnet Journey: Sepolia Is Live, Hoodi Is Paused

The delay on Hoodi does not affect the upgrade's status on Sepolia, Ethereum's other major public testnet. Sepolia activated the Glamsterdam upgrade on October 6 and has been producing blocks under the new protocol rules since then.

One notable aspect of the Sepolia activation is the gas limit. Sepolia is running with a gas limit of nearly 200 million — more than three times Ethereum mainnet's current gas limit of approximately 60 million. This elevated limit on Sepolia allows developers to test how protocols behave under conditions of much higher throughput, stress-testing the new parallel processing capabilities introduced by the block-level access lists.

Ethereum's testnet sequencing — moving through networks like Sepolia and Hoodi before committing to mainnet — reflects a deliberate safety philosophy. Each testnet serves a distinct purpose in the upgrade pipeline: Sepolia provides a relatively open environment for broad developer testing, while Hoodi more closely simulates mainnet conditions and validator behavior. A security issue surfacing at the Hoodi stage, while disruptive to the timeline, is far preferable to one emerging after mainnet deployment — where millions of contracts and billions of dollars in total value locked (TVL) would be exposed.

Impact on the Ethereum 2026 Roadmap

Ethereum developers had been targeting a Glamsterdam mainnet activation by the end of 2026, which would have made it one of the more consequential protocol upgrades since the Dencun hard fork. That timeline now faces uncertainty given that no new date has been announced for the Hoodi fork.

The delay also has downstream implications for Hegotá, the upgrade currently expected to follow Glamsterdam in 2027. Hegotá is anticipated to include native privacy features for Ethereum — a long-discussed goal for the protocol that would allow certain transaction data to be shielded from public view at the base layer. Ethereum developers typically aim for a minimum interval between major upgrades, meaning that slippage on Glamsterdam's mainnet date can push Hegotá's timeline accordingly.

The broader context is that Ethereum's development process prioritizes safety and consensus over speed. The decision to delay Glamsterdam on Hoodi rather than proceed and manage the security issues post-fork reflects a consistent pattern: Ethereum's core developer community treats smart contract security as a non-negotiable constraint, not a post-deployment concern.

Why This Matters for the Ethereum Ecosystem

The Glamsterdam delay is significant for several overlapping reasons that extend beyond the immediate timeline disruption:

For smart contract developers and DeFi protocols: The 13 contracts already identified by ChainSecurity are likely only the first confirmed cases. Any protocol that uses gas checks or relies on call-failure behavior to protect against reentrancy, griefing, or malicious callers should audit its logic against the Glamsterdam gas model before mainnet activation — whenever that ultimately occurs. The responsible disclosure process ChainSecurity is conducting buys time, but the window between now and any eventual mainnet date is the critical period for remediation.

For Ethereum's security reputation: The discovery of a critical gas vulnerability at the testnet stage — before any mainnet impact — is actually a validation of Ethereum's multi-layered security process. ChainSecurity's audit, the responsiveness of the developer community, and the decision to delay rather than proceed all reflect an ecosystem that takes protocol security seriously. The finding does not represent a failure of Ethereum's security model; it represents the model functioning as designed.

For the broader crypto market: Ethereum's development milestones are closely watched by institutional and retail investors alike. Delays to major upgrades can introduce short-term uncertainty about ETH price trajectory, particularly when those upgrades carry meaningful technical improvements to throughput and developer experience. The gas limit increase implied by Glamsterdam's Sepolia configuration — potentially tripling the mainnet limit — would represent a significant capacity expansion that validators, layer-2 networks, and dApp developers have been anticipating.

For layer-2 ecosystems: Many Ethereum layer-2 networks (rollups, validiums, and optimistic chains) rely on the Ethereum mainnet for data availability and finality. Changes to mainnet gas economics directly affect the cost structure of these networks, and the parallel processing improvements from block-level access lists could reduce base-layer congestion that periodically causes L2 fee spikes during peak demand periods.

What Comes Next

The immediate next steps are clear: ChainSecurity will complete its responsible disclosure to the 13 identified affected projects; the Ethereum Foundation will determine the full scope of exposure; and client teams will release updated software that removes the Hoodi Glamsterdam activation from their schedules.

What remains uncertain is the revised timeline for the Hoodi fork and, by extension, the mainnet deployment. The Ethereum development process involves broad coordination between multiple client teams — including execution clients like Geth, Nethermind, Besu, and Erigon, and consensus clients like Prysm, Lighthouse, Teku, and Nimbus — as well as the broader community of protocol researchers, auditors, and application developers. Reconvening that coordination around a new fork block requires sufficient time for the underlying security issues to be understood, any necessary EIP modifications to be proposed and reviewed, and client software to be updated and tested.

ChainSecurity's public statement noted it is working through responsible disclosure, suggesting the full technical details of the vulnerability may not be published until affected projects have had adequate time to respond. The publication of a comprehensive post-mortem analysis will be an important step in helping the broader developer community understand the scope of the issue and take appropriate action.