Two deposits, one key, and the builder kept both

Ethereum's consensus specifications have changed how deposits are handled at the Gloas fork, the consensus-layer half of the Glamsterdam upgrade, after a researcher showed that the draft rules could hand one party's ETH to another. The pull request, opened by avsetsin, was merged on 26 October by maintainer Justin Traglia. A week earlier he had closed it, writing that there was not enough support from client teams; it came back after a contributor pointed to changes in the Glamsterdam timeline.

The flaw sat in fork onboarding, when deposits still waiting in the queue are sorted into the new builder registry. Under the draft, once a pending deposit registered a builder, later deposits for the same public key topped up that builder regardless of their withdrawal credentials. The issue spells out the attack. An operator queues a valid builder deposit for a new key, paid from their own address. A staking protocol then funds a validator deposit for the same key. If both are pending at the fork, both amounts go to the builder, and the operator can withdraw the protocol's funds. No validator is created, so the protocol cannot produce the proof it would need to recover them.

In a follow-up comment the researcher checked how Lido, Origin and Rocket Pool might be affected, describing the work as quick AI research that may contain errors. The consequences differ by design. In Lido's predeposit guarantee, the vault loses its 1 ETH predeposit while compensation requires a validator proof. At Origin, a missing initial deposit blocks fresh balance verification for the whole strategy. At Rocket Pool, the missing validator prevents immediate proof-based dissolution. The researcher calls these conditional code findings, not confirmed live exploits, and notes that pre-deposit checks rejecting an earlier builder deposit can prevent the scenario.

The fix routes pending deposits by withdrawal credentials. 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 uses it. The change adds 433 lines and removes 67 across three files, including new routing and deposit-order regression tests. It now sits in the specification; client teams still have to implement it before the upgrade reaches mainnet.