Ethereum Fixed a Glamsterdam Flaw That Could Have Routed Pooled Stakers' ETH Into Node Operators' Builder Accounts
Ethereum developers have patched a deposit-routing vulnerability in the Glamsterdam upgrade specification that would have allowed a malicious node operator to have a staking protocol's deposit credited to an account the operator controls — rather than creating the validator the protocol was paying for. The specification change was merged on October 26, two weeks after the flaw was first reported on GitHub. No funds were at risk on mainnet because Glamsterdam has not yet activated, and the exposure was limited to deposits still pending in the queue at the fork. But the flaw illustrates a previously underappreciated attack surface that the Glamsterdam upgrade's introduction of builder accounts at the consensus layer creates — and two consensus clients, Teku and Lodestar, still need to implement the corrected rule before the flaw is fully addressed across the network.
Key Takeaways
A specification flaw in Glamsterdam would have allowed a rogue node operator to queue a builder deposit for a key they controlled, causing a staking protocol's subsequent validator deposit for the same key to be credited to the operator's builder balance rather than creating a validator
No funds have been lost — the vulnerability only affects deposits still pending in the queue at the fork, and Glamsterdam has not reached mainnet
The flaw sat at the intersection of Glamsterdam's new builder account mechanism and the existing deposit queue: the old rule used public key rather than withdrawal credentials to route deposits, enabling the misdirection
Affected designs mentioned in the issue include Lido's predeposit guarantee, Origin's OETH, and Rocket Pool's Saturn — characterised as conditional code findings, not live exploits; exposure in each case is limited to the first deposit (1 ETH in the Lido and Rocket Pool examples)
The fix proposed on October 12 was rejected on October 19 for lack of client support; the Hoodi testnet delay three days later reopened the debate, and the specification change was merged on October 26
EIP-8282 provides the corrected rule: withdrawal credentials, not the public key, now determine which account a pending deposit at the fork is credited to
Teku and Lodestar still need to ship matching implementations; old reference tests encode the previous routing behaviour and must be updated before the change can be validated across clients
The Background: How Pooled Staking Separates the Money from the Keys
To understand how the vulnerability works, it helps to understand the operational structure that most large-scale Ethereum staking protocols use — and why Ethereum was designed to separate validator signing from withdrawal control in the first place.
Ethereum's proof-of-stake system requires a minimum deposit of 32 ETH to activate a validator. Most individual ETH holders do not have 32 ETH available or do not want to manage validator infrastructure themselves, so liquid staking protocols like Lido, Rocket Pool, and Origin OETH pool ETH from many depositors and delegate the actual validator operation to professional node operators.
This delegation creates a division of roles: the staking protocol holds the ETH and controls the withdrawal credentials — the address that ultimately receives the staked ETH and accumulated rewards when a validator exits. The node operator holds the validator's BLS signing key, which is needed to sign attestations and block proposals and perform the day-to-day operation of the validator.
Ethereum's protocol design explicitly keeps these two functions separate. An operator who holds the signing key cannot access the withdrawal address, and thus cannot steal the staked ETH. The operator's ability to "run" the validator is real; their ability to "take" the ETH is supposed to be zero.
This separation is precisely what the Glamsterdam vulnerability threatened to undermine — not by breaking the validator signing/withdrawal separation directly, but by exploiting how Glamsterdam's new builder account system interacts with the deposit queue.
Glamsterdam's Builder Accounts: A New Attack Surface
Glamsterdam introduces a significant architectural change to Ethereum beyond the gas-repricing proposals (EIP-8037 and EIP-8038) that prompted the Hoodi testnet delay. The upgrade pairs execution-layer changes with a consensus-layer upgrade called Gloas, which adds builders as a new category of consensus-layer participant under enshrined proposer-builder separation (ePBS).
Understanding Proposer-Builder Separation
In Ethereum's current architecture, validators both propose blocks (selecting which transactions to include) and build them (assembling the transaction payload). This creates an incentive for validators — or the searchers and bots who pay them via MEV-Boost — to capture maximal extractable value (MEV) by ordering transactions in ways that benefit the block builder at the expense of users.
External PBS, implemented through the MEV-Boost relay infrastructure that currently dominates Ethereum block production, addresses this by outsourcing block building to specialist firms while validators focus on proposal. But external PBS operates outside the Ethereum protocol itself — it is a social layer arrangement, not a cryptographic guarantee.
Enshrined PBS (ePBS) brings proposer-builder separation into the Ethereum protocol, giving builders a formal protocol-level role, their own balances, and cryptographic accountability for their block assembly activities. This is what Glamsterdam's Gloas upgrade implements at the consensus layer.
Builder Accounts and the Deposit Queue Interaction
Under Glamsterdam, builders hold their own balances in accounts at the consensus layer. At the fork activation, Ethereum converts qualifying deposits that are still waiting in the deposit queue into builder accounts. This conversion is where the flaw sat.
The old deposit routing rule used a simple principle: once a pending deposit has registered a builder for a given public key, every subsequent pending deposit for that same key tops up the builder's balance — regardless of where the deposit's withdrawal credentials point.
How the Exploit Would Have Worked
The attack scenario that the flaw enables is subtle but serious in the context of pooled staking:
Step 1 — The operator queues a builder deposit: A node operator who wants to extract the staking protocol's ETH queues a builder deposit for a fresh key, submitted from an address they control. This registers that public key as associated with a builder account controlled by the operator.
Step 2 — The staking protocol funds the same key: The staking protocol subsequently submits a validator deposit for the same public key — for example, as part of its normal process of funding validators operated by the node. Under the old rule, because the key has a builder registration pending, this deposit is not routed to create a validator. Instead, it is credited to the operator's builder balance.
Step 3 — The fork activates with both deposits still queued: If both deposits are still sitting in the queue when Glamsterdam activates, the operator's builder account is topped up by the protocol's ETH at the fork. The operator can then withdraw from the builder account — taking the protocol's stake.
Step 4 — No validator is created: The staking protocol's deposit fails to create a validator. Protocols that only release the remaining stake (the bulk of the 32 ETH) after receiving proof that a new validator carries their withdrawal credentials would never receive that proof, because no validator was created. The rest of the protocol's stake stays locked until recovery procedures are invoked.
The flaw's author noted that the conditional exposure in several real protocols would involve only the first deposit — typically 1 ETH in the Lido and Rocket Pool examples — with the remainder of the stake protected by the proof requirement. The named designs — Lido's predeposit guarantee, Origin's OETH, and Rocket Pool's Saturn — were identified as conditional code findings from AI-assisted research, not confirmed live exploits, and the list may not be comprehensive.
Critically, because Glamsterdam has not activated on mainnet and the flaw only affects deposits pending in the queue at the fork, no funds have been lost and no exploit has occurred.
The Fix: Withdrawal Credentials Over Public Key
The correction, implemented through EIP-8282, changes the deposit routing logic at a fundamental level: withdrawal credentials, not the public key, determine which account a pending deposit is credited to.
The distinction matters because withdrawal credentials are set by the depositor — the staking protocol — not by the node operator. The operator holds the signing key but does not control the withdrawal credentials. By routing pending deposits based on withdrawal credentials rather than public key, the specification ensures that the operator's builder registration for a key cannot redirect the protocol's subsequent deposit for the same key.
The table from the original article captures the old vs. new rule clearly:
Pending deposit at the fork Old rule New rule Validator deposit, same key as a builder Credited to the builder Stays in the validator queue Valid builder deposit, same key as a validator Blocked from registering Registers the builder Invalid builder deposit, existing validator Kept for the validator Kept for the validator
Importantly, the fix preserves the legitimate use case of reusing a single key for both validator and builder purposes. The rule change does not prohibit this; it simply ensures that the stated purpose of each deposit — validator or builder — determines which account it funds, rather than the key's existing registration state being able to redirect subsequent deposits.
The Fix's Complicated Path to Adoption
The specification change's timeline reflects both the genuine technical difficulty of the problem and the role that Glamsterdam's Hoodi testnet delay played in giving developers the time to address it.
October 12 — Flaw reported, fix proposed: The vulnerability was reported on GitHub with a proposed fix.
October 19 — Fix rejected: After discussion on two core developer calls, the proposed fix was closed for lack of client support. The testing call floated the idea of prototyping the fix after the Hoodi testnet upgrade rather than disrupting an already tight schedule.
October 22 — Hoodi testnet delay: The Ethereum Foundation postponed Glamsterdam's Hoodi activation to investigate the unrelated EIP-8037 gas mechanics issue. This delay removed the schedule pressure that had caused the fix to be rejected three days earlier.
October 23 — Debate reopens: The deposit change was tied to the revised timeline in a comment on the next testing call's agenda. The issue's author added deposit-ordering tests the same day — providing the client teams with concrete test cases against which to validate their implementations.
October 26 — Specification merged: The corrected deposit routing rule was merged into the Ethereum specification.
This sequence illustrates how the Hoodi delay, while disruptive in one dimension, created an unanticipated benefit: it reopened the window for a safety fix that had been set aside for schedule reasons. The two issues — the EIP-8037 gas mechanics problem and the deposit routing flaw — are entirely unrelated technically, but their intersection in the development timeline produced a more comprehensive safety review than would have occurred if Hoodi had activated on schedule.
What Still Has to Happen Before the Fix Is Complete
The specification change's merger on October 26 is a necessary but not sufficient step. The following workstreams remain open:
Client Implementations
Every Ethereum consensus client must implement the corrected deposit routing rule for the fix to take effect at the fork. The specification defines what the protocol should do; client implementations determine what the software running on validators around the world actually does.
Teku (maintained by ConsenSys, implemented in Java): A Teku change was opened on October 27 and was still under review at the time of writing.
Lodestar (maintained by ChainSafe, implemented in TypeScript): The Lodestar change remained open.
Other consensus clients — Prysm, Lighthouse, Nimbus — are not explicitly mentioned in the article's status update.
The Reference Test Problem
The most technically precarious aspect of the remaining work is the reference test suite. Ethereum maintains a shared set of reference tests that all clients are expected to pass — they encode expected behaviour for a comprehensive set of scenarios and serve as the mechanism through which client teams verify that their implementations are mutually consistent.
The old reference tests encode the previous deposit routing behaviour. A client that correctly implements the new rule will fail the old reference tests — not because the client is wrong, but because the tests themselves specify the old (now incorrect) behaviour.
Teku's author has reported passing tests generated from the updated specification, which has not yet been packaged in a formal specification release. This means the updated tests exist but are not yet the canonical test suite against which all clients are being measured.
This creates a coordination risk: if different client teams implement the rule change and validate against different versions of the reference tests, it becomes possible for clients to reach the fork applying subtly different rules to the same deposit queue. Two clients applying different rules to the same pending deposits would compute different balances — and would therefore compute different states for the chain, creating the conditions for a consensus failure or chain split.
This is why the specification release packaging of the updated tests matters: it creates a single authoritative source that all client teams can align against before the fix is considered fully integrated across the network.
The Staking Protocol Line of Defense
Beyond the protocol-level fix, the issue's author noted that staking protocols themselves have an independent line of defence against this attack scenario: pre-deposit checks that reject a key already carrying a builder deposit can prevent the misdirection without relying solely on the protocol-level rule change.
This is an important observation for staking protocol developers regardless of when Glamsterdam activates. A staking protocol that validates the deposit state of a key before committing ETH to it — confirming that no competing builder deposit is pending for that key — can prevent the misrouting even if a client implementation lag or a protocol rule edge case created a window of vulnerability.
The existence of this application-level defence does not make the protocol-level fix less important; it provides a defence-in-depth argument that the fix, the client implementations, and the protocol's own pre-deposit validation collectively address the vulnerability at multiple layers simultaneously.
Broader Implications for Ethereum's Staking Security Model
The deposit routing flaw and its fix carry lessons that extend beyond this specific vulnerability:
New Protocol Features Create New Attack Surfaces
Glamsterdam's introduction of builder accounts at the consensus layer is a significant architectural addition that interacts with existing staking infrastructure in non-obvious ways. The deposit routing flaw emerged from exactly this kind of interaction: the combination of the deposit queue (an existing mechanism) and builder account registration (a new Glamsterdam mechanism) created a state that existing safety assumptions did not account for.
This is a general challenge in complex protocol upgrades: each new feature must be analysed not just in isolation but in combination with every existing mechanism it can interact with. The Ethereum development community's process of public specification, open GitHub discussion, and multi-client developer calls is designed precisely to surface these interactions — and in this case, it did, with enough lead time to merge a fix before any mainnet activation.
The Hoodi Delay's Unintended Benefit
The fact that an unrelated gas mechanics issue (EIP-8037) created the time window for a deposit routing fix (EIP-8282) to be properly reviewed and adopted is a meaningful argument for Ethereum's conservative, staged upgrade process. A faster development cadence that pushed through Hoodi on the original schedule would have activated the upgrade without the deposit routing fix — and while the exposure on Hoodi would not have involved real staked ETH, the specification gap would have persisted into subsequent testnet and potentially mainnet preparations.
Pooled Staking and the Trust Boundary
The vulnerability specifically targeted the trust boundary between staking protocols and their node operators. Ethereum's cryptographic separation of signing keys and withdrawal credentials is designed to make this trust boundary reliable, but Glamsterdam's new deposit routing created a window in which that separation could be circumvented during the fork transition.
As Ethereum's staking ecosystem grows in complexity — with distributed validator technology, sophisticated liquid staking protocol designs, and now ePBS-based builder roles — the trust boundaries between different participants in the staking stack require ongoing scrutiny as each upgrade introduces new interaction patterns.
What Comes Next
The Ethereum Foundation has not set a new date for Glamsterdam's Hoodi testnet activation or the mainnet target, which was previously aimed at end-2026.
For the deposit routing fix to be ready for any new Hoodi activation date, the following must be completed:
Teku and Lodestar implementations of the corrected deposit routing rule must be finished, reviewed, and released
Updated reference tests encoding the new routing behaviour must be packaged in a formal specification release that all client teams can use as a common validation baseline
Cross-client verification that all consensus clients produce identical outputs when processing the same deposit queue at the fork must be confirmed
Staking protocol review of the specification change to ensure their pre-deposit checks and deposit proof flows are compatible with the new rules
The EIP-8037 gas mechanics issue remains the primary stated reason for the Hoodi delay; the deposit routing fix is an additional change that now needs to be incorporated. Each additional specification change extends the timeline for reaching the stable, cross-client-consistent specification that a testnet activation requires.
Summary
Ethereum developers identified and patched a deposit routing flaw in Glamsterdam that would have enabled a rogue node operator to cause a staking protocol's ETH deposit to be credited to the operator's builder account rather than creating a validator — effectively stealing the protocol's deposit at the fork transition. The flaw arose from the interaction between Glamsterdam's new builder account mechanism and the deposit queue processing rule, which used public key rather than withdrawal credentials to determine routing. The fix, merged on October 26 after a three-week journey from GitHub report through rejection to eventual adoption enabled by the Hoodi testnet delay, replaces the public key routing logic with withdrawal credential routing under EIP-8282. No funds have been lost, as Glamsterdam has not reached mainnet and the exposure was limited to deposits pending at the fork. Teku and Lodestar implementations remain open; reference test updates are needed; and the Ethereum Foundation has set no new date for Hoodi or mainnet activation. For the staking community, the episode is a reminder that each protocol upgrade introduces new interaction patterns between existing and novel mechanisms — and that Ethereum's public, multi-party specification review process is designed to find these before they reach the billions of dollars locked in mainnet validators.
Want to join the discussion? Login and create a profile to comment.
