Ethereum developers have introduced two competing proposals to prevent the upcoming Glamsterdam upgrade from disrupting existing smart contracts as concerns grow over changes to the networks gas pricing rules.
Developers Leo Glisic and Giulio Rebuffo have submitted separate proposals on Sunday, November 8, offering different ways to introduce the new gas charges without affecting applications already operating on Ethereum.
The proposals follow security warnings that have forced developers to postpone parts of Glamsterdams testing schedule. Some existing smart contracts rely on fixed gas costs, and changing those costs could cause transactions to fail or interfere with applications that cannot be updated after deployment.
Ethereum developers propose two approaches to gas pricing
Glisics proposal, EIP-8488, would introduce a separate set of instructions for newly deployed smart contracts while allowing older contracts to continue operating under their existing gas rules.
Under the proposal, new contracts would use V2 opcodes that follow the revised pricing introduced through EIP-8037 and EIP-8038. Existing contracts would retain the original pricing structure, allowing developers to introduce the changes without forcing older applications to adapt.
Rebuffo has suggested a different solution in a separate draft that would introduce two gas accounting systems within each transaction.
One would calculate how much gas a contract consumes under the previous rules, preserving the conditions it expects during execution. The second would calculate the actual transaction fee using the revised pricing schedule.
His proposal acknowledges that no execution client implementation or consensus tests have yet been completed for the design. Neither proposal has been approved for inclusion in Glamsterdam.
Why Glamsterdams gas changes have raised security concerns
The compatibility concerns stem from EIP-8037 and EIP-8038, which change how Ethereum charges for creating and accessing blockchain state.
EIP-8037 would raise the base gas charge for creating a smart contract from 32,000 to 183,600, excluding additional execution and code storage costs.
Although the changes are intended to account for the resources consumed by blockchain activity, security researchers have warned that existing applications may not be prepared for the revised charges.
As crypto.news previously reported, security firm ChainSecurity identified eight assumptions used by existing smart contracts that could become invalid under the proposed gas rules.
Some contracts reserve a fixed amount of gas for external calls, while others depend on specific behavior when transactions fail. An unexpected change in gas consumption could interfere with those operations.
Pseudonymous developer banteg warned on X that an existing analysis had already identified roughly 200,000 potentially affected contracts, while methodological problems could mean the actual number is higher.
The developer said the concerns extend to the deployment and operation of several prominent protocols, rather than being limited to isolated coding mistakes.
Ethereum community divided over Glamsterdam risks
The proposed changes have prompted criticism from developers and DeFi industry figures who believe Ethereum should resolve the compatibility concerns before proceeding.
Curve Finance founder Michael Egorov warned on X that Glamsterdam could cause serious problems if developers proceed without addressing the risks.
“Dear @ethereum – please dont 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 with the upgrade, arguing that Ethereum could not guarantee unchanged gas pricing for every existing application.
Berckmans subsequently reversed his position after reviewing the compatibility concerns.
“We should (clearly, now) not continue towards Glam activation asap. I was wrong to say so,” he wrote on X.
Security researcher pcaversaccio has taken a firmer position, arguing that Glamsterdam should not be deployed in its current form.
“imho Glamsterdam should not be shipped in its current form, period,” the researcher wrote, referring to the gas changes that had reportedly been flagged to Ethereums core developers weeks earlier.
Glamsterdam testing remains delayed
Ethereum developers postponed the October 26 Hoodi activation after concerns emerged about how the revised gas rules could affect contracts already deployed on the mainnet.
The postponement covered the Amsterdam execution layer changes, Gloas consensus changes and a planned increase in Hoodis gas limit to 200 million.
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.
A subsequent private Glamsterdam test had been tentatively discussed for November 16 to 20 at the earliest during an October 29 developers meeting. The schedule was drawn up before the two competing proposals were submitted.