Ethereum sets Hoodi test for Oct. 26, but mainnet remains open

Ethereum now has a date for the next public rehearsal of its Glamsterdam upgrade. In an October 16 protocol announcement, the Ethereum Foundation said Hoodi will switch to the new rules on October 26 at 17:42:48 UTC. The testnet’s gas limit is scheduled to rise to 200 million at the same epoch. No date has been set for Ethereum mainnet.

The date is useful, but it is not the whole story. Hoodi will test whether independently maintained software can agree on a substantially changed way of building and checking blocks. The Foundation’s release table still leaves some client versions blank, and its notice tells operators to install compatible software on both sides of a node: the execution client and the consensus client. A calendar entry cannot substitute for that work.

Physical Ethereum-themed tokens appear in the photograph above; they are collectibles, not the digital ETH asset or a depiction of the Hoodi network. Photograph by Stock Catalog for Quote Catalog, available under CC BY 2.0. TECHi cropped the original photograph and added its corner mark.

What changed on October 16

Glamsterdam activated on Sepolia on October 6. The new Foundation notice moves the public testing sequence forward by assigning Hoodi a precise activation point: epoch 132,352, slot 4,235,264. It also schedules Hoodi’s 200 million gas limit for that epoch, matching Sepolia. Those are testnet settings, not an announcement that the main Ethereum network will raise its limit to 200 million on October 26.

The distinction matters to anyone reading this as an ETH investment story. Protocol developers have published a test date, but they have not decided the mainnet date. Hoodi can expose compatibility problems, operational mistakes or performance costs that change the schedule. Conversely, a successful Hoodi fork would be evidence that a complex upgrade works under another public test configuration; it would not, on its own, measure future ETH demand or guarantee lower fees.

TECHi previously examined why Sepolia’s 200 million gas test depends on validator settings. Hoodi adds a different question: can the network’s mix of clients and the surrounding builder tools carry the upgrade reliably, rather than merely reach the scheduled slot? That is the test an investor, application team or validator operator should follow over the next ten days.

The release table is the story behind the date

Ethereum does not run from one company’s software package. A node combines an execution client, which processes transactions and state, with a consensus client, which follows the chain’s validator rules. Validators also run a validator client. Because Glamsterdam changes both layers, an operator cannot update one half and assume the other half will remain compatible.

In the Foundation’s Hoodi client tables checked for this story, confirmed consensus releases include Lodestar 1.50.0, Nimbus 26.10.1 and Teku 26.10.1. The confirmed execution entries include Besu 26.10.0, Ethrex 30.0.0-rc.2 and Nethermind 2.2.0. The table leaves entries for other clients empty and says it will be updated as additional releases are confirmed. A blank entry is not proof that a client is broken or late; it means the official notice does not yet identify a supported Hoodi version for that row.

That turns the next ten days into a practical readiness window. The operator’s job is to check release notes for explicit Hoodi support, update the correct pair of clients and, for staking, update the beacon node and validator client too. Builder and relay infrastructure needs its own compatibility check. The Foundation specifically warns operators to use releases whose notes confirm support for the scheduled activation, rather than assuming that the highest version number is suitable.

There is a more subtle market implication here. When several independent clients converge on the same new rules, the network gains evidence that the upgrade is implementable across its software ecosystem. When one client disagrees at the fork, the result can be a divergent chain view or stalled operation for nodes using it. A smooth Hoodi activation would reduce one category of execution risk; it would not establish a market price for ETH. That is an inference from the way coordinated Ethereum upgrades work, not a prediction about trading.

Why Glamsterdam is harder than a gas-limit headline

A 200 million gas limit is an arresting number, but it is only one piece of the design. Glamsterdam combines changes to block production with changes intended to let nodes process more work without making validation impractical. The two headline proposals are enshrined proposer-builder separation, EIP-7732, and block-level access lists, EIP-7928.

The first moves the exchange between a block proposer and a builder further into Ethereum’s protocol. A proposer can include a builder’s commitment; the builder then reveals the execution payload. A payload timeliness committee checks whether that reveal and the related blob data arrived on time. Validators get more time to verify execution because consensus and execution checks are separated. This is a real change in duties for node operators and builder systems, not a cosmetic rearrangement of software.

The second proposal records which accounts and storage locations a block touches, along with post-transaction state changes. With that map, clients can fetch state data in parallel and look for opportunities to validate work more efficiently. The design opens a path to greater capacity, but the path still has to work in real client implementations and under realistic network conditions. A testnet gas ceiling by itself says nothing conclusive about sustained throughput, ordinary transaction fees or home-node hardware requirements.

The strongest case for Glamsterdam is therefore more precise than “Ethereum gets faster.” It is that Ethereum is trying to make larger blocks verifiable without turning ordinary node operators into a bottleneck. The strongest counterargument is that more capacity and a more complex builder workflow can bring operational strain, even if the specifications are sound. Hoodi is where those competing claims should meet observable results.

Gas repricing could matter to applications before it matters to holders

The upgrade also changes what some operations cost in gas. EIP-8037 raises and separately meters the cost of creating new state, while EIP-8038 revises state-access costs. The aim is to reflect the resource burden placed on nodes as Ethereum’s stored state grows. More block capacity without realistic resource pricing could move costs from users to node operators.

The Foundation’s repricing study replayed historical mainnet transactions under the planned schedule. It reported that most contracts were unaffected, but a small set either needed higher transaction gas limits or relied on assumptions that could cause failure. The identified patterns include fixed gas stipends, hardcoded limits, code that branches on remaining gas and signed transactions with fixed limits. Those are study findings, not a claim that all live applications have been tested or fixed.

For developers, the actionable question is whether their own contracts and wallets handle the new accounting. A transaction that succeeds only after a gas-limit adjustment has a different remedy from a contract whose logic assumes a particular amount of gas remains. Wallets and RPC services also need correct estimates; a cached old constant can make a user-facing transaction fail before anyone notices a protocol bug. The Foundation provides an affected-contracts search and asks teams to test on public networks and review affected call sites.

For ordinary ETH holders, the Foundation says no action is required from this Hoodi notice. Messages claiming that holders must transfer coins, “upgrade” a wallet by sending ETH, or approve a new contract to remain compatible would not follow from the announcement. That warning is a straightforward consequence of the notice’s stated scope, rather than evidence of a specific scam connected to this event.

The question for ETH is execution, not an October 26 price target

It is tempting to turn any dated network upgrade into a price forecast. The evidence here does not support one. Hoodi is a testnet. Its ETH has no role in valuing real mainnet ETH, and an announced fork date does not prove that usage, fees, staking economics or investor demand will improve. Any attempt to attribute an ETH price move solely to this notice would need a timestamped market observation and a way to separate the announcement from other crypto-market events. This report makes no such attribution.

There are nonetheless concrete milestones worth tracking. First, the Foundation’s release table should fill in with versions that explicitly support Hoodi. Second, on October 26, operators and observers can check whether the network advances under the new rules without persistent client disagreement. Third, developers can examine gas estimates and contract behavior after activation. Finally, client teams may decide a mainnet schedule after reviewing the test evidence. That sequence is more useful than treating a planned testnet activation as a completed mainnet launch.

A positive result would strengthen the case that Ethereum can move a demanding combination of proposer-builder changes, parallel-access groundwork and repricing through another public network. A poor result could delay mainnet or require changes to clients or tooling. Neither outcome can be responsibly declared in advance. The immediate news is narrower and more valuable: Ethereum has put a second public Glamsterdam test on the calendar, and the quality of the client rollout will now determine what that date actually tells us.