Skip to main content

Switch to a new client

This document provides guidance on moving from Prysm to a new consensus-layer client like Teku, Lighthouse, or Nimbus.

Slashing Prevention

The following best practices will help minimize the risk of slashing while migrating between clients:

  1. Never run more than a single validator process with the same keys loaded.
  2. Maintain and utilize slashing protection.
  3. Accept downtime as part of a successful migration.

Step 1: Sync the beacon node​

Regardless of which client you are switching to, the first step of the process will be to sync the beacon node. This may take some time to complete. Some clients offer a feature known as "checkpoint sync" which allows you to sync a node within a few minutes. Without this, the process may take several hours to a few days.

Installation documentation links for each client can be found below:

Step 2: Stop and Disable Prysm​

Ensuring you stop and disable Prysm is critical to avoiding slashing events before proceeding further.

Disabling Prysm prevents it from automatically starting up again after a reboot.

Remove Prysm's validator keys as an added protection by following these instructions.

Step 3: Export slashing protection history​

Ensure that you stop Prysm before exporting slashing protection in order to capture all validator actions.

We have a section dedicated to exporting and importing slashing protection history here. Follow the steps regarding exporting slashing protection history.

Step 4: Update port forwarding​

This step is not required for nodes which are running on a virtual public cloud, but keep in mind - nodes will be required to run a an execution client locally post merge!

By default, Prysm uses TCP/13000 and UDP/12000. Remove those two rules and replace them with the appropriate port forwards for the client you are switching to. The process will be very similar to the steps laid out here.

Teku, Nimbus, and Lighthouse all use port 9000 for both TCP and UDP.

Step 5: Import Validator Keys​

To minimize slashing risk, wait until at least 1 full epoch has elapsed between stopping prysm and importing your validator keys, approximately 6.5 minutes, before proceeding. The inactivity leak cost is negligible compared to the cost of getting slashed.

Once that amount of time has passed, import your validator keys into the respective validator client you wish to run.

https://nimbus.guide/migration.html#step-3---import-your-validator-keys-into-nimbus

Step 6: Import Slashing Protection History​

Follow your new clients' instructions regarding importing slashing protection history.

https://nimbus.guide/migration.html?highlight=import%20slashing#step-4---import-your-slashing-protection-history

Step 7: Start the New Validator​

Ensure your beacon node is fully synced with the network by checking your clients logs prior to starting your validator. Once it is fully synced, start the validator.

Search a block explorer like https://beaconcha.in with your validator's public key to confirm that your validator is now active!