Ethereum developers have fixed a potentially serious vulnerability in the upcoming Glamsterdam upgrade that could have allowed block builders to withdraw ETH intended for staking validators. The flaw raised concerns about the security of staking deposits during Ethereum's transition to a new block-production system. No funds have reportedly been lost, but the discovery highlights the importance of extensive testing before major blockchain upgrades reach the main network.
Glamsterdam Bug Exposes Potential Staking Risk
Glamsterdam introduces major changes to how blocks are constructed and validated, including enshrined proposer-builder separation (ePBS), which formally separates the responsibilities of block builders and validators within Ethereum's consensus protocol. Builders assemble transactions into blocks, while validators secure the network and confirm proposed blocks.
Developers discovered that the proposed deposit-handling rules could create an unexpected conflict when a builder and validator used the same public key.
How the Vulnerability Could Have Redirected ETH
The issue was identified by researcher Avsetsin, who described a scenario involving deposits awaiting processing during the Glamsterdam transition. An operator could first register as a builder using a particular public key. If a staking protocol subsequently submitted ETH to establish a validator under that same key, the original upgrade rules could have credited both deposits to the builder's balance. The operator might then have been able to withdraw funds intended for the staking protocol's validator.
Making matters worse, the validator would not be created, potentially preventing the staking service from obtaining the proof required to recover its deposit. The researcher examined possible implications for staking systems associated with Lido, Origin, and Rocket Pool. However, these findings were conditional and did not establish that the protocols were vulnerable in their live deployments. Existing safeguards could also prevent the scenario, depending on how individual staking services handle deposits.
Developers Reverse Earlier Decision on Security Fix
The proposed correction initially encountered resistance. On October 19, Ethereum consensus specifications maintainer Justin Traglia closed the proposed change, citing insufficient support from client development teams. The decision was reconsidered as developers gained additional time to examine the problem. Avsetsin introduced further tests on October 23, and the updated correction was merged on October 26.
Under the revised rules, pending deposits are classified according to their withdrawal credentials rather than relying solely on the public key. This helps ensure that deposits intended for validators remain associated with validators, even when a builder uses the same key.
Glamsterdam Testnet Delays Continue
Although the deposit vulnerability has been addressed at the specification level, Glamsterdam still faces additional testing requirements. The upgrade previously activated on Ethereum's Sepolia test network on October 6. A subsequent activation on the Hoodi test network was scheduled for October 26 but was postponed. The delay followed concerns involving interactions between proposed gas-cost changes and existing smart contracts.
The newly merged deposit correction must also be incorporated into the relevant Ethereum client software before the upgrade proceeds. Developers have not yet confirmed a replacement Hoodi activation date or a mainnet launch schedule.
What the Fix Means for Ethereum Stakers
The resolution represents a positive security development for Ethereum's staking infrastructure. By identifying and correcting the issue before mainnet deployment, developers have reduced the risk of validator deposits being incorrectly assigned during the network upgrade.
Nevertheless, the correction does not mean Glamsterdam is ready for immediate deployment. Client implementation, additional testing, and successful network coordination remain necessary. Glamsterdam aims to improve Ethereum's scalability and block-production efficiency, and its successful deployment will depend not only on introducing new capabilities but also on ensuring that existing staking operations remain secure.
