> ## Documentation Index > Fetch the complete documentation index at: https://docs.novacula.io/llms.txt > Use this file to discover all available pages before exploring further. # Validator > Run an optional Ethereum validator client on a node, signing through your own Web3Signer — Novacula never creates, receives, or stores validator keys An Ethereum node can run an optional third role next to its execution and consensus clients: a **validator** client. It is Lighthouse `vc`, and it signs every duty through **your own Web3Signer** over mutual TLS. Novacula never creates, receives, or stores validator keys — there's no field anywhere for a private key, mnemonic, or keystore. You give the node the **public keys** your Web3Signer signs for, an address for fees, and the signer's address; the keys themselves stay on the server that runs Web3Signer. ## Where it's available | | | | - | - | | **Chain** | [Ethereum](/docs/chains/ethereum) | | **Networks** | `mainnet`, `sepolia`, `hoodi` | | **Node types** | **Full** and **Archive**. A **Blob-serving** node can't run a validator: the validator keeps the beacon API private, and a blob-serving beacon exists to share it. | | **Executors** | Agent (`systemd` and Docker runtimes) and Operator | | **Client** | Lighthouse `vc`, always the same version as the node's consensus client | The validator is offered only when the target executor declares a validator role for the node's consensus client, version, and network. If the switch or the **Add validator** action doesn't appear, that executor can't run one for this combination. A node either runs a validator or serves a [pool](/docs/nodes/pools), never both: a node with a validator can't be added to a pool (the pickers say *Runs a validator; a validating node cannot join a pool.*), and a pool member can't get a validator. ### What Novacula sets for you * **Doppelganger protection** — the validator waits a few epochs on start and refuses to sign if the same keys are already signing elsewhere. * **Slashing protection** — initialised on first start and kept across restarts and updates, including a consensus resync. * **Fee recipient** — passed as `--suggested-fee-recipient`. * **Beacon monitoring** — the node's Lighthouse beacon gets `--validator-monitor-pubkeys` for your keys, so it reports their on-chain duties for [monitoring](#monitoring) and [alerts](#alerts). * **Consensus RPC kept private** — the validator talks to its beacon over loopback, and the beacon API stays **Local** while a validator runs (see [RPC exposure](/docs/nodes/rpc-exposure)). Default resources for the validator role are **1 CPU / 2 GiB / 10 GiB** on `mainnet` and **0.5 CPU / 1 GiB / 10 GiB** on `sepolia` and `hoodi`; its metrics port is `5064` (internal). The deploy wizard's capacity check includes them. ## Before you start: a Web3Signer You need a Web3Signer that the node can reach over HTTPS and that holds the keys you want to validate with. If you don't have one, the validator form shows a **Web3Signer install command** (*"No Web3Signer yet? Run this on an Ubuntu server you control…"*): ```bash theme={null} curl -fsSL https://hub.novacula.io/web3signer-install.sh -o web3signer-install.sh && sudo sh web3signer-install.sh ``` The form fills in your Hub's address; copy the command from there. The installer runs as root on Ubuntu (`amd64` or `arm64`) and asks for: * the **network** — `mainnet`, `sepolia`, or `hoodi` (default `hoodi`); * the signer's **domain** and an email for **Let's Encrypt**; * the node's **outgoing IPv4 address** — only it may reach the signer port; * your **keys** — either **generate** 1–100 new ones (with `ethstaker-deposit-cli` `v1.3.0`, `0x01` or `0x02` withdrawal credentials, and a keystore password of at least 12 characters; generating for `mainnet` asks for an extra confirmation), or **import** existing keystores. It then installs `consensys/web3signer:26.7.0` with `postgres:17-alpine` for its slashing database, configures `ufw` to allow SSH, port 80 (for Let's Encrypt), and port `9000` from the node's IP only, obtains the certificate, and adds two helpers: `/opt/web3signer/allow-node` and `/opt/web3signer/add-keys`. When it finishes it prints the **signer URL** (`https://:9000`), the public keys, and a link to the staking launchpad for the deposits. The keys and mnemonic live only on the server you run the installer on. Back them up there; Novacula has no copy to restore from. ## Add a validator ### At deploy In the [deploy wizard](/docs/nodes/deploy-a-node), on the **Target** step, the **Validator** section reads *"Sign for your keys through your own Web3Signer. Novacula never creates, receives or stores validator keys."* Switch on **Run a validator**. A note confirms the validator runs the same Lighthouse version as the consensus client and that the consensus RPC stays private; the consensus RPC exposure is set to **Local** and locked (*Kept private while a validator runs on this node.*). The **Review** step shows how many keys the validator signs for. ### On a running node Open the node's **Overview**. An eligible node that isn't in a pool shows a collapsed **Validator** panel reading **Not running**, with **Add validator** — on a stopped node too. If the consensus client's RPC was public, saving closes it. Adding, editing, and removing a validator need the `nodes:deploy` permission (Owners and Admins). Every save **restarts the whole node** — execution, consensus, and validator together — so the dialog's button is **Save and restart**. After adding, a toast reads *Validator added. The node is restarting.* with a **Set up validator alerts** link. ### The fields | Field | What to enter | | - | - | | **Public keys** | The BLS public keys your Web3Signer signs for, one per line: 1–100 keys, each `0x` followed by 96 hex characters. | | **Fill from deposit data** | Optional. Choose a `deposit_data-*.json` file to take its public keys. The form reports the withdrawal address in the file and warns about any key with BLS (`0x00`) withdrawal credentials, which can't be withdrawn until they're changed to an execution address. | | **Fee recipient** | The execution address (`0x` + 40 hex characters) that receives priority fees and MEV when the validator proposes a block. | | **Signer address** | Your Web3Signer's address, reachable from the node. HTTPS only, without credentials, a query, or a fragment; loopback, link-local, and `localhost` addresses are refused. | | **Signer CA certificate** | Optional. A PEM file (up to 16 KiB), only if your Web3Signer's certificate is issued by your own CA. **Remove** clears it. | A key can be declared by only one node in your organization. A key already on another node is refused with `validator identity '' is already declared by node ''`, and the form offers a link to open that node; a key listed twice in the same form is refused as listed more than once. ## Let the node reach your signer Each node's validator presents its own client certificate (common name `nvcl-`), generated by the executor and kept across restarts. Web3Signer signs only for clients it knows, so you have to allow the node once: 1. Open the node's **Validator** tab. The **Signer access** panel shows the node's known-clients line — or *Waiting for the node to start* until the validator has started once. 2. Select **Copy known-clients line**. 3. On the Web3Signer server, add the line to the file passed to `--tls-known-clients-file` and restart Web3Signer. On a server set up by the installer, `sudo /opt/web3signer/allow-node "" [executor IPv4 address]` does both, and with an address also lets that IP reach port `9000` — use it for a node on another executor than the one you gave the installer. Until the line is in place, the validator can't sign. Removing the line revokes the node's access; a node created again gets a new certificate, so replace its line. ## The Validator tab A node with a validator gets a **Validator** tab, right after **Overview**. ### Validator keys The **Validator keys** panel lists every key on one line with its status and balance; a single key starts expanded. **Edit validator** is in the panel's header. Expand a key for its **Public key**, **Validator index**, **Explorer** link ([beaconcha.in](https://beaconcha.in) for `mainnet`, `sepolia`, and `hoodi`), **Balance**, **Effective balance**, **Activation epoch**, **Withdrawal address**, and **Exit epoch** with its approximate time. A **Key lifecycle** bar marks the key's stage: **Deposited**, **Pending**, **Active**, **Exited**, **Withdrawn**. | Status | Meaning | | - | - | | **Awaiting deposit** | Make the 32 ETH deposit for this key from the staking launchpad. | | **Pending: deposit queue** | The deposit is seen and waits to be processed by the beacon chain. | | **Deposit status unknown** | The deposit queue couldn't be read; it's retried every epoch. | | **Pending: deposit processed** | The deposit is processed; the key waits to enter the activation queue. | | **Pending: activation queue** | Waiting in the activation queue. | | **Active** | Performing duties. | | **Exiting** / **Slashing** | Active and leaving — voluntarily, or after being slashed. | | **Exited** / **Slashed** | No longer active. | | **Withdrawable** / **Withdrawn** | The stake can be withdrawn / has been withdrawn. | | **Other:** `` | A status the beacon reported that Novacula doesn't recognise, shown raw. | | **Not reported yet** | The node hasn't reported this key yet. | Statuses and balances come from the node's own beacon node. Everything above a key's maximum effective balance (32 ETH for `0x01` credentials) is swept to the withdrawal address automatically, so a balance staying near 32 ETH is expected. ### Key status history **Key status history** lists each key's status changes, newest first (**Show older** pages back; **Retry** reloads it if it couldn't be loaded). Each change is also a `node.validator.status_changed` system event in the [events feed](/docs/notifications/events-feed). ## Edit or remove **Edit validator** opens the same fields; saving restarts the whole node. To take the validator off the node, select **Remove validator** in that dialog, then **Remove and restart**. If keys are still active, the dialog warns that they stop their duties here and miss attestations and lose balance until another validator signs for them — make sure something else takes over first, and never run the same keys in two places at once. The validator's version follows the consensus client: a [version update](/docs/nodes/upgrade-node) moves both. A step that needs a consensus resync keeps the validator's slashing-protection data. ## Monitoring On the [Monitoring](/docs/nodes/monitoring#validation) tab, a node with a validator gets a **Validation** section, open by default: attestation effectiveness, missed attestations, proposed and missed blocks, total balance, active, slashed, and sync-committee keys, beacon node availability, and refused signatures. These metrics are read every 5 minutes, so their charts move in steps. ## Alerts Six built-in conditions watch validators — missed attestations, a missed block proposal, a falling balance, a slashing, a lost beacon node, and refused signatures — each available at **Organization** and **Node** scope. Author rules for them under [Alerts](/docs/notifications/alerts#built-in-conditions); the **Set up validator alerts** link after adding a validator takes you there. ## Related * [Ethereum](/docs/chains/ethereum) — clients, networks, and node types. * [Deploy a node](/docs/nodes/deploy-a-node) * [RPC exposure](/docs/nodes/rpc-exposure) * [Pools](/docs/nodes/pools) This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.