Ethereum Delays Glamsterdam Test on Hoodi as Developers Review Gas-Rule Interactions

Ethereum’s Glamsterdam upgrade did not activate on the Hoodi testnet on October 26 as previously planned. Developers postponed the network change to investigate how proposed state-creation gas pricing might interact with contracts already deployed on mainnet. As of the latest published Ethereum Foundation protocol notice, no replacement Hoodi activation date has been set.

The October 22 postponement notice says core developers made the decision at their All Core Developers Execution meeting, ACDE #248. The immediate concern involved EIP-8037 and its interactions with existing smart contracts. The delay therefore reflects a compatibility review, not a claim that the Ethereum mainnet has suffered a consensus failure.

The revised plan removed the Amsterdam execution-layer and Gloas consensus-layer activations from Hoodi’s earlier schedule. It also canceled the previously scheduled increase of Hoodi’s gas limit to 200 million at the same epoch. The Ethereum Foundation has explicitly said the change does not roll back Hoodi’s existing chain history.

Latest Stories

3 min read • 5 minutes ago

Hanwha Selects Chainlink for Global Tokenized Assets Ahead of Korea’s 2027 Rules

3 min read • 15 minutes ago

Ripple Wins Final US Trust Bank Approval, but RLUSD Issuer Remains Unchanged

3 min read • 25 minutes ago

Chainlink Launches 24/7 Pricing for Tokenized Stocks as Aave Addresses Weekend Risk

Read all latest stories →

Why a gas-pricing change needs more testing

Glamsterdam includes a group of improvements intended to help scale Ethereum Layer 1 while keeping validation practical. Its earlier technical announcement describes enshrined proposer-builder separation, block-level access lists and changes to the way transaction execution and state growth are priced.

The state-creation element matters because writing new persistent data imposes costs that extend beyond the execution of one transaction. A gas schedule that better accounts for these costs can help align demand with long-term network resources, but altering prices may surprise software written against earlier assumptions.

Developers may have constructed contracts using particular gas stipends or estimates for sequences of calls. Even if those contracts remain valid, changing costs can cause operations to run out of gas or become uneconomic. That is why testing compatibility with mainnet contracts before activation is an engineering requirement rather than a sign that scaling has been abandoned.

The Glamsterdam design also includes block-level access lists to help clients validate and access state more efficiently, along with proposer-builder separation that changes block production duties. These features require coordinated software updates across execution and consensus clients.

What node operators and ETH holders should know

The Foundation has instructed Hoodi node and validator operators to check that their execution and consensus client versions reflect the postponed activation. Running software that still assumes the obsolete October 26 schedule could lead to incompatible expectations during a network change.

This requirement is specific to the Hoodi testnet. The announcement says no action is required from ordinary Ethereum mainnet users or ETH holders because of the postponement. The testnet delay does not constitute a new mainnet deadline: the Glamsterdam mainnet schedule was already undecided and remains so.

For market participants, the correct interpretation is that an upgrade milestone has been moved to allow further investigation. It is not sound to attach an invented ETH price target to the timing decision or imply that a canceled Hoodi gas-limit increase has changed mainnet transaction fees.

Developers can continue testing potential changes with current specifications and client release notes, but should not treat outdated timetable tables as authoritative. The next important event will be a confirmed replacement epoch, accompanied by updated client guidance and clear documentation of the EIP-8037 compatibility findings.