Ethereum’s core developers have decided not to change a rule in the Glamsterdam upgrade that could, under narrow conditions, credit ETH meant for a new staking validator to a block builder’s balance controlled by a node operator. The problem was filed on 12 October as issue #5735 in the consensus-specs repository by a developer posting as avsetsin on GitHub. Spec maintainer Justin Traglia closed it as “not planned” on 19 October, for lack of support from client teams. No exploit and no loss have been reported. The Glamsterdam staking deposit risk only concerns deposits still waiting in the queue when the fork activates, and only protocols that fund validators run by someone else.
Dmitry (Dima) Gusakov, who gives his role on GitHub as head of engineering at Lido, the title Crypto Briefing also uses, asked on 14 October for the issue to be discussed on the consensus-layer developers’ call (ACDC #189) the next day. It came back on the testing call (ACDT #101) of 19 October. The specification stays as written, so staking protocols now have to guard against the case in their own contracts. Glamsterdam reaches the Hoodi testnet on 26 October. Mainnet has no date yet.
Developers closed the fix on 19 October, three days after leaning towards it
Traglia closed the companion fix, pull request #5736, at 16:02 UTC on 19 October and the issue three minutes later. His closing note said the topic had been discussed on both calls and that “there was not enough support from clients to make this change at this time.” He posted the same words on the pull request.
That was a turn. On 16 October, in the agenda thread for the 19 October call, Traglia had written that he was “slightly in favor” of the change. His plan kept it out of Hoodi, had clients prototype it, merged it after Hoodi, tested it on a short-lived devnet and did not delay mainnet. He added that the change would spare “every other DVT system” a fix of its own (DVT, distributed validator technology, splits one validator’s key across several machines or operators).
Who objected on the calls, and why, is not public. When we checked, no written notes of the 15 October or 19 October calls had been published, and no client team or Ethereum Foundation member had made a statement on the risk. The only other public trace from a client developer is a question from Michael Sproul of Lighthouse on 13 October, asking whether the fix was compatible with the Sepolia fork that had already happened. Nico Flaig of Lodestar answered that Sepolia never tested builder onboarding, because the deposit contract there needs a special token.
Builders, deposits and ePBS: what newcomers need to know
To stake on Ethereum, someone sends ETH to the deposit contract with two key pieces of data: the validator’s public key and its withdrawal credentials. The credentials say where the ETH goes when it leaves staking. Credentials starting with 0x01 point to an ordinary Ethereum address; 0x02 does the same but lets rewards compound, with a balance of up to 2,048 ETH per validator.
A deposit does not count at once. It joins a queue of pending deposits that the chain processes at a capped rate. On 19 October that queue held about 1.2 million ETH and took roughly 21 days to clear, as we reported in our piece on the staking entry queue. A long queue means deposits sent weeks before a fork can still be pending when it happens.
Builders are the other half of the story. Gloas, the consensus half of Glamsterdam, brings enshrined proposer-builder separation (ePBS, EIP-7732, listed as scheduled for the upgrade in the Glamsterdam meta-EIP), which we explained when Glamsterdam went live on Sepolia. What matters here is one consequence: builders get their own balance on the beacon chain. A builder registers by making a deposit through the same deposit contract, with withdrawal credentials that start with 0xB0.
So the fork has a sorting job. When Gloas activates, the chain must decide which pending deposits are for validators and which create or fund builders. That sorting rule is where the problem sits.
Glamsterdam staking deposit risk: how a validator deposit lands in a builder’s balance
The rule sits in a fork-transition function called onboard_builders_from_pending_deposits, and it sorts pending deposits by public key. Once one pending deposit registers a builder for a key, every later pending deposit for that same key tops up the builder, whatever withdrawal credentials it carries.
The issue describes a staking protocol that works with outside node operators. The protocol funds the operator’s first deposit for a validator, then waits for proof that the validator exists with the protocol’s withdrawal credentials before sending the rest. Suppose the operator first queues a valid builder deposit (0xB0, pointing to its own address) for a fresh key, and the protocol’s 0x02 validator deposit for that key is also pending at the fork. In the issue’s words, “both amounts go to the builder. The operator can withdraw the protocol’s funds.”
No validator is created. The protocol cannot get the proof it was waiting for, may be unable to show what happened, and can end up with broken accounting or locked funds, according to the issue.
Two limits matter. The hazard only covers deposits that are pending across the fork boundary; after Gloas, builder and validator deposits follow separate paths. And it differs from the front-running Lido faced in 2021 (see below): here the protocol’s credentials are recorded correctly with its deposit, and it is the one-off routing at the fork that ignores them.
Who could be exposed, according to a list its author calls unverified
The scenario needs a funder that is not the key holder, an operator who can submit a builder deposit for the same key, and staged funding where a small deposit comes before the rest. Someone who stakes from their own funds and controls their own key does not fit it.
In a second comment on the issue, the same author names three protocols that might be affected. That comment is labelled as “quick AI research” that “may contain errors”. It calls its findings conditional readings of code, not confirmed live exploits, and says permanent freezes are not established. Coindaro has not verified these claims, and none of the three protocols had confirmed them publicly when we checked. The table below reports what the comment says, nothing more.
| Protocol and product | What the AI-assisted comment claims could happen | Recovery path it suggests |
|---|---|---|
| Lido, Predeposit Guarantee used by stVaults | The vault loses its 1 ETH predeposit; the operator’s 1 ETH guarantee stays locked; 31 ETH stays staged | Replay the signed predeposit after the fork, or disconnect and change depositor |
| Origin, OETH native staking strategy | The missing deposit blocks balance checks, while the vault still counts the lost ETH | Replay the signed deposit |
| Rocket Pool, Saturn megapools | The missing validator blocks quick dissolution; the remaining 31 ETH waits for a timeout | User capital refunded first, the shortfall becomes operator debt |
The same comment says the verifier contracts of all three need updates for Gloas anyway, and for EIP-7688, which changes how consensus data structures are laid out. For background on the two named protocols with Coindaro pages, see our profiles of Lido and Rocket Pool and its Saturn upgrade.
Lido’s main stETH pipeline, the curated operator modules, is not named in the issue. Crypto Briefing points to Lido’s Deposit Security Module and its guardian committee as the existing defence and leaves open whether they cover builder deposits. That is the outlet’s question, not a finding, and Lido had made no statement beyond Gusakov’s comments when we checked. No one has put a figure on the ETH at stake.
Lido met a similar deposit race in 2021
The new case rhymes with an old one. On 5 October 2021 a report through Lido’s bug bounty showed that a node operator could front-run the protocol’s deposits. At the time, the first deposit for a key fixed its withdrawal credentials for good, so an operator who deposited first with its own credentials could capture what Lido sent next. Lido paused deposits from its buffer and, on 14 October 2021, published LIP-5, under which a committee of guardians signs off on the deposit data before ETH moves.
One of the options listed then was a long-term change at the consensus layer. The first option on that 2021 list was the pre-deposit: the operator puts down 1 ETH with the protocol’s credentials, the protocol checks, then sends the rest. Five years on, that pre-deposit check is what protocols are told to rely on again.
Pre-deposit checks are now the defence, plus one client patch
The author’s follow-up comment names the protocol-side answer: “Pre-deposit checks that reject an earlier builder deposit can prevent this scenario.” In practice, a protocol would look for an earlier 0xB0 deposit on the key before funding the rest.
Some press coverage said the rejected fix would have “added pre-deposit checks”. That is not what pull request #5736 does. It would have changed the routing at the fork, using withdrawal credentials instead of the key alone:
- validator deposits stay in the validator queue even if a builder uses the same key;
- a valid builder deposit registers or tops up a builder even if a validator uses the key;
- a builder deposit for an existing builder tops it up whatever its signature;
- an invalid builder deposit with no builder behind it stays queued only if a validator with that key exists or an earlier valid validator deposit is queued, and is dropped otherwise.
Client work had started before the closure. Flaig opened Lodestar pull request #10428 on 17 October to route pending deposits by withdrawal credentials at the fork; it was still open when we checked. Every client must compute the same state at the fork, so a change of this kind only works if all of them adopt it through the specification. Flaig also opened a pull request on his personal copy of Lido’s core code on 12 October to compensate predeposits absorbed by builders. That is not a Lido decision.
Hoodi forks on 26 October, and the mainnet date is still open
The Glamsterdam fork on the Hoodi testnet is set for 26 October at 17:42:48 UTC, at epoch 132,352, according to the Ethereum Foundation’s announcement of 16 October. The gas limit rises to 200 million at the fork. Hoodi’s rules are frozen: on the fix, Traglia wrote on 16 October that “that ship has sailed” for this testnet. Builder onboarding at the fork was not tested when Sepolia forked on 6 October, according to Flaig, and Gusakov has said Lido wants time to test with real builders on Hoodi.
For mainnet, the Foundation wrote that the activation date “has not yet been decided”. In the agenda thread of the 15 October call, Barnabas Busa of the Ethereum Foundation proposed two slots, assuming Hoodi goes well: 1 December 2026 at 20:38:47 UTC, or 8 December at 16:29:11 UTC. Gusakov backed the later one that afternoon: “We still need to do a lot of testing with real builders on Hoodi. So Dec 8th works great for Lido.” Whether either date was agreed is not known; both remain proposals.
The next consensus-layer call, ACDC #190, is on 29 October at 14:00 UTC, three days after Hoodi. Busa also brought a separate deposit question to the 15 October call: under EIP-8365, planned for the later Hegotá upgrade, new deposits to old 0x00 credentials would be skipped and the ETH burned. It is a different problem from the builder routing.
What it means for holders of stETH, rETH and staking services
For people who hold proof of stake coin with a protocol that stakes it for you and issues a transferable token (such as Lido stETH or rETH) representing the deposit plus rewards, which you can use or sell while the coins stay staked.">liquid staking tokens or use a staking service, nothing has happened. No funds have moved, and the risk described sits in how a few protocols fund new validators during one window around the fork. The protocols concerned have until the mainnet date to add checks or adjust contracts, and the issue gives them the method.
Lido, Origin and Rocket smart contract holding reserves of two or more tokens, supplied by users, that a decentralized exchange uses to execute trades automatically at a price set by a formula.">Pool had not said publicly whether they are affected when we checked. The next fixed points are the Hoodi fork on 26 October and the 29 October call, where a mainnet date may be picked.