Glamsterdam and EIP-8037: how unchanged Ethereum contracts can fail

The bytecode of an Ethereum contract can remain unchanged even as the rules governing its execution evolve. This is the core question behind the ongoing debate known as Glamsterdam gas dispute. To further clarify this issue, I have prepared a detailed walkthrough focusing on a specific practical query: what happens to an application's functionality if an operation fails following an upgrade?

There are three key aspects to consider in this scenario:

1. The application's call budget is an integral part of its design. When an operation's gas allowance is recalibrated, it may become insufficient for the previously adequate allowance. Raising the outer transaction's gas limit does not automatically rectify this inner call that has a fixed gas cap. The presented scenario is a simplified example, not actual code from a live project. The failure pattern is intentionally laid out to highlight potential pitfalls:

- A consumer contract calls a callback function with a limited gas allowance.

- If the callback runs out of gas while the caller proceeds, the transaction receipt may show success, but the intended operation may not have been executed.

- The application's behavior matters, as it could treat the fulfilled flag as final and lack any retry mechanisms.

- The evidence to assess this lies in the transaction trace, resulting state, and any recovery paths. A simple pass/fail replay count cannot capture the full picture.

2. Pricing and accounting are separate considerations. EIP-8037 suggests a distinct approach to execution and state-creation gas accounting. This proposal introduces reservoir and refill rules that impact assumptions about gas availability during execution. ChainSecurity points out that treating gasleft() as a value that only decreases can become invalid under the proposed rules.

These in-transaction refills must not be conflated with a refund applied only upon transaction completion. If any checks, proofs, or failure handlers depend on the older model, unchanged bytecode does not guarantee the same reasoning will apply.

3. The question arises: what evidence would validate compatibility with an upgrade? An audit report could document:

- The specific assumption that was violated, along with the exact specification or client revision that introduced the change.

- Whether the issue stems from re-pricing, gas accounting, or their interaction.

- Whether the entire transaction reverts or if the failure is contained within an inner operation.

- The final state of the application and whether recovery, upgrade, or migration is viable.

- Where possible, running a minimal reproduction against pricing-only and accounting-only variants could help isolate the root cause.

As of November 15, 2026, these proposed changes have not been implemented on the Ethereum mainnet. The Ethereum Foundation update leaves the specification modifications and Hoodi timing open for further review. A proposal, a testnet result, and an activated mainnet rule represent different forms of evidence. The primary sources include the Ethereum Foundation's updates on EIP-8037 and 8038, the official EIP specification, the Ethereum gas-invariant review repository, ChainSecurity's analysis on spent gas behavior, and a video walkthrough explaining the concepts.