# The Deposit Front-Running Problem in Delegated Staking

_Companion document for the Validator Withdrawal Address Preregistration EIP_

## TLDR

- In delegated staking, the node operator can front-run the protocol's deposit and permanently set the validator's withdrawal credentials — the address that controls the staked ETH — to an address the attacker controls. Every affected delegated staking product has either built its own protection layer or accepted the risk, exposing capital providers to off-chain agreements with node operators.
- Application-layer defenses carry unavoidable costs: capital locked in pre-deposits, trust in guardian committees, and fragmented engineering across every protocol. Each defense has its own trade-offs, and no single approach is a silver bullet — the solution space fragments staking infrastructure on Ethereum in a way that grows harder to audit and maintain over time. New entrants are vulnerable by default until they build and audit their own.
- Preregistration is a protocol-level fix. The key holder signs a binding commitment to withdrawal credentials, submits it through a dedicated execution-layer contract using the [EIP-7685](https://eips.ethereum.org/EIPS/eip-7685) request framework, and the consensus layer enforces the commitment when deposits are processed. It addresses the vulnerability at the Ethereum protocol layer, removing the need for each staking product to build its own defense.

## 1. The Problem

### 1.1 Deposit front-running in delegated staking

When someone stakes ETH on Ethereum, two things happen: funds are deposited, and a validator keypair becomes the validator's identity. Whoever deposits first for a given public key sets the **withdrawal credentials** (the address that will receive the ETH when the validator exits) permanently — subsequent deposits can add to the balance but cannot change the withdrawal address.

In solo staking, one person controls both the funds and the key. No conflict. But in delegated staking, these roles are split: a **funding party** (staking protocol, institutional client) provides ETH, and a **key holder** (node operator) generates the keypair. The key holder, who controls the private key, can always win the race to deposit first.

This means an operator can deposit with attacker-controlled withdrawal credentials before the protocol's deposit goes through. The protocol's ETH ends up locked under an address the attacker controls. Researchers [first documented this vulnerability publicly in 2019](https://ethresear.ch/t/deposit-contract-exploit/6528), and it was found in production code before the Beacon Chain launch. No known exploits have occurred in production to date — precisely because every delegated staking protocol treats this as a critical risk and has independently built defenses against it.

#### Who is affected

The vulnerability applies wherever the funding party and the key holder are distinct parties. [On-chain staking analytics](https://dune.com/hildobby/eth2-staking) show that roughly two-thirds of all staked ETH flows through delegated staking — centralized exchanges, liquid staking protocols, and staking-as-a-service providers. All of it is technically exposed to the deposit front-running vulnerability, and about a third of all staked ETH — the liquid staking protocols (ether.fi, Lido, Puffer, Rocket Pool, Stader, Stakewise, and others) — has publicly documented technical defenses. The rest either relies on off-chain arrangements (single-entity control, contractual trust, reputation) or has no publicly documented protection. A further third of staked ETH is unidentified according to this data source and cannot be attributed.

#### Who is not affected

Stakers who control both their own funds and their own keys — whether solo stakers running their own validators or centralized entities managing both sides — do not face this problem.

### 1.2 How protocols defend today

Delegated staking protocols have converged on two main defense strategies:

**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 remaining funds.

**Guardian committees.** A trusted group of signers attests that no malicious pre-deposits exist before authorizing each deposit batch. This approach avoids locking capital in pre-deposits, but introduces trust and liveness requirements.

Both approaches work. Both impose costs that each protocol bears independently, and in a fragmented way: each defense has its own trade-offs, no single approach is a silver bullet, and the diverging implementations grow harder to audit and maintain as the ecosystem evolves. The table below shows representative examples; similar patterns exist across other protocols as well.

| Protocol | Approach | Capital at Risk | Verification Method | Key Trust Assumption |
| ------------------------------------------------------------------------------------------------------------------- | -------------------- | ----------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | -------------------------- |
| [ether.fi](https://etherfi.gitbook.io/etherfi/ether.fi-whitepaper/technical-documentation) | Pre-deposit + oracle | 1 ETH (protocol capital) | Oracle attestation | Oracle honesty |
| [Lido stVaults (PDG)](https://docs.lido.fi/run-on-lido/stvaults/tech-documentation/pdg/) | Bond + proof | 1 ETH collateral | [EIP-4788](https://eips.ethereum.org/EIPS/eip-4788) Merkle proof | Trustless (on-chain proof) |
| [Lido DSM](https://github.com/lidofinance/lido-improvement-proposals/blob/develop/LIPS/lip-5.md) | Guardian committee | None (protocol funds) | Guardian committee (`depositRoot` snapshot) | 4/6 committee quorum |
| [Puffer Finance](https://docs.puffer.fi/yield/protocol/overview) | Bond + guardian | 2 ETH (pufETH) | Guardian verification | Guardian honesty |
| [Rocket Pool Saturn](https://saturn.rocketpool.net/) | Bond + proof | 4 ETH bond ([Saturn One](https://medium.com/rocket-pool/all-about-saturn-one-42ca035a746d), Feb 2026) | [EIP-4788](https://eips.ethereum.org/EIPS/eip-4788) state proof ([RPIP-43](https://rpips.rocketpool.net/RPIPs/RPIP-43), [RPIP-59](https://rpips.rocketpool.net/RPIPs/RPIP-59)) | Trustless (on-chain proof) |
| [Stader ETHx](https://staderlabs.gitbook.io/ethereum/ethx-security) | Bond + split deposit | 1 ETH pre-deposit (4 ETH total bond) | Oracle verification | Oracle network honesty |
| [Tranchess SafeStaking](https://tranchess.medium.com/recap-deposit-front-run-vulnerability-mitigation-cfc66ef8c50d) | Guardian committee | None specified | Safeguard node quorum | Safeguard node honesty |

### 1.3 Why application-level mitigations are not enough

Despite their differences, the approaches above share structural limitations that follow from defending against a protocol-level gap at the application layer.

**Capital locked behind the entry queue** _(bond and pre-deposit schemes)._ Bond verification requires the protocol to send a small pre-deposit (typically 1 ETH) and then wait before committing the remaining funds. The pre-deposit enters the churn-limited entry queue — validators are not added to the registry instantly. Only after the validator record is created can its withdrawal credentials be proven on-chain via [EIP-4788](https://eips.ethereum.org/EIPS/eip-4788), and only after that proof does the protocol deposit the remaining capital. Until then, the remaining capital — 31 ETH per 0x01 validator, or more for high-balance validators — sits in the protocol's contracts, generating no yield.

During periods of high demand, the entry queue can stretch to [weeks or months](https://www.validatorqueue.com/) — approximately 58 days as of March 2026. With high-balance validators enabled by [EIP-7251](https://eips.ethereum.org/EIPS/eip-7251), more capital sits idle per validator: a single 2,048 ETH validator leaves 2,047 ETH waiting while its 1 ETH pre-deposit clears the queue. When queues are long, high-balance validators become less attractive for initial deposits, since more capital per key sits idle waiting for verification.

**Irrecoverable pre-deposits** _(bond and pre-deposit schemes)._ Deposits are one-way: the consensus layer has no mechanism to return a deposit before activation, and activation requires 32 ETH. If the protocol decides not to top up a pre-deposited validator — because of a liquidity crunch, operator blacklisting, or any other reason — the only way to recover the 1 ETH is to deposit an additional 31 ETH, activate, and then exit the validator. If the protocol lacks liquidity at that point, the pre-deposit is stranded indefinitely.

**`depositRoot` fragility** _(guardian schemes)._ Guardian committees must sign an attestation bound to a specific `depositRoot` — a hash representing the current state of all deposits in the Deposit Contract. If any deposit touches the contract between signing and execution — even a legitimate, unrelated one — the `depositRoot` changes, the attestation becomes invalid, and the entire deposit batch reverts. The protocol's deposit must therefore land as the first deposit in a block. This race condition can be exploited, though submitting through a private mempool with a gas premium reduces the risk.

**Guardian committee trust** _(guardian schemes)._ The committee operates off-chain, with the inherent risks of any off-chain trust system like: members can collude, the signing software is a supply-chain attack surface, and liveness depends on the availability of enough members to reach quorum. To contain these risks, protocols add on-chain rate limits, pause mechanisms, monitoring, and alerting — each of which must be designed, audited, and maintained. The committee members must run dedicated software and keep it updated across protocol upgrades.

**Per-protocol engineering cost.** Each protocol independently builds, audits, and maintains its own defense — custom contracts, proof verification logic, oracle or guardian infrastructure, and edge-case handling. Every Ethereum hardfork may require reviewing and updating these systems. There is no shared library or standard contract; new entrants are vulnerable by default until they build and audit their own, which typically takes months of engineering time plus a dedicated security audit.

## 2. The Solution

Ethereum has already taken steps toward supporting delegated staking at the protocol layer — [EIP-7002](https://eips.ethereum.org/EIPS/eip-7002) (execution-layer triggerable withdrawals) gave capital providers a protocol-level escape hatch, recognizing that the funder and the key holder are often different parties. Preregistration extends this direction by closing the remaining gap in the deposit flow: ensuring that the withdrawal credentials are set correctly before funds are committed.

A protocol-level fix would close the vulnerability at its source and make deposit safety a property of Ethereum itself, rather than a responsibility delegated to each staking product. The existing application-layer defenses work — protocols have been operating safely with them — but each one independently builds, audits, and maintains its own variant of the same defense against the same vulnerability, and the deposit flow evolves across dozens of fragmented implementations rather than in one place. Capital providers using delegated staking face intrinsic risk from node operators on top of the consensus layer's own slashing and penalty rules — preregistration removes one of those risks entirely.

This is a trade-off. Moving complexity from the application layer to the protocol layer means consensus client teams take on implementation and maintenance cost instead of staking protocols. The case for this trade-off rests on three factors: the change is additive (opt-in, no impact on existing validators), the benefit accrues to every current and future delegated staking protocol, and the alternative is continued fragmentation. The consensus-layer changes comprise a new state list with bounded growth, a BLS signature verification step during preregistration processing, a withdrawal credentials check during deposit ingestion, and an epoch-level expiry sweep. The cross-layer delivery mechanism — an EL system contract feeding requests into the CL via EIP-7685 — follows the same pattern established by EIP-7002 (execution-layer triggerable withdrawals) and EIP-7251 (consolidations).

The EIP specification details the full scope of changes: new beacon state fields, modified deposit processing logic, and a new system contract with an anti-spam fee mechanism. Preregistrations expire automatically after ~36 days (262,144 slots of finalized time) and beacon state growth is bounded by a maximum entry count. Under normal operation the list stays near zero, since preregistrations are consumed by matching deposits within hours.

### 2.1 Preregistration

==TODO: link to EIP-XXXX once published==

The root cause is narrow: whoever deposits first for a public key permanently sets the withdrawal credentials, and there is no mechanism for the key holder to make a binding commitment to specific credentials before a deposit is made. Preregistration fills this gap.

**How it works:**

1. The key holder signs a commitment binding a validator public key to specific withdrawal credentials.
2. The commitment is submitted through a dedicated system contract on the execution layer, using the [EIP-7685](https://eips.ethereum.org/EIPS/eip-7685) request framework for cross-layer communication (the same mechanism used by withdrawal and consolidation requests).
3. It is stored in beacon state and provable on-chain via Merkle proof against the beacon block root exposed by [EIP-4788](https://eips.ethereum.org/EIPS/eip-4788) — meaning staking protocols can verify that the preregistration exists before depositing.
4. At deposit processing time, the consensus layer checks that the deposit's withdrawal credentials match the preregistration. Matching deposits proceed and the preregistration is consumed. Mismatched deposits are rejected.

This is not an atomic one-step solution — the preregistration must be submitted before the deposit and become verifiable on-chain before the protocol deposits. But it removes the need for deposit-specific bonds and guardian committees. The operator signs once, the protocol verifies on-chain, and deposits for preregistered public keys with the correct withdrawal credentials are the only ones accepted. Deposits for public keys without a preregistration work exactly as they do today — preregistration introduces the rejection behavior only for keys that have been explicitly preregistered.

**How protocols would use it in practice:**

Preregistration is fully optional — protocols that already have their own defenses can adopt it at their own pace, or not at all. For protocols that do adopt it, the typical flow would be:

1. The node operator generates a BLS keypair and signs a preregistration committing the public key to the protocol's withdrawal credentials.
2. The protocol (or operator) submits the preregistration to the system contract and pays the fee.
3. The protocol waits for the preregistration to be finalized on the consensus layer (~12.8 minutes under normal conditions).
4. The protocol verifies the preregistration on-chain by checking the beacon block root via [EIP-4788](https://eips.ethereum.org/EIPS/eip-4788) — a Merkle proof confirms the preregistration is present in beacon state.
5. The protocol submits the full deposit. The consensus layer enforces the withdrawal credentials match.

Steps 4 and 5 can be handled by a shared verification contract on the execution layer — a contract that validates a preregistration Merkle proof against the [EIP-4788](https://eips.ethereum.org/EIPS/eip-4788) beacon block root and, if valid, forwards the deposit to the Deposit Contract in a single transaction. Any protocol can reuse this contract to make safe initial deposits without building its own verification logic.

==TODO: add reference implementation of the verification contract==

**What happens to rejected deposits?** Mismatched deposits are rejected because front-running should be economically self-defeating: an attacker who deposits with the wrong withdrawal credentials loses their entire deposit. The ETH is not processed by the consensus layer and remains permanently locked in the Deposit Contract, which has no withdrawal function. The risk of accidental mismatch is low in practice — preregistration requires a dedicated signing step, and staking protocols verify the preregistration on-chain before submitting deposits. Preregistrations cannot be overwritten. They expire automatically after ~36 days if unused, freeing beacon state — but because the signed message is publicly visible on-chain, anyone can replay it to re-establish the same binding after expiry. Operators should treat preregistration signing as a permanent, irrevocable decision for that key.

The preregistration signature is permanent and replayable by design. Once signed, the binding between a public key and withdrawal credentials is effectively irrevocable: anyone who holds a copy of the signature can resubmit it at any time to re-establish the on-chain record after it expires. The ~36-day expiry applies only to the on-chain record (freeing beacon state), not to the cryptographic commitment itself. Operators should treat preregistration signing as a one-time, permanent decision per key.

### 2.2 Alternative approaches considered

Several alternative designs were evaluated while developing this proposal. Each offered attractive simplifications but had to be rejected for specific reasons.

**CL gossip distribution.** Instead of an EL system contract, preregistrations could propagate through the consensus layer's peer-to-peer gossip network — similar to how voluntary exits work. This is architecturally clean and would avoid the need for an execution-layer contract entirely. However, it has a fundamental DoS problem. Unlike voluntary exits (which are bounded by the set of active validators), preregistrations can reference any BLS keypair, making the valid message space unbounded. There is no economic cost to submitting a preregistration via gossip, and no way to distinguish spam signatures — for throwaway keypairs that will never be followed by a deposit — from legitimate ones without maintaining additional state. An attacker can flood the network with preregistrations at no cost, degrading gossip performance and bloating beacon state. The EL system contract solves both problems: gas cost plus a dynamic fee (similar to EIP-1559 pricing) that escalates under sustained demand provides the economic barrier, and the fee itself limits throughput.

**Deposit data signature reuse.** Instead of introducing a new signature type, the preregistration could reuse the existing deposit signature. This would offer integration advantages: operators already produce signed deposit data during onboarding, all existing tooling (staking-deposit-cli, web3signer, ethdo) would work without changes, and no new signing ceremony would be needed.

However, this approach assigns new consequences to already-signed messages. Today, an operator can safely sign multiple deposit messages with different withdrawal credentials and even publish them without risk — the worst case is expensive, pointless griefing. Under this approach, any published deposit signature becomes a weapon: if an operator signed deposit data for one set of withdrawal credentials but intended to deposit with different ones, an attacker could use the published signature to preregister — locking the operator out of their own key at the cost of a single transaction fee. This changes backward compatibility assumptions for parties who are currently unaffected by front-running — including exchanges, solo stakers, and others staking their own funds. A dedicated signing domain avoids this issue by keeping preregistration semantics separate from deposit data.

**EIP-7684 — return mismatched deposits.** [EIP-7684](https://eips.ethereum.org/EIPS/eip-7684) addresses a related but distinct problem: when a top-up deposit is sent to an existing validator with different withdrawal credentials than the ones already set, the deposit is silently accepted under current rules, with the funds irrecoverably locked under the existing validator's credentials. EIP-7684 detects such mismatches and queues the deposit for return minus a penalty.

This is a meaningful safety improvement for mismatched top-ups, but it does not prevent the front-running attack on new validator creation. If an operator races ahead and deposits with attacker-controlled credentials, the protocol's subsequent deposit is treated as a top-up to the rogue validator. EIP-7684 returns most of the funds, which is a significant improvement: it turns what is currently a theft-of-funds attack into a griefing attack. But the attack still succeeds in its operational goal — the rogue validator exists, the onboarding attempt fails, and the operator can repeat at will, each time costing the protocol a penalty and an onboarding disruption. Detection, blacklisting, and monitoring infrastructure remain necessary.

Preregistration and EIP-7684 are complementary. Preregistration prevents front-running on new validator creation; EIP-7684 provides a safety net for mismatched top-ups to existing validators. The two cover different scenarios and could ship in the same fork.

---

The deposit front-running vulnerability is narrow but structural: every affected protocol can and does defend against it, but each pays the cost of doing so independently and in a fragmented way. Preregistration closes this gap with an additive, opt-in protocol change — making deposit safety a property of Ethereum rather than a per-protocol responsibility.