EIP-8205: Towards safe delegated staking deposits

1

Ethereum’s deposit flow has a known gap: in delegated staking, whoever deposits first for a public key permanently sets the withdrawal credentials — and the node operator can always win this race. With 32 ETH validators this means 1:32 attack leverage; with EIP-7251 high-balance validators it becomes 1:2048. Every delegated staking protocol has independently built its own defense against this. We have submitted EIP-8205 that proposes to fix this at the Ethereum protocol level.

1. The problem

In delegated staking, the funding party (staker) and the key holder (node operator) are different entities. The operator generates the BLS keypair and can deposit with attacker-controlled withdrawal credentials before the protocol’s deposit goes through. The protocol’s ETH ends up permanently locked under an address the attacker controls.

This was first documented publicly in 2019 and found in production code before the Beacon Chain launched. No known exploits have occurred — precisely because every affected protocol treats this as a critical risk and has built defenses against it. But these defenses come at a cost, and every protocol pays it independently.

2. How the ecosystem deals with it

Protocols have converged on two main strategies: bond-based pre-deposit (deposit a small amount first, prove correct credentials on-chain, then deposit the rest) and guardian committees (a trusted group of signers attests that no malicious pre-deposits exist before authorizing a deposit batch). The table below shows some representative examples; similar patterns exist across other protocols.

Protocol Approach Verification Method Key Trust Assumption
ether.fi Pre-deposit + oracle Oracle attestation Oracle honesty
Lido DSM Guardian committee Guardian committee (depositRoot snapshot) 4/6 committee quorum
Lido stVaults (PDG) Bond + proof EIP-4788 Merkle proof Trustless (on-chain proof)
Puffer Finance Bond + guardian Guardian verification Guardian honesty
Rocket Pool Saturn Bond + proof EIP-4788 state proof Trustless (on-chain proof)
Stader ETHx Bond + split deposit Oracle verification Oracle network honesty
Tranchess SafeStaking Guardian committee Safeguard node quorum Safeguard node honesty

The underlying goal is the same — verify that withdrawal credentials match before committing funds — but the implementations are tightly coupled to each protocol’s operator model, bond structure, and deposit flow. That is why no shared library has emerged in years. New protocols are vulnerable by default until they build and audit their own defense.

Lido’s experience

Lido’s work on this dates to 2021, when a security researcher reported the vulnerability through the Immunefi bug bounty program. Deposits were paused within hours to prevent exploitation.

In direct response, LIP-5 formalized the Deposit Security Module. A guardian committee (currently 4-of-6 quorum) signs off on depositRoot snapshots before any deposit batch goes through. A single guardian can pause deposits (the 1-of-N pause threshold means that even if most committee members are compromised, one honest guardian can stop an attack). Per-block deposit rate limits cap the damage if the committee itself is compromised. As Lido expanded beyond the curated operator set through the Staking Router, the DSM was updated with operator-level unvetting to support permissionless modules, in particular the Community Staking Module.

The DSM guardian model does not scale to a vault-per-operator architecture — each vault has its own withdrawal credentials, and the number of vaults is unbounded, making it impractical for a fixed committee to monitor all deposit queues. So for stVaults Lido built a different system — the Predeposit Guarantee (PDG). A guarantor posts 1 ETH collateral per validator, then proves on-chain that the pending validator has correct withdrawal credentials using an EIP-4788 Merkle proof. If the operator deposited with wrong credentials, the guarantor’s collateral is seized in favor of the vault as compensation.

Today Lido maintains two separate deposit protection systems (DSM for curated/CSM modules, PDG for stVaults), each with its own contracts, trust model, monitoring, and operational overhead. Both work, but both carry structural limitations:

  • DSM depends on off-chain guardian software with low-latency requirements and multiple layers of monitoring, distributed across trusted actors. Any unrelated deposit to the Deposit Contract rotates the depositRoot and invalidates the pending attestation, causing deposit reverts. This could become harder to maintain under faster slot times.
  • PDG requires the node operator or their guarantor to provide 1 ETH capital per validator upfront. If the protocol later decides not to top up, the only way to recover this 1 ETH is to deposit an additional 31 ETH, activate, and exit — locking significant capital to recover a small pre-deposit.

This fragmentation of deposit security infrastructure — not just within Lido but across the entire staking ecosystem — is the motivation behind looking for a solution at the Ethereum protocol level. As Vitalik Buterin has written, systemic complexity (where components interact in ways that cannot be cleanly separated) is more dangerous than encapsulated complexity. Today, every delegated staking protocol adds its own systemic complexity layer on top of Ethereum’s deposit flow; a protocol-level fix would encapsulate this safety property in one place.

3. Protocol-level solution

We have submitted EIP-8205 that proposes to close this gap at the Ethereum protocol level.

How it works:

  1. The node operator signs a BLS commitment binding a public key to specific withdrawal credentials.
  2. The commitment is submitted to a system contract on the execution layer, using the EIP-7685 request framework (same mechanism as EIP-7002 withdrawals and EIP-7251 consolidations).
  3. The consensus layer stores the preregistration in beacon state. It is provable on-chain via EIP-4788 Merkle proof.
  4. At deposit time, the CL checks withdrawal credentials against the preregistration. Match: deposit proceeds, preregistration is consumed. Mismatch: deposit is silently rejected. A complementary proposal, EIP-7684, addresses the return of mismatched deposits instead of permanent rejection — the two EIPs cover different attack surfaces and could ship together.

The preregistration must be submitted before the deposit and become verifiable on-chain before the protocol deposits. Deposits for keys without a preregistration work exactly as today. The mechanism is opt-in.

What it could simplify:

For any protocol that currently uses bond-based or guardian-based deposit protection, preregistration removes the need for:

  • Pre-deposit collateral and the associated recovery logic
  • Guardian committees, depositRoot attestation delivery, and quorum management
  • Private mempool submission to avoid depositRoot rotation
  • The 1 ETH pre-deposit that requires locking 31 additional ETH to recover if something goes wrong

For Lido specifically: DSM’s front-running protection would become unnecessary — the off-chain guardian infrastructure for deposit safety, with its software dependencies, latency requirements, and monitoring layers, goes away. Operational controls like rate limiting and pause mechanisms remain, but become simpler without the withdrawal credentials concern. PDG loses most of its complexity — no guarantor collateral, no proof-and-verify flow, and a simpler trust model with fewer actors and fewer attack scenarios between them.

Note that preregistration is not without trade-offs. A deposit with mismatched credentials against a preregistered key is permanently rejected — the ETH is not returned. This is a deliberate design choice (it makes front-running economically self-defeating), but it introduces a new failure mode for operational errors.

For more details on design decisions and trade-offs, see the companion document and the EIP-8205.

If adopted, EIP-8205 would make safe delegated deposits a property of Ethereum itself — removing the need for each protocol to build and maintain its own defense. We welcome feedback on the proposal and the approach. If you think this is a worthwhile addition to Ethereum, help amplify it.

7 Likes
2

I believe it is highly valuable direction in the long term in that it attempts to address the deposit race issue at the protocol level - it could significantly reduce existing security uncertainties and remove structural hurdles across various staking products.

That said, for implementation & consideration, it would be beneficial to address the following from my view:

1. Standardization Risk

EIP-8205 seems to effectively shift deposit security from being the responsibility of individual protocols to the Ethereum protocol itself. While this is a clear advantage, it also represents a transition from distributed risk to concentrated risk.

Previously, each staking protocol implemented its own deposit protection mechanisms, meaning failures were generally isolated. With EIP-8205 as a shared standard, however, even minor flaws in validation logic or ambiguities in the specification could propagate into ecosystem-wide failures.

Moreover, standardization introduces more than just code consolidation - it also brings potential risks such as implementation divergence across clients and reduced flexibility in future upgrades. For a primitive as critical as deposit—where ultimate ownership of assets is determined—this represents a fundamental shift from a system that can “fail in many places independently” to one that “must be correct everywhere.”

In that sense, this is not simply a trade-off between efficiency and safety, but rather a move away from fault isolation toward systemic correctness.

2. EIP-4788 State Dependency

EIP-8205 relies on EIP-4788. This is a meaningful advancement, as it removes the need for off-chain trust when validating validator state. However, it also introduces a new class of potential risk stemming from temporal asynchrony between the consensus and execution layers(Correct me if I’m wrong! :folded_hands:).

For example, issues such as slot timing mismatches, update latency between the execution and consensus layers, and potential reorg scenarios can create situations where:

  • an intent is generated based on one state,

  • but executed against another.

As a result, correctness becomes dependent not only on what is being verified, but also on when it is verified—making state freshness and timing assumptions critical design considerations.

But again, I strongly believe that protocol systems should remain simple - I fully support this direction and really appreciate the proposal.

1 Like