Mentioned in This Article
1. A former insider pushes back on criticism of Ethereum's core developers
Greg Markou, a former Ethereum core developer and co-founder of ChainSafe, said on November 11 that the people building Ethereum's next upgrade, Glamsterdam, should not be blamed for the stall in its planned gas repricing. In a podcast interview, he argued that packing roughly 30 Ethereum Improvement Proposals into a single hard fork makes it likely that at least one will break something, and he urged application teams to test early.
His comments arrive at an awkward moment for the Ethereum upgrade process. Two proposals that would change what the network charges for certain operations and for stored data have been put on hold, a planned launch on a public test network was called off, and the Ethereum Foundation has acknowledged reports that some contracts already running on the network could stop working if the change goes ahead as written.
Markou's message was aimed at a specific complaint that has circulated among application builders and users: that core developers are focused on protocol engineering and pay too little attention to the software that lives on top of Ethereum. He described that view as mistaken, and he framed the current pause as a predictable product of how Ethereum ships changes rather than as evidence that anyone has stopped caring about apps.
2. What is the Glamsterdam upgrade?
Glamsterdam is the name of Ethereum's next planned network upgrade, a hard fork that will bundle a set of protocol changes and activate them together. Its gas repricing component, which would alter the cost of particular operations and of storing data on the chain, is currently on hold.
To understand why that matters, it helps to recall what gas is. On Ethereum, every action a user or a smart contract takes consumes computation, and some actions also add data that every node must store. Gas is the unit used to meter that work, and the fee a user pays is tied to how much gas a transaction consumes. The gas schedule, meaning the specific price attached to each operation, is set by the protocol itself.
Because the schedule is written into the protocol, changing it requires a coordinated upgrade. That coordination happens through the hard fork process, in which client teams implement the same set of changes, test them across development and public test networks, and then activate them on the main network at an agreed point.
The proposals at the center of the current pause are EIP-8037 and EIP-8038. Both reprice certain operations and stored data. An Ethereum Improvement Proposal, or EIP, is the formal specification document used to describe a change to the network, and a hard fork is the coordinated event that ships several of those specifications at once.
3. Why the gas repricing is on hold
Developers had planned to bring the changes to Hoodi, one of Ethereum's public test networks, on October 26. That launch was called off. On November 9, the Ethereum Foundation said it had received four reports of deployed contracts that could break under the new pricing.
That concern goes to the heart of why gas repricing is delicate. Smart contracts are often written with assumptions about how much gas specific operations will cost. Some contracts set fixed gas limits for internal calls, and others are designed around cost patterns that held when they were deployed. If the protocol suddenly makes an operation more expensive, a contract that worked yesterday can run out of gas partway through a call and fail. Many deployed contracts cannot be edited after the fact, which means a pricing change can permanently disable functionality that users rely on.
Repricing is nonetheless a standard tool in protocol maintenance. When operations are priced too cheaply relative to the real burden they place on nodes, they can become a vector for congestion or for growth in state that every node must carry. Adjusting their price is one of the ways the network keeps resource use in line with what node operators can sustain. The tension is that the same adjustment that protects the network can break code that was written around the old numbers.
4. A monolithic beast with a history of breakage
Markou spoke from experience on both sides of that tension. Core developer call notes from 2019 show him giving updates on Lodestar, the proof-of-stake consensus client built by ChainSafe. He told listeners it is wrong to assume that today's core developers are indifferent to the applications running on Ethereum.
He described Ethereum as a monolithic beast, a system so large and interconnected that changes in one place ripple outward in ways that are hard to anticipate. Past gas repricings, he said, have broken things many times. In his telling, the current friction is not a new failure but a recurring cost of evolving a live network that holds real value and supports a vast amount of software written by independent teams.
He also offered a personal example. Markou said he himself broke web3.js, the widely used JavaScript library for interacting with Ethereum, while he was maintaining it, and that the breakage bricked applications after EIP-1559. ChainSafe, the company he co-founded, received a grant from the Ethereum Foundation in 2020 to maintain web3.js. EIP-1559, an overhaul of Ethereum's fee market that changed how transaction fees are set and introduced a base fee that is burned, went live in August 2021.
The anecdote served his broader point. Even developers who are deeply invested in the application layer, and who maintain the very tools apps depend on, can end up on the wrong side of a protocol change. That, in his view, says more about the complexity of the system than about anyone's priorities.
5. Why bundling roughly 30 EIPs raises the odds of trouble
At the core of Markou's argument is the way Ethereum packages its upgrades. He said developers bundle about 30 EIPs into a single hard fork, and that with that many changes landing together, one of them will likely break.
The logic is straightforward. Each EIP is tested individually, but every additional change widens the surface area that application teams and client developers must review. Interactions between proposals can produce effects that none of them would cause on its own. And because all the changes activate at the same moment, a problem in one can hold up the schedule for the entire package.
Bundling exists for practical reasons. Every hard fork requires coordination across multiple independent client teams, node operators, infrastructure providers, exchanges and application developers, all of whom must update their software in time. Shipping changes in batches reduces the number of those coordination events. The trade-off, as the Glamsterdam pause illustrates, is that a single contested proposal can become a bottleneck for the whole release.
6. Proposals pile up as AI tools speed up drafting
Markou also pointed to the sheer volume of proposals reaching Ethereum's standards process. He estimated that about 10 new proposals arrive each day and said AI tools have added to that flow.
A tally of GitHub pull requests in Ethereum's EIP and ERC repositories over the 30 days ending November 10 found 251, a figure that includes edits to existing documents. That works out to roughly eight per day. It is more than double the 100 recorded over the same window in 2024, but below the 316 counted in that period of 2025.
The EIP repository holds proposals that change the core protocol, while the ERC repository holds application-level standards, such as token interfaces, that developers can adopt without a network upgrade. Both feed into the work load of the reviewers and editors who must read, comment on and shepherd submissions. A higher volume of drafts, whatever their quality, increases the demand on that limited pool of attention, which is part of the backdrop Markou was describing when he spoke about pressure on the people who ship upgrades.
7. Markou's advice to app teams: test early and report what breaks
Rather than waiting for core developers to catch every problem, Markou said application teams should test their own contracts against the upcoming fork, using their own AI tools to help, and report anything that breaks.
The suggestion shifts part of the burden of compatibility testing toward the teams that know their own code best. Core developers can model the effects of a repricing in general terms, but the specific assumptions baked into a given contract are often visible only to the people who wrote and maintain it. Early reports from those teams are precisely what allowed the Ethereum Foundation to flag four contracts that could break before the repricing reached a public test network.
Markou also addressed the public tone of debates over upgrades. He argued that messiness is inherent in the process, because online outrage drives engagement. In his view, the loudest disputes visible on social platforms are partly a function of how those platforms reward conflict, and should not be read as a complete picture of how developers are working through the issues.
8. What happens next for the Glamsterdam gas repricing?
The next decision points are close. Outside security auditors ChainSecurity and Dedaub are due to deliver their reports on November 13. The agenda for a developer testing call on November 16 expects the audit work to wrap up between November 16 and November 19.
A further call on November 19 is set to discuss the findings. The Ethereum Foundation has said that no outcome has been decided in advance, leaving open whether EIP-8037 and EIP-8038 move forward as drafted, are revised, or are handled differently within the Glamsterdam schedule.
For application developers, the coming week is the window Markou was describing: the period in which testing against the proposed changes and reporting problems can still shape the final shape of the Ethereum upgrade. For the wider ecosystem, the outcome will show how the network balances the need to keep resource pricing aligned with real costs against the obligation not to break software that users and businesses already depend on.