Ethereum fixes Glamsterdam bug preventing staking deposits from going to builders

This flaw possessed the potential to redirect staking deposits intended for new validators to builders.

The issue arose because builder and validator deposits shared a public key. Under the draft rules, this situation could result in both deposits being credited to the builder. Consequently, staking services might be unable to recover their deposited funds.

Researcher Avsetsin identified this scenario. If an operator first registered as a builder using a specific public key, and a staking service subsequently deposited ETH to start a validator under that same key, the draft rules would credit both deposits to the builder. Avsetsin noted, “The operator can withdraw the protocol’s funds.”

Since no validator would be created, the staking service would lack the necessary proof to reclaim its money. Avsetsin, who is listed as a member of Lido’s GitHub organization, examined the potential impact on protocols like Lido, Origin, and Rocket Pool during what she termed “quick AI research.” She cautioned, “These are conditional code findings, not confirmed live exploits,” adding that current checks rejecting an earlier builder deposit could prevent the attack.

Initially, developers rejected the proposed fix on October 19. Justin Traglia, who maintains Ethereum’s consensus specifications, stated, “There was not enough support from clients to make this change at this time.” Clients are the distinct software programs utilized by validators to participate in the network.

However, the fix was reopened after further examination. Avsetsin added tests on October 23, leading Traglia to merge the correction on Monday. The revised rules mandate that pending deposits must be sorted according to their withdrawal credentials. This ensures that validator deposits remain associated with validators, even if a builder uses the identical key.

This change is now integrated into Ethereum’s consensus specifications, though client teams must still incorporate it into their software. The Glamsterdam launch on the Hoodi test network, originally scheduled for October 26, has been postponed.

The resolution of this protocol-level bug underscores the intricate coordination required between core protocol upgrades and the decentralized financial infrastructure built upon them. Market participants and institutions must now ensure their client software reflects these revised deposit handling rules before the mainnet deployment.

Why it matters

This fix directly impacts the operational security of staking services and the underlying protocol logic of Ethereum. The successful integration of these revised deposit rules is critical for the successful progression of the Glamsterdam upgrade toward mainnet deployment.