Developers accepted a change that keeps staking ETH out of builder accounts during the Glamsterdam transition. Client updates and network activation are separate steps.
Ethereum developers have accepted a fix for a bug that could route ETH intended for staking to the wrong account during the Glamsterdam upgrade. Fix 5736 was merged into the main consensus specification branch at 19:16 UTC on October 26. The bug could mix pending deposits for a validator and a block builder using the same public key at the moment of the upgrade. Client teams must implement the change in their software; activating it on the network is a separate step.
How could staking ETH reach another account?
In the October 12 issue, avsetsin points out that the party providing the stake may differ from the operator running the validator. A staking protocol may fund a node operator’s first validator deposit, then require proof that the validator was created with the protocol’s withdrawal credentials before sending the remaining stake. The example uses the 0x02 prefix for validators and 0xB0 for builders. Along with the type, those credentials contain the address that receives withdrawals.
Gloas is the consensus part of Glamsterdam. Under its previous transition rule, an operator could first submit a valid builder deposit for a new key using their own withdrawal address. If the protocol then funded a validator deposit for that key, and both were still pending at the fork, both amounts would be credited to the builder. The operator could withdraw the protocol’s ETH without a validator being created. The problem concerns the one-time onboarding of builders from pending deposits during the upgrade.
Without a validator record, the protocol cannot prove whether its withdrawal credentials were used. Depending on its design, the protocol may miscalculate balances, be unable to release funds reserved for later deposits, or fail to recover them through its normal procedures. The issue’s author, avsetsin, explicitly describes the protocol examples as preliminary AI-assisted research that may contain errors or differ from deployed software. The Lido, Origin and Rocket Pool examples were not presented as confirmed attacks or cases of permanently locked funds.
“Not confirmed live exploits.”
The new rule separates validator and builder deposits
The fix routes deposits by their withdrawal credential type instead of relying only on the public key. A builder prepares the transactions that go into a block, while a validator proposes and votes on blocks to help the network agree on its history. Under the new rules, the software will keep validator deposits out of the builder balance even when the keys match.
| Pending deposit | How it will be processed |
|---|---|
| Validator deposit | Stays in the validator queue even when a builder uses the same key. |
| Valid builder deposit | Creates or tops up a builder even when a validator uses the same key. |
| Top-up for an existing builder | A builder-type deposit increases the existing builder balance regardless of signature. |
| Invalid builder deposit when no builder exists | Stays queued if a validator exists for the key or an earlier valid validator deposit is already queued; otherwise it is discarded. |
Developers retained the final-row exception so an existing validator can still receive additional funds. Discarding every invalid builder deposit when no builder exists could, they explained, introduce another loss. Opening the first builder record requires a valid signature. Adding funds to an existing builder follows the separate rule shown above.
Developers define independent builder and validator registries in EIP-8282. EIP stands for Ethereum Improvement Proposal. The proposal provides separate contracts for builder deposits and exits after the upgrade. The software registers pre-fork builder deposits once so builders are available from the first slot, or block-production interval. The fix keeps pending validator deposits separate during that step.
Developers returned to the fix after the delay
Justin Traglia closed the issue on October 19, citing insufficient support from client teams. Dmitry Gusakov requested that it be reopened on October 23 after the Glamsterdam timeline changed. At the October 26 All Core Devs Testing meeting, Gusakov explained that Lido relies on a validator record eventually being created; he also said he had not performed a detailed severity analysis for other protocols.
The 25:22–32:17 section of the October 26 recording on Ethereum’s official channel covers the deposit issue and proposed fix. In the meeting transcript, Traglia proposes merging the change and preparing a release during the week. He merged the change that evening. The call did not announce completed deployments by every client team.
Reviewers requested tests for different deposit orders and keys shared with existing validators. avsetsin added the tests to the change. Lodestar developer Nico Flaig reported that his branch passed the new tests and that differential tests comparing implementations found no issues. Potuz warned that builder top-ups made with tools sending a zeroed withdrawal address and invalid signatures could lose funds. Operators’ tools must also send the correct type, withdrawal address and, where required, a valid signature.
Hoodi was postponed for a separate review
In its October 22 announcement, the Ethereum Foundation postponed Hoodi’s Glamsterdam activation scheduled for October 26. It cited a review of EIP-8037’s interactions with existing mainnet contracts, rather than the staking deposit bug. A replacement Hoodi date has not been set. The scheduled activation and increase to a 200 million gas limit were removed in updated client releases; chain history was not rolled back.
Flaig explained that builders were not onboarded through this process at Sepolia’s transition because its deposit contract requires a special token. He therefore did not expect the revised rule to produce a different result for Sepolia’s history. The Foundation’s postponement notice requested no action from mainnet ETH holders, while instructing Hoodi node and validator operators to follow updated client releases.
Protocol checks also matter: avsetsin said a protocol could prevent the example sequence by checking for an earlier builder deposit under the same key before funding the validator. If funds become locked, recovery depends on protocol-specific options such as a new deposit or administrative intervention. The issue does not claim permanent loss in every protocol.
