Ethereum developers postponed the Hoodi upgrade to examine how changes to gas accounting affect existing smart contracts. Node operators need to update their software before October 26.
Ethereum developers postponed the Glamsterdam upgrade scheduled for the Hoodi test network on October 26, 2026. The Ethereum Foundation’s October 22 notice says teams are examining how existing mainnet smart contracts would behave if EIP-8037 changes gas accounting. No replacement test date has been set. Hoodi node operators need software releases that remove the old activation settings.
The decision was taken during the 248th All Core Devs Execution meeting on October 22. Hoodi had been scheduled to activate at 17:42:48 UTC on October 26, or 20:42:48 in Türkiye, at epoch 132,352. An epoch is a period used to organise validators’ duties. The postponement also removes the increase to a 200 million gas block limit planned for that activation.
Hoodi’s activation settings are removed; mainnet remains unscheduled
The change merged into the Hoodi repository on October 22 removed the execution layer’s Amsterdam timestamp, the consensus layer’s Gloas settings and its gas-limit schedule. The change removes rules scheduled for future activation while preserving blocks already processed. Amsterdam and Gloas are the two parts of the upgrade collectively called Glamsterdam.
Glamsterdam’s Sepolia test announced in September took place on October 6. A postponement notice now appears at the top of the October 16 Hoodi announcement; its earlier date and client table must no longer be used as activation instructions. Ethereum mainnet has no confirmed upgrade date. ETH holders and mainnet users do not need to take action because of the postponement.
Postponement still requires an operator update. A Hoodi client that retains the October 26 settings may follow different rules from the rest of the network. Operators should check that their release notes explicitly remove the old Hoodi activation, rather than relying on a version number alone. Anyone using custom network settings must update those configurations too.
How gas accounting can change contract behaviour
Gas measures the computing and data resources an Ethereum transaction uses. EIP-8037 proposes higher costs for creating accounts, contract code and storage entries, with those costs metered separately from execution. It aims to limit growth in the data nodes must retain as blocks accommodate more work. Users pay both types of gas cost. EIP stands for Ethereum Improvement Proposal; the technical change described here is still under review.
A transaction would still specify one gas limit, but software would track an execution budget and a reservoir for creating new state. State creation draws on the reservoir first and, once that runs out, on the execution budget. The 63/64 limit on execution gas forwarded to a child contract call does not apply to the reservoir. A contract querying its remaining gas through gasleft() sees only the execution side.
Under the proposal, undoing state creation restores the gas charged for that state. The execution budget receives the amount it supplied and has not yet recovered; the remainder goes back to the reservoir. Remaining execution gas can therefore rise after an operation. In the example of writing a value to a storage slot that was empty at transaction start and then clearing it, the difference between two gas readings can become negative. A negative difference can stop execution or wrap the number beyond its valid range, depending on the arithmetic. The risk depends on where the contract takes the readings and how it uses the result.
ChainSecurity’s October 13 technical analysis examines applications that use remaining gas to infer why a call to another contract failed. Code that previously stopped for lack of gas may continue under the new accounting and lead an application to make the wrong decision. Checks that allocate enough gas before a call are not universally invalid: the budget must cover the new costs, every possible path through the call and its overhead.
“a failure path that previously reverted can now complete”
ChainSecurity says it found 13 real-world examples
In its October 22 post, ChainSecurity said it had found 13 real-world examples and was working with affected teams before publicly disclosing the problems. It urged developers to check their code while the Ethereum Foundation assessed how many contracts were affected and in what ways. The post did not name the projects or announce completed attacks or losses.
The Foundation’s testing guide dated August 24 describes replaying historical mainnet transactions under the revised costs. It divides the results into four groups: unaffected transactions, transactions succeeding with different gas use, failures fixed by a higher limit, and potential breakage even with a higher limit. The last group includes fixed-gas calls, code branching on remaining gas and transactions signed in advance with a fixed limit. The Foundation’s August results identify code patterns for application teams to examine.
Application teams need to test what happens after failed calls as well as successful transactions. For wallets and the RPC services that connect applications to the network, the proposal requires eth_estimateGas estimates to account for execution and state-creation costs. Calculations using old constants can allocate too little gas and cause transactions to fail. Teams also need to follow any subsequent changes to the proposal.
Which updates should operators check?
Hoodi node operators need to check both execution and consensus clients. Validator operators must update both the beacon node, which follows blocks and votes, and the validator client, which manages the validator’s signatures. Operators using block-building services or other infrastructure providers should also follow their providers’ Hoodi instructions. The Foundation’s current notice links to client releases incorporating the postponement.
| Client | Release | Published instruction |
|---|---|---|
| Lighthouse — consensus | v8.3.2 | Update Hoodi beacon nodes, validator clients and execution clients before the old October 26 activation time. |
| Besu — execution | 26.10.1 | Hoodi operators should install the release that removes Amsterdam activation. |
Lighthouse v8.3.2, released on October 23, supersedes the Hoodi instructions in v8.3.0 and v8.3.1. Users upgrading from v8.2.x or earlier are also directed to the v8.3.0 notes for database migration and system requirements. Besu 26.10.1, released on October 22, is identical to 26.10.0 apart from removing Hoodi activation. Both teams say mainnet users do not need an update solely because of the postponement.
Glamsterdam’s other main goals include ePBS, which separates the roles of block proposers and builders within the protocol, and block access lists that support parallel transaction validation. Developers will announce a new Hoodi schedule separately after examining the effects on contracts.
Ethereum’s ACDE 248 recording from October 22 documents the developers’ meeting at which the postponement was decided. The official agenda includes EIP-8037 and EIP-8038’s effects on contracts. The link opens the approximately 97-minute recording.
