Ethereum put Glamsterdam’s Hoodi fork on hold. What did auditors find?

이미지 불러오는 중

이미지 불러오는 중

이미지 불러오는 중

Share

Ethereum developers have put Glamsterdam’s Hoodi testnet fork on hold while they work through findings about how applications behave when a transaction runs low on gas. The upgrade changes the way the network charges for some operations that touch or expand its state, and auditors found that even contracts written before the upgrade can behave differently under the proposed rules.

• Ethereum developers had targeted 26 October for the Hoodi fork before postponing it. A 6 November developer update kept the fork on hold while the teams addressed issues raised during review.

• Two proposals, EIP-8037 and EIP-8038, affect the cost of creating state and accessing existing state. The change can alter how much gas a contract has left at a particular point in execution.

• ChainSecurity identified cases where a call can fail and the contract that made it can still complete its failure handler. Under the earlier gas rules, the same path might have caused the outer transaction to revert.

• Developers are checking assumptions across client implementations and existing contracts. ChainSecurity, Dedaub and internal reviewers contributed to the review, according to the Ethereum Foundation update.

• Work on Hegota continues in parallel. The evidence to watch for Glamsterdam is a revised testnet schedule and results from the tests behind it.

Ethereum’s developers were due to fork Hoodi on 26 October. They postponed that test, and on 6 November Ethereum Foundation developer Marius van der Wijden said it remained on hold while developers worked through issues identified in the gas review.

JUST IN: Ethereum’s Glamsterdam upgrade will activate on Sepolia on Oct. 6 The testnet deployment will mark the next major step toward bringing Glamsterdam closer to Ethereum’s mainnet. pic.twitter.com/uW9703RGHC — crypto.news (@cryptodotnews) October 4, 2026

The concern centres on a detail most people encounter only when a transaction fails. Contracts can call other contracts and decide what to do if those calls come back unsuccessful. The code that makes that decision can look exactly the same after an upgrade, yet take a different path because the network now charges for parts of the operation differently.

That is why an upgrade aimed at the way Ethereum accounts for state has become a question for application developers as well as the teams that write Ethereum’s clients. Both need to know which old assumptions survive the change.

What Glamsterdam changes about gas

EIP-8037 changes how the protocol accounts for operations that create state. Ethereum’s state includes records such as contract storage. A change can persist across transactions, so its cost has implications for the nodes maintaining the chain after the original transaction finishes. The proposal separates the accounting for some state creation from ordinary execution gas, with a reservoir that can be drawn on for eligible operations.

EIP-8038 reprices operations that access state. The two proposals affect different pieces of an execution path. A contract might read a value, make an external call and write a result. Reviewing the proposed price of the final write alone misses the effect of the earlier reads and calls on the budget available when execution reaches it.

A familiar application can therefore produce a different result even when a user supplies the same transaction inputs. The important question is which differences reflect the intended repricing and which expose an assumption that a client or a contract relies on.

How a failed call can change the final result

Consider a contract that calls a second contract to perform one step in a larger operation. If the second contract fails, the caller can stop everything or handle the failure and continue. A batch processor might record an unsuccessful item and move on. Another application might expect the whole operation to revert if the failed call exhausts enough gas.

ChainSecurity’s analysis describes how the new accounting can affect that distinction. Ethereum already limits how much gas a caller can pass forward under the EIP-150 rule. Roughly one sixty-fourth can remain with the caller in the relevant case. The issue is how much the caller actually has available once execution returns, and what it costs to finish the instructions on that path.

Suppose an application treats a call failure as an ordinary business outcome. If it has enough gas to finish the failure handler, it might record a result or continue the rest of the transaction. If it runs out while doing so, the outer transaction reverts. Those outcomes leave different records even though the inner call failed in both cases.

The auditor also looked at checks based on gasleft(). A contract can use the instruction to compare its remaining execution budget with a hard-coded minimum. A threshold calibrated under one schedule can become a poor predictor under another, particularly when the contract encounters state operations or forwards gas to another address. The contract has no automatic way to revise a number its developer embedded when it was deployed.

What the auditors need to establish

The Foundation’s November update describes eight assumptions under review. There are at least two distinct questions for testing. Clients that implement the new rules must arrive at the same result for a given transaction. Application reviewers must also identify cases where that shared result differs from what existing contracts expect.

A test for the first question can execute the same transaction against several clients and compare state and gas results. A test for the second needs to follow the application’s own logic. It matters whether the contract treats a failed callback as a cue to proceed, whether it records a state change before the call and whether it can distinguish a business rejection from a call that never had enough gas.

Those paths can be easy to miss in a conventional deployment test. A typical transaction budget may carry the call and its handler through both schedules. A deliberately tight budget can expose the difference. Boundary tests therefore have to include failed calls and cases close to the amount of gas required to enter or finish the failure handler.

What Hoodi can show

Glamsterdam had already reached Ethereum’s Sepolia testnet, where developers tested a 200 million gas limit. Hoodi would give developers a further shared deployment in which to exercise the revised upgrade.

A public testnet fork gives client teams and application operators a common environment in which to run these checks. Operators can update clients on a shared schedule, compare their results and test tooling against the fork rules. Application teams can check whether transaction simulation and gas estimation account for the same changes they are seeing during execution.

A successful Hoodi fork would give developers evidence about the versions and transactions they tested. The longer-term question is what representative applications do at the limits of their gas budgets. A new fork date will be easier to assess alongside a record of which cases were reproduced, what changed in response and how the teams tested it.

The gas work runs alongside other fixes. Ethereum developers separately revised the validator deposit specification while the Hoodi gas review was underway. Those fixes need their own tests because they affect a different part of the fork.

For now, the latest developer update on the gas risks gives a reason for the hold and says work on Hegota is continuing. It leaves the timing of the next Glamsterdam test to a subsequent decision.

JUST IN: Ethereum delays Glamsterdam upgrade on Hoodi testnet The Ethereum Foundation postponed the Oct. 26 activation to review how EIP-8037 interacts with mainnet smart contracts, with no new date announced. pic.twitter.com/F2HmXs1meR — crypto.news (@cryptodotnews) October 23, 2026

How gas limits and state costs fit together

A higher block gas limit gives Ethereum room for more work under its accounting system. The price assigned to an individual operation determines how much of that room the operation occupies. A change to the limit and a change to the prices can therefore affect different parts of the same transaction.

Some work ends when the transaction does. Creating state is different because the data can persist, leaving node operators with something to store and process later. A new storage slot, account or contract can add to that burden even if the application that created it receives little traffic afterwards.

EIP-8037 changes how the cost of certain state creation is accounted for. EIP-8038 reprices access to state, which can include operations involving records that already exist. A transaction that reads a value, calls another contract and creates a storage entry can encounter both changes during a single run.

A higher block limit alone does not say whether that sequence will cost more or less. It describes the room available to the block as a whole. The transaction’s path and the price of each operation determine whether it can fit within the gas the sender supplied.

That distinction was already relevant when Sepolia began testing Glamsterdam with a 200 million gas limit. The test showed what developers were running on that network. The hold on Hoodi addresses whether the rules are ready for the next testnet, including the behaviour of applications that rely on earlier gas assumptions.

The eight assumptions under review

The Ethereum Foundation’s auditor repository groups its examples by changes to operation prices and changes to the way gas is tracked. The numbers in the repository come from a pinned version of the proposed specification and can change if the proposals are revised.

The first group of concerns involves fixed allowances and the cost of completing work after a call. Developers may have set a gas limit for an operation that now costs more. A reserve intended to pay for a final write may no longer be sufficient. In another case, the small fraction retained by a caller can be enough to complete a failure path that the application previously expected to revert.

The accounting changes introduce other possibilities. If a separate reservoir can still fund eligible state creation, a caller can write a record after a failed call even when its ordinary execution budget is tight. The caller’s final outcome can then depend on which operations use that separate budget.

Clearing a slot created earlier in the same transaction can return some state gas immediately in the reviewed specification. A reverting call can also return state gas. Code written on the assumption that all gas consumed before a revert is gone can therefore misread what happened.

A pair of gasleft() measurements can likewise give an incomplete view of the cost of work. A contract that uses the difference to bill someone or calculate a refund relies on assumptions about how gas changes between the two readings. Charges drawn from a separate pool and state gas returned during execution can change the relationship.

The eighth case involves EIP-7702, which allows an account to authorise delegation to contract code. A transaction can be included even when an authorisation inside it did not take effect because it ran short of gas. A wallet or service that uses transaction inclusion alone to infer that the delegation worked could treat an incomplete action as finished.

The repository says many findings received by its authors concerned fixed amounts or reserves. It asks developers and auditors to test their applications against the examples and report problems. The inventory identifies patterns that require review. It does not imply that every application using one of those patterns will produce a loss.

How a failed call can still leave a successful transaction

An Ethereum transaction can contain several calls. A contract can request that another contract perform a step and then decide how to respond to the result. A failed inner call and a failed transaction are distinct outcomes.

A batch processor provides a useful example. If one item fails, the processor might record that failure and move on to the next item. If it runs out of gas before it can record the result, the outer transaction can revert and undo earlier changes. The same inner failure therefore leaves different final state depending on what the caller can do afterwards.

A different application might treat a failed call as a reason to change who can submit a request or whether it is allowed to be tried again. If the caller can complete a path the application expected to roll back, the resulting state can persist. The security consequence depends on what the completed path actually records.

An actor may be able to choose how much gas a transaction supplies. If that person can leave enough gas for the outer contract to enter a path but too little for the inner call to finish, the failure can be induced by the transaction budget. A contract that acts on the failure needs to distinguish that case from a call that reached the callee and legitimately failed.

The EIP-150 forwarding limit is one part of this. A caller that forwards as much gas as permitted retains roughly one sixty-fourth under the relevant rule. The retained amount still has to pay for the instructions that follow. Whether those instructions complete depends on the schedule and the accounting applied to them.

A contract can be vulnerable to a narrow range of budgets. Give the inner call enough gas and it works normally. Give the entire transaction too little and the outer path reverts. The problematic interval is where the inner call fails while the caller still has enough to carry out an action the developer did not intend for that failure.

Why changing a fixed gas number may not solve the problem

A hard-coded threshold can give a contract a simple way to check that it has enough gas before it makes a call. The developer may have tested the threshold with common transactions and left a buffer for the work that follows. The number becomes a dependency on the schedule under which it was chosen.

An operation can also cost different amounts depending on whether the application is updating an existing record or creating one. A transfer to someone who already has a balance can encounter a different storage path from a transfer that creates a first balance. A test that covers only repeat recipients can miss the more expensive path.

The point where the contract measures gas matters. A reading immediately before the call is different from a reading after several state accesses and the call itself. A contract that infers the reason for failure from the latter reading assumes that it understands what could have been charged or returned in between.

Changing a stipend can have consequences of its own. It can let a previously failing path complete, and it can also give the callee enough gas to perform work it could not perform under the old allowance. The developer needs to know what the allowance was intended to prevent before adjusting it.

Some contracts can be changed through a governance or administrative process. Others are immutable or depend on components that cannot be changed in place. Even when a contract can be revised, services that estimate, sponsor or relay its transactions may also need to update their own assumptions.

What a convincing reproduction needs to show

A test can begin with the same transaction, state and gas limit under the old and proposed rules. A comparison should identify which call returns a failure, what the caller does next and whether the transaction records any changes that did not persist before.

Testing budgets just above and below the threshold helps show whether the effect occupies a narrow range. It can also identify where execution diverges. An early balance check, the amount forwarded to the callee and a write in the failure handler are different points at which a change can surface.

The reviewer then has to ask who can reach that path. A change reproduced in a test contract establishes a difference in execution. A real application may require an authorisation, check a separate condition or make the affected operation retryable. Those details determine whether someone can force an unwanted outcome.

There is also a separate test for client teams. All execution clients should reach the same result for a transaction under the same fork configuration. A disagreement between clients is a different problem from all clients consistently producing a result that an application did not anticipate.

A test suite needs successful paths as well as failures. Forcing every failed call to revert might prevent one unwanted state change but also remove a legitimate ability to complete the rest of a batch. The intended application behaviour determines what a fix needs to preserve.

A good reproduction should make the final state easy to inspect. If a failure record remains after one run and disappears after another, the test can show the exact difference rather than relying on a general report about gas usage. That makes it easier to assess both the risk and a proposed change.

What public testnets add after a local reproduction

A developer can test an edge case on a local fork or in a controlled client environment. A public testnet then lets several operators run the same upgrade and compare its behaviour in shared conditions. It also gives wallet and infrastructure teams somewhere to test their own software against the active rules.

Sepolia and Hoodi serve different steps in that process. The Sepolia activation showed that developers could run the planned code on that network and examine its operation under the configured gas limit. Hoodi gives them a further deployment after addressing findings that became important during the review.

The applications, traffic and historical state on a testnet differ from mainnet. A smooth fork can give evidence about client agreement and routine transactions without exercising every contract pattern that users rely on. A targeted reproduction supplies evidence about an edge case that may be absent from ordinary testnet traffic.

The upgrade instructions are another part of the test. An operator needs a release that implements the intended configuration and a precise activation point. An application needs to know when its simulations should start using the revised rules. A new date is useful alongside those details.

The October postponement and the November status report describe the same hold at different times. The first removed the scheduled Hoodi date. The second explained that the issues still had to be resolved. The next deployment notice can show which changes are ready for operators to test.

How wallets can report success while an action fails

Wallets commonly estimate gas before asking a user to sign. The estimate depends on the state and rules the node applies in its simulation. A service using an older fork configuration can give an estimate that is no longer suitable for a transaction the current chain executes.

A transaction that reverts can still cost the sender gas. An outer transaction that completes after catching an inner failure can be harder to interpret. The chain can record the overall transaction as successful while an action within it did not happen. The wallet may need the application’s events or state to explain the difference to the user.

Relayers and transaction sponsors face a related problem. They may choose the budget or pay the costs for a transaction that someone else requests. If the budget no longer covers the intended path, the sponsor can pay for execution that fails to deliver the requested action.

Indexers can see the effect after execution. A failure path that now completes can produce logs or state changes the downstream system did not previously see. The indexer still follows the chain’s actual state. An application that relies on the indexer may need to change how it interprets the resulting record.

An end-to-end test can compare a wallet’s estimate, a relayer’s submitted budget, the client’s execution result and the interface’s explanation. Each step can succeed on its own while the user still receives a misleading account of which actions took effect. The distinction matters most where the application treats a result as final.

What would resolve the Hoodi hold

The Foundation is asking application teams to identify the assumptions they use and supply cases developers can reproduce. Some issues may be addressed through changes in the proposed gas rules. Others may require an application or infrastructure provider to revise how it handles the new behaviour.

If the specifications change, the relevant test is whether a case that previously diverged now reaches the intended result. If developers retain a behaviour change, application teams need enough detail to determine whether their software relies on the previous result. Both outcomes depend on describing the affected call and what persists after it.

A revised specification also has to reach the client builds operators run. A build that supported an earlier Glamsterdam configuration may not contain subsequent changes. The release numbers in a new Hoodi notice would identify which versions can be tested together.

The Foundation’s November update says work on Hegota continues in parallel. That means the hold on the earlier fork does not account for every development decision on the next one. For Glamsterdam, the next relevant milestone is a revised Hoodi schedule with a configuration that developers are ready to run publicly.

A successful fork would give the teams a shared record to examine before a mainnet decision. The cases that prompted the delay remain the clearest tests of whether the revised rules are ready. Those tests have to show what happens when a call fails close to its gas limit and the outer transaction still has work left to do.

What the proposed gas numbers show about different paths

The Foundation’s repository gives a concrete example of the difference between creating state and updating it. Under its pinned Glamsterdam specification, a cold write that creates a new slot is split between execution costs and a substantially larger state charge. A write to an existing slot is repriced too, but follows a different calculation.

The difference can reach two users making what appears to be the same application request. One user may have used the service before, so the contract updates an existing entry. Another may need a fresh record. A gas allowance that works for the first user can fail for the second.

The repository also says a separate reservoir is available only above a specified transaction gas limit in the configuration it tested. In smaller transactions, state costs instead come from the ordinary budget. That threshold makes it important to test several budgets rather than assume the reservoir behaves the same way for every call.

Code that reads remaining gas can therefore observe only part of the transaction’s resources in some cases. The data it reads are still meaningful for the budget the instruction exposes. What changes is the inference the application can draw about the total resources that have been consumed or remain available.

The gas examples are tied to the proposed configuration. They do not give a single multiplier that can be applied to a wallet’s existing estimates. A first-time storage write, a call using a fixed stipend and a failed delegation each require a separate check because they encounter different parts of the rules.

That is also why a revised Hoodi date would be more useful with the specification revision and the list of cases covered by the release. Those details would let teams rerun tests that match their applications before drawing conclusions from the testnet’s overall stability.

What to Watch

• Hoodi schedule: A revised fork date should identify the client versions and fork configuration operators are expected to run.

• Client agreement: Cross-client tests can show whether execution clients reach the same state and gas results around the new boundaries.

• Contract behaviour: Reproductions should show when a failed external call leaves the caller enough gas to finish and what the outer transaction records.

• Proposal revisions: Changes to EIP-8037 or EIP-8038 will help show which review findings required a protocol change.

• Application tooling: Simulation and gas estimation results can show whether wallets and infrastructure providers correctly reflect the fork rules.

FAQs

What is Hoodi?

Hoodi is an Ethereum testnet used to exercise network upgrades in a shared environment. The postponed fork would have applied Glamsterdam rules there so operators and application teams could observe them together.

Why was the fork postponed?

Developers are reviewing findings tied to gas accounting and the way existing applications handle failed calls. They are also checking that client implementations agree on what happens under the proposed rules.

Does the hold change Ethereum mainnet today?

The November update concerns the Hoodi test fork. It does not announce activation of the proposed gas rules on mainnet or give a new mainnet date.

Can a contract change behaviour without an update?

Yes. Its instructions execute under the network’s gas schedule. If a changed charge leaves a different budget for an external call or its failure handler, the same instructions can lead to a different result.

Does a failed call always revert the entire transaction?

A caller can handle an unsuccessful external call and continue. Whether the outer transaction completes depends on the caller’s instructions and the gas remaining to execute them.

What does a gas reservoir do?

It gives eligible state creation operations a separately tracked budget under the proposal. Reviewers have to consider how that budget interacts with the execution gas a caller can inspect or pass forward.

Why do auditors test low-gas paths?

A call with a generous budget might behave the same under both schedules. A transaction close to its execution limit can reveal whether a handler completes under one schedule and reverts under the other.

Has Hegota work stopped?

The Foundation’s November update says Hegota work continues in parallel. That work has its own milestones, while Glamsterdam’s Hoodi fork remains subject to the gas review.

Disclaimer: This article is for informational and educational purposes only and does not constitute financial, investment, legal or tax advice. Cryptocurrency and blockchain activities carry risks, including loss of funds. Readers should conduct their own research and consult a qualified professional where appropriate. Information reflects publicly available material as of 9 November 2026 and may change as developers publish further updates.