Ethereum developers are weighing rival ways to prevent the planned Glamsterdam upgrade from breaking contracts that were deployed under the network’s current gas rules. The disagreement centers on whether backward compatibility should be preserved directly, or whether Ethereum should apply new pricing broadly while creating a separate accounting system for older code.
The issue follows Leo Glisic’s proposal for versioned opcodes, which would give newly deployed contracts access to V2 operations carrying the higher gas schedule proposed for Glamsterdam. Existing contracts would continue using the legacy schedule. A separate draft by Giulio Rebuffo would instead separate the cost of executing an operation from the cost charged for it.
The competing designs address a planned change with potentially broad consequences. EIP-8037 proposes higher costs for creating state and separate metering for state creation, with the aim of limiting state growth and supporting higher block gas limits. Under the schedule described for the upgrade, the base cost of contract creation would rise from 32,000 gas to 183,600 gas before storage and execution costs are added.
That change could affect contracts that allocate fixed gas budgets, test gas availability or depend on a particular failure pattern. Many deployed contracts cannot be upgraded, meaning their developers would have no direct way to revise those assumptions after Glamsterdam activates.
Two approaches to compatibility
Glisic’s EIP would preserve the existing gas schedule for legacy contracts and require new contracts to use the updated V2 opcodes. The proposal also excludes GAS and GASLIMIT from the V2 set, according to the draft. Its version of DELEGATECALL would be restricted to V2 targets, creating a clearer separation between old and new execution rules.
The design would allow Ethereum to reprice operations for future contracts without retroactively changing the economic environment in which older applications were written. Its tradeoff is that the network would need to support two opcode regimes and developers would have to understand which version applies to each contract.
Rebuffo’s alternative draft proposes separate legacy-priced execution credits and new-priced billing credits. Under that model, a contract could continue executing according to the older assumptions while the network separately accounts for the higher costs associated with the new schedule.
The proposal includes a significant consequence for billing exhaustion. If billing credits run out, the transaction would face an uncatchable, transaction-wide abort. Rebuffo’s draft also says its schedules, accounting details and testing remain incomplete. It has not yet undergone execution-client implementation or consensus testing, leaving open questions about how it would behave across Ethereum’s software implementations.
Neither proposal has a target activation date. The next private Glamsterdam test was being considered for November 16 to 20 at the earliest, according to CoinDesk’s report on the rival drafts.
Security researchers challenge the assumptions
The disagreement is not only about engineering preference. Security researchers have argued that the proposed gas changes could alter application behavior in ways that are difficult to identify through simple cost estimates.
In its analysis, ChainSecurity warned that Glamsterdam’s gas changes could make previously failing paths complete. The firm said EIP-8037 and related EIP-8038 could change gas availability and failure behavior, allowing failure handlers to finish in cases where they previously reverted. It also warned that existing gas checks could be undermined.
That concern matters because many smart contracts use gas behavior as part of their control logic. A contract may deliberately reserve gas for cleanup, invoke a fallback path when an internal call fails, or treat a gas shortage as evidence that an operation should be rejected. If the same call has more or less usable gas after the upgrade, the contract could take a different path even when its source code has not changed.
CoinDesk reported that Ethereum postponed a planned Hoodi testnet activation after security researchers raised concerns about EIP-8037 and EIP-8038. The delay reflects the difficulty of testing a network-level change when the risk is not limited to contracts that directly create state. Internal calls, error handling and assumptions about available gas may also be affected.
The potentially exposed population may be larger than early estimates suggested. An analysis cited by CoinDesk identified about 200,000 contracts that could be affected, including major protocols as well as smaller applications. The significance is therefore not confined to poorly designed or rarely used code. Contracts holding user assets or supporting financial infrastructure may also contain assumptions tied to the existing schedule.
A decision about Ethereum’s operating model
The proposals present different answers to a broader policy question: how much should Ethereum prioritize the efficiency of future state growth when existing applications were built under older rules?
Versioned opcodes offer a more explicit compatibility boundary, but they could increase complexity for developers and clients. Separate execution and billing credits could preserve more of the old execution model, but Rebuffo’s draft still needs implementation and consensus testing, and its transaction-wide abort behavior could introduce its own operational risks.
Ethereum’s decision will determine whether the cost of adapting to state growth falls mainly on new contracts, on the network’s execution clients, or on users interacting with older applications. It will also show how the protocol balances long-term capacity goals against the practical reality that much of its financial infrastructure is controlled by immutable code.
Sarah Thompson is not a person. No notebook, no deadlines, no face behind the name — just a byline this newsroom publishes under. Here is the production line underneath it, because a name beside a portrait reads like a journalist, and this one is not one.
The models. Writing: gpt-5.6-luna. Out on the live web: gpt-5.6-luna and gpt-5.6-terra. Pictures: gpt-image-1. Swap one in the newsroom and this line swaps with it — it is read off the machines, not typed here.
How a story is made
- Research. The searching model reads around the story, pointed at primary sources — the filing, the post, the repository — rather than at somebody else's write-up of them.
- Writing. The writing model drafts it against what was found, at Sarah Thompson's usual length and in Sarah Thompson's usual register.
- The loop. A reviewer reads the draft and sends it back with notes. Then reads it again. A piece can go round several times before it leaves the building.
- Enrichment. A quotation has to appear word for word on the page it is taken from. A chart may only use figures that appear in the source it cites. Whatever fails is dropped, and the reason is kept.
- Fact check. A last pass hunts for claims the article makes and its sources do not.
- A human stop. Sensitive subjects are held for a person to read before publication, and a person can kill any of it at any point.
If that sounds less like a newsroom and more like a factory: quite. It is called Press Factory.
This article was generated using AI and published automatically without human pre-publication review.
Read and checked by admin on 11/10/2026
How this article was made
The article was produced by the Grandmonts Media News Engine using automated research, drafting and verification workflows. No human editor reviewed the article before publication. Grandmonts Media remains responsible for the published content. Errors can be reported at office@grandmonts.cz.