Ethereum Fixes Glamsterdam Staking Deposit Bug

Ethereum developers have changed the rules for the coming Glamsterdam upgrade to close a gap in how staking deposits are handled at the moment of the fork. Without the change, a node operator could, in some set-ups, have had ETH that a staking protocol paid in for a new validator credited instead to a “builder” account the operator controls. The fix, pull request 5736 in the consensus-specs repository, was merged at 19:16 UTC on 26 October.

This was a flaw in the specification, found before the upgrade reached mainnet. It was not a live exploit, and no losses have been reported. The researcher who raised it described the effects on named staking protocols as “conditional code findings, not confirmed live exploits”. Glamsterdam has not been switched on for Ethereum mainnet, so the corrected rules land before any real deposits could be routed the old way.

In brief

Ethereum developers merged a spec change on 26 October that keeps validator deposits out of the new builder registry at the Glamsterdam fork.
The flaw was found in code under review, not exploited, and no funds have been lost.
The fix had been shelved on 19 October for lack of client support, then revived after the upgrade’s test-network date slipped.
Lido’s Dmitry Gusakov says core developers “unanimously agreed to patch the issue”.

How a validator deposit could end up with a builder

Glamsterdam pairs an execution-layer upgrade with a consensus-layer upgrade called Gloas. Gloas introduces builders, the parties that assemble blocks, as a separate kind of staked participant with their own deposits. At the fork, deposits still waiting in the queue are sorted between validators and builders.

The bug was in that sorting rule. As issue 5735 explains, once a pending deposit registers a builder, later deposits for the same public key top up that builder “regardless of their withdrawal credentials”. The issue gives an example. A staking protocol funds an operator’s first validator deposit and waits for proof that the validator has the protocol’s withdrawal address before sending the rest of the stake. If the operator had already queued a builder deposit for the same key, and both deposits were pending at the fork, both amounts would go to the builder. The operator could then withdraw the protocol’s money, and because no validator was created, the protocol could not get the proof its contracts expect.

The reporter, who said the protocol list came from “quick AI research” that “may contain errors”, traced possible knock-on effects in Lido’s Predeposit Guarantee, Origin’s OETH and Rocket Pool’s Saturn. In each case funds could be stuck or accounting disrupted until a recovery deposit or administrative step, but “permanent freezes are not established”.

The fix was shelved, then revived by a delay

The pull request was opened on 12 October and closed a week later. “There was not enough support from clients to make this change at this time,” consensus-specs maintainer jtraglia wrote on 19 October. Lido’s Dmitry Gusakov warned on X on 20 October of “an important new attack on delegated staking”, adding that it was “only possible at the moment of the hardfork” because builder deposits move to a separate contract afterwards.

What changed was the timetable. On 22 October the Ethereum Foundation said Glamsterdam’s activation on the Hoodi test network had been postponed, with no new date, to investigate how one of its gas changes interacts with existing mainnet contracts. Hoodi had been due to upgrade at 17:42:48 UTC on 26 October. Gusakov asked for the issue to be reopened on 23 October “due to changes in the Glamsterdam timeline”, and on 26 October he posted that core developers had “unanimously agreed to patch the issue because of the additional time we now have before Glamsterdam on Hoodi”.

Under the merged rules, validator deposits stay in the validator queue even if a builder uses the same key, and a valid builder deposit registers or tops up the builder even if a validator already uses that key. Reviewer Potuz wrote: “I could not find any way of exploiting this, which is not to say that there isn’t any.” Reviewer nflaig said the Lodestar client was passing the new tests and that extra differential testing produced “no findings”.

Fork transitions need their own threat model

The episode shows where upgrade risk now sits. Most of Glamsterdam’s rules were reviewed as steady-state behaviour, how builders and validators work once the fork is live. This flaw existed only in the one-off migration step at the fork, when old queues are moved into new structures. That is exactly the kind of code that gets the least real-world testing: Sepolia’s activation earlier this month did not exercise builder onboarding at the fork, according to the pull request discussion, because the test network’s deposit contract needs a special token.

It also shows how much of Ethereum’s staking now relies on contracts that check proofs about the beacon chain. Liquid staking products, including the Lido-based staked ETH funds that issuers have been trying to list, sit on top of those checks, so a change in how the chain records a deposit can reach them even when the protocols themselves are unchanged. The fix also shows that the release schedule can decide which bugs get fixed: on 19 October this one was deemed not worth the change, and a test-network delay reversed that a week later. Compare the XRP Ledger overflow bug, which sat unnoticed for a decade; here the gap was found in review and closed before activation.

Gusakov’s earlier thread advised staking protocols to add their own safeguards. The issue notes that pre-deposit checks rejecting an earlier builder deposit for the same key would prevent the scenario, and that several verifiers need updates for Gloas in any case. Client teams now have to ship the new routing in their Glamsterdam releases, and the next marker is a fresh Hoodi date, which the Ethereum Foundation has not yet set.