Ethereum Puts Glamsterdam Test on Hold Over Contract Compatibility Risk

Ethereum’s next major upgrade has run into a problem that is less visible than a failed transaction or a crowded block, but potentially more consequential for the network’s long-term capital base: changing the cost of computation without changing the code that depends on it.

The delay affects Glamsterdam’s planned activation on Hoodi, an Ethereum testnet used to evaluate upgrades before they move toward mainnet deployment. Researchers at ChainSecurity identified risks connected to EIP-8037 and EIP-8038, proposals that would change how the network accounts for gas in certain operations. Their concern is not that the changes create an active exploit. It is that they may invalidate assumptions embedded in contracts that have already been deployed and funded.

CoinDesk reported that Ethereum delayed the Hoodi test after security developers flagged risks to existing contracts. The findings have forced developers to reconsider how aggressively Ethereum can raise its capacity while preserving the behavior expected by applications, wallets, exchanges, lending protocols and other systems built on top of the chain.

The issue is important because Ethereum’s upgrade process is designed around backward compatibility. A contract deployed years ago cannot be rewritten by its users simply because the protocol changes the price of a storage operation or the amount of gas reserved for a failed call. If the economics of that contract change, the code may remain untouched while its outcomes change.

That creates a difficult tradeoff. Ethereum needs more capacity to support capital flows through decentralized finance, stablecoins, tokenized assets and consumer applications. At the same time, a larger gas limit and cheaper or differently priced operations can expose weaknesses in contracts that were written under older assumptions. The Glamsterdam delay shows that scaling is not only a question of how many transactions a block can process. It is also a question of whether the network can raise throughput without changing the economic meaning of existing code.

Why gas accounting matters

Gas is Ethereum’s mechanism for pricing computation and limiting the amount of work that can be included in a block. Every operation consumes gas. Users pay for that work through transaction fees, while validators use the gas limit to determine how much computation a block can contain.

The system performs two jobs at once. It allocates a scarce resource, block space, and protects the network from transactions that would require unlimited computation. A transaction that runs out of gas normally fails and reverts its state changes. That predictable failure behavior is part of the programming environment on which smart contracts rely.

Gas is also a form of risk management. Developers do not only ask whether a transaction is logically valid. They ask whether it can complete within the gas available to it, whether an internal call can forward enough gas, and whether a storage update will cost more than expected. Contracts often use these constraints deliberately. A failed operation can trigger fallback logic, prevent a state change or cause a larger transaction to revert.

EIP-8037 and EIP-8038 have raised concerns because changes to gas accounting can affect those assumptions from several directions. Some error paths could potentially succeed when they previously reverted. Other operations that were previously affordable could fail if their storage costs increase unexpectedly. The danger is therefore not limited to a single class of contract. It concerns any application whose logic depends on a particular relationship between gas consumption and execution outcomes.

A contract does not need to contain an obvious bug to be exposed. It may simply have been designed around the existing gas schedule. Developers could have estimated the cost of a storage update, set a gas limit for an internal call or used failure as a signal that an operation did not complete. If the protocol changes those costs, the contract can produce a different result without any change in its source code.

That difference is especially significant for contracts that manage funds. A lending market, exchange, bridge or vault may have tightly coupled accounting steps. If one step fails, the whole transaction may be expected to revert. If a call succeeds under conditions where it previously failed, later code may execute with a different state assumption. Conversely, if a valid storage operation becomes too expensive, an action that users and integrators consider routine could stop completing.

The researchers’ warning does not establish that these outcomes would occur across Ethereum or that funds are currently at risk. It does establish that the proposed changes need broader testing before they can be treated as safe for a network containing years of deployed applications.

The capital cost of a compatibility failure

The immediate effect of the delay is technical, but the underlying stakes are financial. Ethereum’s contracts hold and route a large share of the ecosystem’s on-chain liquidity. Stablecoins, lending collateral, exchange inventory, staking positions and tokenized assets all depend on code continuing to behave as expected after protocol upgrades.

A compatibility problem can damage that liquidity even without an exploit. Users may stop interacting with a contract if its transactions become unreliable. Market makers may reduce inventory in a venue if settlement paths can fail unexpectedly. Wallet providers and exchanges may pause support for affected operations while developers investigate. In each case, capital becomes less mobile.

That loss of mobility matters because decentralized finance relies on composability. One contract often calls another, and an application may depend on several external systems completing in a particular order. A change in gas behavior at one layer can affect the execution assumptions of an entire transaction path. If users cannot predict whether a call will succeed, they may demand higher returns for providing liquidity or move funds to simpler applications.

The risk also falls unevenly across the ecosystem. New contracts can be written with the revised rules in mind. Older contracts cannot necessarily be upgraded, especially when they are immutable or governed by mechanisms that do not allow changes to core execution logic. Some applications may have upgrade administrators, but upgrades themselves require testing, governance approval and user confidence. A protocol with locked funds or many integrations cannot treat a network-wide accounting change as a routine software release.

This is why backward compatibility has a direct relationship with investor conviction. Large capital allocators can accept technical change when the migration path is clear. They are less likely to commit funds when a protocol upgrade creates uncertainty about whether established infrastructure will continue to settle transactions in the same way.

Glamsterdam’s capacity target is now under review

The delayed Hoodi activation also puts Glamsterdam’s proposed capacity increases under scrutiny. Earlier testing had pushed the network toward a gas limit near 200 million gas per block, a level intended to expand the amount of computation Ethereum can process in each block.

CoinDesk reported that Glamsterdam’s test runs were approaching 200 million gas per block. That target reflects Ethereum’s continuing effort to increase base-layer capacity while using rollups and other scaling systems to handle additional activity.

A higher gas limit can improve throughput, but it is not free. Validators must execute, verify and propagate larger blocks. The more work a block contains, the greater the hardware, bandwidth and timing requirements for participants. If the increase is too aggressive, it can make it harder for smaller operators to keep up, potentially affecting the distribution of the validator set.

Gas repricing adds another layer to that calculation. If certain operations become cheaper, users may be able to include more of them in a block. If storage operations become more expensive, the same block may contain fewer storage-heavy transactions, while contracts built around those operations face higher execution costs. The final result is not determined by the headline gas limit alone. It depends on the mix of workloads that applications generate.

This is relevant to where liquidity is positioned. Ethereum’s base layer competes with layer 2 networks and other chains for settlement activity. A larger gas limit could make Ethereum more attractive for transactions that require direct access to mainnet liquidity or security. But an upgrade that introduces uncertainty for established contracts could encourage applications to delay deployment, keep balances on alternative networks or rely more heavily on systems with lower execution costs.

Scaling therefore involves more than increasing the number of transactions per block. It requires preserving predictable costs for the applications that create demand for block space in the first place.

How developers test backward compatibility

Ethereum’s upgrade process includes multiple testnets, client implementations and stages of review before a change is activated on mainnet. Testnets such as Hoodi allow developers to run the proposed rules against realistic workloads without putting mainnet funds directly at risk.

That testing is particularly important for gas changes because standard functional tests may not expose every compatibility problem. A contract can pass its normal unit tests while failing under a different gas budget. Developers need to examine transactions that run close to their limits, internal calls that forward only part of their available gas and failure paths that are rarely exercised in ordinary conditions.

They also need to test interactions between contracts. A storage change that appears harmless in isolation may become significant when a lending protocol calls a token contract, which then calls another contract, all within one transaction. The question is not only whether each component works independently. It is whether the entire chain of calls continues to produce the same result under the new accounting rules.

Researchers and client teams can use historical transaction traces to identify contracts that would be affected. They can compare execution under the current rules with execution under the proposed rules and search for differences in success status, gas consumption and state changes. That kind of analysis can reveal exposure in contracts whose developers are no longer active or whose source code is difficult to interpret.

The broader ecosystem also needs time to respond. Infrastructure providers, security firms, wallets, exchanges and application teams must receive clear specifications and test releases. If a contract needs to be modified, its operators must determine whether an upgrade is possible and whether users need to move funds. If no change is possible, developers may need to identify transaction patterns that should be restricted after the upgrade.

The Hoodi delay gives that process more time. It also indicates that the current implementation has not yet provided enough confidence for a public testnet activation.

No replacement date has been announced

Ethereum has not announced a replacement date for the Hoodi activation or a mainnet date for Glamsterdam. That uncertainty is preferable to setting a schedule before the compatibility questions are resolved. A rushed test could produce misleading confidence if it does not cover the contracts and execution paths most likely to be affected.

For market participants, the absence of a new date means the upgrade should not yet be treated as a near-term source of additional capacity. Developers may continue preparing applications and infrastructure, but they cannot rely on the proposed gas limit or final accounting rules until the changes are settled. Capital deployment decisions will remain tied to the existing network environment and to the capacity available through layer 2 systems.

The pause also gives Ethereum developers several possible paths. They could revise the EIPs, narrow the scope of the gas changes, introduce compatibility safeguards or abandon a particular accounting approach. They may also determine that the expected benefits justify the risks, provided the affected contracts can be identified and protected. Each option carries a different balance between capacity, implementation complexity and backward compatibility.

The central question is whether Ethereum can make computation and storage more efficient without turning old assumptions into new failure modes. That question will shape not only Glamsterdam but future attempts to raise the network’s throughput.

Ethereum’s value is tied to the amount of capital that users are willing to place inside its execution environment. Higher capacity can attract more activity, but only if users believe transactions will settle predictably and contracts will keep their promises. The Glamsterdam delay is a reminder that protocol upgrades are ultimately judged by that confidence.

For now, the prudent signal is not that Ethereum has abandoned scaling. It is that developers are treating compatibility as part of the scaling problem itself. Before the network can safely process more work, it must show that the contracts already carrying billions of dollars can continue to perform the work they were designed to do.