Ethereum postpones Hoodi Glamsterdam upgrade; no new date set

Ethereum's Hoodi testnet will not activate Glamsterdam on October 26, 2026. The Ethereum Foundation postponed the upgrade on October 22 to investigate EIP-8037's interactions with existing smart contracts; its current notice sets no replacement date. The immediate issue for operators is removing the superseded activation from their software configuration.

The distinction matters before Monday's former deadline. A published date in an old announcement, a candidate date in a developer agenda and a currently scheduled network activation are three different things. CoinAbout compared the original announcement, its replacement notice, the developer-call records and the proposal itself to reconstruct which statements still hold.

The schedule that changed

The Foundation's postponement notice withdraws the previously scheduled Hoodi activation at epoch 132,352, or October 26 at 17:42:48 UTC. It also withdraws the associated increase in Hoodi's gas limit to 200 million. No replacement activation epoch or timestamp is supplied.

That is a change to a future testnet configuration. It should not be described as reversing already processed transactions, erasing Hoodi history or switching off Ethereum mainnet. Those would be materially different events, requiring separate evidence.

The October 16 Hoodi announcement now carries an October 22 update saying that its schedule and activation instructions have been superseded. The older page remains useful for understanding the upgrade's intended scope. Its remaining activation table is historical context, rather than permission to follow the withdrawn timetable.

A four-step decision timeline

October 16: a Hoodi activation was announced

The original Foundation post paired an execution-layer upgrade called Amsterdam with the consensus-layer upgrade Gloas. It supplied a specific Hoodi epoch, slot and timestamp, while leaving mainnet undecided. That combination established a testnet plan; it did not establish a production launch date.

October 22: the old plan was withdrawn

The later Foundation notice says developers decided during All Core Devs Execution call 248 to postpone Hoodi for further investigation. Its explicit supersession statement resolves the conflict between the two blog pages. A reader finding the older schedule through search should follow the newer notice and the client team's current instructions.

October 26: the former deadline is no longer an activation

The date still matters operationally because an outdated configuration may retain it. It no longer means that Glamsterdam is scheduled to start on Hoodi that afternoon. An application test plan tied to that transition needs a revised basis; treating the cancelled time as a live countdown would misstate the network's plan.

October 29: a discussion is scheduled, not an outcome

The All Core Devs Consensus 190 agenda lists a call for October 29 at 14:00 UTC with Glamsterdam among its topics. An agenda establishes an intended discussion. It does not establish that participants will choose a date, agree on a fix or publish compatible software during that call.

Why December candidates are still candidates

The Execution call 248 agenda listed December 1, 8 and 9 as mainnet possibilities, explicitly framed as a heads-up. It said the aim was to set the date at the following consensus call if Hoodi went smoothly. Those qualifications are essential to interpreting the entry.

After the Hoodi plan was withdrawn, copying one candidate into a launch calendar would create certainty that the source does not provide. The current Foundation notice does not set mainnet activation. A subsequent agreement, network configuration and matching client guidance would be stronger evidence than an unchanged agenda entry.

This is also why closing a GitHub meeting issue is insufficient proof of a protocol decision. The execution-call issue contains an automated comment explaining that it closed because the meeting was more than 24 hours old. Issue housekeeping and an activation decision carry different meanings.

What EIP-8037 is trying to change

The EIP-8037 proposal concerns the gas charged for creating persistent Ethereum state. It proposes harmonizing those costs and metering state creation separately, with the aim of limiting database growth as execution capacity increases. Its specification and security discussion remain the relevant documents for technical review.

State is the information contracts and accounts leave behind for the network to maintain. More execution capacity is useful only if nodes can continue processing and storing the resulting workload. Repricing state creation therefore addresses a different resource constraint from simply counting transactions or announcing a larger block allowance.

The proposal currently displays a Last Call status and a November 1 deadline. That is a review milestone within the EIP process, not a network activation timestamp. Moving a proposal through review and scheduling an upgrade require different evidence; neither date should be substituted for the other in a launch tracker.

The compatibility question is what existing contract logic assumes about gas. A change can be beneficial for the protocol's resource model while still requiring careful review of deployed applications. An EIP's intended benefit does not, by itself, establish that every dependent contract behaves safely under the proposed accounting.

Conversely, the decision to investigate does not prove a live mainnet exploit, a realized financial loss or that every contract is affected. This report has not run a contract replay, audited a protocol or measured an affected balance. Its finding is about the documented scheduling decision and the limits of the available confirmation.

Operator checks involve more than one client

Ethereum's nodes and clients documentation explains the separation between execution software, which processes transactions and maintains state, and consensus software, which implements agreement on the chain. A validator adds another software responsibility. Updating one component does not demonstrate that the rest use the same network schedule.

For Hoodi operators, a useful verification sequence is to identify the network, inventory execution and consensus versions, and read each team's release notes for explicit removal of the old activation. Validators should include their validator client and any builder infrastructure in that inventory. This is an evidence checklist, not a replacement for client-specific operating instructions.

Version numbers alone are weak evidence. A release table prepared for the original activation can remain available after a postponement. The question is whether the actual release and any custom configuration reflect the revised schedule. A newer-looking number without the relevant release note should not be treated as confirmation.

Application developers face a related distinction between a planned test environment and one actually running the intended rules. Before comparing behavior across networks, record the network, software and active configuration. An unsuccessful test against the wrong rules cannot establish compatibility with Glamsterdam; a successful one cannot establish it either.

What ETH holders should take from the update

The postponement announcement concerns Hoodi and says no action is required from Ethereum mainnet users or ETH holders because of this update. It is not a reason to move funds, connect a wallet to an upgrade website or sign a transaction advertised as activating Glamsterdam.

The strongest optimistic interpretation is that stopping a scheduled rehearsal gives developers room to examine compatibility before a broader rollout. The counterargument is that uncertainty remains until the investigation produces a reviewed path forward. Neither interpretation establishes a replacement date or a price consequence.

The next meaningful confirmation would be a new official schedule with an activation epoch and timestamp, accompanied by client instructions matching it. A meeting headline alone would leave the operational question unresolved. CoinAbout will check the October 29 discussion and any replacement announcement against this timeline.

Readers following the Ethereum research page should keep protocol milestones separate from price observations. Crypto assets carry market, liquidity, custody and software risks; a testnet schedule neither guarantees an investment outcome nor removes those risks.