Ethereum validators run on two keys. An active BLS key signs the duties that keep the validator running, and a separate withdrawal credential records who ultimately controls the staked ether. EIP-7002, titled “Execution layer triggerable withdrawals,” gives that second credential a direct path to start an exit. The change matters most when the two keys are held by different parties.
The hostage problem it addresses
Before EIP-7002, only the active key could initiate a validator exit. An owner who kept the withdrawal credential but outsourced operation to a staking provider could end up needing the operator’s cooperation just to begin leaving. The proposal’s motivation names two risks: ether being “held hostage” by the active-key holder, and the difficulty of recovery when active keys are lost. The fix is a second initiation path that runs through the execution-layer (0x01) withdrawal credential instead of the hot signing key.
What a request contains
The mechanism is a predeployed system contract that accepts a 56-byte input: a 48-byte validator public key plus a uint64 amount. The public key is required because many validators can share one withdrawal credential, so an address alone would not say which validator is leaving. The contract records its caller, and the specification states that the calling address must match the 0x01 withdrawal credential recorded in beacon state. Paying gas while naming someone else’s validator does not transfer authority.
Submission, exit, and payment are separate steps
A request passes through distinct stages: execution admission into a queue, dequeueing into a block, consensus processing, and finally a withdrawal. The consensus sketch says handling a request “can fail validations (e.g. validator is already exited) without the block failing.” A transaction receipt can therefore show success while the validator transition never occurs, and neither outcome confirms that ether has arrived.
Two fees and a no-refund rule
Ordinary transaction gas and the request fee are separate costs. The fee moves with demand, and the specification warns that “overpaid fees are not returned to the caller.” Because the fee can change between composing a transaction and its inclusion, a quote shown earlier may not match the fee applied on execution. The queue is bounded: at most 16 requests are dequeued into a block, while a target of 2 per block drives the fee mechanism. These figures cap processing load and make griefing expensive; they are not promises about how many exits or payments complete per block.
What it does and does not change
For a solo staker who controls a matching withdrawal credential, EIP-7002 removes the exclusive dependence on an operator’s cooperation. For a contract-controlled credential, the contract’s own authorization logic decides whether a call can happen, so smart-wallet permissions and upgrade controls still matter. For a holder of a pooled staking receipt, the credential controller is usually the pool or custodian rather than the token holder, and the protocol path does not override a product’s redemption terms. Reading request, exit, and receipt as separate events is the practical takeaway.
Adapted from Ethereum Validator Exits: How EIP-7002 Withdrawal Requests Work.