Glamsterdam: Fix Keeps Validator Deposits Out of Builder Balances

None; pre-mainnet. Per the report, an operator 'can withdraw the protocol's funds' if both deposits are pending at the fork.

Root cause: Per issue #5735: at the Gloas fork, onboard_builders_from_pending_deposits routed pending deposits by public key. Once a pending deposit registered a builder, later deposits for the same key topped up that builder regardless of withdrawal credentials. The fix routes by withdrawal credentials.

Timeline, as sourced: Issue filed 12 Oct 2026; PR closed 19 Oct and later reopened; merged 26 Oct 19:16 UTC. Client releases pending.

Ethereum consensus specs, 26 Oct 2026. Pre-mainnet; no live funds at risk on mainnet today.

Per the report (issue #5735 (opens in a new tab), filed 12 Oct by avsetsin): at the Gloas fork (the consensus half of Glamsterdam), onboard_builders_from_pending_deposits routed pending deposits by public key. Once a pending deposit registered a builder, later deposits for the same key topped up that builder regardless of withdrawal credentials. An operator who queues a builder deposit for a key, then gets a staking protocol to fund a validator deposit for that key, would receive both if both are pending at the fork, and "can withdraw the protocol's funds". No validator is created, so the protocol may be unable to produce the proof it needs to recover.

The fix (PR #5736 (opens in a new tab), merged 26 Oct 19:16 UTC by jtraglia) routes pending deposits by withdrawal credentials: validator deposits stay in the validator queue; builder deposits register or fund builders. It was closed on 19 Oct for lack of client support and reopened after Glamsterdam's timeline changed (per CoinDesk (opens in a new tab)). Client teams still need to ship it.

Pattern: who pays for a deposit and who holds the key are different parties; fork logic keyed on the key alone mixes them.