Ethereum Developers Patch a Potential Staking Deposit Flaw
Ethereum developers have merged a change to the network’s upcoming Glamsterdam upgrade to address a potential flaw in how pending ETH deposits are processed. The issue could have caused funds intended to create new validators to be credited to a block builder instead.
The fix was merged on Monday after developers initially rejected the proposed change on October 19. The revision is recorded in the Ethereum consensus specifications pull request, which documents the change to validator deposit handling.
The issue concerns the separation of responsibilities planned for Glamsterdam. Builders assemble transactions into blocks, while validators stake ETH to help secure Ethereum and participate in block validation. Although both roles can deposit ETH, their funds must be tracked separately to ensure that deposits reach the correct destination.
How the Glamsterdam Bug Could Have Affected Deposits
The flaw involved deposits that were still waiting to be credited during the upgrade process. Researcher Avsetsin identified a scenario in which an operator could first register as a builder using a particular public key, then receive a staking service’s deposit intended to establish a validator under that same key.
Under the draft rules, both deposits could have been credited to the builder rather than being assigned to their respective roles. As a result, the validator would not be created, leaving the staking service without the validator-related proof it would need to recover its funds.
“The operator can withdraw the protocol’s funds,” Avsetsin wrote in the GitHub issue describing the potential vulnerability. The scenario highlighted a risk in the planned deposit accounting rather than a confirmed loss of user funds.
The concern was especially relevant to staking protocols that manage deposits on behalf of users. However, the researcher emphasized that the findings were conditional and depended on how each protocol handled deposits. Existing checks that reject a deposit after an earlier builder deposit could prevent the scenario from occurring.
Lido, Origin and Rocket Pool Were Examined
Avsetsin examined how the potential issue could affect Lido, Origin and Rocket Pool. The researcher described the work as “quick AI research” and cautioned that the findings represented conditional code-level observations, not confirmed live exploits.
The distinction matters because a theoretical flaw in protocol specifications does not automatically mean that a deployed system is vulnerable. The outcome depends on the implementation, the sequence of transactions, and any safeguards already in place.
No losses were reported in the supplied information. The research instead identified a possible failure mode developers could address before the Glamsterdam upgrade reaches Ethereum’s main network.
Developers Reconsidered the Fix After Initial Rejection
The proposed change was initially closed on October 19. Justin Traglia, a maintainer of Ethereum’s consensus specifications, explained the decision by writing: “There was not enough support from clients to make this change at this time.”
Ethereum clients are software implementations that validators use to participate in the network. Changes to consensus specifications require coordination across these implementations, so developer support and testing are important before a revision can be adopted.
The proposal was subsequently reopened following further review. Avsetsin added tests on October 23, and Traglia merged the fix on Monday. The revised timeline gave developers more opportunity to examine the deposit-handling behavior and test the proposed solution.
How the Updated Rules Protect Validator Deposits
The revised rules sort pending deposits according to their withdrawal credentials. These credentials specify where funds can eventually be withdrawn, helping distinguish deposits associated with different roles and destinations.
Under the updated approach, validator deposits remain assigned to validators even when a builder uses the same public key. This is intended to prevent the builder’s registration from causing funds meant for a new validator to be credited to the wrong account.
The fix has now been incorporated into Ethereum’s consensus specifications. However, specification changes still need to be implemented by client teams before they can take effect across the network. The merge is therefore an important development step, but it does not by itself mean that every Ethereum client has already deployed the change.
Glamsterdam Testing Delays Continue
The Glamsterdam upgrade has already run on Ethereum’s Sepolia test network. Its planned October 26 launch on Hoodi, another test network used to test Ethereum changes, was postponed.
A new Hoodi launch date is needed before developers can schedule a mainnet launch. The postponement means the timeline remains dependent on further testing and coordination, rather than a confirmed date for activation on Ethereum’s main network.
The deposit-handling fix addresses one identified risk in the upcoming upgrade, while the delayed Hoodi testnet launch leaves developers with more work to complete before mainnet deployment. For staking services and users, the key point is that the issue was identified during development and a specification-level fix has been merged, with no reported losses associated with the scenario.
