Ethereum client developers released Geth 1.17.10 on October 23, 2026, removing the scheduled Amsterdam upgrade from the Hoodi test network. The release translated a postponement announced the previous day into software that node operators could install, replacing a configuration that had pointed to October 26.
The change matters for people rehearsing Ethereum upgrades and validator operations. Geth's release notes say the scheduling change leaves other networks unaffected. The Ethereum Foundation's postponement notice, checked on November 5, still gives no replacement activation date and requires no action from mainnet ETH holders.
A software release that removes an activation
Geth, also called go-ethereum, is an execution client: software responsible for the transaction-processing side of an Ethereum node. Its official download page records publication of the 1.17.10 binaries on October 23. The accompanying code change reverses the earlier Hoodi scheduling change.
The broader decision to postpone Glamsterdam was announced on October 22, after core developers agreed to investigate how a proposed gas-accounting change would interact with existing smart contracts. Amsterdam is the upgrade's execution-layer component; Gloas is its consensus-layer component.
The Foundation removed both scheduled components and a planned increase in Hoodi's gas limit to 200 million. It explicitly distinguishes withdrawing a future activation from reversing blockchain history. Existing Hoodi transactions were not rolled back by the announcement.
The release originally told Hoodi operators using Geth 1.17.9 to update before October 26 at 17:42:48 UTC. That deadline has passed. The relevant check now is whether their installed software and any custom network configuration still contain the superseded schedule.
Why the gas changes need more investigation
The Foundation identified EIP-8037 as the subject of further investigation. An Ethereum Improvement Proposal, or EIP, specifies a proposed protocol change. This one would alter how Ethereum charges for creating persistent state, such as new storage entries and contract code.
The proposal aims to limit database growth as block capacity expands. It separates accounting for computation from accounting for newly created state, instead of treating both through one undifferentiated gas budget. Gas measures the resources a transaction consumes; it is distinct from the market price paid for each unit.
Those changes reach beyond a simple increase in capacity. The proposal's compatibility section says wallet and node software must adapt gas estimation to the revised accounting. It also identifies contracts that measure work by comparing gas remaining before and after an operation as a compatibility concern, because that remaining amount can increase under the proposed rules.
This helps explain why testing transaction behavior matters alongside testing whether clients can agree on blocks. A protocol change can be implemented consistently by node software while still changing assumptions made by application code. The broader relationship between resource use and user costs is covered in the guide to crypto transaction fees.
Hoodi operators have two software layers to check
Hoodi is a public test network with an open validator set. Ethereum's documentation describes it as a place to rehearse staking and protocol upgrades, with a substantial state database useful for testing complex contract interactions. It has its own balances and transaction history, separate from mainnet.
Updating Geth addresses only the execution side. Geth's documentation explains that a production-style Ethereum node also needs a consensus client. That software works with the execution client to follow the chain, and validators have additional responsibilities associated with proposing and attesting to blocks.
The Foundation's operator instructions therefore cover both client layers. Validator operators also need to review their validator client and any external block-building infrastructure. An earlier release's compatibility with the originally planned fork is not evidence that it includes the postponement.
The release also changes synchronization behavior
Geth 1.17.10 includes another operational change: automatic selection of the snap/2 synchronization protocol once Amsterdam is active. Synchronization is the process through which a node catches up with the blockchain and its current state.
The associated developer change specifies selection at startup after Amsterdam has been active for an hour. A node resuming an unfinished snap/1 synchronization stays with that protocol. Operators can override automatic selection, and forcing snap/2 before Amsterdam still falls back to snap/1.
These are client behaviors, not a new activation timetable. Readers following the earlier Glamsterdam testnet plans should treat the Hoodi schedule in the postponement notice as authoritative. A replacement Hoodi date, and a confirmed mainnet activation schedule, remain separate announcements to watch.