Whitebox
Part III · Chapter 41 of 43 · Prague · Electra

EIP-7002: letting the owner, not the operator, exit a validator

After the Merge, only a validator's consensus-layer signing key could trigger its exit — but the person who actually owns the stake often holds an execution-layer withdrawal credential, not that key. So a staking pool couldn't force out a rogue operator, and delegated staking rested on trust. EIP-7002 lets the withdrawal-credential holder trigger an exit from the execution layer.

Updated Jun 24, 2026 · 8 min · An authored explorable
Assumed
  • beacon-chain withdrawals (4895)
  • validators & withdrawal credentials

Prague / Electra, May 2025. EIP-4895 let staked ETH flow out of the consensus layer — but it left a gap in who controls that flow. A validator can only be told to exit by its active signing key on the consensus layer. Yet the party who actually owns the stake is usually whoever holds the validator’s withdrawal credential, which points at an execution-layer address — a staking pool’s contract, a smart account, a custody setup. Those owners could receive withdrawals but couldn’t initiate an exit; they had to rely on the operator running the validator to do it. EIP-7002 closes that gap by letting the execution-layer owner trigger the exit. Let’s derive it.

1 step Only the key can exit

The problem: the owner can’t trigger their own exit

A validator has two keys: an active signing key (on the consensus layer, used to attest and propose) and a withdrawal credential A value in the validator's record naming where its funds go and who controls withdrawals. A 0x01 (or 0x02) credential points at an execution-layer address — a wallet, a staking-pool contract, a smart account — which is the stake's economic owner. naming where the funds go. After the Merge, an exit could be initiated only by the signing key. But in delegated staking — pools like Lido or Rocket Pool, or any smart-contract staker — the operator holds the signing key while the owner holds the withdrawal credential at the execution layer. So the owner could receive a withdrawal but couldn’t trigger one. If a node operator went offline or rogue and refused to exit, the pool had no way to force it and reclaim the stake.

only the validator's signing key could trigger an exit EL owner / pool holds withdrawal creds ✗ can't exit validator (consensus layer) only the signing key exits if the operator won't exit, the pool can't get its stake back the economic owner depends on the operator's key — misplaced trust
A validator exits only when its consensus-layer signing key says so. But the stake's real owner holds an execution-layer withdrawal credential, not that key — so a staking pool couldn't force out a rogue operator, and delegated staking rested on trusting the operator to exit.

→ Step 2: let the EL side ask.

2 step Ask from the EL

EIP-7002: a request the consensus layer processes

EIP-7002 adds a path from the execution layer to the consensus layer. The withdrawal-credential address submits a withdrawal request A request to partially withdraw or fully exit a validator, submitted by its 0x01/0x02 withdrawal-credential address to a predeployed system contract. The consensus layer reads these each block and processes them. to a predeployed system contract (the withdrawal-request contract, at a fixed address). Each block, the consensus layer reads the queued requests from that contract and processes them — as a partial withdrawal or a full exit — provided they come from the validator’s actual withdrawal-credential address. It’s the mirror image of 4895’s push withdrawals, and it reuses the same clean pattern: an execution-layer request goes into a system contract, and the consensus layer acts on it.

let the withdrawal-credential holder ask, from the EL 0x01/0x02 creds submit request withdrawal-request predeploy contract the CL reads it each block → processes the exit same 'EL request → system contract → CL acts' pattern as withdrawals
The withdrawal-credential address (0x01/0x02) submits a request to a predeployed withdrawal-request contract; the consensus layer reads the queue each block and processes the exit or partial withdrawal. It's the same 'EL request → system contract → CL acts' pattern as beacon-chain withdrawals.

→ Step 3: staking you don’t have to trust an operator for.

3 step Trustless staking

The payoff: the owner is in control

With exits triggerable from the execution layer, control follows ownership. A staking pool A contract that pools users' ETH into validators run by operators. With EL-triggerable exits, the pool contract — not the operator — can force a validator to exit, so users' funds aren't hostage to operator behaviour. can now force-exit a validator whose operator has gone rogue or offline, reclaiming the stake without the operator’s cooperation. Smart-account stakers can govern exits with arbitrary execution-layer logic. And it composes with the rest of Pectra’s staking work — raising the balance cap (7251) and smart-account EOAs (7702) — to make staking genuinely programmable and safer to delegate.

now the owner — not the operator — controls the exit trustless staking pools the pool can force-exit a rogue operator smart-account stakers EL logic governs the exit composes with 7251, 7702 staking becomes programmable & trustless from the execution layer part of Pectra's push to make staking safer to delegate
With EL-triggerable exits, the withdrawal-credential owner controls the exit: a staking-pool contract can force out a rogue operator, and smart-account stakers can govern exits with their own logic — composing with EIP-7251 and EIP-7702 to make delegated staking trustless.
04 Go Deeper Where to take it from here

Go deeper