Switching from Prysm to Teku, etc.
Quick Steps
To switch from one Consensus Client to another (for example, from Prysm to Teku, or vice versa), follow these steps:
Make sure you have the keystore or backup files.
Stop the validators, or remove the existing Consensus Client entirely.
Install and sync the target Consensus Client.
Allow a minimum of 5 epochs to pass between stopping the existing validators (Step 2) and re-loading them into the new Consensus Client (Step 5).
Restore your validators into the new Consensus Client.
The following paragraphs provide detailed information about each step.
What does this mean?
If you wish to change the Consensus Client you are using, such as switching from Prysm to Teku, or from Teku to Nimbus, or vice versa, you will need to remove the validator keys from the existing Consensus Client, install and sync the new Client, and re-load the validator keys into the new Client.
Other Scenarios
Changing AVADO machine, or upgrading the disk. For example, you may have a replacement AVADO machine, or a 4 TB disk upgrade for the i7. To "move" the validators to the new hardware, you will remove the existing validators from the old machine or disk, install and sync the new ETH Clients on the new hardware, and re-load the validator keys into the new Consensus Client. The process is essentially the same as what is described on this page.
Switching Execution Client. Note that if you are only switching the Execution Client, e.g. from Geth to Nethermind or vice versa, you do not need to "move" any validators. Just remember to change the Execution Engine setting in the Consensus Client DApp.
Physically moving the AVADO from one location to another. If you are simply relocating your AVADO from one location to another, for example when you're moving home, you do not actually need to "move" any validators. Just shut down the AVADO at its current location using the System > Shutdown option. Then, plug in the machine at the new location, and it will pick up where it left off.
Step 1. Make sure your have the keystore or backup files
Solo Stakers
For Solo Stakers, ensure that you have access to your validator keystore files and their passwords. The keystore files were generated during the Key Generation process using a tool like the Wagyu Key Gen software. A set of output looks like this:
You should have one keystore file (keystore-xxxxxx.json) for each and every solo validator you have. You can open up the keystore file(s) with a text editor and check the pubkey; this should match with one of your validators.
The mnemonic.txt and password.txt files (if available) contains, respectively, the 24-word secret recovery phrase, and the password for the keystore file(s). In any case, you should have written down and kept these secrets very safe from the time your created them.
You will need to use the keystore files and their associated password(s) to re-load the validators.
If you have lost the keystore files, or have forgotten the password(s), don't worry! You can always regenerate them from the 24-word mnemonic, using a tool like Wagyu Key Gen. See Re-generate or Generate More Keys section for detailed instructions.
Download a copy of your staking keys from Teku
The newer versions of AVADO Teku package (since version 0.0.47) offer a feature to download a backup of your staking keys. On the Main page of the DApp, click Download backup of my staking keys to create a backup file containing all the necessary information for restoring your validators if needed.
Rocketpool Stakers
For Rocketpool Stakers, ensure you have a fresh backup of your settings. This can be obtained through the Rocketpool DApp. The rocket-pool-backup.zip file contains all the information required to restore your Rocketpool nodes and minipools. Make sure your backup is up-to-date.
Go to the Setup tab in the DApp and press the button Download Rocker Pool Data Backup. Refer to the Backup and Restore section for more detailed instructions.
Having a Backup File serves as a precautionary measure in case things don't go as planned during the transition process. However, if you are only switching the Consensus Client and everything goes smoothly, the Rocketpool DApp will automatically prompt you to re-load the validators into the new Consensus Client. In this scenario, you won't actually need to use the Backup File.
Stader Stakers
For Stader Stakers, ensure you have a fresh backup of your settings. This can be obtained through the Stader DApp. Navigate to the Admin tab in the DApp and click the Download Backup button to obtain the backup file.
Take note of how many keys you have
Regardless of whether you are a Solo Staker, Rocketpool Staker, or Stader Staker, it is recommended to take a picture or a screenshot of your Consensus Client. This will allow you to compare the data later on with the information on your newly installed Consensus Client.
Step 2. Shut down the existing validators
Before you load your validators to another Consensus Client, you must shut down your existing validators. There are two ways to do this:
Remove the validator from the Consensus Client dashboard. This can be done by clicking the Trash icon at the right-hand side of the validator line. By removing the validator in this way, your existing Consensus Client will "forget" about this validator and will not perform any duties assigned to it. Your validator still exists on the Beacon Chain, but it won't be attesting because it is no longer serviced by your Consensus Client. There is no need to "exit" from the Beacon Chain. Repeat for multiple validators.
Remove the Consensus Client. If you do not plan on using the existing Consensus Client anymore, a more thorough option is to remove the DApp (Teku, Prysm or Nimbus) entirely. This ensures that all validator keys are deleted from the existing instance of the Consensus Client and will no longer be validating. To remove the Consensus Client, go to its Management Page and click on the Remove button.
Either way, you can verify that your validator(s) have stopped functioning by checking the beaconcha.in website. After waiting a couple of epochs, beaconcha.in will start to indicate that your validator(s) are missing attestations and you will incur small penalties each epoch. This confirms that your validator(s) are no longer functioning.
Step 3. Set up the target Consensus Client
Proceed to install and sync the new chosen Consensus Client on your AVADO. For detailed instructions on how to do this, refer to the instructions in the Setting up the ETH Clients section (especially: Step 2, Step 3, and Step 4).
Setting up and syncing the Consensus Client will typically take only a few minutes to no more than an hour.
Remember to configure the Default Fee Recipient Address and the Execution Engine settings.
Rocketpool users need to change the CONSENSUSCLIENT variable on the Management Page of the Rocketpool DApp. See here for instructions.
There is no need to change anything on the Execution Client (Geth or Nethermind). In case the Execution Client does not sync in tandem with the new Consensus Client, a simple Restart may be all that is needed to get it to work.
Step 4. Allow a minimum of 5 epochs to pass
Beware of slashing risk
Always ensure that there is a time gap between removing the existing Consensus Client (or its validator keys) and loading those keys into the new Consensus Client.
Wait for a minimum of 5 finalized epochs before importing the keys. Given the current network conditions, this waiting period amounts to approximately 30 minutes. To err on the side of caution and ensure absolute safety, we recommend waiting for 10 finalized epochs. This precaution is necessary to prevent the risk of slashing due to premature activation.
It is important to allow a minimum of 5 epochs to pass before proceeding with the transition process.
This is especially crucial if you're switching Consensus Clients, as the new Consensus Client can sync and go live in as quickly as a few minutes. Be sure to allow sufficient time between stopping the validators in the old Consensus Client and loading the keys in to the target one. This precaution is necessary to prevent the risk of slashing due to premature activation.
Step 5. Restore your validators
Once the target node is fully synced, and you have confirmed that your existing validator(s) have stopped validating for at least 5 epochs, you can proceed to restore your validators.
For Solo Stakers: Import the validator keystore files into your Consensus Client. See Import Validator Keys section for details.
For Rocketpool Stakers: Open the AVADO Rocketpool DApp. Provided you have set the
CONSENSUSCLIENTvariable correctly, Rocketpool will detect that it has configured minipools without their corresponding validators loaded into the Consensus Client. You will see the prompts similar to the process of Adding a Minipool (Step 4 and Step 5). Follow the prompts and your validators will be automatically restored.Stader Stakers: Use the Admin panel to restore the backup you created earlier. This should bring back your validators, and you will also find an import validator button to add the validator keys back into your Consensus Client.
After restoring the validators, perform a final check by comparing the validator list with the screenshot you took before the transition. If the lists match, you are ready to proceed without any issues.
Last updated
