Ethereum developers merged a fix on October 26 for a bug in the upcoming Glamsterdam upgrade that could have sent a staker's validator deposit into a block builder's account instead, closing a flaw first flagged two weeks earlier. The fix, authored by Lido Chief Protocol Architect George Avsetsin, changes how Gloas, the consensus-layer half of Glamsterdam, handles deposits still pending when the fork activates.
How the Glamsterdam Deposit Bug Worked
Glamsterdam gives block builders their own deposit registry, separate from validators, though both roles can share a public key. In an October 12 bug report, Avsetsin explained that "the party that pays for a deposit is not always the key holder." Under the original rules, once a pending deposit registered a builder for a given key, every later deposit tied to that key, including a validator deposit from a staking protocol, would be credited to the builder instead.
The risk: an operator could queue a builder deposit for a new key, then a staking protocol could fund a validator deposit using that same key. If both were pending at activation, the protocol's funds would land in the builder's balance, and the operator could withdraw them without creating the expected validator. Avsetsin flagged Lido, Origin, and Rocket Pool as contracts with possible exposure, cautioning the review was preliminary: "These are conditional code findings, not confirmed live exploits."
Closed, Reopened, Then Merged
The fix almost did not make it in. Ethereum researcher Justin Traglia closed the issue on October 19 after client developers found "not enough support" for the change. Three days later, Glamsterdam's Hoodi testnet activation was postponed to review a separate gas-accounting proposal, EIP-8037, opening a window to revisit the deposit fix. Lido's Dmitry Gusakov asked to reopen the issue on October 23, and after regression testing from client teams including Prysm and Lodestar, Traglia merged the revised code on October 26. The update now sorts pending deposits by withdrawal credentials, so validator funds stay with validators and builder funds stay with builders.
No losses tied to the flaw have been reported, and independent reporting on the fix confirms it only affects how pending Glamsterdam deposits route once the fork activates, not any transfers already completed on Ethereum's live network. Glamsterdam activated on the Sepolia testnet on October 6, but Hoodi's new date remains unannounced, leaving the mainnet timeline open for now.
Why This Matters for Stakers
The episode is a reminder that validator-related security risks are not limited to wallets or node software; protocol upgrades carry their own risk surface, and catching conditional findings like this one before mainnet activation is exactly what public testnets and open developer review are for. Node operators and stakers do not need to take any action themselves. Client teams must ship the updated consensus rules before Glamsterdam reaches a public network again, and no funds were ever at risk on Ethereum's production chain.
Frequently Asked Questions
Did the Glamsterdam bug affect funds on Ethereum mainnet?
No. The flaw only concerned how pending deposits would route once Glamsterdam activates; no losses have been reported and mainnet was never exposed.
Do stakers need to do anything right now?
No. The fix is a consensus-layer specification change that client teams must implement before the next testnet activation; individual stakers do not need to act.
When does Glamsterdam reach Ethereum mainnet?
No date has been set. The Hoodi testnet activation planned for October 26 was postponed on October 22, and a new date has not been announced.