Skip to main content
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

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, 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 and 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).
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…”):
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://<domain>: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, 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

A key can be declared by only one node in your organization. A key already on another node is refused with validator identity '<key>' is already declared by node '<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-<node id>), 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 "<line>" [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 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. 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.

​
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 moves both. A step that needs a consensus resync keeps the validator’s slashing-protection data.

​
Monitoring

On the Monitoring 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; the Set up validator alerts link after adding a validator takes you there.