Breakdown of EIP-7002
Introduction
The main idea behind EIP-7002 is to allow validator exits to be triggered by a transaction sent from their withdrawal address (also known as the eth1 address). Currently, the only mechanism to initiate a validator exit requires a message signed by the validator key.
In this post we will look at why we would want a second mechanism to exit our validators and some technical details on how this feature is implemented. This is essentially the written version of the talk I gave at Devcon 7; if you prefer watching, that one covers the same ground.
A tale of two keys
Before we understand why we want to add a second way to exit validators, we need to understand the two keys used when creating a validator: the validator key and the withdrawal key.
The validator key is used for performing validator duties, like signing attestations and blocks. The withdrawal key is used to access your Ethereum rewards (partial withdrawals) or your staked balance (full withdrawal — available when a validator exits). This two-key design separates the ownership of the staked Ether from the node operation, allowing the withdrawal keys (arguably the more important of the two) to be safely stored in cold (offline) storage.
Exiting a validator
Currently, the only way to exit a validator (and make all staked Ether accessible to the owner of the funds) is by signing a Voluntary Exit message with the validator key.
The flow is fairly simple: the validator key signs a SignedVoluntaryExit message, which is sent to a beacon node (typically over the Beacon API). The beacon node gossips it to the network and, eventually, a block proposer includes it in a block. Once processed, the validator is queued for exit.
This design is simple and sufficient for most users. However, there are a few cases in which the funds might end up “locked up” and inaccessible to the owner (at least not when they want them to be).
The simplest one to think of is if the validator key is lost. Without it, the owner of the funds will not be able to sign the Voluntary Exit message. Their only option would be to stop performing their duties until their balance gets low enough that they are “kicked out” from the active validator set. Needless to say this isn’t a great thing as it means burning a large portion of the stake.
Another scenario is when the party running the node (and therefore with access to the validator key) is a different party than the one that owns the funds (has the withdrawal key). In case of disagreement between the parties, the party with the validator key can keep the staked balance “hostage” by refusing to sign a Voluntary Exit message.
A second way to exit
If the problem is that only one type of key can trigger an exit, the simple solution is to allow both keys to do it. Easy, right? Well…
The challenge is that the validator key lives in the Consensus Layer world, and the withdrawal key lives in the Execution Layer world. The Consensus Layer is where validator duties happen and where the exit queue is maintained. The Execution Layer is where regular Ethereum transactions are processed. Asking the Consensus Layer to react to something that happened on the Execution Layer is not as simple as it sounds. We need a way for the EL to tell the CL that an exit was requested, and the CL needs to be able to trust that signal.
A useful way to think about it is to split the problem into two halves:
- Authentication (Execution Layer side): how do we prove that whoever is asking for the exit actually controls the withdrawal address?
- Authorization (Consensus Layer side): how do we prove that this withdrawal address is the one tied to the validator we are trying to exit?
EIP-7002 solves the first half with a smart contract on the Execution Layer, and the second half with a check the Consensus Layer performs while processing the block.
The Withdrawal Request flow
EIP-7002 introduces a new system contract (also known as a predeploy) deployed at a fixed address on the Execution Layer (0x00000961Ef480Eb55e80D19ad83579A64c007002). This contract is part of the protocol; it has no owner and it will be baked into the chain as part of the upcoming Pectra fork.
The contract is purposefully simple. It accepts a transaction with a small payload containing the validator public key (48 bytes) and an amount (8 bytes), and it stores the request in its own state along with the source address (the account that sent the transaction). There is also a fee that must be paid as part of the call, but we will get back to that one in a moment.
Here is how a withdrawal request travels from a transaction all the way to an exited validator:
- The owner of the withdrawal address sends a transaction to the Withdrawal Request contract.
- The transaction is propagated through the Execution Layer network as usual.
- A block proposer picks it up and includes it in a block.
- At the end of the block, the Execution Client reads the pending requests from the contract’s state. This piggy-backs on the mechanism introduced by EIP-7685, which adds a generic way for the Execution Layer to surface “requests” to the Consensus Layer.
- The Execution Client sends the requests to the beacon node over the Engine API, where they are included in the consensus block as part of the execution payload.
- The consensus block is gossiped through the Consensus Layer network.
- Every beacon node processes the consensus block and, for each withdrawal request, performs the authorization check: does the source address match the withdrawal credential of the validator being exited?
If the check passes, the validator is queued for exit. From this point on, the rest of the flow is identical to the Voluntary Exit one.
This check is the whole point of EIP-7002. The withdrawal credentials of a validator with 0x01 (and the upcoming 0x02) prefixed credentials contain an Execution Layer address. Only the owner of that address can produce a transaction whose source matches, and so only the owner of that address can successfully exit the validator this way.
One caveat: EIP-7002 only works for validators with 0x01 or 0x02 withdrawal credentials. Validators that still have the original BLS-based 0x00 credentials need to either use a Voluntary Exit message or upgrade their credentials first.
A fee to prevent spam
If anyone can call the predeploy contract, what stops someone from filling every block with bogus withdrawal requests just to be annoying? This is where the fee comes in.
Each call to the predeploy contract must pay a fee in Ether (in addition to the regular gas cost of the transaction). The fee follows a dynamic mechanism similar to EIP-1559:
- There is a target number of requests per block (2).
- There is a maximum number of requests per block (16).
- If the previous block included more than the target, the fee for the next block goes up. If it included less, the fee goes down.
The minimum fee is 1 Wei, so during quiet periods this is essentially free. But once the contract is at the maximum number of requests per block, the fee roughly doubles every block. Within minutes of sustained spam, the per-request fee climbs from 1 Wei into the ETH range, well past the point of being worth it.
There is a small UX wrinkle worth flagging here: because the authentication and authorization happen at different layers, the Execution Layer has no way to know whether the request you are submitting is actually valid (e.g. that the source address matches an existing validator). The contract will happily accept the transaction, charge you the fee, and store the request. The Consensus Layer will then quietly drop it when it fails the authorization check. You pay the fee either way, so it is worth double-checking the validator public key before submitting.
More than exits: partial withdrawals
Remember the amount field we glossed over earlier? That field is what lets EIP-7002 do more than just trigger full exits.
If the amount is set to zero, the request is treated as a full exit: the validator is added to the exit queue and its entire balance is eventually swept to the withdrawal address.
If the amount is greater than zero, the request is treated as a partial withdrawal. The validator stays active, and the specified amount is sent to the withdrawal address. This becomes much more interesting once we combine it with EIP-7251, which introduced 0x02 (compounding) validators and raised the maximum effective balance to 2,048 ETH. Without partial withdrawals through the Execution Layer, the only way to take any balance out of a compounding validator would be to exit it entirely.
EIP-7002, then, is not just about exits. It is about giving the owner of the withdrawal address full control over the staked funds, exits and partial withdrawals alike, without ever needing the validator key.
Does this replace Voluntary Exits?
Short answer: no.
The Voluntary Exit message is still the simplest and cheapest way to exit a validator. It is a single signed message; no gas, no Execution Layer fee, no new contract. For solo stakers who control both keys, there is no reason to change anything.
Think of EIP-7002 as a second path that sits alongside the existing one. It is the path for everyone who, for whatever reason, cannot or does not want to use the validator key to exit. That includes:
- Stakers who lost their validator key but still hold the withdrawal key.
- Staking pools and custodial services, where the operator and the funds owner are different parties.
- Smart contract-based staking products that want to expose exits as an on-chain action.
- Validators with
0x02credentials that need to withdraw a partial balance.
Both mechanisms now coexist, and validators are exited the same way regardless of which one was used.
Conclusion
EIP-7002 sounds like a small change but does a lot of work. By moving exit-triggering into the Execution Layer, it closes a gap that has been there since the Beacon Chain went live: the withdrawal key, which arguably has the strongest claim on the staked funds, will finally be able to use them.
The whole feature rests on splitting authentication (handled by the Execution Layer via a predeploy contract) from authorization (handled by the Consensus Layer by checking withdrawal credentials), and gluing the two together with the generic request mechanism from EIP-7685. The result is a clean addition to the protocol that does not interfere with the existing Voluntary Exit flow.
If you are running a validator, two things change for you. First, your withdrawal key just got more powerful, so treat it accordingly. Second, if you ever lose access to your validator key, you are no longer stuck waiting to be kicked out of the active set. You have a way out.