Discussion thread for EIP-XXXX: 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
-
EIP: ethereum/EIPs#XXXX
-
Companion document: The Deposit Front-Running Problem in Delegated Staking — covers the problem scope, how existing protocols defend today, why application-layer defenses alone are insufficient, the trade-offs each approach introduces, and alternative designs that were considered
-
Original vulnerability discussion: Deposit contract exploit (ethresear.ch, 2019)