Exit a DV
Users looking to exit staking entirely and withdraw their full balance back must also sign and broadcast a "voluntary exit" message with validator keys which will start the process of exiting from staking. This is done with your validator client and submitted to your beacon node, and does not require gas. In the case of a DV, each charon node needs 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.
- A threshold of operators needs to run the exit command for the exit to succeed.
- 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.
voluntary-exit command on your validator client
Run the appropriate command on your validator client to broadcast an exit message from your validator client to its upstream charon client.
It needs to be the validator client that is connected to your charon client taking part in the DV, as you are only signing a partial exit message, with a partial private key share, which your charon client will combine with the other partial exit messages from the other operators.
- All operators need to use the same
EXIT_EPOCHfor the exit to be successful. Assuming you want to exit as soon as possible, the default epoch of
162304included in the below commands should be sufficient.
- Partial exits can be broadcasted by any validator client as long as the sum reaches the threshold for the cluster.
docker exec -ti charon-distributed-validator-node-teku-1 /opt/teku/bin/teku voluntary-exit \
/home/user/data/charonto the newly created
For each file in the
nimbus_beacon_nodewith the following arguments:
deposits exit: Exits validators
$command: The generated command string from the loop.
--epoch=162304: The epoch upon which to submit the voluntary exit.
--rest-url=http://charon:3600/: Specifies the Charon
--data-dir=/home/user/charon/: Specifies the
Keystore pathwhich has all the validator keys. There will be a
validatorsfolder inside it.
docker exec -it charon-distributed-validator-node-nimbus-1 /bin/bash -c '\
cp -r /home/user/data/charon/ /home/user/data/wd
for file in /home/user/data/wd/secrets/*; do \
filename=$(basename "$file" | cut -d. -f1); \
command+=" --validator=$filename"; \
/home/user/nimbus_beacon_node deposits exit $command --epoch=162304 --rest-url=http://charon:3600/ --data-dir=/home/user/data/wd/'
node /usr/app/packages/cli/bin/lodestar validator voluntary-exitwith the arguments:
--beaconNodes="http://charon:3600": Specifies the Charon
--data-dir=/opt/data: Specifies the folder where the key stores were imported.
--exitEpoch=162304: The epoch upon which to submit the voluntary exit.
--network=goerli: Specifies the network.
--yes: Skips confirmation prompt.
docker exec -it charon-distributed-validator-node-lodestar-1 /bin/sh -c 'node /usr/app/packages/cli/bin/lodestar validator voluntary-exit --beaconNodes="http://charon:3600" --dataDir=/opt/data --exitEpoch=162304 --network=goerli --yes'
Once a threshold of exit signatures has been received by any single charon client, it will craft a valid voluntary exit message and will submit it to the beacon chain for inclusion. You can monitor partial exits stored by each node in the Grafana Dashboard.
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.
- Exit epoch - epoch at which your validator is no longer active, no longer earning rewards, and is no longer subject to slashing rules.caution
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.
- 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.
How to verify a validator exit
Consult the examples below and compare them to your validator's monitoring to verify that exits from each operator in the cluster are being received. This example is a cluster of 4 nodes with 2 validators and threshold of 3 nodes broadcasting exits are needed.
- Operator 1 broadcasts an exit on validator client 1.
- Operator 2 broadcasts an exit on validator client 2.
- Operator 3 broadcasts an exit on validator client 3.
At this point, the threshold of 3 has been reached and the validator exit process will start. The logs will show the following:
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.