Ethereum developers have delayed the Glamsterdam upgrade on the Hoodi testnet after security researchers identified eight existing smart contract assumptions that could become invalid under the proposed changes to gas accounting.
Summary
- Ethereum developers have delayed the Glamsterdam upgrade on the Hoodi testnet after ChainSecurity identified eight smart contract assumptions that could become invalid under the proposed gas changes.
- EIP 8037 and EIP 8038 would change how Ethereum charges gas for certain operations, potentially affecting existing contracts that depend on fixed gas costs or specific transaction failure conditions.
- The Ethereum Foundation has asked developers and auditors to review affected projects and report potential issues before core developers decide whether changes to the upgrade specifications are necessary.
- The Hoodi hard fork will remain on hold until the identified concerns are resolved, while development of Ethereum’s subsequent Hegota upgrade continues without interruption.
In a November 6 blog post, the Ethereum Foundation said auditing firm ChainSecurity had identified several projects that could become vulnerable once EIP-8037 and EIP-8038 take effect.
Both proposals change how Ethereum charges gas for certain operations, particularly those involving the creation and access of blockchain state. Some existing contracts depend on fixed gas costs or assumptions about how much gas remains after an operation fails.
The findings have prompted Ethereum’s All Core Developers (ACD) group to hold off on the Hoodi hard fork until the compatibility concerns are addressed.
Developers are now examining whether the affected contracts can be updated independently or whether changes to the upgrade specifications are necessary.
Ethereum’s Glamsterdam upgrade faces eight compatibility concerns
The security concerns were detailed in an October 13 analysis by ChainSecurity, which examined how Glamsterdam could change the behavior of contracts that continue executing after an external call fails.
Under Ethereum’s existing rules, some contracts depend on a failed operation leaving too little gas for subsequent instructions to complete. Glamsterdam’s revised accounting could allow certain operations to finish even when developers originally expected the entire transaction to revert.
ChainSecurity warned that such behavior could interfere with safeguards designed to prevent failed transactions from being permanently recorded or legitimate operations from losing their retry options.
One example involves contracts that mark an operation as unsuccessful after an external call runs out of gas. Under the new rules, previously unavailable gas could become accessible again, allowing the contract to record a permanent failure.
The Ethereum Foundation has published a GitHub repository documenting eight affected invariants, with explanations, examples and instructions for developers to examine their own code.
Among the identified risks are contracts that assume gas consumption can only move in one direction, fixed gas allowances will remain sufficient, or reverted calls cannot return gas already spent on creating state.
The repository identifies fixed gas budgets and gas reserves as the most common issues found so far, particularly in contracts that depend on predetermined transaction costs.
Developers have been asked to review both on-chain contracts and supporting off-chain systems, including wallets, relayers and infrastructure that may contain hardcoded gas limits.
Hoodi activation remains on hold as security reviews continue
The latest findings provide further details behind Ethereum’s earlier decision to postpone the Hoodi activation, originally scheduled for October 26 at 17:42:48 UTC.
As crypto.news previously reported, the postponement removed both the Amsterdam execution-layer and Gloas consensus-layer activations from Hoodi’s schedule, alongside a planned increase in the testnet’s gas limit to 200 million.
No replacement activation date has been announced.
Ethereum Foundation developer Marius van der Wijden said the organization is working with ChainSecurity and Dedaub while conducting internal audits to assess the possible effects across existing applications.
The Foundation acknowledged that its reviews cannot cover every Ethereum project, particularly where vulnerabilities may involve interactions between smart contracts and off-chain infrastructure.
It has therefore asked developers and independent auditors to identify affected applications and submit their findings before the next All Core Developers discussions.
The repository requests details of affected contracts, the specific invariant involved, possible fixes and supporting tests where available. Reports can be submitted privately to [email protected].
Depending on the feedback, developers may consider adjustments to EIP-8037 and EIP-8038 before proceeding with the upgrade.
Work on Ethereum’s subsequent Hegotá upgrade will continue in parallel and remains unaffected by the Glamsterdam delay, according to the Foundation.
Glamsterdam’s scaling changes remain under testing
Glamsterdam had already activated on the Sepolia testnet on October 6, where developers began examining its scaling changes under a 200 million gas limit.
The upgrade introduces enshrined proposer-builder separation through EIP-7732, which brings block-building responsibilities into Ethereum’s consensus protocol.
Another major component, EIP-7928, introduces block-level access lists designed to help clients process transaction data more efficiently and support parallel execution.
Gas repricing forms another part of the upgrade. EIP-8037 changes the cost of creating new blockchain state, while EIP-8038 adjusts charges for accessing existing state.
In an August technical assessment, the Ethereum Foundation said historical transaction replays showed that most smart contracts remained unaffected by the proposed pricing changes.
A smaller group, however, required higher gas limits or more substantial modifications to avoid unexpected failures.
Separately, developers merged a validator deposit fix on October 26 after identifying a flaw that could have credited staking deposits to block builders sharing the same public key.
The correction addressed a separate issue involving Glamsterdam’s Gloas consensus changes, with regression tests added to the specifications before client implementations incorporate the revised behavior.
