A specification change merged on October 26 closes a flaw in Ethereum's deposit processing that could have allowed node operators to redirect stakers' queued deposits into balances under their own control once the network's Glamsterdam upgrade activates. The fix landed in the consensus-specs repository — the reference rules that Ethereum's client teams implement — two weeks after the flaw was reported on GitHub. Only deposits still waiting in the queue when the fork activates could have been misrouted, and because Glamsterdam has not reached mainnet, no funds have been lost.

How an operator could have taken a staker's deposit

Pooled staking protocols commonly split the work of running a validator. The protocol puts up the ETH, while an outside node operator holds the validator's signing key. Ethereum keeps signing and withdrawals separate, so an operator can run a validator without being able to withdraw the protocol's stake.

Glamsterdam pairs execution-layer changes with a consensus-layer upgrade called Gloas and adds builders as a new kind of participant under enshrined proposer-builder separation. Builders assemble the transaction-carrying part of block and hold their own balances. At the fork, Ethereum converts qualifying deposits still waiting in the queue into builder accounts.

That conversion is where the flaw sat. Under the old rule, once a pending deposit registered a builder for a key, every later deposit for that key topped up the builder, regardless of where its withdrawal credentials pointed. An operator could queue a builder deposit for a fresh key from an address they controlled. If a staking protocol then funded a validator deposit for the same key, and both were still pending at the fork, the protocol's ETH would have been credited to the operator's builder balance, which the operator could then withdraw. No validator would be created either. Some protocols release the rest of a stake only after proving that a new validator carries their withdrawal credentials, and that proof would never have arrived.

In a follow-up comment, the issue's author listed designs the bug could have disrupted: Lido's predeposit guarantee, Origin's OETH and Rocket Pool's Saturn, while flagging the list as quick AI-assisted research that may contain errors. In each case the exposure would have been a first deposit — 1 ETH in the Lido and Rocket Pool examples — with the rest of the stake left locked until recovery steps were run. The author described these as conditional code findings, not live exploits.

Rejected on October 19, merged a week later

The fix was proposed on October 12. After discussion on two core developer calls, it was closed on October 19 for lack of client support, and the testing call floated prototyping it after the Hoodi testnet upgrade rather than disrupting the schedule.

Three days later, the Ethereum Foundation postponed Glamsterdam's activation on Hoodi to investigate how EIP-8037 interacts with existing smart contracts, a problem unrelated to deposits. The extra time reopened the debate. An October 23 comment on the next testing call's agenda tied the deposit change to the revised timeline, the author added deposit-ordering tests the same day, and the change was merged on October 26.

What the new rule does

After the fork, builder and validator deposits already travel separate paths under EIP-8282. The fix applies the same logic to the queue at the fork: withdrawal credentials, not the public key, decide where each pending deposit goes.

Reusing one key for a validator and a builder is still allowed; the purpose stated in each deposit now decides which account it funds.

What still has to happen before the fork

The specification merge is only the first step; client teams now have to ship the same rule. A Teku change opened on October 27 was still under review, and Lodestar's equivalent remained open.

A late change also has to land identically in every client. Older reference tests encode the previous routing, so a client following the new rule fails them. Teku's author reports passing the tests generated from the updated specification, which has not yet been packaged in a specification release. If clients reached the fork applying different rules to the same queue, they would compute different balances and disagree on the chain's state.

The Foundation has not set a new Hoodi date or a Glamsterdam mainnet date. Staking protocols that rely on deposit proofs also have their own line of defense: according to the issue's author, pre-deposit checks that reject a key already carrying a builder deposit can prevent the scenario. The markers to watch from here are the two open client pull requests, a specification release that packages the updated tests, and fresh dates for Hoodi and mainnet.