Ethereum’s Glamsterdam Upgrade Hits a Security Checkpoint

Ethereum developers have postponed the Hoodi testnet launch for Glamsterdam, a major protocol upgrade intended to improve the network’s capacity and execution performance. The testnet fork had been scheduled for October 26, 2026, but concerns about smart-contract compatibility pushed the launch back.

The immediate issue centers on two proposed Ethereum Improvement Proposals, EIP-8037 and EIP-8038. The changes would revise gas accounting in parts of the Ethereum Virtual Machine, or EVM. Gas is the accounting system that measures computational work on Ethereum and limits how much processing a transaction can consume.

The changes are designed to support larger and more efficient blocks. Yet researchers warned that they could also affect the way existing contracts handle failed calls, including whether an error can be caught and corrected or instead becomes permanent within a transaction.

CoinDesk reported that developers delayed the testnet launch after security researchers identified risks to existing contracts. ChainSecurity found 13 real-world examples that may require review under the proposed rules.

That finding matters because Ethereum’s compatibility promise is broader than keeping old code syntactically valid. A contract can continue to compile and deploy while its economic assumptions change underneath it. If a call that once failed in a recoverable way becomes unrecoverable, an application may behave differently even though its source code has not changed.

Why gas accounting is a contract issue

Gas is often described as a transaction fee, but it also functions as a control mechanism inside smart contracts. Each operation performed by the EVM consumes gas. A transaction receives a gas limit, and execution must stay within that limit to complete successfully.

Contracts also make calls to other contracts. Those calls can succeed, return a value, or fail. Developers commonly write logic that anticipates failure. A contract might attempt an operation, detect that it did not work, and then execute an alternative path. In other cases, a protocol may deliberately use a limited amount of gas for a call so that a failure does not invalidate the entire transaction.

This pattern is important across decentralized finance, token infrastructure, bridges, wallets, marketplaces, and automated trading systems. A lending protocol, for example, may call another contract to transfer collateral or verify a condition. A payment router may attempt one route and then try another. A vault may call an external strategy and record the result before continuing.

The distinction between a failed call and a failed transaction is central. In some designs, a lower-level call can fail while the surrounding transaction continues. The contract can inspect the result and decide what to do next. Proposed changes to gas behavior could alter that boundary.

Researchers warned that some calls could become permanently unsuccessful under conditions where developers previously expected the contract to recover. Other operations could fail even though they remain valid under the contract’s original logic. The risk is not necessarily that every contract will break. The concern is that a relatively small set of assumptions may be distributed across widely used applications and difficult to identify through simple code searches.

That makes the issue more complicated than a routine software update. Ethereum developers cannot test only the protocol’s own implementation. They must also examine the behavior of applications that were written years ago, sometimes using low-level EVM features that are not obvious from the application’s user interface.

The 13 contracts under review

ChainSecurity’s identification of 13 real-world examples gives the concern a concrete scope. The number does not represent all potentially affected contracts, and it does not mean that each example contains an exploitable vulnerability. It indicates that researchers found deployed code whose behavior could change under the proposed gas rules.

Security reviews of this type usually focus on interaction patterns rather than the business purpose of a contract. Researchers may look for low-level calls, gas forwarding, error handling, nested execution, and logic that depends on whether an operation can be retried. A contract can be safe under the current rules while becoming fragile if one of those conditions is evaluated differently.

The practical response for developers is a review of affected code and its dependencies. Projects may need to test both successful and failed execution paths, including cases where an external call runs out of gas or returns an error. They may also need to examine whether state changes occur before a failure and whether later logic assumes that a failed call can be handled locally.

For users, the concern is indirect but meaningful. A smart contract does not need to be drained for a protocol to suffer damage. Transactions could fail more often, withdrawals could become unavailable under particular conditions, automated strategies could stop operating, or funds could become temporarily difficult to move. In a more serious case, an application’s accounting could diverge from its intended design.

The postponed Hoodi launch gives teams additional time to identify such cases before the change reaches a public testing environment. It also creates an opportunity to expand testing beyond a small set of known examples. A testnet fork can reveal how the protocol behaves in practice, but it is most useful when projects have time to deploy, simulate and monitor their applications against the new rules.

Glamsterdam’s capacity ambitions

The compatibility debate is connected to Glamsterdam’s wider objective: allowing Ethereum to process more work per block. Earlier testing suggested that blocks could approach 200 million gas after the upgrade.

CoinDesk reported that Glamsterdam test runs came close to 200 million gas per block. A higher gas target can give Ethereum more execution capacity, allowing more transactions or more complex operations to fit into each block.

For users and businesses, that capacity could support lower congestion and better application performance. Ethereum’s base layer remains important for settlement, high-value decentralized finance, stablecoin transfers, token issuance and other activity that depends on a widely secured execution environment. Increasing the amount of work each block can handle could improve the experience for those applications, particularly during periods of heavy demand.

However, block capacity is not free. Larger blocks require more computation, storage and network bandwidth from validators. If the hardware and connectivity requirements rise too quickly, fewer participants may be able to operate nodes. That could weaken the network’s distribution even as transaction throughput improves.

The gas changes therefore sit within a broader engineering balance. Ethereum must increase capacity while protecting validator participation, predictable execution and application compatibility. A rule that makes blocks more efficient for one workload could create unexpected behavior for another. The network’s challenge is to improve performance without shifting excessive complexity onto developers and users.

This is why a testnet delay can be valuable. It slows the timetable, but it may prevent a more expensive failure after mainnet activation. A protocol upgrade that breaks a limited number of contracts during testing can be corrected through code changes and revised specifications. The same discovery after deployment could require emergency coordination among application teams, infrastructure providers and users.

A separate deposit bug

Developers also fixed a separate conditional bug involving validator and builder deposits. The issue is distinct from the gas-accounting concerns, but its appearance during the same upgrade process illustrates the number of moving parts involved in Glamsterdam.

Validator deposits are connected to Ethereum’s proof-of-stake security model. Builder deposits relate to participants involved in block construction and transaction ordering. Conditional logic governing those deposits must distinguish among different actors, states and eligibility requirements. A mistake in that logic could cause a deposit to be accepted or rejected under the wrong conditions.

The reported fix does not indicate that funds were lost or that the network suffered an active attack. It does show why protocol changes are tested across more than one category of behavior. The execution layer, consensus rules, validator operations and builder infrastructure all interact, and a change in one area can expose assumptions in another.

For organizations building on Ethereum, this creates a planning challenge. Teams need to track the upgrade’s specification, client releases, testnet schedule and security findings. Protocol developers must coordinate with node operators, wallets, custodians, exchanges and application teams. A testnet date is not merely an event for core developers. It is a dependency for the wider ecosystem.

What the delay means for mainnet

The postponed Hoodi fork makes Glamsterdam’s mainnet timeline less certain. Ethereum upgrades typically move through stages that include specification work, client implementation, testnet deployment and extended monitoring. A delay at the testnet stage can compress later testing or push the mainnet activation window.

That uncertainty is not necessarily a sign that Glamsterdam is failing. It may reflect a deliberate decision to prioritize compatibility over schedule. Ethereum’s decentralized development process gives client teams and researchers multiple opportunities to challenge an upgrade before it becomes irreversible on the main network.

The key question is what developers find during the additional review. If the affected patterns can be addressed through clarifications, client changes or guidance for application teams, the delay may remain limited. If the rules need to be redesigned, Glamsterdam could require a longer testing cycle.

The outcome will also influence how Ethereum evaluates future capacity increases. Larger blocks and more ambitious execution changes offer clear benefits, but each one increases the importance of regression testing for old contracts. Developers may need better tools that can simulate an entire application ecosystem under proposed EVM rules, rather than testing contracts only in isolation.

For businesses, that tooling could become as important as the upgrade itself. Financial applications, payment companies and infrastructure providers need confidence that a protocol change will not silently alter settlement behavior. Auditors need ways to identify contracts that depend on subtle gas semantics. Developers need clear migration guidance before an upgrade is finalized.

A test of Ethereum’s upgrade model

Glamsterdam presents a familiar tension in blockchain development. Ethereum wants to remain a reliable settlement network for code deployed across many years, while also improving enough to serve new users and applications. Those goals can conflict when performance improvements touch the low-level rules that contracts use to communicate.

The current findings do not establish a live exploit, and there is no indication in the reported concerns that user funds have been lost. The risk is one of compatibility and future behavior. That distinction is important, but it does not make the issue minor. Smart contracts often control assets, enforce financial agreements and coordinate automated systems. Even a narrow change in execution semantics can have consequences if it reaches production without adequate testing.

The delay gives Ethereum an opportunity to demonstrate that its upgrade process can respond to evidence before deployment. Researchers identified real examples, developers acknowledged the need for further work, and the testnet schedule was adjusted rather than forced through.

That approach may be slower than a fixed release calendar, but it supports the larger goal behind Glamsterdam. Ethereum’s next stage of growth will depend not only on processing more gas per block. It will depend on expanding capacity while preserving the assumptions that make existing applications dependable.

The postponed Hoodi launch therefore represents more than a scheduling setback. It is a checkpoint for Ethereum’s innovation model. If the network can resolve the gas risks, validate the deposit fix and give application developers a stable migration path, Glamsterdam could strengthen the foundation for higher capacity. If not, the delay will show that the proposed performance gains require a more careful redesign before they are ready for mainnet.