Ethereum developers are weighing new ways to prevent the network’s next major upgrade, Glamsterdam, from breaking existing smart contracts. The concern emerged around planned gas-cost increases that could cause some older applications to fail if they were built around today’s fee assumptions.
Two draft proposals, submitted by developers Leo Glisic and Giulio Rebuffo, aim to preserve compatibility while still allowing Glamsterdam to move forward. The ideas surfaced after a planned second test of the upgrade was delayed amid warnings from security researchers about possible effects on contracts already deployed on Ethereum.
Gas changes at the center of the issue
The debate is focused on EIP-8037 and EIP-8038, two proposals included in Glamsterdam that would make contract creation and data storage more expensive in gas terms. Under EIP-8037, the base gas cost to create a smart contract would rise sharply to 183,600 from 32,000.
That change matters because some existing contracts were written with fixed gas limits when interacting with other contracts. If those limits no longer cover the required execution cost after Glamsterdam, related transactions could begin to fail. In cases where contracts cannot be updated after deployment, the result could be lasting service disruptions.
Testing delay followed warnings
Concerns over those risks were serious enough to affect the upgrade’s testing schedule. The second Glamsterdam test, which had been set for Oct. 26, was postponed after security researchers flagged the possible impact on previously deployed contracts.
An anonymous developer known as Vanteg said roughly 200,000 smart contracts may already be exposed to the issue, while also cautioning that the real figure could be higher. That estimate added urgency to the discussion over whether the upgrade needs compatibility protections before further testing proceeds.
Two draft approaches to preserve legacy behavior
Glisic’s draft, EIP-8488, would preserve the current gas schedule for contracts that already exist on the network, while applying the higher fees only to contracts created later. The approach is aimed at shielding older applications from unexpected breakage while still introducing the new cost model for future deployments.
Rebuffo proposed a different structure. His idea would apply the new fee system across transactions but let existing smart contracts continue operating under the previous gas rules, effectively creating two gas-accounting paths in parallel.
Both approaches are still drafts. Ethereum developers have not decided whether either proposal will be adopted, or on what timeline.
What happens next
Rebuffo’s draft has not yet gone through execution-client implementation or consensus testing, leaving substantial review work ahead. More broadly, the compatibility questions raised by Glamsterdam appear unresolved for now.
Before the latest proposals were submitted, developers had discussed running the next private test as early as Nov. 16 to Nov. 20. With the new drafts now under consideration, additional evaluation is likely before that plan can be confirmed or revised.
Source: en.bloomingbit.io