Ethereum developers merged a consensus-specification change Monday to prevent validator deposits from being credited to block builders during the planned Glamsterdam upgrade. The flaw concerned a transition case in which a builder deposit and a validator deposit used the same public key.
Under the previous onboarding logic, a valid builder deposit could register that key first. A later validator deposit with different withdrawal credentials could then top up the builder instead of creating or funding a validator. The operator controlling the builder’s withdrawal address could withdraw funds that a staking protocol intended for a validator, while no validator record would exist for the protocol’s normal proof and recovery process. GitHub
The merged pull request separates the paths using withdrawal credentials. Non-builder deposits remain in the validator queue even when a builder uses the same public key. The change also adds deposit-order regression tests. GitHub
Developers initially closed the proposal on 19 October because client support and test coverage were not ready, then reconsidered after additional testing. The fix is now in the specification, but client teams still must implement it. No live exploit or loss has been reported because Glamsterdam is not active on mainnet. Testing delays, including a postponed Hoodi test launch, created time to resolve the transition logic before deployment. coindesk.com
TOKEN RECON ASSESSMENT
This is a successful pre-deployment catch, not evidence that Ethereum staking funds were stolen. The residual risk sits in implementation consistency across clients and in the next test activation. A new Hoodi date, matching client releases and clean transition tests will confirm that the specification fix survives contact with production code. Any mainnet schedule set before those conditions would deserve scrutiny.
Sources
Ethereum consensus-specs issue 5735
