Glamsterdam Gas Changes Threaten Existing Ethereum DApps

Why Glamsterdam Is Raising Compatibility Alarms

Ethereum core developers are debating how to implement the Glamsterdam upgrade after security researchers flagged potential disruptions to deployed smart contracts. Two competing proposals, submitted November 8 by developers Leo Glisic and Giulio Rebuffo, aim to introduce revised gas pricing without breaking legacy applications. The changes follow planned gas repricing under EIP-8037 and EIP-8038, which alter how the execution environment bills for state creation and access. With DeFi protocols and other on-chain services at stake, the community is racing to find a safe path forward.

The proposals: Two different strategies to preserve compatibility

EIP-8488 and V2 opcodes: Glisic's path for new contracts

Leo Glisic proposed EIP-8488, a model that isolates new gas rules to freshly deployed contracts by introducing V2 opcodes. Under this approach, legacy contracts would continue running with the existing gas schedule while new contracts adopt the revised pricing introduced through EIP-8037 and EIP-8038. The goal is to avoid forcing developers to redeploy or modify immutable contracts while still allowing the network to evolve its gas accounting for future deployments.

Dual gas accounting: Rebuffo's transaction-level split

Giulio Rebuffo put forward an alternative draft that keeps two separate gas accounting systems inside each transaction. One counter would compute gas consumption using the legacy rules so that contract execution sees the same resource assumptions as before; the other would calculate the actual fee billed to the user under the new pricing schedule. This dual-accounting idea attempts to preserve execution semantics while migrating fees to the updated structure, but it currently lacks execution client implementations and consensus tests.

Technical background: What EIP-8037 and EIP-8038 change

The compatibility debate centers on EIP-8037 and EIP-8038, which change how Ethereum charges for creating contracts and accessing state. Most notably, EIP-8037 would raise the base gas cost for deploying a smart contract from 32,000 to 183,600, excluding execution and code storage costs. The repricing is intended to better reflect the long-term resource burden contracts impose on node operators, but it also disrupts assumptions that many existing contracts make about available gas and failure modes.

Security analysis: Which contracts are at risk?

Assumptions invalidated by new gas rules

Security firm ChainSecurity highlighted eight common assumptions in deployed smart contracts that could break under the new gas regime. Examples include reserving a fixed gas amount for external calls, expecting specific behavior on partial execution failures, or relying on predictable gas refunds and checkpoints. If those assumptions no longer hold, transactions may revert at unexpected times or external interactions can fail in ways the original developers did not anticipate.

Scope of potential impact

Community analyses suggest the issue is not isolated. A pseudonymous developer, banteg, cited an existing analysis identifying roughly 200,000 potentially affected contracts, and warned that methodological limitations could undercount the true scope. The concern extends beyond toy contracts to established DeFi protocols, wallets, bridges, and other applications that manage user funds or rely on deterministic execution.

DeFi and community reaction

The prospect of breaking live contracts prompted urgent responses from industry figures. Curve Finance founder Michael Egorov warned that proceeding without resolving compatibility risks could force an emergency hard fork, introducing drama and operational strain for the network. Investor and community member Ryan Berckmans initially supported rapid activation but reversed his position after reviewing the compatibility warnings. Security researcher pcaversaccio urged that Glamsterdam should not ship in its current form, reflecting a broader push for caution.

Testing, postponements, and developer coordination

Glamsterdam testing faced schedule changes after the warnings. Developers postponed the October 26 Hoodi activation, which covered Amsterdam execution-layer modifications, Gloas consensus changes, and a planned increase of Hoodi's gas limit to 200 million. The postponement allowed time to work with auditors and security firms to identify at-risk contracts and collect developer feedback.

Audit partners and next test windows

Ethereum Foundation developer Marius van der Wijden said the foundation coordinated with ChainSecurity and Dedaub to examine affected contracts and gather feedback. Teams tentatively discussed a private test window for November 16 to 20, but that schedule was drafted prior to the submission of the two competing proposals and may evolve as research progresses and potential mitigations are validated.

What could happen next: Paths to resolution

At least three outcomes are possible. First, the community could adopt one of the compatibility proposals—either Glisic's opcode segregation or Rebuffo's dual accounting—followed by extensive client implementations and network testing. Second, the team could revise the EIP-8037 and EIP-8038 parameters to minimize behavioral changes for legacy contracts. Third, developers might delay Glamsterdam components until a robust mitigation strategy is proven, avoiding the risk of forced emergency forks or degraded DeFi operations.

Why this matters for node operators, developers, and users

Gas repricing is not just a fee adjustment; it changes runtime invariants that many smart contracts assume. Node operators and infrastructure providers could see different resource profiles, while dApp developers may face unexpected reverts or broken integrations. For users, the immediate risk is failed transactions, lost gas, or temporarily unavailable services in widely used DeFi apps. Given the systemic nature of these risks, the community is emphasizing careful testing, audits, and a coordinated rollout to preserve network reliability.

Conclusion: Caution before activation

The Glamsterdam debate highlights the complexity of evolving a decentralized execution layer. While the goals behind EIP-8037 and EIP-8038—to better price long-term resource use—are widely understood, ensuring a safe transition for millions of deployed contracts is proving more challenging. The competing proposals from Glisic and Rebuffo offer different trade-offs between forward progress and backward compatibility, but neither has been approved for inclusion yet. As audits continue and community feedback accumulates, Ethereum stakeholders will need to balance technical upgrades with operational safety to avoid network disruption or an emergency hard fork.