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 .

6 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!

1 Like
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.

2 Likes
4

Recent recordings of EIP-8205 overviews:

1 Like