The change separates pending validator and builder deposits, addressing a conditional vulnerability rather than a confirmed live exploit.
Ethereum developers have merged a specification change addressing a potential problem with pending staking deposits during the planned Glamsterdam upgrade.
The issue could cause funds intended for a validator to be credited to a builder using the same public key. The fix changes how those deposits are classified during the upgrade transition.
The public development record shows that the proposal was merged on October 26 after being closed and subsequently reopened for review.
What Was the Deposit-Handling Issue?
Researcher avsetsin identified a scenario involving two deposits associated with the same public key but intended for different purposes.
A builder deposit could be processed first, followed by a validator deposit funded by a staking service. Under the previous transition rules, both amounts could increase the builder’s balance.
The distinction matters because the person controlling a key is not necessarily the party supplying the staking funds.
If the validator deposit were redirected into the builder balance, the expected validator might not be created. That could also interfere with recovery procedures that depend on proving the validator exists.
How the Fix Works
The merged change routes pending deposits according to withdrawal credentials.
Validator deposits remain queued for validator processing even when a builder uses the same public key. Valid builder deposits follow the builder-registration or funding path.
The purpose is to preserve the separation between the two roles instead of treating a shared key as sufficient reason to combine their funding.
Proposal Was Reopened Before Approval
The development discussion records an initial decision to close the proposal on October 19 because there was insufficient support from client teams at that time.
The proposal was reopened on October 23 and merged three days later.
| Date | Development milestone |
|---|---|
| October 19 | Proposal closed |
| October 23 | Proposal reopened |
| October 26 | Fix merged |
In Ethereum development, clients are the software implementations that translate protocol rules into working network behaviour.
Were Staking Services Exploited?
The researcher discussed possible implications for deposit workflows associated with Lido, Origin and Rocket Pool.
However, the accompanying analysis explicitly described conditional findings rather than confirmed live exploits. It also warned that the preliminary research could contain errors, that deployed code might differ and that existing checks could prevent the scenario.
Naming a protocol in that analysis is therefore not evidence that it suffered a theft.
The relevant questions concern its actual implementation, deposit checks and recovery mechanisms.
Specification Approval Is Different From Deployment
The verified milestone is acceptance of a change into Ethereum’s consensus specifications.
That should not be described as proof that every client has released an implementation or that the revised rules are active on mainnet.
Likewise, the reviewed records do not establish that an existing deployed deposit contract was replaced. The documented change concerns how pending deposits are handled during the upgrade transition.
Why This Matters
Staking systems rely on more than accepting a deposit. They must attribute funds correctly and preserve the records needed for accounting and recovery.
This case illustrates how an upgrade can introduce an edge case when different participants share an identifier but have different funding and withdrawal arrangements.
For operators, the next practical checkpoint is implementation in their chosen client and compatibility with their deposit workflow.
For readers, the essential distinction is between a potential vulnerability found during development, an accepted specification fix and a completed network deployment.
