I’ve been watching Ethereum upgrades for years, and this one feels different. Just when the Glamsterdam upgrade looked ready to move forward on the Hoodi testnet, developers hit the brakes. The reason is not a flashy security hole or a broken client. It’s something quieter and, in many ways, more unsettling: auditors found that the new gas rules can make existing smart contracts behave in ways their creators never intended. Even code that has sat untouched for years can suddenly take a different path when a transaction runs low on gas.
Why Developers Put The Hoodi Fork On Hold
The plan had been clear. Ethereum teams targeted late October for the Hoodi testnet fork. That schedule slipped. By early November the pause was still in place while teams worked through a list of gas-related findings. Marius van der Wijden and others made it plain that the issues needed more attention before anyone would push the button again.
At the center of the review sit two proposals. EIP-8037 changes how the network accounts for operations that create new state. EIP-8038 adjusts the cost of reading or touching state that already exists. Together they reshape the gas budget available at different moments during a transaction. The code itself may look identical. The amount of gas left at a critical decision point may not.
That is the part that caught my attention. Most people only notice gas when a transaction fails and they lose a little ETH. Developers notice it when the same call sequence produces a different final state under the new rules. That is exactly what the auditors started documenting.
What Changes In How Gas Is Counted
State is the permanent memory of the chain. Contract storage, new accounts, and freshly created contracts all live there long after the original transaction ends. Nodes still have to store and process that data. The old gas model mixed the cost of creating state with ordinary execution costs. The new model tries to separate them more cleanly.
EIP-8037 introduces a kind of reservoir for certain state-creation operations. Eligible work can draw from that separate pool instead of draining the regular execution budget as aggressively. EIP-8038 then reprices many of the operations that simply look at or update existing state. A single transaction that reads a value, makes an external call, and then writes a result can feel both changes in one run.
The practical effect is easy to underestimate. A contract may still receive the same total gas limit from the user. The amount remaining at the moment it decides what to do with a failed call can be different. That small difference is often enough to change the outcome.
How A Failed Call Can Still Leave A Successful Transaction
Picture a batch processor. It loops through a list of items and calls another contract for each one. If one item fails, the processor records the failure and continues. Under the old gas schedule the failure path might have run out of gas and forced the whole transaction to revert. Under the new schedule the same failure path can finish, write its record, and leave the outer transaction looking successful.
ChainSecurity highlighted cases exactly like this. A call can fail, the caller can still complete its failure handler, and the final state ends up different from what earlier rules would have produced. The EIP-150 rule already limits how much gas a caller can forward. Roughly one sixty-fourth can stay behind. The question becomes whether that retained gas is now enough to finish work that previously would have aborted.
I’ve seen similar edge cases bite projects before. The difference this time is that the change is intentional and network-wide. Contracts that treated a failed call as a hard stop may suddenly treat it as a recoverable business outcome. Contracts that treated it as recoverable may now leave permanent records they never meant to leave.
The Role Of gasleft() Checks
Many contracts still contain hard-coded gas thresholds. A developer once measured how much gas a path needed, added a safety margin, and embedded the number. The contract later uses gasleft() to decide whether it is safe to proceed. Those numbers were calibrated under the old pricing.
When the cost of state operations shifts, the same threshold can become unreliable. A contract might think it has enough gas to finish a failure handler when it no longer does. Or it might have more than enough and complete a path the developer expected to revert. Either way, the original assumption no longer holds.
Auditors also noted that measuring gas before a call is different from measuring it after several state accesses. Charges drawn from a separate reservoir, or state gas returned during a revert, can change what the second reading shows. Code that bills users or calculates refunds based on the difference between two gasleft() readings can therefore produce surprising results.
Eight Assumptions Under The Microscope
The review team grouped the findings into a clear set of patterns. Some involve fixed gas allowances that no longer cover the work they were meant to cover. Others involve the small retained fraction after a call and whether it can now finish a failure path. A few touch the new reservoir itself: if state-creation costs can still be paid from that separate pool, a caller may write a record even when its ordinary execution budget is nearly empty.
Clearing a storage slot created earlier in the same transaction can return some state gas immediately under the reviewed specification. A reverting call can also return state gas. Code written on the assumption that gas spent before a revert is simply gone can misread the situation. A pair of gasleft() measurements can give an incomplete picture of total resources consumed.
One of the more interesting cases involves EIP-7702 authorizations. A transaction can be included even when an authorization inside it fails because of insufficient gas. Services that treat mere inclusion as proof that the delegation succeeded could therefore mark an incomplete action as finished. That is the kind of subtle mismatch that rarely shows up in ordinary testing.
The inventory of assumptions is useful precisely because it does not claim every contract using these patterns will break. It simply flags patterns that deserve a second look. Many of the reports the auditors received centered on fixed amounts or reserves. That tells you where most of the practical risk currently sits.
Why A Narrow Gas Window Matters
Not every transaction will notice the change. Give a call a generous budget and both the old and new schedules often produce the same result. Give the entire transaction almost nothing and the outer path reverts in both cases. The interesting zone is the narrow band in between.
In that band the inner call can fail while the caller still has just enough gas to execute an action the developer never intended for a failure. An attacker who can choose the gas limit supplied to a transaction may be able to force the contract into that window. Whether that leads to a real security problem depends on what the completed failure path actually records and who can reach it.
This is why boundary testing matters so much. Ordinary deployment tests often supply comfortable gas amounts. They never exercise the edge cases that only appear when the budget is deliberately tight. Teams that only test the happy path will miss the difference.
Client Agreement Versus Application Expectations
There are really two separate questions under review. First, do all the major execution clients produce the same final state and gas usage for a given transaction under the new rules? That is a client-agreement problem. Second, even if every client agrees, does the shared result match what existing applications expect? That is an application-assumption problem.
A test for the first question can run the same transaction against several clients and compare results. A test for the second needs to follow the application’s own logic. Does the contract treat a failed callback as a cue to proceed? Does it record a state change before the call? Can it tell the difference between a legitimate business rejection and a call that never had enough gas?
Those distinctions are easy to miss. A typical transaction budget may carry both the call and its handler through both schedules without incident. Only a deliberately constrained budget reveals the divergence. That is the kind of test the teams are now prioritizing.
What Public Testnets Actually Prove
Sepolia already ran a version of Glamsterdam with a 200 million gas limit. That gave teams a first look at the new configuration in a shared environment. Hoodi was meant to be the next step. A public testnet lets client teams and application operators update on the same schedule, compare results, and exercise tooling against the live fork rules.
Of course a testnet is not mainnet. The applications, traffic patterns, and historical state are different. A smooth fork can demonstrate client agreement and routine transaction behavior without ever hitting the rare contract patterns that real users rely on. Targeted local reproductions still matter. Public testnets then let multiple operators confirm those findings under common conditions.
Wallets, relayers, and indexers also need a place to test. Gas estimation that still uses the old fork configuration can produce numbers that no longer match actual execution. A transaction that reverts still costs gas. An outer transaction that completes after catching an inner failure can look successful while an expected action never happened. The interface may need the application’s own events to explain the difference to the user.
Why Changing A Fixed Number Is Not Always Enough
It is tempting to think the fix is simply to raise every hard-coded gas stipend. In practice that can create new problems. A larger allowance may let a previously failing path complete, which is sometimes the goal. It can also give the callee enough gas to perform work it could not perform before. The developer needs to understand what the original limit was meant to prevent before adjusting it.
Some contracts can be upgraded through governance or an admin key. Many cannot. Even when the contract itself can change, the services that estimate, sponsor, or relay its transactions may still operate on older assumptions. A full fix often requires coordinated updates across several layers of infrastructure.
First-time storage writes and updates to existing slots also differ in cost. A test that only covers repeat recipients can miss the more expensive path taken when a new record is created. Any revised stipend has to account for both cases.
What A Convincing Reproduction Looks Like
A useful test starts with the same transaction, the same starting state, and the same gas limit under both the old and proposed rules. The comparison should show which call returns failure, what the caller does next, and whether any state changes persist that did not persist before.
Testing budgets just above and just below the critical threshold helps map the size of the window. It also shows where execution first diverges. An early balance check, the amount of gas forwarded to the callee, or a write inside the failure handler can each be the point where the schedules part ways.
The reviewer then has to ask who can actually reach that path. A difference that appears only in a synthetic test contract is interesting. A difference that appears in a real application that requires specific authorizations or additional checks is more serious. Successful paths need testing too. Forcing every failed call to revert might prevent one unwanted state change while also removing a legitimate ability to finish the rest of a batch.
How Wallets And Infrastructure Can Misreport Success
Wallets estimate gas before asking a user to sign. That estimate depends on the rules the node applies during simulation. A service still using an older fork configuration can produce an estimate that no longer fits the transaction the current chain will execute.
Relayers and sponsors face a related problem. They often choose the budget or pay the cost for a transaction someone else requests. If the budget no longer covers the intended path, the sponsor can end up paying for execution that fails to deliver the requested action.
Indexers see the effect after the fact. A failure path that now completes can emit logs or create state changes the downstream system never expected. The indexer correctly follows the chain. The application that relies on the indexer may need to change how it interprets the resulting records.
An end-to-end test that compares the wallet’s estimate, the relayer’s submitted budget, the client’s execution result, and the final user-facing message can reveal gaps. Each step can look fine on its own while the user still receives a misleading account of which actions actually took effect.
What Would Clear The Path For Hoodi Again
The foundation has asked application teams to identify the assumptions they rely on and to supply reproducible cases. Some findings may be addressed by adjusting the proposed gas rules. Others may require applications or infrastructure providers to adapt to the new behavior. Both outcomes depend on clear descriptions of the affected call and the state that persists afterward.
If the specifications change, the test becomes whether a previously diverging case now reaches the intended result. If the behavior is kept, application teams need enough detail to decide whether their software depends on the old outcome. A revised specification also has to reach the client builds that operators will actually run. Release numbers in any new Hoodi announcement will matter.
Work on the next upgrade, often referred to as Hegota, continues in parallel. The hold on Glamsterdam’s Hoodi fork does not freeze every development track. For Glamsterdam itself, the next meaningful milestone is a revised schedule paired with a configuration that developers are ready to run in public.
Gas Limits, State Costs, And The Bigger Picture
A higher block gas limit gives the network more room for work under its accounting system. The price assigned to each operation decides how much of that room a given step occupies. Changing the limit and changing the prices therefore affect different parts of the same transaction.
Some work ends when the transaction ends. Creating state is different because the data persists. A new storage slot or account adds lasting work for node operators even if the application that created it later sees little traffic. EIP-8037 tries to reflect that reality more accurately. EIP-8038 adjusts the cost of accessing state that already exists. A transaction that mixes reads, calls, and new storage writes will encounter both changes.
That distinction was already relevant when Sepolia tested a 200 million gas limit. The test showed what developers were running. The hold on Hoodi asks a more precise question: are the rules ready for the next shared deployment, including the behavior of applications that still rely on older gas assumptions?
Practical Steps Teams Can Take Now
Application developers do not have to wait for a new fork date. Local testing against the proposed rules can already surface problems. Focus first on paths that involve external calls followed by failure handling. Intentionally constrain the gas budget. Compare the final state under old and new pricing. Pay special attention to any use of gasleft() or hard-coded stipends.
Infrastructure providers should check that their simulation environments can switch to the new fork rules. Gas estimation that remains stuck on the previous configuration will produce numbers that no longer match reality. Relayers that sponsor transactions need to understand whether their budgets still cover the intended outcomes.
Client teams will continue cross-client testing. Agreement on state and gas results at the new boundaries is a necessary condition before any public fork. Disagreement between clients is a different class of problem from clients consistently producing a result that applications did not anticipate.
What To Watch In The Coming Weeks
A revised Hoodi schedule will be the clearest signal that the teams believe the outstanding issues are under control. That announcement should identify the client versions and exact fork configuration operators are expected to run. Cross-client test results around the new gas boundaries will matter just as much as the date itself.
Reproductions that show a failed external call leaving the caller enough gas to finish, and that document exactly what the outer transaction records, will help everyone assess the remaining risk. Any changes to EIP-8037 or EIP-8038 will indicate which review findings required a protocol-level response. Simulation and gas-estimation results from wallets and infrastructure providers will show whether the wider ecosystem has caught up.
In my view the pause is the right call. Rushing a gas accounting change that alters the behavior of existing contracts would create more problems than it solves. The careful review of assumptions, the focus on boundary cases, and the parallel work on other parts of the upgrade all point to a process that values correctness over calendar pressure.
Ethereum upgrades have always involved trade-offs between progress and safety. This episode is a reminder that even well-intentioned changes to low-level accounting can surface assumptions that have been buried in deployed code for years. The teams are treating those assumptions seriously. That is exactly what users should want to see.
The next public signal will be the revised testnet plan. Until then, the most useful work continues quietly: reproducing edge cases, comparing client behavior, and deciding which findings require a protocol change and which require applications to adapt. The outcome will shape not only Glamsterdam but the confidence developers place in future gas-related upgrades.
For now the Hoodi fork remains on hold. The reasons are technical, specific, and worth understanding. Auditors found that the same instructions can produce different results when the gas schedule changes. That discovery has forced a closer look at assumptions many contracts have carried for a long time. The careful response is a sign of a mature process rather than a setback.
