Ethereum Glamsterdam Contract Compatibility: Two Fixes

Ethereum developers Leo Glisic and Giulio Rebuffo filed rival draft fixes on Sunday, Nov. 8, to protect Ethereum Glamsterdam contract compatibility as planned gas changes threaten existing apps. The proposals address repricing that would raise the base charge for creating an Ethereum (ETH▼$2,122.23) contract from 32,000 to 183,600 gas.

The difference is who pays the higher rates. Glisic would preserve legacy pricing for existing contracts and apply the new schedule to newly deployed contracts. Rebuffo would apply the new prices to everyone while letting older contracts execute under the rules they were built for.

The drafts arrived after the compatibility concern had already delayed a Glamsterdam rehearsal. The upgrade is intended for late 2026 and combines changes to Ethereum’s execution and consensus layers, including a redesign of proposer-builder separation and mandatory block-level access lists alongside the repricing proposals.

⚠️Glamsterdam Gas Changes Put Ethereum Glamsterdam Contract Compatibility at Risk
🟣EIP-8488 Would Preserve Legacy Pricing for Existing Contracts
👥Rebuffo Would Separate Contract Execution From User Billing
✨Ethereum's Repricing Dispute Follows a Delayed Rehearsal
🔹Why Glamsterdam Changes Ethereum's Resource Pricing
📖ETH Whales Buy While Funds Continue to Sell
💡The Next Glamsterdam Milestone Is a Private Test
❓FAQ

Glamsterdam Gas Changes Put Ethereum Glamsterdam Contract Compatibility at Risk

Which Changes Triggered the Compatibility Dispute?

Glamsterdam includes EIP-8037 and EIP-8038, which increase charges for creating and accessing stored data. Under EIP-8037, the 183,600-gas base charge for contract creation comes before code-storage and execution costs are added.

The increase is aimed at charging more for state that remains in Ethereum’s database, including newly created accounts and storage slots. That separates the long-term burden of permanent state growth from temporary computation and is intended to give developers more room to increase execution capacity without expanding the database at the same rate.

That is roughly 5.7 times the current base charge, or an increase of about 474%. It makes the assumptions embedded in older applications a central issue for the upgrade.

Why Can Repricing Break a Deployed Contract?

Some apps allocate a fixed amount of gas when calling another app. If the required work becomes more expensive, that allowance can become insufficient and the call can fail. Many deployed applications cannot be updated to accommodate the change.

The two competing drafts target that compatibility problem. For applications already holding users’ funds, preserving their ability to execute is the immediate concern.

The scale of the concern extends beyond isolated calls. A review published in the ethereum/repricing-impact repository listed 200,000 potentially affected contracts, while researchers said methodological issues meant the list could miss additional contracts. The warning included the deployment and operation of several high-profile protocols, not only applications that had used the repriced instructions in an unusual way.

EIP-8488 Would Preserve Legacy Pricing for Existing Contracts

How Would Glisic Separate Old and New Contracts?

Glisic’s EIP-8488 would split Ethereum’s instruction set. Existing contracts would retain the legacy gas schedule, while newly deployed contracts would have to use V2 opcodes carrying the EIP-8037 and EIP-8038 prices.

The draft states that “existing contracts keep the legacy schedule.” Its compatibility protection therefore rests on preserving the pricing environment for code already deployed.

That design makes the deployment boundary the key transition point. A contract already on the network would continue to invoke the old-cost instructions, while a contract launched after the change would be written to use the V2 versions. Developers of new applications would therefore have to account for the revised state-creation and storage-access costs from the outset.

Where Would the Higher Charges Apply?

New contracts would use the repriced instructions. Under this design, deployment timing would determine which schedule a contract uses: legacy rules for existing code, V2 rules for new code.

This preserves older contracts’ cost assumptions while applying Glamsterdam’s revised resource prices to future deployments. The proposal changes how the repricing reaches applications rather than asking every existing application to absorb it at once.

The trade-off is that Ethereum would carry two instruction-price regimes after the upgrade. The new regime would apply to future code, but the old regime would remain available to deployed contracts whose behavior depends on it.

Rebuffo Would Separate Contract Execution From User Billing

How Would the Two Gas Meters Work?

Rebuffo’s draft proposes two gas meters for each transaction. One would track execution under the old rules; the other would account for costs under the new schedule.

The new schedule would determine the transaction fee. Older contracts could continue executing with their established gas assumptions even though users would pay according to the repriced rules.

Rebuffo’s document describes the billing meter as the part that determines the transaction fee. It also records a major implementation caveat: no execution-client implementation or consensus tests had been run for the design when the draft was filed.

What Is the Practical Difference for Users?

Under Glisic’s approach, existing contracts retain legacy pricing. Under Rebuffo’s, compatibility protection would preserve execution behavior while higher prices also apply to transactions involving older contracts.

The choice therefore reaches beyond whether an app continues to function. It also determines whether legacy applications retain their old pricing or move to the new billing schedule alongside newer applications.

For a user interacting with an older application, the two proposals could therefore preserve the same code path while producing different fees. Glisic’s model protects both the execution assumptions and the legacy schedule. Rebuffo’s model protects execution but makes the transaction subject to the new billing calculation.

Ethereum’s Repricing Dispute Follows a Delayed Rehearsal

What Prompted Researchers to Object?

Security researcher pcaversaccio argued on X that the Glamsterdam upgrade should not ship in its current form. He said he had raised the gas-increase concerns with Ethereum core developers two weeks earlier.

Pseudonymous developer banteg pointed to a list of 200,000 affected contracts in ethereum/repricing-impact. He argued that methodological problems caused the analysis to miss additional contracts and said the changes could affect deployment and operation of several high-profile protocols.

Pcaversaccio wrote that, in his view, “Glamsterdam should not be shipped in its current form, period,” linking the objection to the proposed gas increases. Banteg likewise said the impact reached “deployment and operation of several high profile protocols,” rather than only a small group of developers.

How Has the Concern Affected Testing?

Glamsterdam already runs on one Ethereum test network. A second rehearsal scheduled for Oct. 26 was postponed after researchers raised concerns about the gas increases.

That postponement preceded the Nov. 8 compatibility drafts. The proposals now offer different ways to address the execution failures researchers warned about before the next stage of testing.

The delayed rehearsal is part of a broader testing sequence for an upgrade that also changes how blocks expose state access and how execution payloads move through the network. Block-level access lists are intended to make state reads and writes explicit, while proposer-builder separation would extend the execution-payload propagation window from about two seconds to about nine seconds. Those changes are meant to support future increases in block capacity, but the repricing dispute has made application compatibility an immediate test criterion.

Why Glamsterdam Changes Ethereum’s Resource Pricing

What Is EIP-8037 Trying to Achieve?

A June 23 Foresight News analysis described EIP-8037 as an effort to price permanent state growth separately from temporary computation. Creating accounts and storage slots adds lasting demands on Ethereum’s database.

The intended benefit is to allow execution capacity to grow without permanent state expanding proportionally. The compatibility dispute concerns how Ethereum can introduce those higher charges while preserving applications built around the earlier schedule.

The wider Glamsterdam package is not limited to Ethereum gas repricing. EIP-7732 would put proposer-builder separation into the protocol, while EIP-7928 would require access records at the block level instead of relying only on optional transaction-level lists. The combination is designed to give nodes more time and more information to validate and process larger workloads.

What Trade-Off Do the Drafts Put Before Developers?

Glisic’s proposal makes existing and future contracts subject to different pricing rules. Rebuffo’s keeps the new billing schedule across both groups but uses a separate execution meter to protect older code.

Both seek to preserve application behavior. Their different treatment of fees makes the selection consequential for users of legacy apps as well as developers deploying new contracts.

The implementation burden also differs. EIP-8488 requires a second set of V2 opcodes and a rule for deciding which instructions a contract may use. Rebuffo’s design requires clients to maintain separate execution and billing measurements and still needs execution-client and consensus testing before its behavior can be assessed in practice.

ETH Whales Buy While Funds Continue to Sell

How Has the Upgrade Debate Coincided With ETH Volatility?

ETH fell more than 5% in 24 hours on Nov. 9 and traded just above $2,100 after reaching a multi-month low of $2,070. The decline followed a broader market sell-off and came after ETH failed to hold levels reached during the volatility wave surrounding the US midterm elections.

CryptoPotato reported that one Hyperliquid trader lost nearly $20 million on ETH longs across two accounts, with combined losses of $44.78 million. The largest observed single liquidation order involved ETH and was worth $48.16 million on Binance.

Other large holders were buying the decline. One wallet borrowed 22 million USDT▲$0.9991 from Aave and spent $21.55 million to acquire 10,000 ETH at an average price of $2,155. Another wallet withdrew 3,500 ETH from Binance, bringing its weekly withdrawals to 16,577 ETH.

BeInCrypto reported that US spot Ethereum ETFs recorded $365.3 million of outflows in the week, their sixth consecutive week of withdrawals. Three large wallets added about 35,350 ETH, creating a contrast between fund selling and selected on-chain accumulation.

The Next Glamsterdam Milestone Is a Private Test

What Testing Window Had Developers Estimated?

On Oct. 29, developers estimated Nov. 16–20 as the earliest window for the next private Glamsterdam test. That estimate came before either compatibility draft existed.

Both proposals remain drafts without target dates. Rebuffo’s document also states that its design has not undergone execution-client implementation or consensus testing.

The Nov. 16–20 window is therefore an early estimate rather than an activation commitment. Before a broader rehearsal or mainnet decision, developers still need to compare the proposals, test their effects on existing contracts, and determine whether the repricing and compatibility mechanisms behave consistently across clients.

What Matters Next for ETH Users?

The immediate issue is whether Ethereum can preserve fixed-gas contract calls while introducing the planned repricing. For legacy-app users, the two designs offer different outcomes on fees even when both aim to keep applications running.

Developers must also address the breadth of the compatibility problem raised by researchers. Banteg’s warning extends beyond individual failed calls to the deployment and operation of major protocols, making application behavior a central part of the upgrade debate.

The next decision is not simply whether Glamsterdam proceeds. Developers must choose whether compatibility comes through legacy execution and legacy pricing, through legacy execution with new billing, or through another revision produced during testing. The outcome will determine which applications need code changes and which users bear higher costs after the upgrade.

FAQ

Which Glamsterdam Proposals Raise the Gas Charges at Issue?

EIP-8037 and EIP-8038 contain the repricing addressed by the compatibility drafts. They raise charges associated with creating and accessing stored data, bringing older applications’ fixed-gas assumptions into focus.

How Much Would EIP-8037 Raise the Base Charge for Contract Creation?

The proposed change adds 151,600 gas to the base charge. Code-storage and execution costs would still be added on top, so 183,600 gas would be the starting charge rather than the full deployment cost.

Who Filed the Two Compatibility Drafts?

Leo Glisic and Giulio Rebuffo submitted the competing designs on Nov. 8, 2026. Glisic’s draft is EIP-8488; Rebuffo’s proposal centers on separate meters for execution and billing.

Would New Contracts Keep Legacy Gas Pricing Under EIP-8488?

New deployments would have to use V2 opcodes carrying the EIP-8037 and EIP-8038 schedule. The legacy-price protection is directed at contracts already on Ethereum.

Would Rebuffo’s Design Preserve Older Apps’ Transaction Fees?

Rebuffo proposes billing transactions under the new schedule, including those involving older contracts. The old-rule meter would preserve execution assumptions, while the second meter would determine the fee.

Why Might an Existing App’s Call to Another App Fail After Repricing?

A fixed gas allowance may become too small for a call once the relevant operations cost more. For applications that cannot be updated after deployment, changing their code to increase that allowance may not be an option.

This article is for information only and is not financial advice.