Ethereum Pauses Glamsterdam Test as Gas Accounting Risk Threatens Contract Compatibility

A testnet delay with mainnet significance

CoinDesk reported that Ethereum delayed the Glamsterdam test after security researchers and developers flagged a possible compatibility problem involving operations that run out of gas. The Hoodi testnet is a development environment, so the postponement does not affect users’ balances, active decentralized applications or transactions on Ethereum’s main network.

The decision is nevertheless important because testnets are where protocol changes are expected to encounter difficult edge cases before they reach production. A delay at this stage allows researchers, client teams and application developers to examine the behavior under controlled conditions. It also gives the ecosystem an opportunity to decide whether the proposed implementation needs to change, whether additional safeguards are required or whether the underlying design should be reconsidered.

The issue is connected to two proposals, EIP-8037 and EIP-8038. Their broader purpose is to improve the way Ethereum accounts for the resources required to maintain its state, the continuously updated record of accounts, contract code and storage. At the same time, the proposals support a roadmap that could allow blocks to carry more activity.

That combination reflects Ethereum’s central scaling challenge. More capacity can make the network faster or cheaper to use, but every additional state change creates costs for node operators. If those costs are not measured accurately, the network can encourage activity that becomes expensive to store, verify and serve over time.

Why gas accounting matters

Gas is Ethereum’s internal accounting system for computation and state changes. Every transaction receives a gas limit, and each operation consumes gas according to the work it asks the network to perform. If execution reaches the transaction’s gas limit before completing, the operation fails. The transaction may still consume the gas used up to that point, but the protocol generally prevents an incomplete state change from being accepted as though it had succeeded.

This behavior is a basic assumption in smart contract design. Developers use gas limits to control execution, handle failure and protect contracts from unexpectedly expensive operations. Applications may deliberately call another contract with a limited amount of gas, then inspect whether the call succeeded. Wallets, decentralized exchanges, lending platforms, bridges and automated strategies can all depend on predictable failure behavior.

The concern identified around EIP-8037 and EIP-8038 is that changes to gas accounting could affect what happens when an existing contract call runs out of gas. Researchers warned that some failed operations could become permanent, while other valid transactions might fail unexpectedly. The exact behavior depends on how the proposals interact with contract execution and state changes, but the underlying risk is clear: a change intended to improve resource accounting could alter the execution environment assumed by applications already deployed on Ethereum.

That is not the same as saying that all contracts would break. Ethereum contains millions of contracts with different designs, and many would likely continue operating normally. The challenge is identifying the less common patterns that rely on details of gas forwarding, failure handling or state reversion. A problem affecting a narrow category of contracts can still have broad consequences if that category includes infrastructure used by many applications.

The compatibility burden of a mature network

Ethereum’s appeal is partly based on its accumulated network effects. Developers do not build only for the current version of the protocol. They build on established standards, tools and execution rules, expecting deployed contracts to remain usable as the network evolves. That expectation makes upgrades more valuable, because every improvement can benefit a large existing ecosystem. It also makes changes more difficult, because protocol engineers must preserve compatibility with code they did not write and may not be able to modify.

Smart contracts differ from conventional software in one crucial way: once deployed, many cannot be patched in the usual sense. Some projects use upgradeable contract patterns, but others intentionally make their code immutable. Even when developers can deploy a replacement, moving users, liquidity and integrations to new contracts can be costly. A subtle change in low-level execution behavior can therefore create a long tail of migration work.

Gas accounting is particularly sensitive because developers often use it as a control mechanism. A contract might pass a deliberately restricted gas amount to a callback to prevent excessive computation. Another contract might treat an out-of-gas result as a normal failure and continue with an alternative path. If an upgrade changes whether that failure is reverted, preserved or propagated, the application’s logic may no longer match the developer’s original design.

The most exposed systems could include contracts that make external calls, interact with untrusted code or depend on partial execution. DeFi protocols frequently call multiple contracts within a single transaction. Market makers, vaults and liquidators also use tightly managed gas budgets because a transaction can become unprofitable or unsafe if execution costs rise. A compatibility issue does not need to drain funds to cause disruption. It could prevent a liquidation, interrupt a settlement process or cause an automated transaction to fail at a critical moment.

Scaling without shifting costs elsewhere

The proposals highlight a broader tension in Ethereum’s scaling strategy. Larger blocks can increase the amount of computation and data processed in each block. That may improve throughput for users and applications, but it also increases the burden on validators and other network participants that must execute transactions and retain state.

Ethereum’s state has grown as more contracts, tokens and applications have been deployed. State growth affects more than storage capacity. Nodes must be able to access relevant data quickly, synchronize with the network and verify new blocks. If the cost of creating or modifying state is too low, the network can accumulate obligations faster than operators can manage them.

EIP-8037 and EIP-8038 are intended to address that resource problem through updated accounting. In principle, better pricing can make the network more sustainable. It can align the gas charged to users with the computational and storage burden their actions impose. That alignment matters for long-term scalability because it reduces the chance that short-term demand creates an unpriced burden for the entire ecosystem.

However, changing prices or accounting rules can affect more than transaction fees. Gas is also part of the programming model. Contracts use gas limits, forwarded gas and failed calls as inputs to their logic. Any adjustment must therefore be evaluated in two dimensions. The first is whether the network charges fairly for its resources. The second is whether contracts continue to observe the same execution guarantees.

A technically efficient accounting model would not be a successful upgrade if it makes widely used application patterns unreliable. Conversely, preserving every historical behavior without improving resource pricing could leave Ethereum less able to support growth. The purpose of testing is to find a workable balance before the change becomes difficult to reverse.

What the delay means for builders

For developers, the Hoodi postponement is a reminder that testnet participation is part of product development, not merely a final demonstration. Application teams that depend on Ethereum’s execution behavior can use testnets to exercise contracts against proposed protocol changes. They can compare transaction traces, monitor failure modes and identify assumptions that may not appear in ordinary unit tests.

Testing should include more than successful transactions. Teams need to examine calls that approach their gas limits, callbacks that intentionally fail and transactions that interact with multiple contracts. They also need to test how state changes are handled when execution stops halfway through a sequence. These cases can expose incompatibilities that ordinary end to end tests miss.

Infrastructure providers have a related responsibility. Wallets, node services, block builders, analytics platforms and transaction simulation tools all interpret execution results. If a protocol change alters how a failed operation is represented, those services may need updates even when the application contracts themselves remain unchanged.

The episode also creates a practical opening for developers who build testing and security tools. As Ethereum becomes more complex, protocol upgrades require better ways to simulate alternate execution rules across large contract inventories. Static analysis, transaction replay and formal verification can help identify vulnerable patterns before an upgrade reaches mainnet. The value of these tools extends beyond Ethereum because other smart contract networks face similar compatibility pressures.

A governance test as much as a technical test

Ethereum upgrades are coordinated through a process involving core developers, client teams, researchers, validators and application builders. No single organization can unilaterally guarantee that a change will work across the network. The Glamsterdam delay shows why that distributed process matters. A researcher’s finding can influence the schedule before users are exposed to the risk.

That process can be frustrating for companies planning around a delivery date. A delayed upgrade may postpone expected capacity improvements, alter infrastructure plans or extend uncertainty for application teams. Yet the cost of delay is generally easier to manage than the cost of deploying a change that breaks important contracts. In a network valued for neutrality and reliability, caution is an operational advantage.

The next phase will likely focus on clarifying the interaction between the two proposals, reproducing the reported behavior and determining how broadly existing contracts are affected. Developers may revise the implementation, add compatibility protections or change the testing plan before another Hoodi activation is scheduled. The outcome will provide a more useful signal than a launch that proceeds without resolving the underlying concern.

Why users should pay attention

Most Ethereum users will not need to understand the details of EIP-8037 or EIP-8038 to feel the effects of a future scaling upgrade. They may encounter them through transaction reliability, wallet estimates, application availability or fees. If the upgrade succeeds, users could benefit from a network able to handle more activity while managing the cost of state growth more responsibly.

The immediate message is not that Ethereum is unsafe or that mainnet funds are in danger. It is that scaling is not only a question of adding capacity. Ethereum must also preserve the behavior that gives developers confidence to build financial, commercial and consumer applications on top of it.

A testnet delay is therefore a measurable sign of progress, not necessarily a setback. It shows that the upgrade process is finding problems while there is still time to fix them. For Ethereum’s next stage, that discipline may matter as much as larger blocks or more efficient gas accounting. The network’s ability to scale will depend not only on how much activity it can process, but also on whether the builders using it can trust the rules to remain predictable.