Ethereum’s Next Upgrade Could Change How Old Contracts Run

Key Takeaways

1. Hoodi testnet fork held until gas issues resolved
2. Foundation lists eight gas assumptions Glamsterdam breaks
3. Empty-account delegation now costs 235,606 gas, from 25,000
4. Mined transaction no longer proves delegation applied

In a November 6 update, Ethereum Foundation developer Marius van der Wijden said core developers would not fork the Hoodi testnet until problems found by security firm ChainSecurity are resolved. He asked contract developers and auditors to check their projects against eight gas invariants that the upgrade breaks.

Eight gas rules developers can no longer rely on

An invariant, in this context, is a rule that code treats as always true, such as “a fixed gas budget is enough for this call” or “a mined delegation has taken effect”. The Foundation’s invariants repository lists eight that change under Glamsterdam and says most findings so far involve two of them.

Two proposals drive the change. EIP-8037 raises the price of creating new state, meaning new accounts, storage slots and deployed code, and meters it separately from ordinary execution. EIP-8038 raises the price of reading and updating state that already exists. On the specification the repository tests against, writing to a fresh storage slot rises from 22,100 gas to 110,020, updating a warm existing slot from 2,900 to 10,100 and deploying code from 200 gas per byte to 1,530. Those figures move if the specification does.

The earlier pause on Glamsterdam testing followed ChainSecurity’s October 13 review. The repository extends those findings with the Foundation’s own scan of contracts verified on Sourcify, a public registry of contract source code, and with offchain cases such as software that reads transaction receipts.

The eight assumptions Glamsterdam breaks

INV-1A call running out of gas no longer guarantees the whole transaction fails. INV-2Clearing a value set earlier in the same transaction refunds gas at once. INV-3Gas spent by a reverting call is no longer gone; storage gas comes back. INV-4 · check firstA fixed gas amount may no longer cover the job. INV-5Remaining gas can rise mid-call, so before-minus-after stops measuring cost. INV-6The 1/64 of gas kept after a failed call can now finish and record a failure. INV-7 · check firstGas reserves and stipends sized for today fall short. INV-8A mined EIP-7702 delegation may not have applied and can be reused.

A mined delegation no longer proves a wallet is set up

EIP-7702 lets an ordinary Ethereum account run smart-contract code by signing an authorization that points to a delegate contract. The authorization is meant to be used once. Before Glamsterdam, its full cost was charged up front, so a transaction that could not pay was invalid and never reached a block. If the transaction was mined, the delegation had been applied.

The repository’s INV-8 entry explains what EIP-8037 changes. Part of the cost now depends on the account’s state and is charged only while the authorization is processed. Delegating from an empty account costs 235,606 gas, against 25,000 before. A transaction budgeted at the old figure is accepted, runs out of gas while applying the authorization and lands in a block with a failed status. The delegation is rolled back, and so is the increase in the account’s nonce, the counter that marks an authorization as used. The signed authorization, however, is now public and still valid.

On its own, that leaves a wallet unconfigured rather than compromised. The danger comes when the delegate contract lets anyone call its setup function. An attacker can then resubmit the exposed authorization in their own transaction, call setup first and name themselves the account’s owner. Front-running authorizations in the public mempool was already possible. The repository’s point is that a failed transaction now publishes a valid authorization by itself, so routing it privately offers no protection. It documents the pattern with example code and does not name any affected wallet.

The practical change falls on wallets, relayers and indexers. The repository advises checking the account’s code and nonce after a delegation transaction instead of trusting the receipt. Any failed authorization should be treated as exposed and cancelled, either by advancing the account’s nonce or by delegating again to a safe contract. A specification change that would charge the worst-case cost up front has been suggested but not adopted, and developers are told to build as if the current behaviour stays.

Gas budgets often sit outside the contract

The broadest entry, INV-4, covers any gas amount fixed before the fork. It may now be too small wherever it is written: contract code, a settings value, a signed message or offchain software. That last group includes relayers, services that submit transactions on users’ behalf, as well as keepers and exchange withdrawal systems.

First-time recipients are the most common trigger. Sending a token to an address with a zero balance creates a new balance slot, and sending ETH to an empty address creates a new account, both of which EIP-8037 prices far higher. According to the repository, a transfer that fits in 65,000 gas today can need more than 150,000.

Where the fixed number lives decides how bad a shortfall gets. In offchain software, the whole transaction reverts and can be resent with more gas. In a contract, its settings or a signed message, only the inner call fails. If the outer contract catches that failure, the outcome is often final: a message stored as failed, a callback skipped or rewards booked wrongly. Some of these numbers cannot be edited at all, including multisig transactions signed before the fork, signed meta-transactions and cross-chain messages already in flight.

INV-7 applies the same problem to gas held in reserve. Solidity’s transfer and send pass a fixed 2,300 gas, but a receiving contract that writes a new storage slot now needs more than 110,000. Smart wallets, payment splitters and vaults with logic in their receive functions are the obvious candidates.

Fed Official Questions Stablecoins’ Cash-Out Promise

Failure paths that once reverted can now finish

ChainSecurity’s October 13 analysis explains why some protections that passed earlier audits may stop doing their job. Contracts often catch a failed external call so they can record the failure, skip an item or try a fallback. That becomes dangerous when someone deliberately supplied too little gas, an attack called insufficient gas griefing, because an operation that should be retryable gets marked as permanently failed.

Contracts typically defend against this in two ways. Some check how much gas remains after the call. Others rely on the failure handler being too expensive to complete. Glamsterdam weakens both. EIP-8037 gives transactions with a gas limit above 16,777,216 a separate reservoir for storage costs that the usual gasleft() check does not see. Reverting a call or clearing a freshly written slot can also hand spent gas back. In ChainSecurity’s words, “Even with unchanged contract code, a failure path that previously reverted can now complete.”

The firm now advises against inferring why a call failed from the gas left afterwards. Its preferred approach is to let the whole operation revert where possible, or to keep a recovery path instead of making an irreversible decision based on remaining gas.

An earlier audit cannot close that gap on its own, because it judged the code against the gas rules in force at the time. The Foundation has engaged ChainSecurity and Dedaub alongside its internal audits, but its November 6 post acknowledges it cannot review every project, especially offchain code. Design choices also shape the fix. A gas limit stored as an adjustable setting can simply be raised, while one written in as a fixed constant may leave redeployment and migration as the only route.

Why Ethereum is pushing ahead with repricing

The Foundation’s case for the change rests on pricing accuracy. Its August guidance for contract developers said gas prices for state operations were last adjusted in the 2021 Berlin fork. Ethereum’s state has grown significantly since then, and recent gas limit increases have sped that growth up. The post called the repricing a prerequisite for raising the gas limit further. It said the new schedule is derived from a performance target supporting roughly a threefold increase in base throughput.

The same post reported that replaying historical mainnet transactions under the new prices left the large majority unchanged. Most flagged issues could be fixed by raising a gas limit. It told regular users that no action was needed, because updated wallets and infrastructure would handle the change.

The November findings put more weight on that last clause. Handling the change now includes checking account state after a failed delegation and sizing relayer budgets for first-time recipients, work the old gas rules never demanded.

What the next core developer calls decide

The repository says the Foundation is collecting feedback ahead of the next All Core Developers call. Depending on the response, it may slightly change EIP-8037 and EIP-8038 or leave them as they are. Hoodi stays unforked until the issues are resolved, and the November 6 post gives no new date. According to the same post, work on Hegota, the upgrade planned after Glamsterdam, continues in parallel.

Before Hoodi forks: who checks what

Contract teams: paste addresses into the Foundation’s affected-contracts lookup. Then review any code that hardcodes gas values or branches on remaining gas, whether listed or not.

Wallets and RPC providers: update gas estimation for the new schedule. The Foundation warns that cached gas constants will underestimate costs and cause failed transactions.

Relayers, keepers and bundlers: make limits adjustable and re-estimate under the new rules with a margin. Test transactions on both sides of the reservoir threshold.

Auditors: the repository includes instructions for running its checks with an AI coding agent, with code and results kept local.

The signals worth tracking are a Hoodi fork date on the Foundation’s blog, any revision to either EIP’s specification and affected projects confirming fixes. The Foundation has asked teams to report problems privately to [email protected] rather than in public issues, so that problems can be fixed before details spread.