Two Ethereum developers filed competing draft proposals on Sunday to stop the Glamsterdam upgrade from breaking contracts that are already live. One would leave existing contracts on today’s gas prices forever. The other would charge everyone the new prices but let old contracts run as if nothing had changed. Both are early drafts that have not yet come up on a core developer call, but they give the next one something concrete to weigh.
The problem both drafts try to fix
Glamsterdam includes EIP-8037 and EIP-8038, which raise the gas charged for creating and accessing state on Ethereum. The jumps are large. Under the current EIP-8037 text, the state cost of creating a new account rises from 25,000 gas to 183,600, a new storage slot from 20,000 to 97,920, and code deposit from 200 gas per byte to 1,530.
The aim is to slow the growth of Ethereum’s database so the network can raise its gas limit. The catch is that some deployed contracts assume today’s costs will hold. They forward a fixed amount of gas, reserve a set stipend, or read the remaining gas to decide what to do next. Many cannot be changed once deployed. The Ethereum Foundation said on Friday that security firm ChainSecurity had found live projects that would become vulnerable, and that developers would not fork the Hoodi testnet until the issues are resolved. AltcoinReporter covered the eight broken assumptions the foundation asked teams to check.
EIP-8488: old contracts keep old prices
Leo Glisic’s draft, numbered EIP-8488, splits the instruction set in two. Contracts deployed after the upgrade could only use a new set of “V2” opcodes priced under EIP-8037 and EIP-8038. Any new deployment containing an old opcode would be rejected. “Legacy contracts continue to execute under the pre-Glamsterdam gas schedule indefinitely,” the draft says.
The V2 set would also drop GAS and GASLIMIT, the opcodes that let a contract read its remaining gas, so new code cannot hard-wire assumptions that the next repricing would break. A new DELEGATECALL_V2 would refuse to run legacy code. Proxy contracts would move to the new prices automatically when they upgrade to a V2 implementation.
The cost of this approach is speed. The state-growth controls would cover only new code at first, and Glisic’s draft says the gas limit could be “raised incrementally as the share of V2 execution grows.” Clients would also have to keep both gas schedules running indefinitely, since the draft never retires the old one. Glisic floated the idea a day before filing, in a reply to Ethereum Foundation developer Marius van der Wijden, asking why the new rules should not simply apply to contracts deployed after Glamsterdam.
Rebuffo’s draft: two meters per transaction
Giulio Rebuffo, a contributor to the Erigon execution client, took the opposite route in a separate draft. Every transaction would run two counters, both starting from its gas limit. “Credits decrease according to the old gas schedule and determine ordinary EVM execution. Billing decreases according to the new gas schedule and determines what the transaction sender pays,” it says.
Contracts would only ever see credits, so a fixed gas forward or a remaining-gas check behaves as it does today. Users would pay the new prices. If billing runs out first, the whole transaction aborts in a way no contract can catch, and the sender pays the full gas limit.
The draft is candid about the limits. “Transactions that previously succeeded can now abort with credits remaining,” it says, and an untrusted contract in a batch could use up the shared billing allowance and abort everything. It also notes that “charging more is not itself a physical resource limit,” so block limits would still have to cap actual work. The pull request says no client implementation or consensus tests have been run, and the exact schedules, refunds and receipt fields are still open. An EIP associate has suggested the number 8487 for it.
Where this goes next
Both pull requests were still open on Monday and each needed a review from an EIP editor. Neither draft has its own discussion thread on the Ethereum Magicians forum yet, which the process expects. Glisic wrote in his pull request that the forum is inaccessible to him and pointed readers to the existing EIP-8038 thread.
The next execution-layer call, All Core Devs Execution #249, is set for November 19 with Glamsterdam first on the agenda. The foundation’s Glamsterdam repository says that, depending on the response, developers might slightly change EIP-8037 and EIP-8038, or not. The two drafts add more radical options to that list. No new Hoodi or mainnet date has been set.
FAQ
Do these proposals delay Glamsterdam? Not on their own. They are unmerged drafts with no core developer decision behind them. Glamsterdam’s Hoodi testnet fork was already on hold until the gas issues are resolved, and no new date has been announced.
What is the main difference between the two drafts? EIP-8488 keeps old contracts on old prices and applies the new prices only to code deployed after the upgrade. Rebuffo’s draft charges everyone the new prices but keeps old execution behavior through a separate gas counter that contracts can see.
Should contract teams wait for a fix? The Ethereum Foundation has asked teams to check their code against its list of broken gas assumptions now, since EIP-8037 and EIP-8038 could still ship largely as written.
Disclaimer: This article is for informational purposes only and does not constitute financial advice.
