Ethereum Weighs Two Gas Plans After Glamsterdam Hoodi Delay

Two competing Ethereum proposals from developers Leo Glisic and Giulio Rebuffo, submitted on Sunday, November 8, seek to prevent Glamsterdam gas-rule changes from disrupting deployed contracts after banteg said on X that an analysis had identified roughly 200,000 potentially affected contracts. Neither design has been approved for inclusion, and banteg said methodological problems could make the actual number higher.

What could break in existing contracts?

EIP-8037 and EIP-8038 change how Ethereum charges for creating contracts and accessing blockchain state. EIP-8037 would raise the base gas charge for creation from 32,000 to 183,600, excluding extra execution and code-storage costs. The changes aim to reflect the resources consumed by blockchain activity, but existing applications may not have prepared for the revised charges.

Security firm ChainSecurity identified eight assumptions used by existing contracts that could become invalid under the proposed rules. Some contracts reserve fixed gas for external calls, while others depend on specific behavior when transactions fail. Unexpected gas consumption could interfere with either operation and cause transactions to fail.

Some deployed applications cannot be updated, so a changed charge can become a transaction-failure or application-interoperability problem rather than an isolated coding mistake. The concern extends to established DeFi protocols and applications holding user funds.

How do the competing proposals work?

Glisic’s EIP-8488 would introduce a separate instruction set for newly deployed contracts. Their V2 opcodes would follow the revised pricing in EIP-8037 and EIP-8038, while existing contracts would retain their original gas rules. The aim is to apply the new resource-based charges without forcing older applications to adapt.

Rebuffo’s separate draft would place two gas-accounting systems inside each transaction. One would measure gas consumption under the previous rules, preserving the execution conditions contracts expect; the other would calculate the transaction fee under the revised schedule. His draft acknowledges that no execution-client implementation or consensus tests have been completed.

That leaves both proposals outside Glamsterdam’s approved scope. The technical distinction is operationally material: one design separates pricing by deployment age, while the other separates legacy consumption accounting from the charged fee within a transaction.

Why did developers and DeFi figures object?

Curve Finance founder Michael Egorov warned on X that Glamsterdam in its current form could lead to another emergency hard fork. “Dear @ethereum – please don’t break the chain. It does look like Glamsterdam in the current form would lead to another emergency hard fork back, with a lot of drama,” Egorov wrote.

Ethereum community member and investor Ryan Berckmans initially supported moving ahead because the network could not guarantee unchanged gas pricing for every application. He reversed course after reviewing compatibility concerns. “We should (clearly, now) not continue towards Glam activation asap. I was wrong to say so,” Berckmans wrote on X.

Security researcher pcaversaccio said the gas changes had reportedly been flagged to Ethereum’s core developers weeks earlier and wrote: “imho Glamsterdam should not be shipped in its current form, period.” banteg said the risk extends to the deployment and operation of several prominent protocols, not only isolated contracts.

What did the Hoodi postponement cover?

Developers postponed the October 26 Hoodi activation after concerns emerged about how revised gas rules could affect contracts already deployed on Ethereum’s mainnet. The postponement covered the Amsterdam execution-layer changes, Gloas consensus changes and a planned increase in Hoodi’s gas limit to 200 million. The delay preceded both November 8 submissions.

In a November 6 statement, Ethereum Foundation developer Marius van der Wijden said the organization was working with ChainSecurity and Dedaub to examine affected applications and gather feedback from developers. The update came two days before Glisic and Rebuffo submitted their competing drafts.

What is the next test deadline?

Developers tentatively discussed another private Glamsterdam test for November 16-20 at the earliest during an October 29 meeting. That schedule predates the two November 8 submissions and neither selected a design nor supplied a mainnet activation date. The next concrete checkpoint is the November 16-20 window, when developers will need evidence that legacy contracts can execute without requiring the emergency hard fork Egorov warned about.