Ethereum proposals target legacy-contract risks in Glamsterdam gas changes
Ethereum’s competing Glamsterdam proposals seek to protect legacy smart contracts as gas accounting changes face a Hoodi testing pause.
TL;DR
Two competing Ethereum proposals seek to stop planned Glamsterdam gas-accounting changes from disrupting existing smart contracts. Their core distinction is whether protection is delivered through what contracts observe or through what users ultimately pay. The Hoodi testing pause puts implementation scrutiny ahead of any clearer Glamsterdam timetable.
Glamsterdam gas changes put legacy contracts in focus
EthereumThe second-largest crypto network and its currency, ether (ETH). Unlike bitcoin it runs smart contracts, so stablecoins, DeFi and tokens are built on it.Full explanation in the glossary’s planned Glamsterdam changes to gas accounting have opened a compatibility question: how can the network revise execution economics without breaking Smart contractA program on a blockchain that executes automatically once its conditions are met — no intermediary needed. DeFi, stablecoins and tokens are built on it.Full explanation in the glossary already deployed under older assumptions?
Gas is the unit used to account for computational work on Ethereum. A change in that accounting can therefore reach beyond transaction costs. Legacy contracts may rely on the behavior and values exposed by the existing gas model, making backward compatibility a central constraint rather than a secondary implementation detail.
The two proposals now under discussion are aimed at containing that risk. Both seek to preserve the functioning of existing contracts, but they draw the protection boundary in different places.
Two designs split contract behavior from user costs
The competing approaches differ over what the contract sees and what the user pays. That distinction is technical, but it has direct consequences for how a network upgrade is experienced at the application layer.
One path centers on shielding legacy contracts from changed gas behavior. The other emphasizes separating the new accounting framework from the amount ultimately charged to users. Both aim at the same outcome—avoiding breakage—but they allocate compatibility and pricing effects differently.
For developers, the choice matters because deployed code cannot simply be rewritten after an upgrade. For users, it matters because the visible transaction charge is the practical interface to a deeper protocol rule change.
Compatibility trade-offs shape the upgrade design
A design that prioritizes the historical view available to contracts can reduce the chance that older code behaves unexpectedly. Its trade-off is that Ethereum must carry a more explicit compatibility layer while introducing the revised accounting model.
A design that more sharply separates contract-facing behavior from user-facing charges can make the distinction between execution logic and payment clearer. It also requires developers and infrastructure providers to understand precisely which part of gas behavior remains stable and which part changes.
Neither proposal removes the underlying engineering trade-off. Ethereum must balance the benefits of updated gas accounting against the large installed base of contracts whose behavior depends on established rules.
Hoodi testing pause raises the bar for Glamsterdam
The Hoodi testing pause makes the compatibility debate immediately relevant to Glamsterdam’s sequencing. Testing is where the difference between a clean protocol design and a safe migration becomes concrete, particularly when legacy contracts are the stated protection target.
The pause does not establish a new launch date. It does, however, leave the proposal choice and its testing requirements as key factors before the upgrade can move forward with greater certainty.
At the time of writing, ETH traded at $2,100.94, down 0.94% in delayed pricing. The market move does not by itself assign a value to either proposal, but the protocol decision bears directly on the reliability expectations around Ethereum’s next upgrade.
Glamsterdam next steps hinge on implementation choice
The immediate issue is not whether legacy contracts need protection; both proposals are designed around that premise. The decision is how Ethereum should provide it while changing gas accounting.
The next stage will turn on whether the network favors a model built primarily around the contract’s observed gas behavior or one that more explicitly distinguishes that view from user payment. Until testing resumes and an approach is selected, Glamsterdam’s path remains defined by an unresolved compatibility design choice.