# Import Validator Keys
Your validator keys are used for validating and attesting to the correctness of blocks in the Ethereum blockchain. Validators also use the keys to propose and sign for new blocks, maintaining the integrity of the network.
You will need to import your validator keys into your Consensus Client. Your validator keys are contained in the **keystore files** which you obtained from the key generation process.
The steps to import the validator keys are the same for all three Consensus Clients: Teku, Prysm, or Nimbus.
The following instructions are for Solo Stakers. For Rocketpool and Stader stakers, the respective dapps will populate the validators for you. Please see the corresponding sections for details.
## Before you Begin
1. Make sure your Execution and Consensus Clients are up and running. You can import the validator keys even if the clients are still in the process of syncing.
2. Make sure you have your keystore files with you. There will be one keystore file per each validator you intend to run. Make sure also that you have the [password](/staking-ethereum/solo-staking-32-eth/generate-keys.md#password) to decrypt the keystore.
## The Steps
On your AVADO, open your Consensus Client on the Home Page.
On the **Main** page, click the **Add validator** field to expand it.
Steps to add a validator:
1. Click **Choose keystore file…** and browse to the keystore file (`.json`) you obtained from the key generation process.
2. Enter your keystore password.
3. (Optional) If you have a slashing protection file, upload the file here. For most users, this is not necessary.
4. Finally click **Add validator** to add the validator.
What is "slashing protection"?
Slashing protection prevents validators from signing blocks or attestations based on what it has already signed. It is useful when switching Consensus Clients or machines. Note that slashing protection does not provide protection if the same validator key is inadvertently being used by multiple nodes.
For most users, the easier option is to wait for a minimum of 5 finalized epochs before importing their keys into the target Consensus Client. 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.
## The Validator Dashboard
Once you have added your validator(s) to the Consensus Client, they will appear on the **Main** page:
Here's a breakdown of the displayed items, from left to right:
1. **Beaconchain icon:** Click this link to access your validator's page on **beaconcha.in** web site. It provides valuable information about your validator's status and serves as your primary resource for monitoring its performance.
2. **Index and Public Key:** These identifiers help you locate and access your validator's information on the **beaconcha.in** website.
3. **Balance:** This shows your validator's current balance, including the initial 32 ETH stake and any accrued *Consensus Layer* rewards. Amounts over 32 ETH are periodically sent to your Withdrawal Address.
4. **Effective Balance:** This is the basis for calculating your *Consensus Layer* rewards and is capped at 32 ETH. If your validator is penalized and the balance drops below 32 ETH, the Effective Balance will also decrease. Your validator can continue to validate even if your balance drops slightly below 32 ETH, though your rewards will be proportionally reduced. Your validator will be "kicked out" of the network if the Effective Balance drops below 16 ETH.
5. **Fee Recipient:** This is an Ethereum Address you can set to receive *Execution Layer* rewards. It defaults to the Fee Recipient Address you provided during Consensus Client setup. You can change this address for individual validators if needed.
6. **Withdrawals:** This indicates the status of your Withdrawal Address. If set, withdrawals are `enabled`. If not, it will show as `todo`.
7. **Status:** This displays the current status of your validator. It will show as `pending_initialized` while the deposit is waiting to be recognized, `pending_queued` while waiting for activation, and `active_ongoing` once active.
8. **Trash Bin:** This removes the validator entry from the dashboard but does not delete it from the Beacon Chain. It is useful for moving validators between Consensus Clients or machines.
9. **Exit Button:** Click this button when you decide to exit the validator. For the detailed exit steps, see [Exit from a Solo Validator](/staking-ethereum/solo-staking-32-eth/exit-from-a-solo-validator.md).
These elements help you monitor and manage your validators efficiently within the Consensus Client interface.
## Next Steps
In the next section, we will provide a walkthrough of the **beaconcha.in** web site and mobile app. These are important resources for your to track the activities of your validators.
---
# Agent Instructions: Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter:
```
GET https://docs.ava.do/staking-ethereum/solo-staking-32-eth/import-validator-keys.md?ask=
```
The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.