Ethereum Developers Merge Glamsterdam Fix to Keep Validator Deposits Out of Builder Accounts
Ethereum developers merged a fixon Oct. 26 for a Glamsterdam bug that could have credited a staker's validator deposit to someone else's builder account, one week after closing the same change for lack of client support.
The pull request , written by Lido Chief Protocol Architect George Avsetsin, changes how Gloas, the consensus-layer half of the upgrade, treats deposits still sitting in the queue when the fork activates. The new rule looks at the withdrawal credentialson every deposit still pending at activation. Those meant for validators stay put, and builder accounts get funded only by deposits with builder credentials.
Get Unchained's crypto news in your inbox with the free Unchained Daily newsletter .
How the Bug Worked
Glamsterdam gives block buildersa registry of their own, separate from validators. In a bug report filed on Oct. 12, Avsetsin wrote that "the party that pays for a deposit is not always the key holder." Under the old fork rules, once a pending deposit registered a builder for a public key, every later deposit for that key went to the builder, whatever credentials it carried.
The report walked through an operator who queues a builder deposit for a new key, after which a staking protocol funds a validator deposit for the same key. "If both deposits are pending at the fork, both amounts go to the builder. The operator can withdraw the protocol's funds," Avsetsin wrote.
In a follow-up comment, the author shared what they called "quick AI research" naming Lido, Originand Rocket Poolcontracts that could be affected, and warned it "may contain errors." The comment added, "These are conditional code findings, not confirmed live exploits."
Closed, Then Reopened
Ethereum researcher Justin Tragliaclosed the issue and the fix on Oct. 19 after discussions on two developer calls, writing that "there was not enough support from clients to make this change at this time."
Three days later, developers unscheduled Glamsterdam's Oct. 26 activation on the Hoodi testnet , which had followed the upgrade's Sepolia launch on Oct. 6 . On Oct. 23, Lido Staking Head of Engineering Dmitry Gusakovasked to reopen the issue "due to changes in the Glamsterdam timeline and a potential chance to fix it."
Prysm developer Potuzapproved the change that day while asking for extra tests. "I'm still scared of putting this change before the fork," Potuz wrote in the review , adding that with the fork's status now "Unknown," there was "more than adequate time to study this change both in the specs and how it affects our caches."
ChainSafe Protocol Engineer Nico Flaigapproved on Oct. 26, saying the Lodestar client "is passing them too on my branch" and that extra differential testing turned up no findings. Traglia approved and merged the fix the same day.
Related Listen: Why an Ethereum Proposal to Zero Out Staking Yield Sparked a Revolt
