Skip to main content
Version: next 🚧

Exit a DV

Introduction​

Users looking to exit staking entirely and withdraw their full balance back have two options:

  1. Exit via Withdrawal Address (Recommended for Post-Pectra): If your cluster's withdrawal address is an EOA or OVM, you can trigger an EL exit directly from the Launchpad without needing validator keys or operator coordination. This is the simplest method and is described in the Exit via Withdrawal Address section below.
  2. Exit via Validator Keys (Traditional Method): This method requires signing and broadcasting a "voluntary exit" message with validator keys. In the case of a DV, Charon nodes need to broadcast a partial exit to the other nodes of the cluster. Once a threshold of partial exits has been received by any node, the full voluntary exit will be sent to the beacon chain. This process will take 27 hours or longer depending on the current length of the exit queue. Once the validator is exited, the principal plus unclaimed rewards will go to the withdrawal address of the validator. Depending on the cluster's withdrawal configuration, users can claim their proportion of principal and rewards.

For the traditional validator key-based method, there are two ways to sign the partial exit and broadcast the full exit. Neither solution requires gas:

  1. Using Charon's exit solution - It is an Obol hosted solution which is facilitated by Obol APIs. It provides several benefits such as signing partial exits for multiple validators at once, live monitoring of partial exits status via Launchpad and ability to download partial exits and broadcast them later as required. Users don't have to worry about the intricacies of validator clients. Charon Exit abstracts all the complexity.
  2. Using the Validator Clients directly - Users can also directly use the validator client that is connected to your Charon client to submit partial exits, as the client only signs a partial exit message using its share of the private key. Charon will combine the partial exit messages from the other operators. Once the threshold is reached, they are submitted to the beacon node. All of this is usually wrapped under a single command and hence users cannot download full exit signatures for broadcasting it later. In this case, users cannot use Launchpad to monitor exit status and will have to use Grafana to query the partial exit status.
info

For the traditional validator key-based exit method:

  • A threshold of operators need to run the exit command for the exit to succeed. This is the same threshold as is specified during cluster creation.
  • Ensure that all operators within a cluster consistently use either the hosted solution (Charon Exit) or the non-hosted solution (Validator Client Exit). Mixing both solutions within the same cluster—where some operators use Charon Exit while others use Validator Client Exit—is not allowed.
  • In case of validator client native exits, partial exits can be broadcast by any validator client as long as the threshold for the cluster is reached.
  • If a Charon client restarts after the exit command is run but before the threshold is reached, it will lose the partial exits it has received from the other nodes. If all Charon clients restart and thus all partial exits are lost before the required threshold of exit messages are received, operators will have to rebroadcast their partial exit messages.
  • All operators need to use the same EXIT_EPOCH for the exit to be successful. Assuming you want to exit as soon as possible, the default epochs included in the below commands should be sufficient for the respective network.

Exit via Withdrawal Address (Post-Pectra)​

Post-Pectra fork, withdrawal addresses of validators can trigger an EL (Execution Layer) exit directly. This method allows the withdrawal address (EOA or OVM) to initiate exits without requiring validator keys or coordination between operators. This is an alternative to the validator key-based exit methods described below.

info

When to use this method: If your cluster's withdrawal address is an EOA or OVM, you can use this simpler method to exit validators directly from the Launchpad, without needing to coordinate with other operators or use validator keys.

How to Trigger an EL Exit​

In the Launchpad, you can initiate an EL exit using the Exit validator button in the actions column of the validators table. To trigger an EL exit, you must meet one of the following conditions:

  • Connected with the withdrawal address: If the withdrawal address is an EOA (Externally Owned Account), you must be connected with that EOA wallet.
  • Have WITHDRAWAL_ROLE: If the withdrawal address of the validator is an OVM, you must have WITHDRAWAL_ROLE in that OVM. Read more about how to assign roles here.

Screenshot of the EL-triggered exit interface on the DV Launchpad.

Step-by-Step Process​

  1. Initiate Exit: Upon clicking the Exit validator button, you can multi-select the active validators you would like to exit. In the example below, there is only one active validator, so only one can be selected for the exit.

Screenshot of the multi-select validator exit interface on the DV Launchpad.

  1. Review and Confirm: You will see a confirmation page showing the validators that will be exited. If you are sending exits via EOA, it will require exiting validators one by one. In the future, we will use EIP-7702 to perform a single-click exit for all validators.

Screenshot of the EL exit confirmation page on the DV Launchpad.

  1. Transaction Submission: Once the exit is submitted, a transaction will be sent with 0 as the withdrawal amount. This signals the beacon chain to exit the validator. Once the transaction is processed, validators will enter the Active Exiting stage.
warning

Important: You must keep the nodes up as validators have only entered the exit queue. Once the exit is processed and there are no more active validators on the node, you can bring the node down.

  1. Exit Completion: After the exit is complete, the total balance will be sent to the OVM after the required on-chain withdrawal sweep has finished. At this point, you can distribute the principal and rewards, which are then claimed via the operator page.

Screenshot of the EL exit completion page showing the validator's final balance.

Screenshot of the EL exit confirmation displaying the validator's exit transaction.

Screenshot of the EL exit completion summary on the DV Launchpad.

danger

🚨 Crucial Warning: You must distribute any existing undistributed rewards before the exit process finishes. If you do not perform this distribution beforehand, the exiting principal amount will be combined with the remaining rewards upon completion. This combined value will then incorrectly exceed the principal distribution threshold, which will cause the rewards to be mistakenly sent to the principal recipient when you initiate the final distribution.

For more information on distribution, see the Distribution guide.

Exit via Validator Keys (Traditional Method)​

The following sections describe the traditional method of exiting validators using validator keys, which requires coordination between operators in the cluster.

Choose the correct combination of:

  1. Network : Mainnet or Hoodi
  2. Exit Type : Hosted (Charon) or Non-hosted (Validator client)
  3. Validator Quantity: Exit single or Exit all validators:

Voluntary exit can be submitted directly through Charon. This approach is validator client agnostic as Charon abstracts validator client's native exit commands underneath.

Step 1: Submit partial exit

Following command signs a partial exit for a specific validator pubkey.

docker exec -it charon-distributed-validator-node-charon-1 /bin/sh -c 'charon exit sign \
--beacon-node-endpoints="http://lighthouse:5052" \
--validator-public-key="<VALIDATOR_PUBLIC_KEY>" \
--exit-epoch=256'

Replace <VALIDATOR_PUBLIC_KEY> with the validator's full pubkey (as visible in Ethereum).

Step 2: Monitor the Partial Exits' status

After a threshold of signed partial exits from node operators in the cluster is accumulated, a full (complete) exit can be created. For example, in the cluster below, only 2 out of 4 clusters have reached the threshold. Operators will have to wait for one more partial exit signature, either from operator 1 or 3 to create a full exit message.

Screenshot: After a threshold of signed partial exits from node operators in the cluster is accumulated, a full (complete) exit can be created. For example, in the cluster below, only 2 out…

Step 3: Broadcast the full exit

Once the partial exit threshold is reached, a full exit can be broadcasted from any of the operators. There are two options to do it, depending on your use-case

  1. Fetch the full exit and broadcast instantaneously (Broadcast directly) - users can choose it for a single validator or all validators in the cluster.
  2. Fetch the full exit and broadcast it later(Fetch & Broadcast later) - users can choose it for a single validator or all validators in the cluster.

Following command fetches full exit and broadcasts it instantaneously for a specific validator.

docker exec -it charon-distributed-validator-node-charon-1 /bin/sh -c 'charon exit broadcast \
--beacon-node-endpoints="http://lighthouse:5052" \
--validator-public-key="<VALIDATOR_PUBLIC_KEY>"'
tip

Once a validator has broadcasted an exit message, it must continue to validate for at least 27 hours or longer. Do not shut off your distributed validator nodes until your validator is fully exited.

Other Charon exit commands​

List exitable validators : The following command lists all validators in the cluster whose status is ACTIVE_ONGOING, i.e. those that can be exited. Add --plaintext to print one public key per line for scripting.

docker exec -it charon-distributed-validator-node-charon-1 /bin/sh -c 'charon exit active-validator-list \
--beacon-node-endpoints="http://lighthouse:5052"'

Delete a submitted partial exit : The following command deletes your partial exit message for a specific validator from the Obol API (use --all instead of --validator-public-key to delete partial exits for all validators). This only applies to the hosted (Charon) solution. It is useful if you signed with a different --exit-epoch than the other operators: since all partial exits must use the same epoch to be aggregated, delete the incorrect partial exit and run charon exit sign again with the correct epoch.

docker exec -it charon-distributed-validator-node-charon-1 /bin/sh -c 'charon exit delete \
--validator-public-key="<VALIDATOR_PUBLIC_KEY>"'

Exit epoch and withdrawable epoch​

The process of a validator exiting from staking takes variable amounts of time, depending on how many others are exiting at the same time.

Immediately upon broadcasting a signed voluntary exit message, the exit epoch and withdrawable epoch values are calculated based off the current epoch number. These values determine exactly when the validator will no longer be required to be online performing validation, and when the validator is eligible for a full withdrawal respectively.

  1. Exit epoch - epoch at which your validator is no longer active, no longer earning rewards, and is no longer subject to slashing rules.
warning

Up until this epoch (while "in the queue") your validator is expected to be online and is held to the same slashing rules as always. Do not turn your DV node off until this epoch is reached.

  1. Withdrawable epoch - epoch at which your validator funds are eligible for a full withdrawal during the next validator sweep. This occurs 256 epochs after the exit epoch, which takes ~27.3 hours.