Mentioned in This Article
1. Why could Glamsterdam break existing Ethereum apps?
Ethereum's planned Glamsterdam upgrade could cause some live applications that hold user funds to stop working, and on Sunday, November 8, two developers filed rival proposals to prevent that. Leo Glisic would keep today's gas prices for contracts already deployed, while Giulio Rebuffo would apply new prices to everyone but shield older contracts from the effects. Both drafts are unfinished and carry no target date.
The concern is not about a bug in the usual sense. It stems from a deliberate design choice inside Glamsterdam: a set of repricings that make certain operations more expensive. Smart contracts, the programs behind decentralized applications, were often written with the assumption that the cost of each operation would stay fixed. When the price of an operation changes, code that relied on the old figure can fail at the moment it is called.
The risk is sharpest for contracts that can no longer be changed. Many applications on Ethereum are immutable once deployed, meaning their authors cannot patch them, and some of those hold real user deposits. If such a contract stops functioning after the upgrade, the funds inside it could become hard or impossible to move, which is why the two proposals have drawn attention from security researchers and protocol developers alike.
2. What are EIP-8037 and EIP-8038?
EIP-8037 and EIP-8038 are two Ethereum Improvement Proposals that sit inside Glamsterdam, the network's next major software upgrade. They raise the gas charged for creating and accessing stored data. An Ethereum Improvement Proposal, or EIP, is the formal document through which changes to the protocol are specified, debated and, if accepted, bundled into an upgrade.
Gas is the unit that prices every step a smart contract takes, in the same way a meter prices electricity use. Each operation, whether writing data, reading it or creating a new contract, consumes a set amount of gas, and users pay fees based on the total. Because the amounts are written into the protocol, changing them alters what every contract pays to do the same work.
Under EIP-8037, the base cost of creating a contract rises from 32,000 gas to 183,600 gas. That figure is the starting charge, before the costs of storing the contract's code and executing its setup logic are added on top. The size of the jump is a large part of why developers worry about compatibility with software built under the old numbers.
3. How can a higher gas price cause contracts to fail?
Many applications were built on the assumption that gas costs would never change, and a few of them hard-code a fixed amount of gas when they call other applications. If the called operation now needs more than that fixed amount, the call runs out of gas and fails, even though nothing else about the contract is different.
This is a familiar kind of problem in Ethereum's history. Developers have long been warned not to depend on specific gas figures, precisely because the network has repriced operations in earlier upgrades. Still, code written years ago remains live, and a good deal of it cannot be updated, so the question facing the community is how much responsibility the protocol bears toward software that followed older practices.
The two proposals answer that question differently. One treats existing contracts as a protected class that keeps its familiar pricing. The other accepts the new prices universally but changes how the network accounts for gas internally, so that older code never encounters the higher costs during execution.
4. What has the security community said?
Security researchers have been vocal about the risk. The researcher known as pcaversaccio wrote on X that Glamsterdam should not be shipped in its current form, a position stated bluntly in the post, and identified the gas increases as the problem. He said he had flagged the issue to Ethereum's core developers about two weeks earlier.
The pseudonymous developer banteg pointed to a list of roughly 200,000 affected contracts, kept in a repository named ethereum/repricing-impact. He said his own review found methodological flaws in how that list was assembled, flaws that cause it to miss many more contracts than it includes.
He also argued that the change touches the deployment and operation of several high-profile protocols, and not merely the work of developers who misuse low-level instructions. That distinction matters in the debate, because it challenges the view that only poorly written code stands to suffer from the repricing.
5. What does Glisic's EIP-8488 propose?
Glisic's draft, numbered EIP-8488, splits Ethereum's instruction set in two. Contracts that already exist keep what the draft calls the legacy schedule, so their gas costs remain as they are today. New contracts use what the draft names V2 opcodes, which follow the gas schedule set out in EIP-8037 and EIP-8038.
The approach is simple to explain: old code keeps old prices, and new code pays new prices. Its appeal is that it gives immutable contracts an explicit guarantee, since nothing about their operating costs changes. Its cost is complexity, because the network would need to maintain two parallel versions of the instruction set and track which one applies to each contract.
The proposal is hosted as a pull request on GitHub, where developers can review the text and comment on it. Like the other draft, it has not yet been through the formal process that would lead to inclusion in an upgrade.
6. How would Rebuffo's dual gas meter work?
Rebuffo's draft takes a different route. Every transaction would run two gas meters side by side. One tracks execution under the old rules, so contracts behave exactly as they did before and do not run out of gas unexpectedly. The other bills under the new schedule, and that meter determines the transaction fee the user actually pays.
In the draft's own wording, billing uses the new schedule and determines the transaction fee. The effect is that everyone pays the new, higher prices, which preserves the economic goals behind the repricing, while older contracts continue running as if nothing had changed.
The draft is also candid about its limits. It acknowledges that no execution-client implementation has been built for the design and that no consensus tests have been run against it. Execution clients are the programs node operators run to process transactions, and consensus tests check that different clients all reach the same results, so the absence of both means the idea remains on paper.
7. Why is Glamsterdam already delayed?
Glamsterdam is currently running on test networks, which are copies of the blockchain where developers can try out changes without real money at stake. A second rehearsal on those networks was scheduled for October 26. It was postponed after security researchers raised concerns about the upgrade.
That postponement came before either of the rival proposals existed. The security worries about gas repricing are therefore part of the reason the upgrade schedule has slipped, and the new drafts are attempts to resolve those worries rather than separate matters.
The delay shows how Ethereum's upgrade process works. Changes are not shipped on a fixed date set by a company; they move forward when developers on regular calls agree they are ready. When a credible safety objection arises, the schedule can shift, and both proposals now enter that process.
8. What happens next for the upgrade?
Both drafts are unfinished and neither has a target date. The next private test of Glamsterdam was estimated on an October 29 developer call for November 16 to 20 at the earliest, based on a meeting summary from that call. That estimate was made before either draft had been written.
It is therefore unclear whether the November window will hold. Developers will have to decide whether to adopt one of the compatibility designs, combine ideas from both, or revisit the underlying gas increases. Each path requires specification work and testing before it can be included in a rehearsal.
For application developers and users, the practical question is whether contracts that hold funds and cannot be updated will be protected. Until one of the proposals is accepted and implemented, that remains open, and the pace of the debate will help determine when Glamsterdam can move forward.
9. Why do upgrades like this involve trade-offs?
Ethereum's gas schedule serves several purposes at once. It compensates the network for the resources that each operation consumes, discourages spam, and limits how quickly the stored state of the blockchain can grow. Raising the price of creating and accessing data is one way to slow that growth, which is a long-standing concern for people who run nodes.
Against that goal stands the principle of backward compatibility. Ethereum has built its reputation partly on the idea that contracts, once deployed, keep working. Users deposit funds in applications trusting that the rules will not shift beneath them. A repricing that disables even a small share of contracts tests that trust, and the two rival drafts reflect two ways of honoring it.
The first draft protects compatibility by keeping the old and new rules apart. The second protects it by separating what a contract experiences from what a user is billed. Neither is free: one adds long-term maintenance of two instruction sets, and the other adds new accounting machinery to every transaction. Reviewers will weigh these costs against how many real contracts each design would protect.
The case also shows why independent estimates of affected contracts matter. If the list of about 200,000 contracts understates the exposure, as banteg argues, then the case for compatibility protection grows stronger. If the true number is lower, developers might accept a narrower fix. The debate will likely turn on better data about which contracts are live, funded and immutable.