Ethereum (ETH) Developers Merge Glamsterdam Deposit Fix After Oct. 19 Rejection

Deposit Rules Rewritten Before Glamsterdam

Client teams building Ethereum's next upgrade now have a revised set of deposit rules to fold into their software, after developers merged a patch that closes a funding-theft vector in Glamsterdam, the network's upcoming hard fork. The change went into the consensus specifications on Monday through a pull request that rewrites how pending deposits are sorted. Under the new rules, funds a staking service sends to activate a validator can no longer be claimed by an operator who has registered the same identifier as a builder. The flaw sat in how Glamsterdam would process deposits that were still waiting to be credited. An operator could first register as a builder using a particular public key, the identifier tied to a validator or builder. If a staking service then deposited Ethereum (ETH) to start a validator under that same key, the draft rules would credit both deposits to the builder, who could then withdraw the protocol's funds. No validator would ever be created, so the staking service could not produce the proof it would need to recover its money. The fix sorts pending deposits by their withdrawal credentials, the setting that says where a deposit's money can eventually go, so validator deposits stay with validators even if a builder is using the same key. The patched rules are now part of the canonical specifications every client follows. The risk never reached Ethereum (ETH) price or existing staked balances: it concerned deposits processed under the draft rules, and no losses have been reported.

The design choice that opened the door is central to Glamsterdam itself. The upgrade splits two jobs that today sit bundled in a single role: builders assemble blocks of transactions, while validators, who stake Ethereum (ETH) to help secure the network under proof of stake, pick and confirm them. Both sides can deposit ETH, and the money is meant to be tracked separately, which is what keeps liquid staking providers and their depositors whole. The attack scenario was laid out in an issue on the consensus-specs repository by researcher avsetsin, who also looked at how Lido, Origin and Rocket Pool could be affected. Exposure depended on how each protocol handles deposits. Avsetsin, who is listed as a member of Lido's GitHub organization, described the results as conditional code findings rather than confirmed live exploits, adding that existing checks rejecting an earlier builder deposit could stop the attack in practice. The researcher's summary of the core case was blunt: "The operator can withdraw the protocol's funds." The patch took a winding path to merge. Developers closed the proposed fix on Oct. 19, with Justin Traglia, who maintains Ethereum's consensus specifications, writing that client support for the change was insufficient at that time. Clients are the separate software programs validators run to take part in the network. The pull request was reopened after further review, avsetsin added tests on Oct. 23, and Traglia merged the change on Monday, one week after the initial rejection.

Client Work and the Hoodi Delay

How the fix landed matters as much as what it fixes. Glamsterdam has already run on the Sepolia testnet, but its Oct. 26 launch on Hoodi, a second test network, was postponed. The deposit change went into the specifications the same day, which reads as developers using the delay to land the fix before another public rehearsal rather than shipping the upgrade with a known deposit-crediting defect. What remains is implementation. Merging into the consensus specifications sets the target; the client teams must still build the new sorting rule into their software before a mainnet date can be discussed. Until client releases carry the revised deposit handling, Glamsterdam's timeline sits with the client developers, and Hoodi, once it is rescheduled, gives them a full network to rehearse the change on before mainnet.