Updated October 26, 2026.
Glamsterdam will not activate on Hoodi on October 26. The Ethereum Foundation announced the postponement on October 22 without setting a replacement date, changing what testnet operators need to run but requiring no action from Ethereum mainnet users or ETH holders.
The immediate issue is an obsolete activation schedule, not a migration of assets. The Foundation’s postponement notice replaces earlier activation instructions and tells operators to check software on both sides of their node: execution and consensus.
Glamsterdam: what has been taken off the schedule
The cancelled appointment was October 26, 2026, at 17:42:48 UTC, epoch 132352. There is no announced replacement epoch or timestamp, so operators cannot calculate the next activation by adding a day or a fixed number of epochs to the original plan.
The change removes the scheduled Amsterdam execution-layer fork and Gloas consensus-layer fork. It also removes the associated plan to raise Hoodi’s gas limit to 200 million at that epoch, which means the old date cannot be cited as evidence that this capacity increase has happened.
The October 16 announcement remains available, but now carries a warning that its schedule and activation instructions have been superseded. Its detailed tables are useful for reconstructing the earlier plan, not for deciding what configuration should run today.
| Item | Current position |
|---|---|
| Previous activation | October 26, 17:42:48 UTC, epoch 132352: removed |
| Replacement schedule | No new date or activation epoch announced |
| 200M gas limit | Increase tied to the former epoch removed |
| Hoodi operators | Check execution, consensus and validator components |
| Mainnet users and ETH holders | No action required because of this postponement |
Why EIP-8037 needs further investigation
The stated reason is to investigate interactions between EIP-8037 and mainnet smart contracts. That is not an announcement that an exploit has occurred, that every contract is incompatible or that a named application has lost funds; the notice does not establish any of those claims.
EIP-8037 addresses higher and separately metered gas costs for creating state. For application teams, the relevant question extends beyond the headline price of a transaction to assumptions embedded in contract execution and the tools used to estimate gas.
A contract can depend on a particular gas budget or on how much gas remains during execution. Our coverage of Ethereum’s Glamsterdam gas repricing provides that context; the postponement is a new scheduling decision, not evidence that the proposed changes have been dropped.
What Hoodi node operators should check
Supporting the planned upgrade and supporting its postponement are different requirements. The Foundation explicitly warns that inclusion in the original client release tables does not establish that a version removes the October 26 activation, even if it previously advertised Glamsterdam support.
The Geth v1.17.10 release notes provide a concrete execution-layer example. They cancel Amsterdam on Hoodi and instruct Hoodi operators running v1.17.9 to upgrade before the old activation time, while stating that other networks are unaffected.
On the consensus side, Lighthouse v8.3.2 disables the scheduled Gloas fork on Hoodi. Its staking guidance includes the beacon node, validator client and execution client, rather than treating a single updated process as sufficient evidence that the whole deployment is ready.
These are documented examples, not a client combination installed or tested by CryptoRoad. Operators using other clients should consult their own teams’ release instructions, check custom network settings and review guidance from any external block-building provider they use.
A useful operational record would identify the network, installed versions and configuration source for each component. That makes it possible to distinguish a package downloaded for later use from the software actually running, without assuming that a successful restart proves the cancelled fork has disappeared.
A configuration change is not a chain-history rollback
The postponement removes configuration for a future event; it does not reverse Hoodi’s existing history. Describing it as erasing confirmed transactions or resetting the testnet would confuse two materially different operations and goes beyond what was announced.
Application developers should therefore revisit test plans built around October 26. A test performed before new rules activate cannot demonstrate behavior under those rules, and a calendar reservation based on the old schedule no longer establishes which environment a team will encounter.
For meaningful comparisons, record the network and active rules alongside test results, not just the date and application version. Preparation, activation and post-activation observations are separate checkpoints; a delay at one checkpoint does not make results from another interchangeable.
The earlier Glamsterdam devnet 11 tests belong to a different stage of that process. They offer background on development work but do not prove a Hoodi activation, and neither milestone by itself establishes a mainnet deployment date.
Do ETH holders need to move their funds?
No funds migration follows from this notice. There is no requirement to acquire a replacement token, connect a wallet or sign a transaction to preserve ETH because Hoodi’s scheduled upgrade has been postponed; those would be unrelated requests, not steps described by the Foundation.
The next useful checkpoint is a fresh official activation schedule and matching client guidance. Until those appear, neither a countdown based on the old announcement nor an estimate from a third party should be treated as a confirmed date for Glamsterdam on Hoodi or Ethereum mainnet.
