Ethereum Fixes Deposit-Handling Flaw Ahead of Glamsterdam Upgrade

The Ethereum protocol team has implemented a correction to a vulnerability in the forthcoming Glamsterdam upgrade that could have allowed staking services to lose ETH intended for new validators. The amendment modifies how deposits are attributed when builder and validator roles share identifiers, ensuring funds remain isolated.

Researchers discovered the issue during review of the upgrade’s deposit-processing logic. The flaw could arise when pending deposits are awaiting credit: if an operator first registered as a builder using a particular public key and a staking service later submitted validator funds under that same key, the earlier draft rules risked assigning both deposits to the builder.

How misattribution could occur

In the scenario outlined by researcher avsetsin, the builder’s registration using a shared public key could cause the protocol to treat separate deposits as belonging to the builder. That outcome would prevent a validator from being created and leave the staking service without the necessary proof to reclaim its deposited ETH. The researcher examined potential impacts on protocols such as Lido, Origin and Rocket Pool, noting the results depended on each project’s deposit handling.

Avsetsin emphasized these were conditional findings derived from code review rather than confirmed live exploits. Existing validation checks that reject pre-existing builder deposits could block this path, and, to date, no funds have been reported lost.

From rejection to integration

Initially, the proposed patch was closed on Oct. 19 due to insufficient client support, as noted by Justin Traglia, the maintainer of Ethereum’s consensus specifications. After additional analysis and the addition of tests by avsetsin on Oct. 23, the change was reinstated and merged into the consensus specs.

The update reorders pending deposits by their withdrawal credentials — the marker that determines where funds can ultimately be withdrawn — so validator deposits remain assigned to validators even if a builder uses the same key. While this change now exists in the consensus specification, client teams must incorporate it into their software implementations.

Glamsterdam has already executed on the Sepolia test network, but its planned Oct. 26 deployment to the Hoodi testnet was delayed. A new Hoodi date is required before a mainnet timetable can be set.