TLDR
- The Glamsterdam upgrade scheduled for October 26, 2026 on Ethereum’s Hoodi testnet has been postponed without a replacement date.
- ChainSecurity identified vulnerabilities in EIP-8037 and EIP-8038 that could expose contracts to insufficient gas griefing exploits.
- The security firm has discovered 13 deployed smart contracts vulnerable to the issue and is coordinating private disclosure with affected teams.
- Node operators and validators need to update client software, though regular ETH holders require no immediate action.
- Mainnet deployment in December remains feasible, with testnet rescheduling expected following Devcon in early November.
Ethereum’s core development team has pulled the Glamsterdam upgrade from its planned October 26, 2026 deployment on the Hoodi testnet. A replacement timeline has not been established.
The choice was confirmed during All Core Devs Execution call #248. According to the Ethereum Foundation, additional time is necessary to examine how certain protocol modifications might impact existing smart contract deployments.
Scope of the Postponement
Three components originally slated for October 26 have been removed from the schedule. These include the Amsterdam execution layer fork, the Gloas consensus layer upgrade, and an increase to Hoodi’s gas ceiling to 200 million units.
The postponement leaves Hoodi’s existing blockchain data intact. Regular mainnet participants and ETH token holders face no required steps.
However, node operators and validators must upgrade their client implementations. Software packages including Lodestar, Besu, and Nethermind require updated versions that acknowledge the cancellation of the October 26 activation.
The Sepolia testnet successfully activated Glamsterdam on October 6 and remains unaffected by the current delay.
Gas Mechanism Vulnerabilities Identified
Blockchain security auditor ChainSecurity raised concerns on October 13 regarding two Glamsterdam proposals: EIP-8037 and EIP-8038. The company warned these specifications could diminish existing safeguards against insufficient gas griefing exploits.
This attack vector occurs when a transaction initiator provides insufficient gas for a smart contract to execute properly. ChainSecurity explained that the proposed modifications might allow gas to flow back into a contract following failed operations, enabling continued execution that current rules would halt.
Contracts relying on gas consumption patterns for security logic could experience unexpected behavior. A vulnerable contract might invalidate a user’s claim or prevent retry attempts, effectively locking users out of legitimate operations.
ChainSecurity clarified that not every gas-based security mechanism would become ineffective. Certain implementations would remain secure, though developers must audit them against the revised gas accounting rules.
Security researcher pcaversaccio escalated the matter on October 21, describing the vulnerabilities as “serious” in GitHub discussions. The researcher recommended a comprehensive reevaluation of the hard fork timeline.
The Ethereum Foundation had previously cautioned that Glamsterdam’s modified gas accounting could disrupt wallets, blockchain indexers, and gas estimation tools built on legacy assumptions.
Glamsterdam represents Ethereum’s primary scaling initiative for 2026. It incorporates enshrined proposer-builder separation via EIP-7732, block-level access lists through EIP-7928, and gas cost adjustments under EIP-8037 and EIP-8038.
Core developers had targeted early December for mainnet activation, contingent on successful Hoodi testnet validation. The fourth-quarter deployment window stays viable, with testnet rescheduling anticipated after Devcon, scheduled for November 3 through 6.
ETH market pricing remained stable, as the delay impacts only testing infrastructure. Institutional accumulation has persisted, with SharpLink moving $400 million from its ETH holdings onto blockchain networks and BitMine purchasing 12,535 ETH.
ChainSecurity disclosed Friday that it has identified 13 production smart contracts susceptible to the vulnerability. The firm withheld project names and confirmed it is coordinating confidential disclosure with affected development teams. It recommended immediate contract audits for all developers.


