Ethereum Foundation Delays Glamsterdam Upgrade Past Oct. 27 Activation

Ethereum Pulls Glamsterdam From Hoodi

The Glamsterdam upgrade to Ethereum (ETH) has been pulled back from its testnet stage, one step short of the mainnet rollout where code goes live. In a blog post published Thursday, Oct. 22, the Ethereum Foundation said the latest core developer call had resolved to postpone Glamsterdam's activation on the Hoodi network. The upgrade had been scheduled to switch on Oct. 27 at 02:42 Korea time, which corresponds to 17:42 UTC on Oct. 26, five days after the announcement. No replacement date exists yet; the Foundation said a new one will be announced later. The stated reason is EIP-8037, an Ethereum improvement proposal whose effect on mainnet smart contract code now requires further investigation before developers will advance it, even on a rehearsal network. A testnet is the trial network where new features and stability are checked before anything ships to mainnet, the network that carries the live service. Both layers were to have activated in one coordinated step, the shape a mainnet deployment of Glamsterdam would eventually take. The decision withdrew the activation schedule for both halves of the fork: Amsterdam on the execution layer, which processes transactions and contract calls, and Gloas on the consensus layer, which handles attestations and finality. A plan to raise Hoodi's gas limit to 200 million was withdrawn at the same point in the schedule; the gas limit caps the computation a single block can process and is the parameter that shapes gas fee levels when demand rises. The postponement landed five days before that window, removing a fixed event from operators' calendars with little runway. The Ethereum price played no part in the decision. It came out of the protocol's own release process, and the Foundation framed it as a schedule change rather than a design change.

Config Rollback, Not a Chain Rewrite

The Foundation was explicit about what the postponement is and is not. Undoing the upgrade configuration, it explained, does not roll back the blockchain history already recorded on Hoodi; blocks stay exactly as they were, and only the forward-looking schedule is withdrawn. Glamsterdam itself pairs an execution-layer change named Amsterdam with a consensus-layer change named Gloas, mirroring the two-client structure Ethereum (ETH) has run since its move to proof of stake. That structure is what makes the operator checklist so demanding. Node and validator operators on Hoodi must now confirm the fork will not trigger on the old date, which means checking that their execution and consensus layer clients run versions whose deployment notes no longer list the Oct. 27 activation. The Foundation asked operators to verify explicitly that each development team's release guidance has removed the old schedule, a step meant to keep the testnet from splitting between clients that still expect Glamsterdam and clients that no longer do. The gas limit withdrawal deserves its own note: the 200 million figure was to have lifted throughput on Hoodi in the same window, so the delay removes a separate calibration exercise along with the fork. A hard fork only works if every Ethereum client moves to compatible code at the same block; the same discipline drove the Ethereum 1.0 to 2.0 transition at far larger scale. For operators the practical task is narrow: read the deployment guidance from each client team and patch before any new date is set. The Foundation's longer-horizon planning continues in parallel, including its previously reported target of a quantum-resistant L1 overhaul by December 2029, but Glamsterdam's own path now runs through the unresolved EIP-8037 review and a date that has yet to be named.

EIP-8037 Remains the Blocking Item

Our read of the release process: the gate Glamsterdam still has to pass is a cleared EIP-8037 review, and only after that a freshly tagged activation date that operators can synchronize against. Pulling the 200 million gas limit increase along with the fork is the detail worth weighing; it suggests developers want Hoodi held in a known state until the proposal's effects on mainnet contracts are fully mapped. Until the Foundation names a new date, Hoodi stays on its current configuration, and any mainnet timeline for Glamsterdam remains provisional.