Ethereum Foundation developer Marius van der Wijden said in a November 6 update that core developers will not fork the Hoodi testnet until problems identified by security firm ChainSecurity are resolved. Hoodi is the public test network where Ethereum rehearses protocol changes before they reach mainnet. He asked contract developers and auditors to check their projects against eight gas invariants that the upcoming Glamsterdam upgrade breaks. Gas is the unit in which Ethereum prices every operation a transaction performs, so when those prices move, code written under the old numbers can behave differently even though the code itself is unchanged.

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

Two proposals reshape gas costs

Two proposals drive the change. EIP-8037 raises the price of creating new state — 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 pause on Glamsterdam testing followed ChainSecurity's October 13 review, as previously reported. 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.

A mined transaction no longer proves a delegation applied

EIP-7702 lets an ordinary Ethereum account run smart-contract code by signing an authorization that points to a delegate contract. The mechanism went live with the 2025 Pectra upgrade and underpins the smart-account features that wallets have been rolling out since. 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 a 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 can be accepted, run out of gas while applying the authorization and land 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. The pattern is documented with example code, and no affected wallet is named.

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 behavior 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 functions 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.

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 supplies 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 afterward. 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, the fork that established the current cold-versus-warm pricing for reading state. Ethereum's state — the running record of accounts, balances and contract storage that nodes track — 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 and 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, and that most flagged issues could be fixed by raising a gas limit. It told regular users 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

According to the repository, the Foundation is collecting feedback ahead of the next All Core Developers call, the standing forum where Ethereum protocol changes are agreed. 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, testing 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 glamsterdam@ethereum.org rather than in public issues, so that problems can be fixed before details spread.

This article originally appeared on Coindoo.