Ethereum Developers Propose Consensus Spec Fix to Prevent Gloas Deposit Routing Bug

Ethereum core developers have submitted a patch to the network's consensus specifications to resolve an edge case that could allow validator deposits to be misrouted to block builders during the upcoming Gloas fork transition ¹.

Under issue #5735 in the ethereum/consensus-specs repository, developers identified that the function onboard_builders_from_pending_deposits could credit validator deposits to a builder controlled by a different party if both entities use the same public key ². Under the initial Gloas fork design, once a pending deposit registers a builder, any subsequent pending deposits with matching public keys automatically top up that builder, regardless of their specified withdrawal credentials ². Consequently, a validator deposit would be removed from the validator queue and redirected to the builder's balance, potentially enabling malicious operators to misappropriate deposits funded by staking protocols ². At the time of writing, $ETH changed hands around $2,300.

Revising the Gloas Fork Onboarding Table

To mitigate this vulnerability, developer avsetsin opened pull request #5736, titled "Separate builder and validator deposits at the Gloas fork" ¹. The update alters how pending deposits are evaluated right before transition execution, ensuring non-0xB0 credential deposits stay in the validator queue regardless of whether an active builder uses the same public key ¹. Under the revised logic, non-0xB0 deposits—which represent standard validator allocations—are kept queued for normal validator processing across all builder and validator state permutations ¹.

The pull request also addresses edge cases involving 0xB0 builder credentials submitted for an existing validator when no builder entity has been established ¹. A 0xB0 deposit bearing a valid signature establishes a new builder, while one with an invalid signature remains queued to top up the existing validator ¹. Developer comments note that discarding such invalid deposits outright would introduce fund loss scenarios, which the revised logic explicitly avoids ¹. The protocol rules already separate builder and validator processing paths after the fork, and this pull request ensures that isolation applies cleanly during the transition itself ².