Ethereum developers have postponed the Glamsterdam upgrade on the Hoodi testnet while separately merging a correction to Gloas’ staking-deposit logic. According to the Ethereum Foundation’s official announcement, the October 26 activation was canceled specifically to give developers more time to investigate how EIP-8037 interacts with existing mainnet smart contracts. No replacement Hoodi activation date has been announced.
The postponement removes the scheduled Amsterdam execution-layer fork, Gloas consensus-layer activation and Hoodi’s planned increase to a 200 million gas limit. The change alters Hoodi’s future configuration without reverting any existing testnet history, and Ethereum mainnet users or ETH holders do not need to take action.
EIP-8037 Review Delays Hoodi Testing
EIP-8037 introduces separate accounting for state-creation costs, while EIP-8038 reprices access to existing state. Earlier testing found that contracts relying on fixed gas stipends, hardcoded limits or gasleft() assumptions could behave differently under Glamsterdam’s new pricing model. The compatibility concern is therefore concentrated in applications whose execution logic depends on specific gas behavior, rather than evidence of a general Ethereum smart-contract vulnerability.
Those risks had already been highlighted in previous Glamsterdam gas-repricing testing, where historical mainnet transactions were replayed against the new rules. Most tested contracts behaved normally, while a smaller subset required higher gas limits or potentially application-level changes.
The Hoodi postponement follows Glamsterdam’s successful Sepolia activation on October 6. Sepolia remains on the upgraded rules despite Hoodi being rescheduled, allowing developers to continue testing parts of Glamsterdam while the EIP-8037 compatibility review proceeds.
A separate issue emerged in Gloas’ fork-transition logic. Developer avsetsin reported that a builder could register with a BLS public key and potentially receive a later validator deposit using the same key, even when that deposit carried different withdrawal credentials. The edge case could have redirected ETH intended for validator registration into the builder balance during the fork transition.
Deposit Fix Separates Builders From Validators
The merged consensus-specification fix changes that routing behavior. Validator deposits now remain in the validator queue based on their withdrawal credentials, while valid builder deposits register or top up builders independently, preventing shared public keys from collapsing the two roles into one destination.
The issue was identified on October 12 and corrected before Gloas reached mainnet. No production staking funds were exposed because Gloas remains an unstable specification and Glamsterdam has not activated on Ethereum mainnet. The fix also adds regression tests covering deposit ordering and shared-key scenarios.
Client teams have meanwhile released software that removes the canceled Hoodi fork configuration. Teku 26.10.2 unschedules Gloas, while Geth 1.17.10, Besu 26.10.1 and Nethermind 2.2.1 remove the corresponding Amsterdam activation. Hoodi operators must use client releases that explicitly remove the October 26 schedule rather than relying on versions originally labeled Glamsterdam-compatible.
The additional testing extends a process that already includes the Platåberget public Glamsterdam environment, which was created to expose interoperability and fork-transition problems before longer-lived networks upgrade. Hoodi is now another unresolved testing milestone rather than a completed step toward mainnet.
Ethereum’s current deployment schedule still lists mainnet as TBD. Glamsterdam therefore has no confirmed mainnet activation date, and further progress depends on resolving EIP-8037 compatibility concerns, implementing the revised Gloas deposit rules across clients and establishing a new Hoodi activation window.