Ethereum Glamsterdam Hoodi Testnet Upgrade: What Changes on October 26

Ethereum’s next major protocol upgrade has a second public testnet date: Glamsterdam is scheduled to activate on Hoodi at 17:42:48 UTC on October 26, 2026. The announcement, published by the Ethereum Foundation on October 16, gives node operators and developers another opportunity to test changes to block production, transaction processing and gas accounting before a mainnet date is set. The detail worth watching is not simply the testnet’s planned 200 million gas limit. Glamsterdam also changes how Ethereum organises work inside a block and how it charges for operations that consume network resources.

Hoodi is the next test, not an Ethereum mainnet launch

Glamsterdam combines two coordinated upgrades: Amsterdam for Ethereum’s execution layer, which processes transactions and smart contracts, and Gloas for its consensus layer, which helps validators agree on the chain’s history. The first public testnet activation took place on Sepolia on October 6. Hoodi is scheduled to follow on October 26, at epoch 132,352 and slot 4,235,264. These identifiers determine the precise point at which the new protocol rules take effect; the UTC timestamp is the practical deadline for operators planning their maintenance.

The distinction between testnet and mainnet matters. Hoodi’s activation is a rehearsal under a separate network configuration, not a date for upgrading the live Ethereum network where users hold and transfer ETH. The Ethereum Foundation has not announced a mainnet activation time. Testing on Hoodi can reveal compatibility problems, but the date alone does not establish that every planned change is ready for production.

The 200 million gas limit tests more room inside each block

At the Hoodi fork, Ethereum’s gas limit is scheduled to rise to 200 million, matching the limit being tested on Sepolia. Gas is the unit Ethereum uses to measure the computational and storage-related work required by transactions. A block gas limit caps the total gas that can be consumed by the transactions included in a block, so a higher limit creates room for more work, depending on the transactions involved. It does not mean every block will contain 200 million gas worth of activity, nor does it guarantee that fees will fall by a fixed percentage.

There is a trade-off behind raising this ceiling. Larger blocks can increase capacity, but they also require computers running Ethereum clients to process and propagate more data. If the work becomes too demanding, operators with less capable hardware may struggle to keep up, potentially putting pressure on decentralisation. Glamsterdam’s design therefore combines capacity improvements with changes intended to make execution and state growth more predictable.

Block-level access lists are designed to make parallel processing safer

One of Glamsterdam’s central changes is EIP-7928, which introduces block-level access lists. These record information about the accounts and storage locations a block’s transactions access and modify. That information can help clients identify which operations depend on the same data and which can be processed independently. Today, transaction execution often has to respect ordering dependencies, because two transactions that modify the same account or storage location cannot always be handled as though they were unrelated.

Consider a block containing two transactions that update separate contracts and a third transaction that reads data changed by the first. A client needs to preserve the dependency between the first and third transactions, but the independent work may offer opportunities for parallel execution. Access lists provide a more structured picture of those relationships. The feature does not make every transaction parallelisable, and real performance gains will depend on transaction patterns and client implementations.

Proposer-builder separation changes how blocks are assembled

Glamsterdam also includes EIP-7732, known as enshrined proposer-builder separation. In Ethereum’s proof-of-stake system, validators propose blocks and attest to the chain they consider valid. Block builders, meanwhile, can specialise in selecting and arranging transactions into candidate blocks. The upgrade brings the separation between these responsibilities into Ethereum’s protocol rules rather than leaving it entirely to external arrangements.

The intended benefit is to change the timing and responsibilities involved in building and validating blocks, giving the network more room to propagate data while preserving its consensus process. Ethereum’s published upgrade material describes a longer data-propagation window as part of this design. That is an infrastructure change, not a promise that users will immediately see faster confirmations or lower transaction fees. Its practical value will depend on how clients, validators and block-building services perform under the new rules.

Gas repricing could expose contracts that rely on old assumptions

Glamsterdam is not only about processing more transactions. EIP-8037 and EIP-8038 adjust the gas costs associated with creating and accessing Ethereum’s persistent state, including accounts, storage slots and deployed contract code. The rationale is that gas prices should better reflect the actual resource costs imposed on network nodes as Ethereum’s state grows. The existing pricing for these operations had not been comprehensively recalibrated since the Berlin upgrade in 2021, while the amount of state clients must manage has continued to increase.

The Ethereum Foundation has already replayed historical mainnet transactions under the proposed pricing rules to look for contracts whose behaviour could change. Its August analysis found that most transactions were unaffected, while some flagged cases could be resolved by increasing the supplied gas limit. A smaller set could potentially fail even with a substantially higher limit. The risks include contracts that rely on fixed gas stipends, hardcoded gas values, logic that checks the remaining gas, or transactions signed in advance with a fixed gas allowance.

This is why developers should not treat a successful test under the old gas schedule as sufficient evidence of compatibility. A contract can be logically correct and still fail if the assumptions around the cost of executing it no longer hold. Wallets, application interfaces and infrastructure providers also need accurate gas estimation; stale constants can cause transactions to run out of gas even when the underlying contract remains compatible.

Which client versions are listed for the Hoodi fork?

The Ethereum Foundation’s October 16 announcement lists compatible releases for several execution-layer and consensus-layer clients, while leaving some entries blank as further releases are confirmed. The following versions were included in the announcement at publication time. Operators should check the current release table and each project’s release notes before upgrading, rather than assuming that the newest version number automatically supports this particular fork.

The table is a snapshot, not a complete list of every compatible implementation. In particular, the Ethrex entry is a release candidate, and the announcement did not yet list a Hoodi-compatible version for every client. Operators should only install a release whose notes explicitly confirm support for the scheduled Glamsterdam activation. Validators must also make sure their beacon node and validator client are both updated, not just one component.

What node operators and application developers should do now

Hoodi operators should first identify which execution and consensus clients their setup runs, then verify the specific compatible releases and follow each client team’s migration instructions. Validator operators need to review any changes to builder integration, validator duties and gas-limit configuration. Those running external block-building infrastructure should check the relevant tooling’s Glamsterdam guidance as well. The deadline is before the scheduled October 26 activation, not after the network begins using the new rules.

Smart contract teams have a different checklist. They should review the planned Ethereum Improvement Proposals, inspect code that depends on fixed gas assumptions, and exercise critical transaction paths on the upgraded Sepolia and Hoodi networks. Wallet and infrastructure developers should verify gas estimation against the new pricing rules and investigate any transactions that fail or consume unexpectedly different amounts of gas. The Foundation’s repricing analysis is a useful starting point for identifying potentially affected contracts, but teams still need to test their own integrations.

What the Hoodi results need to prove before mainnet

The next milestone is evidence that clients can coordinate the fork reliably, validators can perform their updated duties, and applications continue to behave correctly under the revised gas schedule. The 200 million gas limit will also test how the network handles a much larger block-processing budget, but a test configuration is not proof that the same setting will be adopted on mainnet. Client compatibility, contract failures and real execution performance are all relevant to the eventual deployment decision.

For ordinary ETH holders, the Hoodi announcement requires no action on mainnet, and there is no need to migrate or convert ETH because of this test. For developers and node operators, however, October 26 is a concrete deadline to prepare for. The next meaningful signal will be the outcome of the Hoodi test and the client teams’ subsequent decision on when Glamsterdam is ready for a mainnet schedule.