Ethereum’s Hoodi testnet will not activate Glamsterdam on October 26 under its previously announced schedule. In an October 22, 2026 announcement, the Ethereum Foundation Protocol Cluster said the activation had been postponed without a replacement date. Hoodi operators need to check that their software and custom configurations remove the old activation settings; Ethereum mainnet users and ETH holders do not need to act because of this notice.
The Foundation’s Hoodi postponement announcement cancels the activation previously set for October 26 at 17:42:48 UTC, epoch 132,352. It supersedes the earlier announcement’s schedule and activation instructions. That distinction matters operationally: a release or configuration prepared for the original date cannot simply be assumed suitable for the postponed upgrade.
What was removed from Hoodi’s schedule
The change covers three scheduled items: Amsterdam on the execution layer, Gloas on the consensus layer, and the gas-limit schedule that would have raised Hoodi’s limit to 200 million at the same epoch. The notice does not provide another activation epoch or timestamp. October 26 is therefore not a provisional fallback date; it has been removed from the updated configuration.
The Foundation explicitly distinguishes this configuration rollback from a reversal of Hoodi’s chain history. Developers are withdrawing settings for a future upgrade, not undoing transactions already recorded on the testnet. Describing the decision merely as a “rollback” would obscure that difference and could wrongly suggest that the chain had already activated Glamsterdam and then reversed it.
The canceled 200 million gas-limit schedule also needs to stay separate from claims about delivered capacity. The release establishes that a planned limit change will not occur under the old schedule. It does not report an achieved throughput improvement, identify Hoodi’s current limit, or provide a replacement capacity timetable. Application teams cannot use the canceled figure as evidence of resources available for their planned tests.
Why the upgrade was postponed—and what remains unknown
According to the Foundation, core developers decided at ACDE #248 to allow further investigation of interactions between EIP-8037 and mainnet smart contracts. An Ethereum Improvement Proposal, or EIP, is a specification for a proposed change. The announcement identifies the proposal under investigation but does not explain the particular contract behavior involved, name affected applications, or publish a technical reproduction.
That leaves an important boundary around the news. The source supports reporting an unresolved compatibility investigation behind the postponement. It does not establish that an exploit occurred, that funds were lost, or that Ethereum mainnet suffered an incident. The reference to mainnet smart contracts describes the subject of the investigation; the operational schedule being changed belongs to Hoodi.
Analytically, the decision trades a scheduled testnet activation for more investigation time. Removing the date prevents teams from treating the old configuration as the agreed upgrade schedule while that work continues. The announcement does not quantify the extra time needed, however, so it cannot support a revised launch estimate or a calculation of how long the eventual delay will be.
Operators must check more than one component
For Hoodi node operators, the immediate task is configuration alignment across both execution and consensus clients. The Foundation says software or custom network settings that still schedule Glamsterdam at the old time need updating before October 26. A calendar change in an announcement is not, by itself, evidence that a particular machine has received the corresponding software or configuration change.
The revised client instructions specifically warn against treating the earlier announcement’s release tables as proof that those versions incorporate the postponement. Operators are directed to release notes explicitly confirming that the October 26 activation has been removed. The relevant check is the documented behavior of the release, not simply whether it once appeared in an upgrade announcement.
Validator operators have additional components to review. The notice says both the consensus-layer beacon node and validator client must be updated, and it separately addresses builder infrastructure. Operators relying on external block-building services should follow their tooling provider’s instructions. The Foundation says builder and validator tooling guidance will be added as it is confirmed, rather than presenting every dependency as settled.
The practical inference is that updating one component does not establish that the whole setup reflects the postponement. An execution-client update alone does not answer whether the consensus software, validator client or custom settings still reference the old activation. This is a dependency-checking problem, not evidence that any particular operator has misconfigured a node or that the network has already experienced a failure.
Application testing loses a date, not its existing history
Application developers also need to separate tests of existing Hoodi behavior from tests that depend on Glamsterdam. The Foundation expressly says not to plan Hoodi testing around an October 26 activation. Work premised on the new upgrade or its accompanying gas-limit schedule therefore lacks a confirmed activation date, even though the announcement does not describe a reversal of the testnet’s existing history.
For a team maintaining a test plan, the useful distinction is between an assumption and a verified network condition. A date copied from the superseded announcement is no longer sufficient to establish that Glamsterdam-dependent tests can run as intended. The new notice supplies no replacement date to substitute into that plan, and it does not report that the compatibility investigation has concluded.
BTC-Pulse’s earlier reporting on Glamsterdam’s tentative Sepolia schedule provides historical context for that distinction. It described a conditional target tied to development-network stability and mentioned an earlier EIP-8037-related issue. That account does not establish whether Sepolia subsequently activated, and the new Foundation notice does not establish that the earlier issue and the current investigation are identical.
There is also a narrower compatibility comparison in BTC-Pulse’s historical coverage of the Fusaka-era EOF debate, which recorded concerns about execution semantics and tooling changes. Those were arguments about a different proposal, not evidence explaining EIP-8037. They illustrate why contract-facing protocol changes can prompt compatibility scrutiny without proving that the present investigation will find the same problems.
A scheduling withdrawal should likewise not be confused with redesigning an upgrade’s scope. BTC-Pulse’s earlier discussions about splitting Pectra concerned a proposal to divide work into phases. The Hoodi notice instead removes scheduled activation settings. It does not announce that Glamsterdam has been split, identify features being dropped, or specify a revised package of changes.
The next evidence is a replacement schedule and investigation outcome
The Foundation explicitly limits the announcement to Hoodi and says it does not set a Glamsterdam mainnet activation date. Neither an old roadmap target nor a testnet postponement supplies a confirmed mainnet date. ETH holders are not being asked to migrate assets, approve transactions or make a wallet change as a result of this update.
The next scheduling signal is a separately announced Hoodi activation epoch or timestamp, accompanied by client instructions that match it. A published outcome of the EIP-8037 investigation would answer the different technical question of what developers found and whether changes were needed. Until those records appear, operators can verify removal of the old activation settings, but application teams cannot replace October 26 with another confirmed Glamsterdam testing date.
