Ethereum: Glamsterdam pushed back, two EIPs threaten ecosystem projects
The deployment of the Glamsterdam update is suspended after the discovery of risks for several projects in the ecosystem.
Quick Look
- Developer Marius van der Wijden has announced a further postponement of the Glamsterdam hard fork of Ethereum.
- Chainsecurity audits revealed that EIP-8037 and EIP-8038 could weaken smart contracts by changing gas pricing.
AI-generated summary
Why It Matters
Glamsterdam is a planned update for Ethereum aimed at optimizing layer-1 via the proposer-constructor separation.
Glamsterdam is marking time. Friday, November 6, developer Marius van der Wijden announced a new postponement for Glamsterdam, the next hard fork of Ethereum, already delayed at the end of October. This time, entire ecosystem projects are in danger.
The key points of this article:
Ethereum developers are postponing the Glamsterdam hard fork, with no new activation date planned.
Auditing firm Chainsecurity spotted projects that would become vulnerable after the update.
The EIP-8037 and EIP-8038 redo gas pricing and break protocol invariants.
Work on Hegotá, the next update, continues in parallel, without slowing down.
A suspended calendar, an intact roadmap
The update was activated on the Sepolia testnet on Tuesday, October 6, before continuing its tour of the test networks. The next meeting, scheduled for Hoodi on Monday October 26, was skipped on October 22.
The ACD, the Ethereum client developer circle, has once again backtracked and decided to delay the entire hard fork process. Hoodi will not update until the detected issues are resolved.
These problems were brought to the table by Chainsecurity, by screening projects in the ecosystem while the update was running on the test networks.
Verdict, several of them would become vulnerable once Glamsterdam is in place, because they are based on rules that the update will break.
No new date has been brought forward since the first postponement, and the update schedule is therefore officially on pause. The mainnet has never had an official meeting to cancel.
The Glamsterdam program includes the proposal-builder separation engraved in the protocol and the block access lists, two projects designed to increase the load on layer-1. Its content has not changed one iota.
What exactly do the EIP-8037 and EIP-8038 break?
The two proposals highlighted overhaul the pricing of gas, the meter that bills each operation on Ethereum. Together, they recalculate the cost of certain operations and billing for access to the state of the chain, its memory.
The affected projects are based on invariants. An invariant is a rule that the protocol has always respected, regardless of the state of the network. Smart contracts can rely on it without rechecking it at each block, and it is precisely this trust that the two EIPs undermine.
Entire contracts have built their logic on operating costs deemed immutable.
Let's take a theoretical case: a loan protocol which verifies in a loop that each debt remains covered by its guarantees and whose contract budgets gas at today's rate.
If the operation becomes more expensive overnight, the control may no longer be successful. The protection mechanism seizes up, and the project becomes vulnerable.
In other words, the smart contract no longer has the gas budget necessary to trigger its own controls.
A hard fork which weakens projects in production is not an option for Ethereum, hence this pause, the time to review the copy.
Details are documented on the Chainsecurity blog, along with a tool to spot exposed contracts. The teams thus have a map of fragile points before retrying the passage.
At the same time, the roadmap does not stop there. Work on Hegotá, the next update, continues at full speed, according to the post. Its perimeter is already being tightened.
The Glamsterdam site is not frozen yet. At the end of October, the teams merged a patch on the update's staking repositories. The bricks are moving forward, the calendar is slipping.
What to Watch
AI outlook — possibilities, not facts
Glamsterdam extended postponement
Very likely · Within weeks
Open Questions
- What will be the new deployment date?
- How will vulnerable projects be fixed?







