EIP-8205
Withdrawal Credentials Preregistration
In delegated staking, a dishonest node operator can deposit first, set its own withdrawal address, and steal the protocol's much larger deposit. Today every protocol defends against this on its own.
EIP-8205 is one shared solution: the operator commits to the withdrawal address before the deposit, and Ethereum enforces it. Opt-in; other deposits are unchanged.
Draft · Proposed for Inclusion in Hegotá
EIP-8205
PFI for Hegotá
CL spec
System contract
Watch it instead
For readers who would rather watch than read
EIP-8205: Withdrawal Credentials Preregistration
Lido Poolside · George Avsetsin
Slides for this talk
The problem
Whoever deposits first controls the ETH
Attack
A dishonest Node Operator can use a small deposit to take control of the Delegator’s entire stake
Delegated staking splits one validator between two actors. The Delegator provides the ETH. The Node Operator generates the validator key, keeps it, and uses it to run the validator. That same key lets a dishonest Node Operator submit a different deposit first and lock in a withdrawal address they control.
01 · The Delegator provides the stake
The Delegator provides the ETH for staking and chooses a Node Operator to run the validator. The Delegator expects to remain in control of the stake and receive the validator’s withdrawals.
02 · The Node Operator runs the validator
The Node Operator generates and holds the validator key, then uses it to run the validator. In return, the Node Operator usually receives a fee or a share of the staking rewards.
03 · Deposit data describes the validator
Before the validator can be created, the Node Operator prepares signed deposit data. It contains the validator public key, the amount, a signature, and the withdrawal credentials — the destination for future withdrawals.
04 · The first valid deposit assigns control
When Ethereum processes the first valid deposit for a validator key, it creates the validator record and copies the withdrawal credentials into it. Later deposits can add ETH to the balance, but they cannot replace those credentials.
05 · The Delegator receives the expected deposit
The Node Operator signs deposit data containing the Delegator’s withdrawal credentials and gives it to the Delegator. The validator key, signature, and withdrawal destination are all exactly as agreed.
06 · The Node Operator creates another version
But the Node Operator still holds the validator key. A dishonest operator can sign a second, equally valid deposit for the same key — this time using their own withdrawal credentials and only 1 ETH.
07 · The 1 ETH deposit is processed first
The Node Operator submits the 1 ETH deposit before the Delegator’s deposit is processed. Ethereum creates the validator record from it and stores the Node Operator’s withdrawal credentials.
08 · The address stays; only the balance changes
When the Delegator’s deposit arrives, the validator already exists. Ethereum adds the Delegator’s ETH to its balance but does not replace the withdrawal credentials. The Node Operator now controls both the validator key and its withdrawals.
Known since 2019
2019
Researchers documented the deposit front-running vulnerability publicly in 2019, before the Beacon Chain launched. No production exploits are known to date — every delegated staking protocol treats it as critical and built its own defense around it.
The scale
About 2/3 of staked ETH is technically exposed
The vulnerability applies wherever the funding party and the key holder are distinct parties — centralized exchanges, liquid staking protocols, and staking-as-a-service providers.
Liquid staking protocols, with documented defenses
Exchanges and staking services, relying on off-chain arrangements or with no published protection
Unidentified in this data source, cannot be attributed
Everyone built their own fence
Seven implementations, two strategies
Delegated staking protocols have converged on two main defense strategies. Both work, and both impose costs that each protocol bears independently.
Bond and pre-deposit verification
The operator deposits a small amount first (1–4 ETH), then proves on-chain that the pending validator has the correct withdrawal credentials. Only after verification does the protocol release the remaining funds.
Guardian committees
A trusted group of signers attests that no malicious pre-deposits exist before authorizing each deposit batch. This avoids locking capital, but introduces trust and liveness requirements.
And none of the fences are free
31–2,047 ETH
Sits idle while the pre-deposit clears
The validator record appears only after the 1 ETH pre-deposit clears the churn-limited entry queue. Until its credentials can be proven on-chain, the rest sits in the protocol's contracts earning nothing — and the queue can stretch to months.
+31 ETH
To recover a stranded 1 ETH
Deposits are one-way, and activation requires 32 ETH. Recovering an abandoned pre-deposit means depositing 31 more, activating, then exiting — if liquidity is short, it stays stranded.
Any deposit
Can invalidate a guardian snapshot
A guardian attestation is bound to one depositRoot. Any call to the Deposit Contract in between — even an unrelated one — changes that root and reverts the whole batch, so the deposit has to land first in its block.
Off-chain
Adds trust and liveness risk
Committee members can collude, signing software adds supply-chain risk, and quorum must stay available. Rate limits, pause controls, monitoring, and alerting become part of the security system.
Per protocol
The same guarantee is rebuilt
Contracts, proof logic, oracle or guardian infrastructure and monitoring are rebuilt per protocol, and every hardfork may require review. There is no shared library: new entrants are exposed until they build their own — months of engineering plus an audit.
The solution
Preregister the address before depositing
The key holder signs the withdrawal address in advance. The chain remembers the commitment and refuses any deposit that does not match it. The race stops deciding anything.
A small change with big impact
Existing rails on the EL, bounded additions on the CL
No new transaction type, no new cryptography, no change to how deposits work. The proposal reuses the EL→CL request pipeline that Ethereum already ships, and adds validation and short-lived storage on the consensus side.
Execution layer
A well-trodden path
Ethereum already runs a standard bus for execution-to-consensus requests: a system contract takes the call, charges a fee, and queues the request for the beacon chain via EIP-7685. EIP-8205 adds one more contract of the same shape.
Consensus layer
Validation and a short-lived store
One extra check inside deposit processing, and a small store of pending commitments that expires on its own.
One BLS signature check per request — the same verification a deposit already performs
An extra validation step during deposit processing — if a commitment exists for that key, it must match
A bounded store of commitments — entries expire after about 36 days, so nothing accumulates
At most four requests per block — a hard cap on the work added
What does not change
Opt-in. Keys without a preregistration behave exactly as they do today — same deposit flow, same rules, nothing to migrate, nothing to coordinate. No change for solo stakers, no change for existing validators.
How a protocol would use it
Sign the commitment
The node operator signs a commitment binding one specific public key to one specific withdrawal credentials. They can then hand it to the protocol to submit with the deposit, or submit it themselves.
ONE SIGNATURE TO BIND PUBKEY → WITHDRAWAL CREDENTIALS
Submit it
The commitment is sent as a transaction to the execution-layer system contract, the same way as any other EL → CL request: EIP-7002, EIP-7251, EIP-8282.
EL contract → EIP-7685 request → CL processing
Deposit with proof
Once the preregistration is on the consensus layer, depositing is safe — there is nothing left to front-run. The protocol can send the deposit in a transaction carrying a proof that the commitment is present in the consensus-layer state, checked against the beacon block root exposed on the execution layer by EIP-4788.
Merkle proof of the preregistration · beacon root via EIP-4788
Progress
The specs are ready for client implementation
Standards Track, adapted to the latest Gloas spec
Full spec change with test coverage
Execution-layer predeploy on the EIP-7685 request bus
Reference verifier contract
Checks the beacon-root proof that a commitment exists, then makes the deposit
Client implementations
CL and EL client support
Devnets
Interop testing across clients
Support needed
Get it into Hegotá
EIP-8205 is Proposed for Inclusion in Hegotá. Client teams and the community decide what makes the final scope — support now is what moves it forward.
Client teams, community
Include it in your vote
Put EIP-8205 on your Forkcast ranking, where the fork's priorities are actually assembled.
Rank it on ForkcastVALIDATORS
Vote for the EIP
One click on the EthVA hub. Community signal is read alongside client-team ranking.
Vote on EthVA hubResearchers, protocols
Comment in the thread
The thread that matters for Hegotá. Say whether the problem is worth protocol surface.
Open the thread