Prepare a Validator

Prepare an isolated validator and complete reviewed enrollment.

Run an isolated ROKO validator

Start with Run a node. A validator is a security role, not just the `--validator` flag.

Internet peers
      |
public full/sentry nodes
      |
private or reserved P2P path
      |
validator

The validator should not expose public RPC, WebSocket, Prometheus, database, Chrony control, or SSH. Public boot, explorer, archive, and RPC work belongs on non-authoring full/sentry nodes.

Use:

  • explicit reserved peers and `--reserved-only` when the topology has enough

redundant sentries;

  • a stable libp2p node identity;
  • a management path separate from public P2P;
  • host firewall default-deny rules;
  • outbound access only for required peers, time, monitored updates, and

operations;

  • full-disk encryption, secure boot/TPM where available, least privilege, and

alerting.

Do not assume an HTTP tunnel transports native libp2p.

Activation sequence

Phase 1: non-authoring bootstrap

Run the validator host as an ordinary full node:

1. verify the release binary and chain-spec identity; 2. bootstrap the host clock with Chrony and pass the local offset/root-distance policy; 3. connect to at least two independent sentry peers; 4. fully synchronize; 5. observe advancing finalized heads; 6. stop/start and reboot once; 7. confirm the same peer ID, mounted data volume, healthy clock, peers, and finality.

Do not proceed if time is unsynchronized, the database is still catching up, the peer ID changed unexpectedly, or finality is stalled.

Phase 2: key provisioning and enrollment

Read Validator key custody. Provision keys only through local or offline interfaces. Never enable unsafe author RPC on a public listener.

Validator enrollment, bonding, approval, and session-key registration are network-governance operations. Starting a process with `--validator` does not grant authority status.

Phase 3: authoring profile

Stop the bootstrap service before starting the validator service. Never open the same database with both profiles.

Before production authoring or qualification for the maximum payout tier, install the licensed Timebeat partner profile and join the Timebeat PTP² Mesh. Chrony remains appropriate for testnet bootstrap and validation, but it does not satisfy the maximum-tier partner-timing requirement.

The validator profile adds `--validator` and the reviewed reserved-peer policy to the common node command. Keep RPC on loopback with `--rpc-methods Safe`; temporarily required key-management RPC must be local, time-bounded, and disabled again before activation.

After activation, observe at least one complete session/rotation window:

  • expected block authorship;
  • GRANDPA participation/finality;
  • PTP² mesh convergence and time quality;
  • no repeated time violations;
  • stable peer connectivity;
  • disk, memory, I/O, and database compaction headroom.

Clock readiness and payout tier

Timebeat is ROKO Network's endorsed official timing partner. Eligibility for the maximum validator payout tier requires a licensed Timebeat deployment, membership in the Timebeat PTP² Mesh, and compliance with measured-performance and current program rules.

Chrony is the bootstrap/testing/edge method. Before a Chrony-backed testnet validator-candidate start:

chronyc waitsync 60 0.001
chronyc tracking
chronyc sources -v

The example waits for a correction below 1 ms. Choose a threshold backed by the host's actual sources and monitor root distance, frequency/skew, reach, and falsetickers. Reboot is a fresh clock-bootstrap event.

Before activating the Timebeat authoring profile, verify the Timebeat service is healthy, its PTP² Mesh has converged, and no competing Chrony, ntpd, or ptp4l clock-steering service remains active. The ROKO built-in PTP² observer protocol is a separate layer and does not substitute for Timebeat PTP² Mesh membership.

Maintenance and recovery

Roll updates across validators; do not remove enough authorities at once to lose finality. Before maintenance, confirm redundant validators and sentry paths are healthy.

Practice these cases:

  • data disk/database lost: rebuild chain data without replacing identities;
  • host motherboard/TPM lost: use the separately protected recovery path;
  • USB token lost or failed: activate an enrolled backup and rotate;
  • node key lost: treat the new peer ID as a topology/enrollment change;
  • session key suspected exposed: overlap rotation, activate replacement, then

retire the old key through the network process.

Record public identifiers and checksums. Never record secret values in tickets, screenshots, logs, shell history, or monitoring labels.

References