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

The bytecode can stay identical while the execution rules underneath it change. That is the compatibility question behind the current Glamsterdam gas debate.

I made a video on this topic; this written walkthrough focuses on one practical question: if an operation fails after an upgrade, can the application recover?

1. A fixed call budget is part of the application

Repricing an operation can make a previously sufficient gas allowance too small. Increasing the outer transaction gas limit does not necessarily repair an inner call with a hardcoded cap.

Here is an intentionally simplified failure pattern, not code from a deployed project:

// Illustrative pseudocode: deliberately unsafe completion logic.
(bool ok, ) = consumer.call{gas: callbackGas}(payload);
fulfilled[requestId] = true;
emit CallbackResult(requestId, ok);

If the callback runs out of gas and the caller continues, the receipt can indicate transaction success while the requested operation never happened. If the application treats fulfilled as final and offers no retry path, the consequence differs from a whole-transaction revert.

The relevant evidence is the trace and resulting state, including any recovery path. A pass/fail replay count cannot express all of that.

2. Pricing and accounting raise different questions

EIP-8037 proposes separate execution and state-creation gas accounting. Its reservoir and refill rules also affect assumptions about the gas available during execution.

ChainSecurity documents why treating gasleft() as a value that only decreases can become invalid under the proposed rules. These in-transaction refills should not be confused with a refund applied only when a transaction finishes.

If a check, a proof, or a failure handler relies on the older model, unchanged bytecode alone does not establish that the same reasoning remains valid.

3. What would make compatibility evidence useful?

For each finding, an audit report could record:

• The violated assumption and exact spec/client revision.
• Whether repricing, accounting, or their interaction triggers it.
• Whether the entire transaction reverts or an inner failure is caught.
• The resulting state and whether retry, upgrade, or migration is possible.

Where feasible, running a minimal reproduction against pricing-only and accounting-only variants could help isolate the cause. That is a proposed diagnostic approach, not a claim that those variants have already been tested here.

Current status and sources

Status as of November 15, 2026: these proposed changes are not active on Ethereum mainnet. The EF update leaves specification changes and Hoodi timing open pending review. A proposal, a testnet result, and an activated mainnet rule are different evidence.

Primary material:

• Ethereum Foundation update on EIP-8037/8038
• EIP-8037 specification
• Ethereum gas-invariant review repository
• ChainSecurity: When Spent Gas Comes Back

Video walkthrough

Disclosure: I created the accompanying explainer. The English version is embedded below.

Watch on YouTube · Chinese version on Bilibili

If a transaction succeeds but its callback fails, what evidence would you require before calling that application compatible with an upgrade?