Skip to content

Run a validator

Testnet

Operate an RP1 active-validator node with the DAG runtime, QUIC transport, and evidence-first readiness checks.

Updated View as Markdown

An RP1 validator runs the custom consensus server and the Cosmos SDK application together. The role value is active-validator; observer is a separate non-voting role.

If the goal is to join the public or shared testnet as an external partner, start with Join the testnet as a validator. That page covers bootstrap, software packaging, and admission into the live validator group.

Prerequisites

  • A release-matched rp1d artifact obtained through the validator join guide
  • Genesis/config artifacts or a bootstrap manifest for the target network
  • Stable disk for application and consensus stores
  • Publicly reachable consensus transport according to the network plan
  • A validator key and node identity provisioned through the supported operator workflow
  • RPC, REST, gRPC, and optional EVM listeners bound to the intended interfaces

Startup mental model

Start the daemonbash
rp1d start

rp1d start assembles the release-owned consensus, application, RPC, gRPC, API, EVM, genesis, validator, and runtime services. It is not a vanilla CometBFT block-production path; use the release-matched runbook for flags, identity, peers, and recovery rather than recreating internal startup stages in an operator wrapper.

Readiness checks

Before advertising a validator:

  1. Query /status and confirm the expected chain ID and node identity.
  2. Check that the consensus role is active and the node is connected to the expected validator set.
  3. Query a current complete block_header from every declared endpoint and compare height, hash, app hash, and retained time.
  4. Confirm RPC, REST, gRPC, and EVM requests are served from the intended home and network.
  5. Submit a small testnet transaction only after readiness succeeds.

Shutdown and maintenance

Use the release’s bounded shutdown and drain settings. Accepted transactions and certified work have ownership lifecycles; force-killing a process during a drain can turn a recoverable maintenance event into a startup repair or replay event. Preserve the consensus and application homes until the release-specific recovery procedure says they are safe to replace.

Navigation

Type to search…

↑↓ navigate↵ selectEsc close