# Two rival Ethereum drafts aim to stop Glamsterdam's gas repricing from breaking deployed contracts

One draft keeps existing contracts on the old gas schedule and sends new contracts to new instructions. The other applies the new prices to everyone but lets old applications keep running as they do now. Neither sets a date.

- Published: 2026-11-09T05:43:40.268Z
- Canonical: https://polylog.news/crypto/2026-11-09/two-rival-ethereum-drafts-aim-to-stop-glamsterdam-s-gas-repr
- Publisher: Polylog (Crypto desk)
- Section: crypto
- Sources: [CoinDesk](https://www.coindesk.com/tech/2026/11/09/two-rival-ethereum-proposals-aim-to-stop-glamsterdam-breaking-old-contracts), [Ethereum Foundation Blog](https://blog.ethereum.org/2026/08/24/glamsterdam-repricing-testing), [ChainSecurity](https://www.chainsecurity.com/blog/glamsterdam-gas/), [CoinDesk (October)](https://www.coindesk.com/tech/2026/10/23/ethereum-delays-glamsterdam-test-after-security-devs-flag-risk-to-existing-contracts), [OpenZeppelin (GitHub)](https://github.com/OpenZeppelin/openzeppelin-contracts/issues/6858)

On Sunday, two Ethereum developers filed competing draft proposals to keep the Glamsterdam hard fork from breaking smart contracts that already run on the network, [CoinDesk reported](https://www.coindesk.com/tech/2026/11/09/two-rival-ethereum-proposals-aim-to-stop-glamsterdam-breaking-old-contracts). The trouble comes from two parts of the upgrade, Ethereum Improvement Proposal (EIP) 8037 and EIP-8038. They raise the gas Ethereum charges for creating new state and for accessing existing state.

The [Ethereum Foundation wrote in August](https://blog.ethereum.org/2026/08/24/glamsterdam-repricing-testing) that the goal is to make gas costs match the real resource cost of each operation. Its developers replayed historical mainnet transactions under the new schedule and found a small set of contracts that rely on assumptions the change breaks. These include the fixed 2,300-gas allowance that Solidity's transfer and send functions forward, gas values hardcoded into calls, logic that branches on the remaining-gas reading, and presigned transactions with fixed gas limits. The audit firm [ChainSecurity](https://www.chainsecurity.com/blog/glamsterdam-gas/) flagged contracts that assume a reverted call cannot return gas already spent on creating state. CoinDesk cites its estimate that creating a new storage slot could cost 110,020 gas once a separate allowance runs out, compared with 22,100 gas under current rules. OpenZeppelin opened [a review of gas invariants](https://github.com/OpenZeppelin/openzeppelin-contracts/issues/6858) that tracks problems such as its default post-operation cost function under-billing after EIP-8038. Developers [postponed a Glamsterdam testnet activation in October](https://www.coindesk.com/tech/2026/10/23/ethereum-delays-glamsterdam-test-after-security-devs-flag-risk-to-existing-contracts) after security researchers raised these risks.

The two drafts solve the problem in opposite ways. EIP-8488, from a developer CoinDesk identifies as Glisic, splits the instruction set in two. Existing contracts stay on the legacy gas schedule, and new contracts must use "V2" instructions. The draft from developer Giulio Rebuffo applies the new prices to every transaction but lets old applications behave as they do today. CoinDesk describes the split as a choice about what contracts see versus what users pay. Both are drafts. Neither names a target date, and Glamsterdam has no confirmed mainnet activation date.

Each option has a cost. Versioned instructions keep old contract behavior exactly as it is, but every client must then maintain two gas schedules permanently. That conflicts with the Lean Ethereum program's goal of simplifying the protocol. Uniform pricing keeps a single cost model for users, but clients must show legacy contracts one gas figure while charging another, and that mismatch can itself cause consensus bugs. The findings so far show no contract under exploit. The code these changes affect underlies the [$42.13 billion](https://defillama.com) that DeFiLlama counts as locked in decentralized finance (DeFi) on Ethereum.

## What this means

Ethereum's plan to raise base-layer capacity depends on pricing state growth correctly. The repricing that makes higher gas limits safe also breaks contracts written on the assumption that gas costs never change. Several groups are exposed: client teams, who would carry the extra complexity of versioning, auditors, and the holders of funds in older contracts that forward fixed gas. Layer-2 networks are also exposed, because a faster base layer competes with them. The market already expects some delay, since the testnet slipped in October. What is new is that core developers now have two concrete designs, and the choice sets a precedent on whether a fork may change how deployed contracts behave. The consensus treats this as a scheduling issue. It is a governance question about whether deployed contracts are permanent. The nearest precedent is January 2019, when ChainSecurity found that EIP-1283 opened a reentrancy path through the same 2,300-gas allowance. Developers pulled the EIP, and the Constantinople fork shipped weeks later as St. Petersburg. Net gas metering returned months afterward in EIP-2200 with a safeguard. The desk's read is that core developers will narrow or defer the state-repricing EIPs in the first Glamsterdam release, rather than adopt opcode versioning under time pressure. That would push full repricing into a later fork within months. That depends on neither draft clearing historical-replay testing quickly. The read is wrong if developers schedule a public testnet fork with EIP-8037 and EIP-8038 intact before year-end.

## What to watch

- Whether the next All Core Developers call keeps EIP-8037 and EIP-8038 in Glamsterdam or moves them to a later fork. That decision sets how fast Ethereum's base layer can raise its gas limit.
- Any updated count of affected contracts from ChainSecurity or OpenZeppelin. A larger list makes the version-split approach more likely despite its added complexity.
- A new public testnet date for Glamsterdam. Developers would only set one once they believe the compatibility problem is settled.