Ethereum Developers Patch Glamsterdam Bug That Could Have Redirected Validator Deposits

What to Know

• Ethereum developers patched a flaw in the upcoming Glamsterdam upgrade that could have allowed an operator to withdraw ETH intended for new validators.
• The issue involved builder and validator deposits sharing a public key, creating a scenario where both deposits could be credited to the builder.
• The fix was merged Monday after developers initially closed the proposed change on Oct. 19 due to insufficient client support.
• Researcher Avsetsin identified the scenario and later added tests on Oct. 23 before the fix was merged.
• No losses have been reported, and the findings were described as conditional code findings rather than confirmed live exploits.
• The revised rules sort pending deposits by withdrawal credentials so validator deposits remain with validators even if a builder uses the same key.
• Client teams still need to incorporate the updated consensus rules into their software before Glamsterdam can proceed toward mainnet launch.
• Glamsterdam has already run on the Sepolia test network, while its Oct. 26 launch on Hoodi was postponed.

Ethereum Tightens Glamsterdam Deposit Rules

Ethereum developers have patched a vulnerability in the upcoming Glamsterdam upgrade that could have allowed ETH meant for new validators to be misdirected to builders. The issue centered on how deposits are handled during the upgrade process, particularly when deposits are waiting to be credited and when the same public key is used in both builder and validator contexts.

The fix changes the rules for handling validator deposits and has now been merged into Ethereum’s consensus specifications. The change follows a short but important reversal by developers, who initially rejected the proposal before reopening it for further review. The added time created by testing delays gave client teams and researchers more room to examine the consequences of the flaw and agree on a safer approach.

For Ethereum, the patch is significant because Glamsterdam is designed to reshape how certain network roles interact. The upgrade separates functions that are currently more closely bundled together. Builders bundle transactions into blocks, while validators stake ETH to help secure the network and confirm blocks. Both builders and validators can deposit ETH, but those deposits are meant to remain separately tracked.

How the Deposit Bug Could Have Worked

The vulnerability emerged from a specific deposit-handling scenario. A public key serves as an identifier tied to a validator or builder. Researcher Avsetsin identified a case in which an operator could first register as a builder using a particular public key. If a staking service later deposited ETH to start a validator under that same key, the draft rules could have credited both deposits to the builder.

In that scenario, the staking service would not get the validator it intended to create. Because no validator would be created, the staking service could also be left without the proof needed to recover the money. Avsetsin warned that the operator could withdraw the protocol’s funds under the vulnerable handling path.

The concern was not presented as a confirmed live exploit. Avsetsin described the findings as conditional code findings, not confirmed live exploits. The outcome depended on how each protocol handled deposits and whether existing checks would reject an earlier builder deposit. Those checks could stop the attack in some cases. No losses have been reported.

Why Builders and Validators Matter

Ethereum’s post-merge design relies on validators to secure the chain by staking ETH and participating in block confirmation. Builders, meanwhile, are part of the transaction packaging process. They assemble transactions into blocks, which validators can then select and confirm. The separation of these roles is central to how the network aims to improve efficiency and manage the increasingly specialized block production pipeline.

Glamsterdam is expected to further refine this division. That makes deposit accounting especially important. When two roles can interact with deposits under overlapping identifiers, the consensus rules must make clear which funds belong to which role and which withdrawal credentials control eventual access to those funds.

The patched rule focuses on withdrawal credentials, the setting that specifies where a deposit’s money can ultimately go. By sorting pending deposits according to those credentials, the revised approach is designed to ensure that validator deposits remain with validators even if a builder is using the same public key. That distinction is essential because public keys alone were not sufficient to prevent the problematic overlap under the earlier draft rules.

Developers Reversed Course After Further Review

The fix was initially closed on Oct. 19. Justin Traglia, who maintains Ethereum’s consensus specifications, wrote that there was not enough support from clients to make the change at that time. In Ethereum development, client support is critical because validators run separate client software programs to participate in the network. A consensus change must be implemented reliably across those clients to avoid fragmentation or unexpected behavior.

After additional review, the fix was reopened. Avsetsin added tests on Oct. 23, strengthening the case for the revised rule and helping demonstrate the behavior developers wanted to prevent. Traglia then merged the change Monday, bringing the updated handling into Ethereum’s consensus specifications.

The reversal highlights a core feature of Ethereum’s development process: changes can be debated, rejected, reopened, tested, and merged as new evidence becomes available. While that process can appear slow, it is meant to reduce the likelihood that unclear or unsafe consensus logic reaches mainnet. In this case, the delay around testing gave developers more time to reassess the flaw before Glamsterdam moved further along its launch path.

No Reported Losses, But Client Work Remains

No losses have been reported in connection with the bug. The issue was identified in the context of an upcoming upgrade rather than as a confirmed exploit on mainnet. That distinction matters for users and staking providers because the vulnerable behavior was tied to draft upgrade rules, not a reported theft of existing funds.

Still, the work is not finished. Client teams must now incorporate the revised deposit rules into their software. Ethereum consensus specifications define the intended behavior, but the rules must be translated into working client implementations before validators can rely on them in upgrade testing and, eventually, on mainnet.

This implementation stage is important because Ethereum depends on multiple independent client teams. Diversity across clients helps the network avoid overreliance on a single software base, but it also means that specification changes require coordinated engineering work. Each team needs to implement, test, and validate the new behavior so that all clients agree on how deposits should be processed.

Glamsterdam Testing Timeline Faces Delay

Glamsterdam has already run on the Sepolia test network, giving developers an early environment to examine the upgrade’s behavior. However, its Oct. 26 launch on Hoodi, a second test network, was postponed. That delay became relevant because it created additional time for researchers and developers to revisit the deposit issue before the upgrade advanced further.

Test networks are designed to surface problems before code reaches mainnet. They give protocol engineers, staking operators, infrastructure providers, and application teams a lower-risk environment for validating assumptions. In this case, the postponement helped prevent a potentially serious accounting flaw from being pushed forward without adequate review.

For staking services, the main concern is operational certainty. These services need to know that ETH deposited to start validators will be credited correctly, that validator creation will happen as expected, and that recovery paths remain available if something goes wrong. A flaw that interferes with validator creation or shifts deposit credit to another role could create meaningful financial and operational risk.

Why the Patch Matters for Staking Providers

Staking providers handle validator creation at scale. Their systems often automate deposits, credential management, and validator onboarding. Any ambiguity in protocol-level deposit handling can therefore affect not only a single validator but potentially broader staking workflows. The Glamsterdam patch addresses a narrow scenario, but the implications touch a core requirement for staking infrastructure: deposits must map cleanly to their intended purpose.

Avsetsin examined how Lido, Origin, and Rocket Pool could be affected, while noting that the findings depended on each protocol’s deposit handling. The researcher is listed as a member of Lido’s GitHub organization and characterized the review as quick AI research. That framing is important because it signals that the findings were exploratory and conditional rather than proof of active compromise.

Even so, conditional findings can be valuable in protocol development. They help identify edge cases that may not occur frequently but could be damaging if left unresolved. Ethereum’s consensus layer must handle adversarial conditions, including situations where identifiers, credentials, and pending deposits interact in unexpected ways.

Market and Network Implications

For the wider Ethereum ecosystem, the patch is more about risk reduction than immediate market impact. The absence of reported losses limits the direct financial fallout, while the fix demonstrates that developers are continuing to harden Glamsterdam before any mainnet launch. That may reassure staking services and infrastructure operators watching the upgrade path closely.

At the same time, the episode underscores how complex Ethereum upgrades have become. Changes involving builders, validators, deposits, and withdrawal credentials must be carefully specified because small differences in accounting logic can create large differences in who controls funds. As Ethereum continues to evolve, security review and testnet iteration remain central to maintaining confidence in the network’s consensus process.

The next step is for client teams to build the merged rule into their software and continue testing. Until that work is complete, Glamsterdam remains an upgrade in progress rather than a finished mainnet change. Market participants and staking operators will be watching for further client updates and renewed testnet scheduling as the upgrade moves forward.

Frequently Asked Questions (FAQs)

What was the Glamsterdam bug?

The bug was a deposit-handling flaw in Ethereum’s upcoming Glamsterdam upgrade. It could have allowed ETH intended for new validators to be credited to a builder if both used the same public key under the affected draft rules.

Did anyone lose ETH because of this issue?

No losses have been reported. The issue was described as a conditional code finding rather than a confirmed live exploit, and it was identified before Glamsterdam proceeded to a mainnet launch.

How could staking deposits have been misdirected?

The risky scenario involved an operator registering as a builder with a specific public key, followed by a staking service depositing ETH to create a validator under that same key. Under the draft rules, both deposits could have been credited to the builder.

What changed in the fix?

The revised rules sort pending deposits by withdrawal credentials. That means validator deposits are designed to remain with validators even if a builder is using the same public key.

Why did developers first reject the fix?

The proposed fix was closed on Oct. 19 because there was not enough support from clients to make the change at that time. After further review and added tests on Oct. 23, the fix was reopened and later merged.

Who identified the vulnerability?

Researcher Avsetsin identified the scenario and examined how staking protocols such as Lido, Origin, and Rocket Pool could be affected depending on their deposit handling. The findings were described as conditional rather than confirmed live exploits.

What still needs to happen before Glamsterdam can move forward?

Client teams need to incorporate the revised consensus rules into their software. Once implementations are ready and tested, Glamsterdam can continue progressing through its upgrade process.

Has Glamsterdam already been tested?

Glamsterdam has already run on the Sepolia test network. Its Oct. 26 launch on Hoodi, a second test network, was postponed, which gave developers more time to review and address the deposit issue.

Why is this important for staking services?

Staking services rely on correct validator creation and deposit accounting. If ETH meant for validators were credited elsewhere, a service could be left without the validator it intended to create and without the proof needed to recover funds.