TL;DR
- Ethereum developers merged a Glamsterdam fix after finding fork-transition logic that could route validator deposits to builders sharing the same public key.
- The bug affected Gloas onboarding, where pending deposits could be misclassified during creation of builder and validator registries, but it was not a live mainnet exploit.
- Pull request #5736 now separates deposit routing by withdrawal credentials, preserves validator deposits in their queue, and adds regression tests before deployment.
Ethereum developers merged a consensus-specification fix for Glamsterdam after identifying a Gloas fork-onboarding bug that could route validator deposits to block builders sharing the same public key. Pull request #5736 was merged into master on October 26 and changes how pending deposits are classified during the fork. The flaw affected transition logic for Ethereum’s future upgrade, not the current mainnet protocol, keeping the issue within the development and testing path for Ethereum.
Gloas Fix Separates Validator and Builder Deposit Paths
The underlying issue involved the moment Gloas initializes its separate builder registry. Under the previous routing rule, once a pending deposit registered a builder, later deposits using the same public key could increase that builder’s balance regardless of their withdrawal credentials. A validator deposit could therefore leave the validator queue and be credited to a builder instead. The bug created a conditional path where funds supplied for staking could reach an account controlled by a different party.
The issue description illustrates the risk with a staking protocol funding a validator operated by another party. If the operator first queued a valid builder deposit using the same key and both deposits remained pending at the fork, the protocol-funded validator deposit could also flow to the builder. No validator would be created from that deposit, potentially disrupting proof-based accounting or recovery procedures. The documented scenario was a protocol-level edge case, not evidence that Ethereum mainnet deposits had been diverted.
The merged fix separates deposits according to withdrawal credentials during Gloas onboarding. Validator deposits now remain in the validator queue even when a builder uses the same key, while valid builder deposits can register or top up builders independently. Existing builder deposits can also receive top-ups under the revised rules. The change aligns onboarding with the independent validator and builder registries described by EIP-8282 and adds regression tests covering deposit ordering and routing behavior.
The timing matters because Glamsterdam combines Amsterdam execution-layer changes with Gloas consensus-layer changes, including enshrined proposer-builder separation. The broader upgrade has already moved through public testing, while its Hoodi deployment was postponed for additional review and mainnet activation remains unconfirmed. The deposit-routing fix therefore strengthens specifications for a future fork rather than repairing a live Ethereum exploit. It also reinforces why transition logic around staking and block-building infrastructure requires testing before proposed protocol changes reach production safely.
