TLDR:
- Ethereum core developers delayed the Glamsterdam fork on Hoodi after a ChainSecurity report.
- Gas already spent can return mid-transaction, which lets the gasleft() value rise during execution.
- A failed sub-call can return gas, so an unreachable path runs and the transaction looks successful.
- Developers will review contracts this week, and the fix may need coordination or specification changes.
The Glamsterdam fork on Ethereum’s Hoodi testnet has been delayed after ChainSecurity flagged compatibility risks in EIP-8037 and EIP-8038.
Core developers are now reviewing whether the upgrade specification needs changes. ChainSecurity has identified 13 real-world cases.
Why the Hoodi Fork Was Postponed
Ethereum researcher Toni Wahrstätter shared the update on X after core developers paused the rollout last week. The Glamsterdam fork had been planned for Hoodi as a testing step.
The delay followed a report from ChainSecurity on how EIP-8037 interacts with certain contracts. Developers spent the weekend assessing the scope, and Wahrstätter said the picture is now well understood.
Contracts that hardcode forwarded gas were already known to be affected by repricings. For example, state writes through SSTORE become more expensive under the new rules.
However, the latest finding involves a different issue. Some coding patterns rely on an invariant that EIP-8037 breaks.
In his post on X, Wahrstätter explained the new problem. He wrote, “Gas already spent can come back mid-tx, so gasleft() can go up.”
Contracts that assume gas usage only moves downward may therefore behave in unexpected ways. As a result, code built around earlier gas behavior could fail once the change goes live.
ChainSecurity’s cases come from real-world contracts rather than theoretical examples. Because of this, developers are treating the findings as a practical compatibility concern for the upgrade. Accordingly, the Glamsterdam fork remains on hold while the review continues.
Three Gas Problems and the Next Steps
Wahrstätter described two problems tied to the broken invariant. In the first, a before-and-after gas counter underflows and the transaction reverts.
In the second, a failed sub-call hands gas back, so an unreachable path runs. The transaction then looks like it succeeded. Both outcomes stem from the same change in how gas is returned during a transaction.
A related but separate problem affects gas measurement. Contracts that compare GAS before and after a call may undercount usage.
This happens because the state gas reservoir is not visible during execution. Therefore, tools and contracts that track gas this way may report figures lower than actual usage.
Wahrstätter said the Hoodi delay “bought time but won’t resolve the issue.” The Glamsterdam fork delay gave contributors extra time to study each affected pattern.
This week, contributors plan to examine contracts closely and confirm that no case is missed. He wrote, “It’s now about deciding how to proceed.”
Resolution might only need coordination among dapps, core developers, auditors, and node operators. In the worst case, the specification itself would need changes.
Wahrstätter urged app developers and auditors to “check your contracts for issues with EIP-8037/EIP-8038, and report them.” He also asked readers to share the post with other app developers.
