Ethereum spec fix stops Gloas fork crediting validator deposits to builders

Victoria Shinder29 October 2026, 09:252 min read

Ethereum's consensus specification has been changed to close a fund-misrouting scenario at the Gloas fork, the consensus-layer half of the Glamsterdam upgrade. Issue 5735 on the consensus-specs repository described how the fork's onboarding step could credit a validator deposit paid for by one party to a builder controlled by another; pull request 5736, opened on 12 October, fixed it and was merged on 26 October.

The cause was a routing rule: once a pending deposit registered a builder, later deposits for the same public key topped up that builder regardless of their withdrawal credentials, so a validator deposit was removed from the validator queue and added to the builder's balance. The issue gives an example: a staking protocol funds an operator's first validator deposit and requires proof that the validator has the protocol's withdrawal credentials before funding more. If the operator first queues a builder deposit for the same new key, both amounts go to the builder at the fork, and the operator can withdraw the protocol's funds. No validator record is created, which can also block the protocol's recovery path.

The fix routes pending deposits at the fork by withdrawal credentials. Validator deposits stay in the validator queue even if a builder uses the same key; a valid builder deposit registers or tops up the builder; a builder deposit for an existing builder tops it up regardless of signature; and an invalid builder deposit with no builder is dropped unless a validator with that key exists or a valid validator deposit is queued. Regression tests were added; three test-vector cases were renamed and four now require BLS.

What it means

The bug only existed during the one-time fork transition, which is exactly the code that gets the least real-world exercise before it runs on mainnet. Staking protocols that pre-fund operator deposits are the ones that would have been exposed, and the fix landed before activation rather than after a loss.