Withdrawal Credentials Preregistration

Yes — and the attacker already has it. The attacker in this threat model is not a stranger. It is a malicious node operator. In delegated staking, the operator holds the validator key, and a staking protocol or a delegator supplies the ETH.

The attack is simple:

• The operator deposits first. A small deposit with the operator’s own withdrawal credentials registers the key.
• The protocol’s deposit becomes a top-up. It adds funds to the attacker’s validator. A top-up cannot change the withdrawal credentials.

EIP-8205 protects the funding party from the key holder. An outsider without the key cannot run this attack at all: a deposit that creates a validator needs a valid signature from that key.

Preregistration is for setups where one party holds the funds and another party holds the validator key. Everyone else can ignore it:

• Existing validators are safe. A preregistration cannot change the withdrawal credentials of an existing validator. A key that already has a validator cannot be preregistered at all.
• Current flows do not change. Keys without an active preregistration follow today’s rules. Top-ups, withdrawals, solo stakers, exchanges, and institutions that hold both funds and keys are unaffected.
• Protocols with existing defenses adopt at their own pace. Bond-based flows keep working, and adoption removes the verification delay and the locked bond. Guardian flows that approve depositRoot snapshots need one update to their deposit flow — in return, the protocol-level guarantee replaces the committee and its liveness dependency.
• It is not a registry. Preregistration is not a whitelist and not an identity layer. Submission is permissionless, and the record grants no rights. It only constrains future deposits for one key, because the key holder signed that constraint.

The key holder commits to specific withdrawal credentials before any deposit, and the consensus layer enforces that commitment.

The flow has three steps:

1. Sign. The operator signs a message that binds the validator pubkey to specific withdrawal credentials, and hands it to the delegator together with the deposit data.
2. Submit. The delegator sends the signed request to the system contract. The record becomes active once the consensus layer processes the request, usually within a few blocks, and stays active until a matching deposit consumes it or it expires after about 36 days.
3. Verify and deposit. The delegator proves the record and its expiry from beacon state through EIP-4788, checks the current slot through EIP-7843, and deposits in the same transaction. If the proof is missing, wrong, or expired, the transaction reverts before the ETH moves.

While the record is active, the consensus layer accepts a deposit for that key only if the credentials match and the deposit signature is valid. An active record also proves that nobody front-ran the delegator: the key has no validator and no valid pending deposit yet.

Yes. The consensus layer silently rejects a deposit that conflicts with an active preregistration. The ETH stays in the Deposit Contract, which has no withdrawal function.

This is not a new kind of loss. A deposit that creates a validator must already be valid today: if its BLS signature is invalid, the consensus layer ignores the deposit, and the ETH is unrecoverable. EIP-8205 adds one more validity condition: while a preregistration is active for the key, the withdrawal credentials must match it.

The scope is narrow. The rejection can only hit a deposit for a key that has an active preregistration with different credentials. In practice, that is the attacker’s own deposit, or a flow that skipped verification. In the intended integration, verification and deposit run in one transaction, so a mismatch reverts before the ETH moves. Deposits for keys without a preregistration never see this rule.

Because only the consensus layer can give the needed guarantee: “no deposit for this key can set different withdrawal credentials.” The consensus layer decides which deposits take effect. Applications can only approximate this rule in two ways:

• A bond. The operator deposits a small amount first. The protocol waits until the validator record appears in beacon state, proves its withdrawal credentials on-chain, and only then sends the rest as a top-up. Capital sits locked while the entry queue clears.
• A guardian committee. A trusted committee checks a snapshot of all deposits (the Deposit Contract’s depositRoot) and approves the batch only if no hostile deposit is inside. The approval is bound to that exact snapshot: any new deposit changes the root and invalidates it. This adds a trusted party and a liveness dependency.

Both are workarounds with real downsides: locked capital and waiting in one case, a trusted committee and fragile approvals in the other. And each protocol builds, audits, and maintains its own copy. EIP-8205 replaces these workarounds with one universal rule inside the deposit flow: no bond, no committee, no waiting. The rule knows nothing about protocols or operators, only about one key and its credentials.

Anyone who stakes ETH with a validator key that someone else holds, and wants that stake protected on-chain: staking protocols, institutions, and individual delegators.

• Established protocols replace their bonds and guardian committees with one protocol rule.
• New protocols start protected from day one. Today a new entrant is vulnerable by default until it builds its own defense.
• Institutions and individual delegators get the guarantee from Ethereum itself, not from an operator’s promise.

Nothing in it is protocol-specific: no allowlist, no privileged caller, no operator registry. A BLS signature from the validator key is the only authorization.

The race can still happen, but it no longer decides who controls the ETH:

• The delegator deposits only after the record is active. The deposit transaction includes a proof that the record is in beacon state, and it reverts if the proof fails. Once the record is active, there is nothing left to front-run.
• A faster attacker only burns the key, never wins the ETH. The operator can still send its own deposit before the preregistration becomes active. Then the consensus layer never stores the record: a key with a pending deposit cannot be preregistered. The delegator sees no active record for that key, does not deposit, and loses nothing.

So a malicious operator can only block its own keys. Blocking gains the operator nothing: an operator earns from running validators, and a blocked key simply never receives the deposit.

The EIP looks big at first glance, but most of its length is boilerplate for the EL → CL request bus, not new logic:

• On the execution layer, it is a familiar pattern. One more system contract like EIP-7002, EIP-7251, and EIP-8282, copied with small changes: the same queue, the same fee, the same system call.
• The consensus-layer changes are fairly simple. One extra check when processing deposits, and a capped store of preregistrations in beacon state that expires on its own.
• The added load is small and bounded. A payload (the execution part of each block) carries at most four preregistration requests: up to 704 bytes of data and four signature checks, and a gas limit increase does not raise that cap.

The trade-off: one shared implementation in clients, or every delegated-staking protocol building and auditing its own bonds, proofs, guardians, and monitoring for the same credentials check.

Anyone can relay a signed request. Nobody can author one without the key.

• The signature is the authorization. The consensus layer stores a request only if it carries a valid BLS signature from the validator key.
• The contract is only a queue. It checks the fee and the input length, nothing more. The consensus layer discards invalid signatures later, and the fee is not refunded.
• Existing validators cannot be targeted. A key that already has a validator, or a valid pending deposit, cannot be preregistered.

Submission is permissionless, but the parameters are set so that spam does not pay:

• The fee is a rate limiter. It starts at 1 wei and grows exponentially while demand stays above the target of one request per block. Transaction gas is separate. The fee changes only in the next block, so one block can create a backlog, but the consensus layer admits at most four requests per payload.
• State is bounded. Active records expire after about 36 days and are capped at 524,288 — about 46 MB at that limit. To reach the cap, an attacker needs a sustained above-target rate, and therefore an exponentially growing fee.
• What the fee does not prevent. At exactly the target rate, the fee stays minimal, and an attacker can hold roughly 2**18 records — about 23 MB before client overhead. The fee limits the rate. It does not promise cheap or immediate inclusion.

No. A preregistration carries no ETH, creates no validator, and consumes no activation churn.

• It uses a separate, rate-limited request queue. That queue only checks and stores the signed binding.
• After the binding is provable, the delegator sends one normal deposit. That deposit follows the existing pending-deposit and activation flow.

This avoids the pre-deposit pattern, where a protocol must lock a small deposit, wait, verify, and only then send the rest of the stake.

No. The first valid commitment that becomes active wins for the lifetime of that record. It cannot be cancelled, overwritten, or refreshed.

• A matching valid deposit consumes it.
• Otherwise it expires. After 262,144 slots (about 36 days at today’s 12-second slots), the record becomes inactive, and epoch cleanup removes it.
• The signed message itself never expires. After the record expires, anyone can submit the same message again, as long as the key still has no validator and no valid pending deposit.
• Later signatures do not replace it. If the operator signs a second commitment with different credentials, the first active record still wins. That is why the deposit proof checks the exact credentials, not just that some record exists.

Treat the signature as a permanent commitment. If the operator signed the wrong credentials, the safest option is to abandon that validator key.

The operator signs one pair: the validator pubkey and the withdrawal credentials. The signature uses a dedicated BLS domain with two properties:

• Fork-agnostic. The domain uses the genesis fork version. The operator can sign on air-gapped hardware without knowing the current fork.
• Chain-separated. The domain includes genesis_validators_root, so a mainnet signature is useless on any testnet.

A deposit signature cannot serve this purpose. It also binds an amount, its domain is replayable across chains, and reuse would retroactively give old deposit signatures a new meaning. Any setup that signs deposits today, including DVT threshold signing, can produce this signature the same way.