Ethereum Developers Draft Fixes for Glamsterdam Contract Risks

By Tom Whitfield

Ethereum postponed its second Glamsterdam test, previously scheduled for Oct. 26, after security researchers raised compatibility concerns tied to gas changes that anonymous developer Vanteg said could affect about 200,000 smart contracts.

Vanteg said “about 200,000 smart contracts may already be affected” and that the actual number could be larger. He also warned that “service disruptions are possible” when deployed contracts cannot adjust to the new gas schedule.

What could break under Glamsterdam?

EIP-8037 and EIP-8038, both included in Ethereum’s next upgrade, form the center of the compatibility debate. The proposals would raise gas costs for creating smart contracts and storing data.

Under EIP-8037, the base gas required to create a smart contract would increase to 183,600 from 32,000. The new requirement is roughly 5.7 times the current baseline, a 151,600-gas increase that changes assumptions developers used when designing existing applications.

Some contracts were designed around current gas costs. If they assign a fixed gas amount when calling other contracts, the transactions could fail after the increase takes effect. Contracts that cannot change after deployment could lose service availability rather than merely face higher operating costs.

The failure mode does not require contract code to change. A fixed gas allowance can become insufficient after the schedule change, blocking a transaction even when the deployment remains untouched.

How do the two fixes work?

CoinDesk reported on Nov. 9 that Ethereum developers Leo Glisic and Giulio Rebuffo each submitted a proposal on Nov. 8. Both documents remain drafts; developers have not selected either approach or set an adoption date.

Glisic’s EIP-8488 would keep current gas fees for existing smart contracts while applying higher rates only to new contracts. Existing deployments would retain their established gas assumptions, while newly deployed contracts would absorb the higher schedule.

Rebuffo proposed applying the new fee structure to all transactions while allowing existing smart contracts to run under the previous rules. His design would effectively operate two gas-calculation systems in parallel, preserving prior rules for existing contracts while applying the new structure at the transaction level.

Rebuffo’s proposal still lacks execution-client implementation and consensus testing. That leaves the alternative unproven at the software and network layers required to support parallel gas calculations.

Can developers test the fixes before the next window?

Developers had expected to conduct the next private test as early as Nov. 16-20. The postponement of the Oct. 26 test therefore shortens the period available to review both drafts and prepare another execution trial.

That target predates both Nov. 8 submissions. Compatibility review must now determine which fee treatment developers will test and whether the upgrade can proceed on the expected private-test timetable.

Further review is likely as developers compare a deployment-age split with parallel gas calculations. The unresolved choice covers both contract compatibility and the operational complexity of applying two calculation regimes.

For now, the Nov. 16-20 private-test window remains conditional on further review, with no adoption date for either draft and no final choice between the two fee treatments.