What to Know
- Ethereum’s planned Glamsterdam upgrade would raise gas costs for some operations tied to contract creation and stored data.
- The changes could disrupt older apps that were written around current gas assumptions and may not be upgradeable.
- Two rival draft proposals have emerged to reduce the risk of Glamsterdam breaking existing contracts.
- Leo Glisic’s EIP 8488 would preserve legacy gas rates for existing contracts and apply the new schedule only to contracts launched afterward.
- Giulio Rebuffo’s draft would charge transactions under the new schedule while allowing older contracts to execute as though the legacy rules still applied.
- EIP 8037 would raise the base charge for creating a contract from 32,000 gas to 183,600 gas before additional costs are added.
- A second Glamsterdam rehearsal scheduled for Oct. 26 was postponed after security researchers raised concerns.
- Both proposed fixes remain drafts and neither has a target date.
Ethereum’s Glamsterdam Upgrade Runs Into a Compatibility Test
Ethereum’s next major software upgrade, known as Glamsterdam, is facing a critical compatibility debate after developers and security researchers raised concerns that planned gas repricing could cause some existing applications to fail. The issue is not about whether Ethereum should continue improving its fee model and execution environment. It is about how far those changes can go without undermining deployed contracts that already hold user funds and, in many cases, cannot be changed after launch.
The concern centers on two Glamsterdam related proposals, EIP 8037 and EIP 8038. These measures would increase the amount of gas Ethereum charges for creating contracts and interacting with stored data. Gas is the internal metering system that prices each action performed by smart contracts. Every transaction, contract call, and storage operation must fit within gas rules, which means even technical repricing can have direct effects on live applications.
Under EIP 8037, the base charge for creating a contract would rise from 32,000 gas to 183,600 gas before code storage and execution costs are included. That increase is significant because many applications were designed under the assumption that certain gas costs would remain stable. If an older contract sends a fixed gas amount to another contract and the receiving operation becomes more expensive, the call may fail even if the business logic remains valid.
Why Old Contracts Can Be Vulnerable to Gas Repricing
Smart contracts are often described as self executing programs, but their reliability depends heavily on the underlying rules of the blockchain. When developers build applications, they make assumptions about how much gas specific operations consume. In some designs, those assumptions are flexible and can absorb protocol changes. In others, the gas amount is fixed directly into contract behavior.
This creates a difficult challenge for Ethereum governance. If the network never adjusts gas costs, some operations may remain underpriced relative to their burden on the system. If the network adjusts gas too aggressively, contracts that were deployed under older assumptions may stop working as expected. The most difficult cases are immutable contracts, because once deployed, they cannot be patched by their creators.
The risk becomes more serious when those contracts hold user assets or connect to high profile protocols. A failed call can block a withdrawal, interrupt a protocol action, or cause an application to behave in ways its users did not expect. Market participants are therefore watching Glamsterdam not only as a technical milestone, but also as a governance test for how Ethereum balances progress with backward compatibility.
Two Rival Drafts Take Different Paths
Two developers have proposed competing fixes to address the same basic problem. Leo Glisic’s draft, EIP 8488, would split Ethereum’s instruction set so existing contracts keep the legacy schedule while new contracts use updated instructions tied to the EIP 8037 and EIP 8038 gas schedule. In practical terms, this approach would protect deployed contracts from the repricing while ensuring that contracts created after the change operate under the new cost model.
That design has an intuitive appeal for developers worried about old applications. It treats deployed code as something that should continue to see the rules it was built for, while allowing Ethereum to move forward for newly launched contracts. The tradeoff is added complexity, because the network would need to distinguish between legacy and newer execution paths.
Giulio Rebuffo’s draft takes another approach. It would run two gas meters per transaction. One meter would track execution under the old rules, preserving the behavior older contracts expect. A separate meter would apply the new schedule for billing and determine the transaction fee. This method attempts to let Ethereum charge according to the updated economics while avoiding execution failures caused by legacy assumptions.
Rebuffo’s draft also acknowledges that no execution client implementation or consensus tests have been run for the design. That caveat matters because Ethereum upgrades require close coordination across client teams, test networks, security researchers, infrastructure providers, wallets, exchanges, and application developers. A solution that appears elegant on paper still has to survive implementation and consensus testing before it can be considered safe for deployment.
Security Researchers Push for Caution
The compatibility question has already affected the Glamsterdam testing process. Glamsterdam is running on one of Ethereum’s practice networks, where developers test changes before they are exposed to real user funds. However, a second rehearsal planned for Oct. 26 was postponed after security researchers raised alarms about the gas increases.
Security researcher pcaversaccio wrote on X that Glamsterdam should not be shipped in its current form, referring to the gas increases and saying the issue had been flagged to Ethereum core developers two weeks earlier. Pseudonymous developer banteg also warned that the impact may be broader than previously identified, citing an already large list of 200,000 affected contracts and arguing that methodological issues could mean many more are missed.
Those warnings have intensified the debate around how Ethereum should evaluate upgrade risk. Core protocol changes typically aim to improve efficiency, security, and long term scalability. Yet each change must be weighed against Ethereum’s unusually large base of existing contracts. Unlike traditional software, where operators can often push updates directly, many Ethereum applications depend on immutable code and decentralized coordination.
What the Debate Means for Ethereum Users
For ordinary users, the Glamsterdam debate may sound highly technical, but the underlying issue is straightforward. If a contract has been coded to expect one gas environment and the network changes that environment, the contract may fail in certain situations. If that contract manages user deposits, protocol logic, or application access, failures can become more than a developer inconvenience.
At the same time, Ethereum cannot avoid all change. Gas schedules exist to reflect the cost of computation and storage on the network. If certain operations are too cheap, they can create inefficiencies or security concerns. Repricing is one tool available to protocol developers, but the current discussion shows that repricing must be handled with care when old contracts depend on previous assumptions.
The rival drafts illustrate two philosophies. One protects historical execution by preserving legacy gas rules for existing contracts. The other separates execution from billing so the network can modernize fees while allowing legacy assumptions to continue functioning. Neither approach has yet won the debate, and both remain draft proposals without target dates.
No Final Timeline Yet
The next private test of the upgrade was estimated on Oct. 29 for Nov. 16 to 20 at the earliest, but that plan was made before either draft proposal existed. With the new proposals now part of the discussion, Ethereum developers may need to evaluate whether either design can be implemented, tested, and reviewed in time to influence the Glamsterdam path.
For now, the key point is that Glamsterdam is not simply a fee adjustment. It has become a live example of Ethereum’s central challenge as a mature smart contract platform: improving the protocol without breaking the accumulated base of applications that already depend on it. The outcome will matter for developers, infrastructure operators, and users whose funds interact with contracts that may have been written under different assumptions.
FXCOINZ will continue monitoring how Ethereum developers assess the competing drafts, whether client teams begin implementation work, and whether further testing reveals a narrower or broader impact on deployed contracts. Until then, Glamsterdam remains a major upgrade under review, with backward compatibility at the center of the discussion.
Frequently Asked Questions (FAQs)
What is Ethereum’s Glamsterdam upgrade?
Glamsterdam is Ethereum’s next major software upgrade. It includes proposed changes to how the network prices certain operations, including contract creation and interactions with stored data.
Why are developers concerned about Glamsterdam?
Developers are concerned because some older smart contracts were written around current gas assumptions. If gas costs change, fixed gas calls inside those contracts could fail, and some contracts cannot be updated after deployment.
What does EIP 8037 change?
EIP 8037 would raise the base charge for creating a contract from 32,000 gas to 183,600 gas before code storage and execution costs are added.
What is Leo Glisic’s proposed fix?
Leo Glisic’s EIP 8488 would preserve the current gas schedule for existing contracts while requiring newly launched contracts to use updated instructions tied to the new gas schedule.
What is Giulio Rebuffo’s proposed fix?
Giulio Rebuffo’s draft would use two gas meters per transaction. One would preserve legacy execution behavior, while another would apply the new schedule for billing and determine the transaction fee.
Have the proposed fixes been finalized?
No. Both fixes remain draft proposals, and neither has a target date. Rebuffo’s draft also notes that no execution client implementation or consensus tests have been run for that design.
Why was a Glamsterdam rehearsal postponed?
A second rehearsal planned for Oct. 26 was postponed after security researchers raised concerns about the gas increases and their possible impact on existing contracts.
How many contracts could be affected?
Developer commentary cited an already large list of 200,000 affected contracts and warned that methodological issues could mean additional contracts are not captured by that count.
What should Ethereum users watch next?
Users should watch whether Ethereum developers adopt either draft, conduct implementation and consensus testing, and set a revised path for Glamsterdam after reviewing backward compatibility risks.