Ethereum Fixes Glamsterdam Deposit Flaw, Reverses Course

Ethereum patches a potential validator deposit routing bug

Ethereum developers have merged a specification change to address a deposit-handling vulnerability discovered in the Glamsterdam upgrade roadmap. The fix, incorporated into the consensus specs on October 26, prevents a rare edge case in which staking deposits intended to create a new validator could be misattributed to a block builder that registers with the same public key. While this issue did not represent a proven mainnet exploit, it exposed a logical gap in how pending deposits would be classified during the Gloas transition and required coordinated client updates and additional testing.

What went wrong: builder and validator deposits could collide

The root cause

The vulnerability emerged from enshrined proposer-builder separation (PBS) logic planned under Glamsterdam. PBS splits block construction and proposal duties: specialized builders assemble block payloads while validators propose and attest to blocks under Ethereum's proof-of-stake consensus. A researcher, avsetsin, reported on October 12 that deposit-processing rules could route funds incorrectly when both roles used the same public key.

Under the originally proposed transition rules, a builder registered with a public key before a validator deposit for that same key arrived could receive credit for both a builder deposit and the subsequent validator deposit. In practice that meant a staking operator or liquid staking protocol initiating a validator deposit might see its ETH credited to a builder balance whose withdrawal credentials the operator controls, rather than creating the intended validator entry.

Potential impact on staking services

The report outlined hypothetical exposure for major liquid staking protocols including Lido, Origin and Rocket Pool, depending on how each protocol submits and monitors deposits. Importantly, those findings were conditional and did not prove actual thefts on mainnet. Nonetheless, the scenario could complicate deposit proofing and recovery flows for staking services if a validator object never materialized where it was expected.

Developer review, initial rejection, and reversal

Timeline of decisions

After the issue was raised, core maintainers discussed the proposed correction. On October 19, maintainer Justin Traglia closed the pull request, citing insufficient client support for the change at that time. The decision prompted further analysis and testing, and developers reopened the proposal on October 23. Reviewer potuz signaled approval but requested additional regression tests for combinations where builder and validator deposits share a public key. Avsetsin added those tests on October 23, and after additional client review the change was merged into the consensus specifications on October 26.

What the merged fix does

The approved correction separates builder and validator deposits by using withdrawal credentials as the distinguishing factor. Valid validator deposits are directed into the validator queue, while legitimate builder deposits continue to register or top up builder records. The rules preserve separate records even when the same public key appears in both roles, closing the deposit-routing gap that created the risk.

Context: Glamsterdam activation and related delays

Hoodi testnet postponement and EIP-8037

The deposit-fix landed while Ethereum teams were already reassessing Glamsterdam activation timelines. The Ethereum Foundation postponed the planned October 26 Hoodi testnet activation after researchers identified contract compatibility risks tied to EIP-8037. Researcher Toni Wahrstätter highlighted scenarios where gas accounting changes could cause unexpected reverts or enable execution paths developers assumed unreachable, potentially breaking contracts that rely on gas-remaining semantics.

This separate issue prompted the Foundation to remove both execution changes and the Gloas consensus transition from Hoodi's rehearsal and delay a proposed increase to the block gas limit. The EIP-8037 concerns are distinct from the builder-deposit fix, but both issues underscore the complexity of coordinating enshrined consensus changes and execution-layer adjustments.

Client implementation, testing, and next steps

What client teams must do

Although the specification change has been merged, individual consensus clients must implement the revised behavior and pass regression tests before the rules can take effect in a network upgrade. The merged patch includes tests that cover deposit classification during the Gloas transition, but client teams will need to integrate those tests into their CI pipelines and complete inter-client testing in testnets such as Sepolia and the eventually rescheduled Hoodi rehearsal.

Glamsterdam already activated on Sepolia on October 6, which provided an early venue to observe PBS behavior and higher transaction throughput. With Hoodi postponed, there is no confirmed activation date for the mainnet upgrade. Developers have indicated a cautious approach: incorporate the specification update, expand test coverage, and coordinate client releases before any production rollout.

Recommendations for staking operators and protocol teams

- Monitor client release notes and upgrade guidance closely; apply client updates that include the deposit-routing fix as soon as stable releases are published. - Audit deposit submission and monitoring workflows to ensure deposits are tracked until a validator object is confirmed on-chain. - Coordinate with infrastructure and validator operators to verify withdrawal credential handling and to test recovery procedures in private or testnet environments. - Consider additional telemetry that alerts on unusual deposit classifications or builder registrations that use keys tied to pending validator deposits.

Takeaway: a narrowly averted edge-case risk

The merged fix eliminates a subtle but meaningful edge case in Glamsterdam's deposit handling that could have allowed builders to receive funds intended for validators under specific timing and registration conditions. Although no exploit of this vulnerability has been reported on mainnet, the episode highlights how tightly coupled consensus changes, proposer-builder separation, and staking workflows are in a live proof-of-stake ecosystem.

Ethereum's developers addressed the issue via specification updates and regression tests, but client implementation and coordinated testing remain essential before Glamsterdam-related changes are activated more broadly. Staking protocols, node operators, and developers should continue to watch client updates, participate in testnets, and validate their own deposit and withdrawal credential handling to reduce risk ahead of the next network upgrade.