The specification change separates validator and builder deposits, addressing a conditional risk rather than a confirmed theft.
Ethereum developers have merged a consensus-specification change addressing how pending staking deposits are handled during the planned Glamsterdam upgrade.
The issue concerned deposits associated with the same public key being assigned to different roles. Under the previous transition rules, funds intended for a validator could instead increase a builder’s balance in a particular sequence of pending deposits.
The merged change routes deposits according to their withdrawal credentials, preserving the distinction between validator funds and builder funds.
What Was the Potential Problem?
Validators stake ETH to participate in securing Ethereum. Builders assemble transaction payloads. These roles have different responsibilities, so correctly attributing their deposits matters.
Researcher avsetsin identified a conditional scenario in which a builder registration and a validator deposit shared a public key.
If the builder registration was processed first during the upgrade transition, a later validator deposit could be credited to the builder rather than retained for validator processing.
That matters when the party supplying the validator’s funds is different from the operator controlling the key. The funding party could expect a validator to be created with its designated withdrawal credentials, while the transition rules produced a different outcome.
How the Fix Changes Deposit Handling
The patch separates pending deposits using withdrawal credentials—the information governing their withdrawal destination or treatment.
Validator deposits remain in the validator queue even when a builder uses the same public key. Valid builder deposits follow the builder-registration or top-up path.
In practical terms, sharing a public key should not cause a validator deposit to be treated automatically as builder funding.
The Corrected Development Timeline
The proposal was initially closed after developers discussed it and lacked sufficient client support to proceed at that point.
It was subsequently reopened, reviewed and merged.
| Date | Recorded development |
|---|---|
| October 19, 2026 | Proposal closed |
| October 23, 2026 | Proposal reopened |
| October 26, 2026 | Fix merged into the consensus-specifications repository |
The merge date is important because it distinguishes the actual development record from later reporting about the change.
Was ETH Stolen Through This Issue?
The researcher described the protocol-specific findings as conditional, not confirmed live exploits.
The disclosure discussed possible implications for staking systems including Lido, Origin and Rocket Pool, while warning that the preliminary analysis could contain errors and that deployed implementations might differ.
Those references should not be interpreted as confirmation that the named services suffered losses.
Whether the scenario could occur depends on the relevant deposit sequence, implementation and protective checks. The researcher also noted that checks rejecting an earlier builder deposit could prevent it.
A Specification Merge Is Not a Network Deployment
The confirmed milestone is acceptance of the change into Ethereum’s consensus specifications.
Client software implements those specifications. A repository merge alone does not establish that every client has incorporated the fix, that a release containing it has shipped or that the rules are active on Ethereum mainnet.
For that reason, “Ethereum patches live staking theft” would overstate the evidence.
The more accurate description is that developers corrected a deposit-handling rule during upgrade development.
What Staking Operators Should Watch
For staking operators and protocol developers, the relevant follow-up is implementation: whether their client versions and deposit workflows correctly distinguish builder and validator funding.
The development discussion also illustrates why recovery assumptions need review. A system expecting proof of a newly created validator may require different handling if that validator was never created.
For ordinary readers, the central distinction is simpler: researchers identified a potential routing failure, developers accepted a specification fix, and the disclosure does not establish a successful theft.
