Glamsterdam, Ethereum’s next network upgrade, has hit its first serious speed bump, and developers are now debating two very different ways around it.
Within four hours on Sunday, November 8, two draft proposals landed in the official Ethereum Improvement Proposals repository. Both try to solve the same problem: the upgrade’s planned gas repricing could break smart contracts that were written years ago on the assumption that gas costs would stay put.
The drafts arrived two days after the Ethereum Foundation said core developers had paused the next testnet step until those risks are understood.
Why Glamsterdam Was Paused Before the Hoodi Fork
On November 6, the Ethereum Foundation published a post by Marius van der Wijden explaining the delay.
During testing, the security firm ChainSecurity found several projects that would become vulnerable after Glamsterdam because they rely on fixed assumptions about gas, which developers call invariants. Two proposals in the upgrade, EIP-8037 and EIP-8038, change how much gas many operations cost and how state is charged, and that breaks those assumptions.
Based on those findings, the All Core Devs group decided not to fork the Hoodi testnet until the issues are resolved. The Foundation said it is working with auditors ChainSecurity and Dedaub and running internal audits, but admitted it “can not cover all projects on Ethereum.”
Instead, it published a repository describing eight invariants that Glamsterdam would break, along with example prompts, and asked contract developers and auditors to check their own code. Work on the following upgrade, Hegota, continues in parallel.
How Big Is the Glamsterdam Gas Increase?
The core of the issue is EIP-8037, titled “State Creation Gas Cost Increase.” Its goal is to slow the growth of Ethereum’s state, the data every full node has to store, so the network can safely raise its block gas limit.
The proposal’s own figures show why. After the gas limit rose from 30 million to 60 million units, the average new state added each day more than tripled, from about 105 MiB to about 326 MiB. That works out to roughly 116 GiB a year. As of January 2026, a Geth node already held about 390 GiB of state.
ADVERTISEMENT
EIP-8037 introduces a fixed “cost per state byte” of 1,530 gas, targeting average state growth of 120 GiB a year at a reference block gas limit of 150 million. It also meters state creation separately from regular execution.
The price impact on everyday operations is large, as the proposal’s estimates table shows.
- Creating a new account: from 25,000 gas to 183,600 gas, about 7.3 times higher.
- Writing a new storage slot: from 20,000 gas to 97,920 gas, about 4.9 times higher.
- Deploying a full 24 kB contract: from 4,947,200 gas to 37,784,880 gas, about 7.6 times higher.
Those numbers describe gas units, not final Ethereum gas fees. What users actually pay also depends on the base fee, and the upgrade is designed so the network can carry more activity overall.
The EIP is candid about side effects. The well-known Nick’s method deployment factory uses a pre-signed transaction with a hardcoded 100,000 gas limit. Under the new pricing, that transaction would no longer succeed, and the same applies to other deterministic deployers such as SingletonFactory, Create2Deployer and CreateX.
Both EIP-8037 and EIP-8038 sit in “Last Call” status, with a review deadline of November 1, 2026.
Fix One: Keep Old Contracts on the Old Price List
The first draft to appear, filed by Giulio Rebuffo as pull request 12637, proposes separating “execution credits” from “billing credits.”
Under this design, the Ethereum Virtual Machine would keep running contracts on the old gas schedule. Execution credits, which follow the legacy prices, decide whether code runs out of gas and what the gasleft() function reports. Billing credits follow the new prices and decide what the sender actually pays.
If a transaction runs out of billing credits, the whole transaction aborts. The idea is that existing contracts see exactly the gas behavior they were written for, while the network still charges the new, higher price for state.
The draft did not yet have an EIP number when it was filed.
Fix Two: New Opcodes for New Contracts
The second draft, EIP-8488 “Versioned Opcodes for Gas Repricing” by Leo Glisic, was filed as pull request 12638 later the same evening.
It takes the opposite route. Existing contracts would keep the legacy gas schedule indefinitely. New contracts would have to use versioned opcodes, such as SSTORE_V2 and CALL_V2, that carry the new prices.
GAS and GASLIMIT are excluded from the new opcode set, and the draft says the approach would let the block gas limit be raised in steps rather than all at once.
What Glamsterdam’s Delay Means for Ethereum Builders
Both drafts are early and have not been accepted by core developers. The All Core Devs calls will have to weigh the added complexity of a two-track gas system against the risk of breaking live contracts.
In our view, the pause is a healthy sign. Developers caught the problem on testnets, before real funds were exposed, and opened the question to the whole ecosystem instead of pushing ahead on schedule.
For teams building on Ethereum, the practical step is clear. The Foundation has asked anyone whose contracts depend on fixed gas costs, such as hardcoded gas limits, gas stipends or gasleft() checks, to review the published invariants and report findings to [email protected].
The wider crypto market has stayed led by Bitcoin while Ethereum works through these choices, a trend we covered in our look at Bitcoin dominance crossing 60%.
No new date has been set for the Hoodi fork. The next All Core Devs discussions are expected to decide whether either fix, or a change to EIP-8037 and EIP-8038 themselves, moves Glamsterdam forward.
DC Forecasts is a leader in many crypto news categories, striving for the highest journalistic standards and abiding by a strict set of editorial policies. If you are interested to offer your expertise or contribute to our news website, feel free to contact us at [email protected]
