Ethereum core developers have merged a specification fix preventing pending validator deposits from being incorrectly credited to block builders during the transition to Glamsterdam’s Gloas consensus rules. According to the official consensus-specification pull request, the revised onboarding logic now separates builder and validator deposits according to their withdrawal credentials rather than allowing a shared public key to determine where later deposits are routed.
The flaw was reported on October 12 and affected the fork-transition process used to introduce builders under Gloas, Ethereum’s enshrined proposer-builder separation architecture. A builder could previously register using a BLS public key and then receive a pending validator deposit using that same key, even when the second deposit carried validator withdrawal credentials controlled by another party. The scenario existed in pre-mainnet specifications, and no production losses have been reported.
Shared Keys Could Redirect Validator Deposits
The edge case matters because the entity funding an Ethereum validator is not always the entity controlling its signing key. A staking protocol, for example, may provide ETH to an operator only after confirming that the validator uses withdrawal credentials controlled by the protocol. Under the previous Gloas onboarding rules, an operator could first establish a builder with that public key and potentially cause a later validator deposit to increase the builder balance instead.
The merged change keeps non-builder deposits in the validator processing queue even when a builder already uses the same key. Valid deposits carrying Gloas’ 0xB0 builder withdrawal prefix are instead routed to the builder registry. Builder and validator identities can therefore share a public key without allowing one deposit type to absorb funds intended for the other registry.
The issue surfaced while Ethereum was already testing Glamsterdam across development networks and Sepolia. The upgrade activated on Sepolia on October 6, although developers noted during review of the fix that builder onboarding at the fork was not exercised there because Sepolia’s deposit setup requires a special token. Sepolia’s successful fork therefore did not establish that this specific builder-onboarding edge case was safe.
Developers initially declined to merge the change before Hoodi. During the October 19 All Core Devs Testing call, the preferred approach was to prototype the fix, merge it after Hoodi and test it on a short-lived devnet without delaying mainnet. That sequencing changed after Hoodi itself was postponed, giving developers room to reopen the proposal and merge the corrected routing rules on October 26.
Hoodi Delay Gives Clients More Testing Time
Hoodi had been scheduled to activate Glamsterdam on October 26, but Ethereum developers postponed the fork on October 22 to investigate an unrelated interaction between EIP-8037 and existing mainnet smart contracts. The Hoodi delay removed both the Amsterdam execution-layer and Gloas consensus-layer activation from the schedule, leaving no replacement date currently assigned.
The broader upgrade has already undergone extensive compatibility testing through environments such as Platåberget and through client implementation work including Glamsterdam-related changes in Geth. Developers have separately been testing gas-repricing effects on existing smart contracts. The newly merged deposit fix adds another specification change that consensus clients must now implement and test before the remaining rollout can proceed.
Glamsterdam combines Amsterdam on Ethereum’s execution layer with Gloas on the consensus layer, with ePBS among its most significant architectural changes. The deposit-routing bug did not affect current Ethereum validator deposits or mainnet staking because Gloas has not activated there, and ordinary ETH holders do not need to take action.
For now, the confirmed change is that Ethereum’s Gloas specification no longer allows a builder to absorb a pending validator deposit merely because both use the same public key. Hoodi and mainnet activation dates remain unset, giving client teams additional time to incorporate the revised rules and test the fork transition before Glamsterdam advances further.