Nolus Docs
Infrastructure

Run a validator

Turn a synced pirin-1 full node into a Nolus validator, with the create-validator file, fee flags, slashing and governance parameters, and unjailing.

Validators run the CometBFT consensus that produces Nolus blocks, which means that they sign and commit blocks and vote on governance proposals. NLS holders delegate stake to validators, and up to 25 validators with the most stake form the active set. Because a validator is a full node with a consensus key and an on-chain validator record, start from a node that has fully caught up with the chain.

Keys

A validator uses two keys, and both of them need to be kept safe and backed up:

KeyWhere it livesUsed for
Consensus key~/.nolus/config/priv_validator_key.json, created by nolusd initSigning blocks
Operator keyYour keyring, created with nolusd keys addTransactions: creating and editing the validator, unjailing, voting

Alongside the keys, the node records the last height and round it signed in ~/.nolus/data/priv_validator_state.json, which prevents it from signing twice at the same height.

Create a validator

Creating a validator takes five steps, from the operator key to a check that the validator has joined the active set.

Create or restore the operator key

The operator key lives in your keyring. The following commands create a new key, restore an existing one from its mnemonic and print the key's account:

nolusd keys add <key-name>              # new key, prints the mnemonic once
nolusd keys add <key-name> --recover    # restore from a BIP39 mnemonic
nolusd keys show <key-name> -a          # your nolus1... account

Replace <key-name> with the name of the key in your keyring. When you create a new key, write the mnemonic down, because it is the only way to restore the key.

Fund the account

The operator account needs NLS for the self-stake and for the transaction fee, and amounts on chain are denominated in unls, where 1 NLS = 1,000,000 unls.

Write the validator file

The validator file is built around the consensus public key, which the following command prints as a JSON object such as {"@type":"/cosmos.crypto.ed25519.PubKey","key":"..."}:

nolusd comet show-validator

Next, create validator.json with that object as pubkey:

{
  "pubkey": {"@type": "/cosmos.crypto.ed25519.PubKey", "key": "<key from comet show-validator>"},
  "amount": "1000000unls",
  "moniker": "<your validator name>",
  "identity": "<optional Keybase identity>",
  "website": "<optional website>",
  "security": "<optional security contact email>",
  "details": "<optional description>",
  "commission-rate": "0.05",
  "commission-max-rate": "0.10",
  "commission-max-change-rate": "0.01",
  "min-self-delegation": "1"
}

Replace the placeholders with the key that comet show-validator printed and your validator's name, and fill in the optional Keybase identity, website, security contact email and description if you want to set them. The remaining fields set the stake and the commission, as follows:

FieldMeaningIn the example
amountSelf-stake, in unls1 NLS
commission-rateShare of delegators' rewards the validator keeps5%
commission-max-rateUpper limit for the commission, fixed at creation10%
commission-max-change-rateLargest commission change allowed per 24 hours1 percentage point
min-self-delegationMinimum self-stake the validator must keep, in unls1 unls

Submit the create-validator transaction

The create-validator transaction submits the file to the chain:

nolusd tx staking create-validator validator.json \
  --from <key-name> --chain-id pirin-1 \
  --gas auto --gas-adjustment 1.3 --gas-prices 0.025unls

Here <key-name> is the operator key. With --gas auto, nolusd simulates the transaction to size the gas, and --gas-prices turns that gas into the fee. If you set a fixed --fees value instead, nodes reject it when it is below the node's minimum gas price times the gas limit.

Confirm the validator is in the active set

Once the transaction is in a block, look for your consensus address in the active validator set:

nolusd query comet-validator-set | grep "$(nolusd comet show-address)"

Any output means that your consensus address is in the active set. No output means that the validator is inactive, either because it is jailed or because all 25 places are taken by validators with more stake, and in that case its record shows the details:

nolusd q staking validator $(nolusd keys show <key-name> --bech val -a)

Chain parameters

Chain parameters for staking, slashing and governance change only through governance, so the table below pairs each value, as of 2026-10-19, with the query that returns the live one. Query the live values before relying on them.

ParameterValueQuery
Active set size25 validatorsnolusd q staking params
Unbonding period21 daysnolusd q staking params
Minimum commission0%nolusd q staking params
Signing window10,000 blocksnolusd q slashing params
Minimum signed in the window5%nolusd q slashing params
Downtime jail600 secondsnolusd q slashing params
Downtime slash0.01%nolusd q slashing params
Double-sign slash5%nolusd q slashing params
Proposal deposit20,000 NLS, 25% of it at submissionnolusd q gov params
Deposit period / voting period10 days / 3 daysnolusd q gov params
Quorum / threshold / veto33.4% / 50% / 33.4%nolusd q gov params
Expedited proposals30,000 NLS deposit, 1 day voting, 66.7% thresholdnolusd q gov params

Fees and rewards

Nolus routes 100% of transaction fees to the protocol, and NLS fees go to the treasury contract nolus14hj2tavq8fpesdwxxcu44rty3hh90vhujrvcmstl4zr3txmfvw9s0k0puz, so none of the fees stay with validators. Fees can also be paid in approved IBC denoms, each with a governance-set minimum price, and nolusd q tax params returns the live settings.

Staking rewards come from newly minted NLS, which the distribution module pays to validators and their delegators, less each validator's commission. Minting is time-based and currently runs at, for example, about 10.25 million NLS a year, toward a maximum supply of 1,000,000,000 NLS. To read the current annual amount, which is given in unls, run nolusd q mint inflation.

Restore a validator on a new machine

Moving a validator to a new machine requires the consensus key file, priv_validator_key.json, and the mnemonic of the operator key.

Never run the same consensus key on two machines at once. Two nodes that sign with one key are double signing, and the validator is then slashed 5% and jailed permanently.

  1. Set up a new full node and let it catch up.
  2. Stop the old validator for good, and keep it stopped.
  3. On the new node, stop nolusd, copy the old ~/.nolus/config/priv_validator_key.json over the new one, and copy the old ~/.nolus/data/priv_validator_state.json as well if you have it.
  4. Restore the operator key with nolusd keys add <key-name> --recover.
  5. Start the new node.

Unjail

A validator that signs fewer than 5% of the last 10,000 blocks is jailed for downtime, which removes it from the active set and slashes its stake by 0.01%. After the 600-second jail period, bring the node back in sync and send an unjail transaction:

nolusd tx slashing unjail --from <key-name> --chain-id pirin-1 \
  --gas auto --gas-adjustment 1.3 --gas-prices 0.025unls

Replace <key-name> with the operator key. To check the validator's signing record afterwards, run nolusd q slashing signing-info "$(nolusd comet show-validator)".

On this page