Two rival Ethereum drafts try to stop Glamsterdam breaking old contracts, and neither has been tested

Two Ethereum developers filed rival draft proposals on Sunday 8 November that try to stop the Glamsterdam upgrade from breaking contracts already deployed on mainnet. EIP-8488, by Leo Glisic, would keep every existing contract on today’s gas prices and force new contracts onto a new set of opcodes. A second draft, by Giulio Rebuffo and still without a final number, would run two gas counters side by side: one that contracts see, one that sets the fee. Both target the same problem, the Glamsterdam gas repricing in EIP-8037 and EIP-8038, and neither has client code, test results or a slot on a developer call yet.

Both texts were opened as pull requests on the ethereum/EIPs repository, Rebuffo’s at 15:58 UTC and Glisic’s at 19:40 UTC, and both sit in Draft status waiting for an editor’s review, according to GitHub. CoinDesk reported the two filings early on Monday. They arrive while Glamsterdam is stuck: the upgrade’s rehearsal on the Hoodi test network was called off in October and has no new date, a story told in full in our page on the postponed Glamsterdam fork on Hoodi.

What the Glamsterdam gas repricing changes: EIP-8037 and EIP-8038

The two EIPs at the centre of the dispute make writing new data to Ethereum much dearer. EIP-8037, “State Creation Gas Cost Increase”, prices state by the byte: a constant called CPSB is set at 1,530 gas per byte, chosen so that the chain’s stored state grows by about 120 GiB a year at a 150 million gas limit. That state gas is also metered apart from ordinary execution gas, in what the text calls a reservoir. EIP-8038 raises the price of reading and writing state that already exists.

Both proposals have been in “Last Call”, the final review stage, with a deadline of 1 November 2026. On 9 November the EIP site still showed that status for both. The main figures, from the two texts:

EIP-8037 estimates that a new account will cost about seven times what it costs now, a new storage slot about five times and the deployment of a 24 kB contract about eight times. At a base fee of 0.08 gwei, that 24 kB deployment comes to roughly 0.003 ETH, or a little over $6 with ETH near $2,090 at 08:09 UTC. Ether was down 6.52% over 24 hours at that time, in line with a market that lost 6.68%; no source links the drop to this debate.

What breaks: old contracts that count on fixed gas

Higher prices alone would only make transactions dearer. The trouble is code that assumes a price. Many contracts send a fixed amount of gas with a call to another contract, and many cannot be changed once deployed. If the call suddenly needs more than the fixed amount, it fails, CoinDesk explained.

The Ethereum Foundation flagged this in August. Its research, EthPandaOps and specifications teams replayed past transactions under the new schedule and wrote that “a small set of smart contracts rely on assumptions the new schedule shifts”. Their post of 24 August sorts the results into four groups, from “no change” to “potentially broken”, and names the risky habits: the 2,300-gas stipend of Solidity’s transfer and send, gas values hard-coded into calls, logic that branches on gasleft(), and presigned transactions with fixed gas limits. For ordinary users the post said “no action is needed”.

EIP-8037 admits one break of its own. Because the state-gas reservoir can top up the gas a contract sees, code that measures work by reading the GAS opcode twice and subtracting can get a negative number. For contracts already on mainnet with that pattern, the EIP says the problem cannot be fixed. Wallets, the eth_estimateGas call of node software and ERC-4337 bundlers all have to be updated to price the two dimensions.

The audit firm ChainSecurity then found a sharper version of the risk in October: refills can leave just enough gas for a contract’s failure handler to finish, so a failure meant to be retried gets written down as final. Its findings, the 13 mainnet contracts it said on 22 October it had found (unnamed, with disclosure to their teams under way) and the October decision to pull the Hoodi date are covered in our report on the Glamsterdam rule developers reversed for staking deposits and on the Hoodi page. ChainSecurity has not shown that a major live protocol can be exploited, CoinDesk noted at the time.

EIP-8488: old contracts keep the old price list

Glisic’s draft, titled “Versioned Opcodes for Gas Repricing”, adds a second set of instructions to the Ethereum Virtual Machine. Every opcode whose cost changes under EIP-8037 or EIP-8038 gets a V2 twin, such as SSTORE_V2, CALL_V2 or CREATE2_V2, priced on the new schedule. Contracts deployed before the fork keep running on the old schedule “indefinitely”, in the draft’s word.

After activation, any new runtime code is scanned when it is stored. If it contains an old opcode that has a V2 twin, the deployment fails. If it passes, the account gets a code_version field set to 2. A new DELEGATECALL_V2 refuses to run code whose version is below 2, because delegatecall executes someone else’s code inside the caller’s own storage. Plain CALL and STATICCALL can still reach any contract, old or new.

The draft also drops GAS and GASLIMIT from the V2 set, so new contracts cannot read their remaining gas at all. Glisic’s argument is that code which cannot see the gas meter cannot build assumptions that a later repricing would break. What would replace gasleft() for the code that needs it, such as standard out-of-gas signals or gas-spent receipts, is left to companion proposals.

Upgradeable protocols would move to the new prices as soon as they swap in a new implementation, and the gas limit could then rise step by step as more activity runs on V2 code, the motivation section says. It calls this “a third option” between applying the repricing to everyone and dropping it.

When abcoathup, who assigns EIP numbers for the editors, gave it 8488 on Monday at 01:06 UTC, Glisic, who had filed it as 8888, replied: “I’ll settle for three 8s instead of four I guess”. He added that he cannot open a discussion thread on Ethereum Magicians, the forum where EIPs are debated, because his account there was deleted and his IP blocked. The reason given was sock-puppeting, which he says he did openly. His draft’s discussion link still points at the EIP-8038 thread.

Rebuffo’s draft: two gas meters, one bill

Rebuffo’s pull request #12637, “Separate execution credits and billing credits”, leaves the opcodes alone and splits the gas counter instead. Both counters start at the transaction’s gas limit. “Credits” fall according to the old schedule and are all the EVM ever sees: gasleft() returns credits, calls forward credits, the 2,300 stipend is paid in credits. “Billing” falls according to the new schedule and decides what the sender pays.

So a contract that sends a fixed 2,300 gas still gets the 2,300 it always got. What changes is the end of the road. If billing runs out before the next charge, the whole transaction aborts with a new error, BILLING_OUT_OF_GAS. No contract can catch it or run a failure handler, every frame is unwound and the sender pays the full gas limit. According to the draft, the uncatchable abort keeps a contract from committing a failure record once billing runs out, which is the pattern ChainSecurity warned about. It adds that griefing and denial-of-service risks remain.

Rebuffo is open about what is missing. The exact schedules, the charge points, rebate rules, receipt fields and block accounting are still to be written, the pull request says, and “no execution-client implementation or consensus tests have been run for this design”. The text calls itself a basis for discussion, not a claim that it is ready to deploy. abcoathup suggested the number 8487 on Monday and asked for a Magicians thread.

Two rival fixes and what each one costs

Put simply, Glisic changes which price list a contract runs under, while Rebuffo keeps the old list inside the EVM and changes only the bill. Each approach has a price, and the drafts admit most of it. The points below are Coindaro’s reading of the two texts; no client team has commented on either pull request so far.

EIP-8488 would leave clients running two gas tables for good, plus a V3 later if the pattern repeats, as the draft itself foresees. More important for the goal of the repricing, contracts that already exist would keep writing new state at today’s prices. Token contracts, exchanges and lending markets deployed before the fork would grow the chain’s state at the old rate until they migrate. The draft accepts that and proposes raising the gas limit gradually as V2 use rises.

One consequence is not discussed in the draft, and this is Coindaro’s reading, not the author’s. The deployment gate covers CREATE, CREATE2 “or any other code-creation path” and rejects new code that still contains a legacy opcode with a V2 twin. A factory that is already deployed, cannot be upgraded and creates new contracts from bytecode written before the fork (a smart contract holding reserves of two or more tokens, supplied by users, that a decentralized exchange uses to execute trades automatically at a price set by a formula.">pool, a vault or a wallet per user, for example) would therefore see those deployments revert. That sits uneasily with the draft’s line that existing contracts are “unaffected”: the factory keeps running, but one of its main jobs stops. Which live factories this would touch, and whether an exception is intended, the draft does not say.

Rebuffo’s design keeps old behaviour only as long as billing lasts, and the draft says so plainly. Transactions that succeed today “can now abort with credits remaining”, its compatibility section warns. An untrusted contract inside a batch can eat the shared billing allowance and abort everything, unrelated work included. Fee estimation and receipts would have to report two numbers. And charging more is not a hard resource limit, the text adds: if the repricing is meant to cap state growth, block rules must enforce that separately.

“Should not be shipped in its current form”: the pressure on Glamsterdam

The drafts landed in a heated thread. Security researcher pcaversaccio wrote on X that “imho Glamsterdam should not be shipped in its current form, period”, and said he had raised the gas increases with core developers two weeks earlier, according to CoinDesk. The pseudonymous developer banteg pointed to “the already huge list of 200,000 affected contracts” in the Foundation’s repricing-impact tool and said its method misses many more. He added, CoinDesk reported, that the problem touches the deployment and operation of several high-profile protocols.

That 200,000 figure is a count of contracts the replay tool lists as affected, not of contracts shown to be exploitable. The Foundation sorts replay results into four buckets, from “no change” through “succeeds with changes” and “fixable with a gas-limit increase” to “potentially broken”, and being on the list does not put a contract in the last one. Teams can look up their own contracts in the tool.

Other outlets have reported that the Foundation brought in audit firms, with CoinCentral citing Geth developer Marius van der Wijden on work with ChainSecurity and Dedaub.

What happens next: ACDC on 12 November, ACDE #249 on 19 November

Two core developer calls are on the calendar of the ethereum/pm repository. All Core Devs Consensus #191 meets on Thursday 12 November at 14:00 UTC, and All Core Devs Execution #249 on Thursday 19 November at 14:00 UTC, four weeks after #248 because of Devcon. Both agendas list “Glamsterdam” as their first item. Neither names EIP-8488 or Rebuffo’s draft, and as of Monday morning no comment on either issue asks for them to be added.

Before either draft is debated, the EIP editors still have to merge it, and both authors have been asked to open a forum thread. Developers had estimated on 29 October that the next private Glamsterdam test could come between 16 and 20 November at the earliest, CoinDesk reported; that plan predates both drafts. No new Hoodi date exists, and no mainnet date either: the December slots discussed before the delay are listed on our Hoodi page.

Going by the drafts’ own framing, core developers now have four options. They can apply the repricing to everyone and ask affected projects to adapt, carve existing contracts out as Glisic proposes, or decouple fees from execution as Rebuffo proposes. Or they can drop the two EIPs from Glamsterdam, which EIP-8488 says would postpone the state-growth controls that support a higher gas limit.

What it means for ETH holders, stakers and developers

Nothing changes on mainnet today. Glamsterdam is live only on the Sepolia test network, where it activated on 6 October, and the Foundation’s October post on the Hoodi delay said no action was required from mainnet users or ETH holders.

Developers are the ones with homework. A contract that forwards a fixed gas amount, uses transfer or send, branches on gasleft() or relies on presigned transactions should be checked against the repricing tool now, whatever version of the fix wins. Teams that run wallets or ERC-4337 bundlers will have to handle two gas dimensions under EIP-8037 as written, or two counters under Rebuffo’s draft.

Gas, repricing and hard forks in two paragraphs

Every Ethereum operation has a price in gas units, and the fee a user pays is the gas used times the gas price. Our glossary entry on gas fees covers the basics. Repricing changes the number of units an operation costs, not the price per unit.

Changing those costs requires a hard fork: every node must switch to the new rules at the same block, or the chain splits. That is why a test fork on Hoodi has to go well before any mainnet date is set, as our guide to soft forks and hard forks explains. The next public step on the calendar is the consensus call of 12 November.