Ethereum has removed the activation date for the Glamsterdam upgrade on the Hoodi testnet. The October 26, 2026 slot at 17:42:48 UTC, epoch 132,352, is gone, and the Ethereum Foundation has not named a replacement. The notice is narrow, and reading it correctly depends on keeping three things apart: the schedule that was withdrawn, the chain history that was not touched, and the compatibility question that remains open.
The Foundation’s Protocol Cluster posted the update on October 22. Core developers agreed at ACDE #248 to delay the upgrade so they could investigate how EIP-8037 interacts with mainnet smart contracts. That investigation is unresolved. The announcement names the proposal under review but does not describe the specific contract behavior involved, does not identify affected applications, and does not publish a reproduction. A compatibility review is not an exploit, and nothing in the notice suggests funds were lost or that mainnet suffered an incident.
The withdrawn schedule bundles three items. The Amsterdam execution-layer activation and the Gloas consensus-layer activation are both removed, along with the gas-limit schedule that would have raised Hoodi’s limit to 200 million at the same epoch. Because none of these has a new epoch or timestamp, October 26 is no longer a fallback date. It has been removed from the configuration.
For node and validator operators, the risk is a stale configuration. The Foundation asks operators to check both execution and consensus clients before October 26 and to stop treating the release tables in the earlier announcement as authoritative. A version that once appeared in the superseded upgrade notice does not prove it carries the postponement; the test is whether the release notes explicitly confirm the October 26 activation has been removed. New client releases that incorporate the postponement will be listed in the announcement as they are confirmed, and operators should prefer releases whose notes state outright that the old activation is gone. Validator operators face a second layer of work, because the beacon node, the validator client, and any external builder tooling are updated separately.
Application teams lose a planning assumption; the testnet itself remains intact. Work that depended on Glamsterdam or its gas-limit schedule has no date to schedule against, and the announcement supplies nothing to substitute into a test plan. Existing Hoodi behavior remains testable. Only Glamsterdam-dependent work is unscheduled.
One more boundary matters. The announcement concerns Hoodi only and does not set a Glamsterdam mainnet activation date, so a testnet postponement is not a mainnet schedule. ETH holders are not being asked to migrate assets, approve transactions, or change wallets because of this update.
The practical reading is a dependency check. Updating an execution client does not establish that the consensus client, validator software, or custom settings have stopped referencing the old activation. The next useful signals are a replacement Hoodi activation epoch with matching client instructions, and a published outcome of the EIP-8037 investigation. Until those appear, the correct posture is to verify removal of the old settings and to avoid committing to another Glamsterdam date that no one has announced.
Source: BTC-Pulse.
