Ethereum Glamsterdam Bug Could Have Sent Staked ETH to the Wrong Accounts, Developers Step In

Ethereum developers have patched a potential big bug in the upcoming Glamsterdam network upgrade that could have caused funds intended to activate new validators to be credited to block builders instead.

The issue emerged during a review of the proposed rules governing deposit processing. Although the scenario had not been observed in an actual attack, it raised concerns about how Ethereum would assign pending deposits when block builders and validators used the same public key.

The fix was merged into Ethereum's consensus specifications on Monday, October 26, after an earlier proposal was rejected because it lacked sufficient support from client development teams. Additional analysis and new tests helped developers revisit the change.

Researchers described the issue as a potential flaw in the draft rules rather than a confirmed exploit. No losses linked to the bug have been reported, and existing validation mechanisms may have prevented the scenario from occurring.

Why Glamsterdam's Deposit Rules Matter

Glamsterdam is designed to introduce changes to Ethereum's block production and validation processes, alongside adjustments to gas accounting and network data management.

One of its key objectives is to establish a more structured separation between block builders and validators. Block builders assemble transactions into proposed blocks, while validators participate in confirming blocks and maintaining the network's consensus after depositing ETH to support network security.

Although these roles serve different purposes, their operations can involve deposits associated with the block-production process. The protocol must therefore distinguish between funds belonging to each participant, even when both use the same public key.

A public key identifies an entity within the system, but using the same key should not cause deposits intended for separate purposes to be combined or assigned to the wrong account.

The potential flaw involved pending deposits that had not yet been assigned to their final accounts. Under the original draft rules, registering a block builder could have affected how a subsequent deposit intended to create a new validator was processed.

How the Potential Bug Could Have Redirected Funds

The scenario outlined by the researchers begins with an operator registering as a block builder using a particular public key. If an Ethereum staking service subsequently deposited the ETH required to activate a new validator using that same key, the draft rules could have treated the new deposit as belonging to the block builder.

Instead of being correctly recorded for the validator, the funds could have been credited to the block builder's account. The intended validator would then fail to be created as expected, potentially leaving the staking service unable to recover its funds through the usual process.

The researchers warned that, if the necessary conditions were met, the flaw could have allowed an operator to withdraw protocol funds that did not belong to it.

However, they did not report an actual exploitation. The finding described a conditional scenario arising from how the proposed rules could interact with deposit processing.

The issue highlights the importance of correctly ordering pending deposits and validating their associated data before assigning them to final accounts. Changes to how participants are registered or deposits are processed can introduce unexpected interactions even when other network safeguards continue to operate as designed.

Staking Protocols Also Came Under Review

The investigation extended beyond Ethereum's core consensus rules to consider how liquid staking protocols, including Lido, Origin, and Rocket Pool, might be affected.

The potential impact could vary depending on how each protocol handles deposits and validates the information associated with them. The researchers characterized the work as a rapid investigation assisted by artificial intelligence, while emphasizing that the findings did not establish that an exploit had occurred.

Existing validation rules may also have blocked the proposed scenario. According to the explanation, the current checks can reject a deposit if a block builder has already deposited funds using the same public key.

This means the potential risk depended on how the revised rules interacted with those existing checks, rather than representing a universally exploitable flaw under all circumstances.

Reviewing the possible effects on staking protocols gives developers an opportunity to determine whether additional safeguards or changes to deposit handling are necessary before the upgrade progresses further.

Why Developers Revisited the Rejected Patch

The repair went through a review process before being incorporated into Ethereum's consensus specifications.

On October 19, developers closed the initial proposal after it failed to secure sufficient support from client teams. The researchers cited Justin Drake, an Ethereum consensus-specifications contributor, in describing the lack of support for including the change at that stage.

Client teams maintain the software that node operators and validators use to interact with Ethereum. Their agreement is essential when consensus rules change, since different implementations must apply the updated specifications consistently.

The proposal was subsequently reopened for further consideration. The researchers added tests on October 23, and Drake merged the fix on October 26.

The sequence illustrates how a proposed change can move from rejection to adoption after additional technical analysis and testing. Even a relatively narrow adjustment can require further scrutiny when it affects validator deposits and the allocation of funds.

Patch Changes How Pending Deposits Are Ordered

The fix changes the ordering of pending deposits so that they are organized according to their withdrawal credentials, the information used to determine where the funds associated with a deposit can ultimately be withdrawn.

The objective is to preserve the distinction between validator deposits and block-builder deposits, even when the participants share a public key. Under the revised approach, the public key alone should not determine how funds are assigned.

The change has been incorporated into Ethereum's consensus specifications, but implementation still requires client teams to integrate the revised rules into their software and verify that their implementations behave consistently.

That distinction matters because a change to the written specifications must also be reflected in the software operating across the network.

Glamsterdam Faces Further Testing Delays

The deposit fix comes as developers continue to assess other technical changes planned for Glamsterdam.

The upgrade was activated on Ethereum's Sepolia testnet on October 6, 2026, allowing developers to test changes related to block production, gas accounting, and network capacity.

A subsequent activation on the Hoodi testnet had been scheduled for October 26. However, developers announced a delay on October 22 to allow more time to assess how proposed gas-accounting changes could affect existing smart contracts. No replacement activation date had been announced in the supplied reports.

Developers must now establish a revised Hoodi testing schedule after addressing the outstanding technical concerns and verifying compatibility across client implementations.

A mainnet launch date has also not been established. The deposit patch is therefore one part of a broader review process, rather than confirmation that Glamsterdam is ready for final deployment.

Analysis: A Small Code Change With Broader Implications

The deposit bug illustrates why major Ethereum upgrades require more than performance improvements and new network features. Changes to consensus rules must also preserve the integrity of deposits, account assignments, and the interactions between different types of network participants.

Separating block-building responsibilities from validator duties could help Ethereum improve how it organizes block production. But the benefits depend on implementing precise rules that prevent overlapping identities or processing sequences from affecting the ownership of funds.

The incident also highglights the value of independent research and adversarial testing before changes reach the mainnet. Although no losses were reported, identifying a possible failure mode gave developers an opportunity to amend the specifications and add tests before the upgrade progressed further.

At the same time, the delay to Hoodi demonstrates that a successful testnet activation does not establish that an upgrade is ready for production. Developers must assess the combined effects of protocol changes, confirm that client implementations remain consistent, and investigate potential consequences for existing smart contracts.

For Glamsterdam, progress will depend on resolving these technical questions while preserving the security guarantees that Ethereum's validators and users rely on.

The latest patch addresses one identified risk, but the wider upgrade remains subject to further testing and review.