EIP-8205: Withdrawal credentials preregistration

EIPs
1

Discussion thread for EIP-8205: Withdrawal credentials preregistration

EIP: EIP-8205: Withdrawal credentials preregistration

NOTE: This EIP has been authored mainly by @sjors; I’m just posting it on his behalf as we wanted to make sure that the document is available ASAP and his forum account is fresh.

The problem

In delegated staking, the entity funding a validator and the entity generating the BLS keypair are distinct parties. Due to how Ethereum’s current Consensus Layer logic works, whoever deposits first for a given public key permanently sets the withdrawal credentials — this means that the key holder can front-run the funder’s deposit and divert the ETH to attacker-controlled credentials. This vulnerability was first documented publicly in 2019 and was found in production code before the Beacon Chain launch.

Every affected delegated staking protocol treats this as a critical risk and has independently built application-layer defenses — bond-based pre-deposit schemes, guardian committees, or both. Each defense introduces its own trade-offs: capital locked in pre-deposits, trust in off-chain committees, depositRoot fragility, and per-protocol engineering and audit costs. New entrants are vulnerable by default until they build and audit their own. The companion document covers existing defenses in detail, with a protocol-by-protocol comparison.

The proposal

Preregistration lets a key holder sign a binding commitment to specific withdrawal credentials before any deposit is made. It is submitted via an EIP-7685 system contract on the execution layer and enforced by the consensus layer at deposit processing time: matching deposits proceed, mismatched deposits are rejected. The mechanism is opt-in — deposits for non-preregistered keys work exactly as today.

Worth noting a related EIP: EIP-7684 addresses a distinct scenario: mismatched top-up deposits to existing validators. Without preregistration, EIP-7684 alone turns theft into griefing. Without EIP-7684, preregistration doesn’t protect existing validators from mismatched top-ups. The two are orthogonal and could ship in the same fork.

Links

EDIT LOG:

Apr 15, amended references to EIP to include EIP number and link to EIP-8205: Withdrawal credentials preregistration .

8 Likes
2

Hi everyone,

This is Kenneth :slightly_smiling_face: I noticed EIP-8205 during the recent Lido community call. The proposal makes use of BLS signatures for the preregistration commitment (binding a validator pubkey to specific withdrawal credentials).

Given Ethereum’s active work on post-quantum cryptography (PQC), leanEthereum, I’m wondering whether there are any ongoing discussions or plans to replace (or make optional) the BLS signature in this mechanism with a PQC-resistant alternative? What signature schemes are you currently considering or exploring for this?

Thanks in advance!

2 Likes
3

Hi Kenneth,

Thanks for raising this – it’s a fair question to ask of any new EIP that adds a signature.

The short answer: the BLS signature in EIP-8205 isn’t a new cryptographic primitive. It follows the exact same pattern as every other validator-key operation on the consensus layer – attestations, block proposals, voluntary exits, BLS-to-execution-credential changes, sync committee messages, and the deposit message itself. Structurally it’s just another signed CL message with a dedicated domain.

So for a future PQC migration: whatever path is chosen for those existing operations, preregistration inherits it for free. There’s no extra surface area to migrate – when Ethereum migrates the validator-signing layer to PQC as part of leanEthereum, this EIP migrates with it the same way voluntary exits, WC rotations, and attestations would.

5 Likes
4

Recent recordings of EIP-8205 overviews:

5 Likes
5

This problem has been bothering me for more than three years, since I first worked on Lido V2.

Back then, when I learned how Lido handles predeposits and protects itself from a node operator potentially stealing the deposited ETH, I remember thinking there had to be a better way.

I kept coming back to this problem over the years and tried to solve it myself. I had a few ideas, but every one of them introduced a different tradeoff, whether it was permissioning, requiring ETH to be deposited in advance, or making the system less capital efficient.

That’s why I think EIP 8205 is important.

It solves a problem I’ve wanted to see solved for years, but more importantly, it solves it at the right layer. Liquid staking protocols shouldn’t need additional trust assumptions or workarounds for something the consensus layer can give them a clean primitive for.

These protocols secure a significant part of Ethereum, and anything that lets us reduce their complexity and attack surface is worth taking seriously.

I really believe EIP 8205 is a meaningful security improvement, and I hope people here will support it.

Like I love to say, it just works.

6 Likes
6

Hey! MixBytes team here! We fully support the proposal.

Some context for why we care: back in February 2022 we did the first audit of Lido’s Deposit Security Module. That construction works, but it costs a guardian committee, an off-chain daemon, and deposit-root tracking logic in the contract - a lot of moving parts and a lot of trust for what is, at its core, a missing binding at the base layer. Since then every serious delegated staking product has built its own version of the same defense - bonds, guardians, or both. Each one is designed, audited, and maintained separately, and anyone new to the space is vulnerable by default until they do the same work. That is the actual cost of leaving this at the application layer, and it is not getting cheaper as the number of withdrawal credentials per protocol grows.

Preregistration replaces all of that with one check at deposit processing time, and reuses the EIP-7002/7251 request pattern rather than inventing a new one. Nothing changes for solo stakers, top-ups, or existing validators. We think this is the right shape for a fix at this layer.

Three things we would flag.

Stranded ETH: A deposit that conflicts with an active preregistration is rejected and the ETH stays in the deposit contract forever. Incorrectly signed deposits are already treated this way on the consensus layer side (via check in is_valid_deposit_signature which is invoked if validator pubkey hasn’t been seen yet), and we agree with the reasoning - refunding mismatched deposits would make front-running attempt free to retry (but operationally costly for protocol), so permanent loss is what makes the attack self-defeating. What changes is how much data a protocol has to get right: today the deposit data, under EIP-8205 the deposit data plus a preregistration signed earlier. Same class of consequence protocols already engineer around, applied to one more input - but it means preregistration generation deserves the same rigor as deposit data generation.

The guardian model stops covering the threat model: This lands on exactly the construction we audited. DSM’s detection surface is the deposit root: guardians watch for a competing deposit that would front-run Lido’s. Preregistration moves the decisive action off that surface. A Node Operator holds the validator private key, so nothing stops them from preregistering their own pubkey against their own withdrawal credentials before handing deposit data to the protocol. No deposit happens, so guardians see nothing. The protocol’s later 32 ETH deposit then mismatches and is silently rejected - stranded permanently, no recourse, no revocation.

This is griefing rather than theft - the operator burns the protocol’s ETH but cannot redirect the stake - so it is weaker than the attack preregistration closes. Adding preregistration alongside an unchanged DSM leaves a hole neither layer watches, and a guardian-model protocol that skips preregistration entirely is exposed to it with no defense at all. The research paper accompanying the EIP notes there are not many such protocols today, but they will need to pay attention and switch. The fix is what the EIP already prescribes: verify via EIP-4788 atomically with the deposit.

Two smaller integration notes: That atomic EIP-4788 check must also require the current slot to be below the proven expiry_slot, in the same transaction. An expired preregistration stays in beacon state until the epoch-boundary sweep, so it remains provable after the consensus layer has stopped enforcing it - a presence-only check passes in that window while the deposit is no longer protected. The EIP says this; we would just underline it as a MUST, since a partially-correct implementation looks identical to a correct one until someone races it.

The other is queue stuffing. The contract does not bound how many requests it accepts per block - MAX_PREREGISTRATION_REQUESTS_PER_BLOCK = 4 caps the dequeue rate, not admission - and every submission in a block pays the fee computed from the excess persisted before that block, so the fee does not rise within the block. An attacker can stuff hundreds of requests into one block at roughly gas cost, producing a FIFO backlog hundreds of blocks deep in which nobody can pay for priority. This is inherited from EIP-7002 and an accepted tradeoff, not an argument against the EIP, but a protocol that assumes its preregistration lands within a few blocks may be caught off-guard - the ~36-day window absorbs this only if the protocol is built to wait.

Overall - the vulnerability class is old and has been handled by application-layer workarounds for years because there was no alternative. Closing it at the base layer removes trust assumptions and maintenance burden from every involved protocol at once, and lowers the bar for new entrants to be safe by default.

Again, we totally support it.

4 Likes
7

Hey, etherfi team here :slight_smile:

We support EIP-8205.

we currently use a protected multi-step validator onboarding flow: an initial deposit establishes the validator, followed by verification of the intended withdrawal credentials before we fund the remaining balance. This is necessary because the current first-deposit-wins model leaves protocols exposed to validator deposit front-running.

EIP-8205 gives Ethereum a clean native primitive for the property we need: binding a validator pubkey to its intended withdrawal credentials before funding. With an atomic proof of an active, unexpired preregistration at deposit time, it can reduce custom protection logic, avoid capital being tied up in pre-deposits and the entry queue, and make operator onboarding simpler and safer.

We believe this is the right problem to solve at the protocol layer and support its inclusion in Hegota

1 Like
8

Hi everyone, adding Kelp’s support for EIP-8205.

This is timely for our validator infrastructure work. In the funding flow we’ve been designing, withdrawal-credential protection requires a protocol-funded bootstrap deposit, an off-chain credential check, and approval before the remaining funding. That flow brings its own contract states, operational handoffs, and recovery procedures.

Having a standard way to verify the credential binding before depositing stake would let us simplify that design. Beyond the capital and queue benefits already mentioned, we see value in reducing how much security-sensitive infrastructure each staking protocol has to build, audit, and maintain independently.

We also agree with MixBytes on the integration requirements: our deposit path would need to verify the intended binding and its expiry atomically with funding, and account for delays in preregistration processing.

We support considering EIP-8205 for inclusion in Hegotá. Thanks to the authors for moving this forward.

1 Like
9

Hi, FP Validated (Four Pillars’ validator brand) team here :slight_smile:

As an institutional staking infrastructure and solutions provider, we support the direction of EIP-8205.

In delegated staking, the separation between capital providers and operators controlling validator keys creates a clear trust boundary, yet the Ethereum protocol currently offers no way for capital providers to ensure that their intended withdrawal credentials will be honored before the first deposit.

To address this risk, staking protocols and service providers have had to develop their own safeguards, including pre-deposit bonds, guardian committees, and deposit monitoring systems. While these mechanisms have worked, they introduce additional complexity, operational overhead, and application-specific security assumptions that become increasingly difficult to manage as operator sets and staking architectures expand.

By moving this protection into the protocol, EIP-8205 can establish a common security foundation for delegated staking while preserving the existing flow for validators that do not require preregistration.

We appreciate the authors for putting forward this proposal, and FP Validated has also covered it through our research platform, whose core audience includes Korean institutions, to help bring greater visibility to this important discussion.

Monthly EIP - Apr 2026 (ft. Staked Assets at Work, The Prepared Win)