Ethereum’s Glamsterdam Upgrade Faces Two New Fixes for Contract Risks

Ethereum’s next major upgrade is confronting a practical compatibility question: how should the network change the cost of storing data without disrupting smart contracts already built around today’s rules? Two developers have now offered competing draft answers, while the Ethereum Foundation continues reviewing reports from affected projects.

The proposals concern Glamsterdam, whose planned changes include EIP-8037 and EIP-8038. These would adjust how Ethereum charges for creating and accessing blockchain state. They are not approved fixes, and no mainnet activation date has been announced.

What changed in the latest update

In a November 6 post, Ethereum Foundation developer Marius van der Wijden said testing had surfaced projects whose contracts rely on assumptions that the proposed gas changes would break. The AllCoreDevs group delayed the Glamsterdam hard fork process and held off on a planned Hoodi testnet fork while the issues are investigated.

The Foundation said on November 9 that it had received four reports describing deployed contracts that could be affected. It is reviewing those reports and contacting potentially affected protocols. The Foundation did not identify the projects publicly, and the reports describe possible failures—not confirmed exploits or evidence that every contract is at risk.

That distinction matters. This is a compatibility and reliability review of proposed protocol rules, not a report that Ethereum has been breached. The question is whether some existing code could behave differently if its gas assumptions change.

Why gas repricing can affect old contracts

Gas is the unit Ethereum uses to meter computation and state operations. EIP-8037 would increase and separately meter charges associated with creating persistent state; EIP-8038 would revise charges for accessing state. The proposals aim to better account for the resources nodes use as the chain grows.

A price change can matter beyond the transaction’s final bill. Contract code sometimes forwards a fixed gas allowance to another contract, assumes a failed call will leave a certain amount available, or branches on the result of a gas check. If the cost or accounting changes, a call that once fit may fail—or a failure-handling path may have a different amount of gas left to run.

CoinDesk reported that EIP-8037’s proposed base charge for contract creation would rise from 32,000 to 183,600 gas, before code-storage and execution costs. That is one illustration of the scale of repricing, not the total transaction cost. Ethereum’s August impact analysis said most replayed transactions were unaffected, while a smaller set relied on assumptions that could require fixes or further review.

Two proposals, two different compatibility models

Leo Glisic’s draft, EIP-8488, proposes versioned instructions. Existing contracts would continue using the legacy gas schedule, while newly deployed contracts would use a V2 instruction set carrying the new schedule. The approach draws a boundary between old and new code: the new pricing applies to future deployments, while deployed legacy code retains its current execution rules.

That could reduce the risk of retroactively changing assumptions embedded in older contracts. It would also require new code to follow a distinct instruction set and would introduce rules for how new and old contracts interact. These are design consequences of a draft proposal, not settled protocol behavior.

Giulio Rebuffo’s separate draft takes another route: it proposes two gas measurements for a transaction. Execution would be tracked under the earlier rules so existing contracts retain the conditions they expect, while a second accounting measure would apply the new schedule to determine charges. The draft says it has not yet had an execution-client implementation or consensus tests.

The trade-off is straightforward to describe but technically demanding to resolve. Glisic’s design separates old and new code paths; Rebuffo’s separates the conditions contracts execute under from the schedule used for billing. Both need careful specification, client implementation and testing before developers could judge their effects in practice.

The upgrade remains on hold

Ethereum had scheduled a Glamsterdam activation on the Hoodi testnet for October 26, including a planned gas-limit increase. The Foundation postponed that activation on October 22 and said no replacement date had been set. Its November 6 update kept the testnet fork on hold while developers investigate the risks.

The Foundation’s November 9 update says ChainSecurity and Dedaub are preparing findings, with publication expected November 13. The auditors and Foundation developers are scheduled to present findings and take questions on November 16; a developer discussion of possible next steps is planned for November 19. The Foundation explicitly said no decision about specification changes or a Hoodi schedule is pre-committed.

Those dates are checkpoints for review, not a promised launch timetable. The proposed private test window discussed earlier in October predates the new drafts and the latest reports, so it should not be treated as a confirmed schedule.

What developers and users should watch

For contract teams, the immediate task is to test assumptions rather than predict which draft will win. The Foundation has asked developers and auditors to review eight identified invariants, including fixed gas budgets, behavior after failed calls and assumptions about gas remaining. Projects should test relevant transaction paths against the proposed rules and report concrete findings through the Foundation’s process.

For users, there is no announced action to take on the basis of these draft proposals alone. The reports do not establish that user funds have been stolen or that a particular protocol is currently unsafe. If a project later identifies a material issue, it should communicate the affected contracts and any user steps directly rather than leaving users to infer risk from upgrade headlines.

A design decision still lies ahead

The immediate story is not that Glamsterdam has broken Ethereum contracts; it is that developers have paused a testnet step, received specific reports and begun comparing possible compatibility fixes before the planned gas changes move further. The next evidence will be the published audit findings and the developers’ November discussions.

Until those reviews are public and the proposals are tested, the scope remains uncertain. Neither draft is a final decision, and there is no confirmed replacement date for Hoodi or mainnet. For an upgrade intended to change Ethereum’s long-term state economics, resolving how existing applications behave is a necessary part of the work—not a footnote to the launch.