Setting up a Validator Node

This section details how to set up and run a validator node. It is divided into two sections -- pre-genesis validators and post-genesis validators.

Prerequisites

  • A machine that meets the requirements for running a validator node
  • An associated public static IPv4 address with ports 26656 reachable from anywhere for P2P connections
  • You have installed Namada and its dependencies

Pre-genesis validators

A pre-genesis validator is one which begins validating right from the first block of the chain, i.e., at genesis. The details of genesis validators are hardcoded into the genesis files that is distributed to all users who want to interact with a chain. Becoming a pre-genesis validator involves generating and signing a genesis transaction for inclusion in the genesis files; upon network launch, the validator can participate in consensus assuming they possess the expected consensus keys.

Method

The method for setting up a genesis validator is described under the pre-genesis participants section.

Post-genesis validators

Post-genesis validators are validators that become initialized after the genesis block; this is the most common way of becoming a validator.

Method

Sync a full node

Before initializing your validator account, you must first set up a full node and sync it with the head of the chain.

Initialize a new validator account

A validator account can be initialized from an established account by submitting an on-chain transaction. namadac init-validator will create a new established account and convert it to a validator account in a single command.

💡

You can also use the command namadac become-validator to convert an existing established account into a validator account, instead of creating a new one.

The required arguments to initialize a validator are:

namadac init-validator \
  --commission-rate 0.05 \
  --max-commission-rate-change 0.01 \
  --email $EMAIL \
  --alias $ALIAS

Note:

  • commission-rate is the percentage of staking rewards kept by the validator for all tokens bonded to it. A validator can change its commission rate by no more than max-commission-rate-change per epoch. The max-commission-rate-change parameter cannot be changed after validator initialization. Typical values are 0.05 (5%) and 0.01 (1%) respectively but validator are free to choose otherwise.
  • email should be set to a dedicated infra/security email account that you monitor regularly. It may be used to notify validators of urgent security issues, patches or chain upgrades.
  • alias is used to reference your account by name in your wallet; it does not appear on-chain.

You can optionally provide any of the following additional information to identify your validator on-chain (frequently displayed in block explorers):

  • name: An on-chain display name (similar to 'moniker' in Cosmos SDK chains)
  • avatar: A url to your validator logo
  • discord-handle: Your Discord handle
  • website: A url to your validator website
  • description: A 1-2 sentence description, tagline or slogan

Restart your node

You must restart your node after initializing your validator; your node will be unable to sign any future blocks until you do so.

Bond stake

A validator will only participate in consensus if the amount of tokens bonded meets both requirements:

  • Greater than the chain's validator_stake_threshold parameter, and
  • Enough to rank it among the top X active validators as defined by the max_validator_slots parameter. For example, if max_validator_slots = 100, then you must rank within the top 100 active validators by stake to participate in consensus.

Validators can bond tokens to themselves (self-bond) and solicit bonds from other parties (delegation); see the section on staking. Note that the balance of NAM tokens that is in your validator account does not count towards your validator's stake and voting power.

Await the pipeline_length

The chain's pipeline_length parameter defines the number of epochs that must pass before actions such as bonding, unbonding, or unjailing take effect. Therefore, after bonding sufficient stake to place in the active consensus set, you must wait an additional pipeline_length number of epochs before your validator is included in the consensus set.

Validator account keys