Skip to main content

ZIGChain Validators FAQ

TL;DR: This ZIGChain validators FAQ explains how validators join consensus, earn rewards, face slashing, and recover nodes after upgrades.

Overview​

This ZIGChain validators FAQ helps validators, delegators, and node operators learn core chain rules. A validator is a full node that proposes blocks and validates transactions. ZIGChain uses Proof-of-Stake, so stake decides who joins the active set.

Active validators secure the network and process transactions. Rank follows total stake, including self-stake and delegated funds. Delegators stake ZIG with validators and share rewards based on stake and commission.

The rest of this ZIGChain validators FAQ covers selection, keys, statuses, duties, rewards, slashing, and upgrade recovery. For mainnet and testnet staking parameters—including unbonding period, max_validators, and commission limits—see Staking Module. Governance can change these values over time.

For staking CLI commands and live parameter queries, see Staking Module. For setup steps, see Set Up a ZIGChain Validator.

Key Concepts​

The terms below appear throughout this ZIGChain validators FAQ. Each entry is a short definition in plain language.

  • Active Validator Set: The top N validators ranked by total staked ZIG, including tokens delegated to them.
  • Self-delegation: A validator's own bonded stake; a minimum amount is required to join the active set (see How Validators Are Selected and query live params with the Staking Module CLI).
  • Unbonding period: The wait after unstaking before tokens become transferable; mainnet and testnet durations are in Staking Module.
  • Commission: The share of delegator rewards a validator keeps for running the node and signing blocks.
  • Slashing: On-chain penalties that burn bonded stake when a validator breaks rules or misses uptime targets.
  • Jailing: A consensus state that removes a validator from block signing until the operator fixes the issue and is unjailed.
  • Delegator: A token holder who stakes ZIG with a validator and earns part of that validator's rewards minus commission.

What Is a Validator​

A validator is a full node on ZIGChain that joins consensus by proposing blocks and validating transactions. ZIGChain uses Proof-of-Stake, so validators are ranked by staked ZIG—their own tokens and those delegated by others.

Active Validators are the network's top token holders by stake. They secure the chain and process transactions. Their rank depends on total stake, including self-stake and delegated tokens. Anyone can delegate ZIG to a validator; that stake counts toward the validator's rank but is not the validator's self-bond.

Validator Keys​

Validators use three key types on ZIGChain:

  1. Tendermint Consensus Key (also known as the CometBFT key)

    • Purpose: Used to sign blocks.
    • Address prefix: zigvalcons
    • Public key prefix: zigvalconspub
    • Key type: ed25519 (can be stored in Key Management System (KMS)).
    • Generated during: zigchaind init process.

  2. Validator Operator Application key

    • Purpose: Used to create transactions that create or modify validator parameters.
    • Address prefix: zigvaloper.

  3. Validator Owner Key

    • Purpose: Used to manage the validator and handle auto stake.
    • Address prefix: zig.

How Validators Are Selected​

ZIGChain picks active validators by total staked ZIG tokens, as described in this ZIGChain validators FAQ. This total includes self-delegated and delegated tokens. The top N validators with the highest stake form the Active Validator Set. These validators propose blocks and earn rewards.

To be eligible, a validator must meet the minimum self-delegation requirement of 100,000 ZIG. This bond is enforced on-chain. Delegations from others do not count toward this minimum. Validators below the threshold are not considered for the active set even if they receive delegations.

  • The maximum number of active validators is defined by the max_validators chain parameter. See Staking Module for mainnet and testnet values and CLI commands to read live parameters.
  • Only active validators participate in consensus and earn block rewards.
  • The minimum bond threshold and max_validators value can be updated through governance proposals.

How Validator Selection Works​

Validator selection is dynamic. It runs at the end of every block using Cosmos SDK v0.50 staking module logic. The active set may change block by block as stake changes.

Validator Selection Process​

  1. Fetch the maximum validator count from the max_validators parameter — for example, 4.

  2. Sort all validators by their total staked power (both self and delegated), using LastTotalPower and LastValidatorPower values.

  3. Select the top N validators as the new Active Validator Set.

  4. Update validator statuses:

    • Validators entering the top N are marked as Bonded.

    • Validators leaving the top N are transitioned to Unbonding.

  5. Unbonding is not immediate — it takes effect over time and may delay actions such as redelegations.

This automatic, block-by-block update keeps the validator set aligned with the latest stake totals.

Validator Unbonding​

Delegators who unstake ZIG tokens must wait through a fixed unbonding period before tokens become transferable. Mainnet and testnet unbonding_time values are in Staking Module. ZIGChain also enforces a per-validator unbonding limit per block, so only part of a validator's delegations can unbond in one block. This supports gradual exits and limits mass unbonding events.

Validator Statuses​

Validators can exist in three states:

  1. Unbonded:

    • Not in the Active Set
    • Cannot sign blocks
    • Earns no rewards
    • Can still receive delegations.

  2. Bonded:

    • In the Active Set
    • Signs blocks and earns rewards
    • Accepts new delegations
    • Faces slashing penalties if misbehaving
    • Delegators must wait through the Unbonding Period if withdrawing stake, during which they remain vulnerable to slashing if their validator commits offenses from the bonded period.

  3. Unbonding:

    • Happens when a validator:
      • Leaves the Active Set (by choice or due to slashing, jailing, or tombstoning)
      • Starts unbonding all delegations. Delegators must wait for the Unbonding Time before their tokens return to their accounts from the Bonded Pool.

Jailing is a special rule the chain can apply to validators. It is not a status on its own, but it removes validators from the Active Set and blocks signing until the operator is unjailed.

Validator Responsibilities​

Validators have several key responsibilities on the network. These duties keep consensus safe and rewards flowing to honest operators and their delegators.

  1. Proposing and Validating Blocks:

    • Propose new blocks and validate blocks proposed by other validators. Ensure only valid transactions are included.

  2. Maintaining Network Security: By validating transactions and maintaining consensus, validators help secure the blockchain against malicious actors and attacks. A key responsibility is to:

    • Prevent double-spending or any tampering with the blockchain's history.
    • Ensure consensus integrity.

  3. Uptime and Availability:

    • Validators must maintain high uptime to avoid penalties
    • Stay consistently online to propose and validate blocks.
    • Failure to meet uptime requirements can lead to penalties or slashing.

  4. Governance Participation:

    • Validators vote on key network proposals (influence critical decisions like protocol upgrades, staking parameters, and other blockchain proposals).
    • Voting power is proportional to their stake.

  5. Staking and Delegation:

    • To operate as a validator, participants must stake a significant amount of ZIG tokens. Higher stakes increase their chances of being selected for validation duties.
    • While personal stakes matter, validators often rely on delegators — users who trust them with additional staked tokens — to enhance their network position.

Delegators help spread stake across validators. This lowers centralization risk on the chain. In return, delegators receive part of the rewards validators earn for consensus work.

Validator Rewards and Transaction Fees​

Validators earn rewards from three main sources on ZIGChain. Later examples in this ZIGChain validators FAQ walk through the reward math step by step. Rewards are paid in ZIG tokens for valid blocks, good uptime, and honest signing.

  1. Block Rewards: Newly minted ZIG tokens distributed to validators and delegators for participating in network activities.
  2. Transaction Fees: Fees from users for processing transactions, paid in ZIG tokens.
  3. Commissions from Delegators: A percentage-based fee that validators collect from their delegators' rewards in exchange for validation services.

Rewards are shared between validators and their delegators. The split follows total stake and the validator commission rate. Validators often set a fee on delegator rewards for their service.

Validator Block Reward Example​

The block reward example in this ZIGChain validators FAQ assumes the following parameters:

  • Validator Voting Power: 10%
  • Commission Rate: 5%
  • Self-Delegation: 20%
  • Total Block Reward: 1000 ZIG

The block reward of 1000 ZIG goes to validators by voting power. Here, 10% power earns 100 ZIG. The pool splits between the validator and delegators by stake. Delegators pay a commission fee to the validator.

Reward distribution calculation:

Total Reward: 1000 ZIG

Validator Share: 100 * 20% = 20 ZIG

Delegator Commission: 100 * 80% * 5% = 4 ZIG
amount * percentage of delegator funds (not including validators as he doesn't pay commission) * commission rate

Total Validator Earnings: 100 * 20% + 4 (commission) = 24 ZIG

Delegators Earnings: 100 * 80% - 4 (commission) = 76 ZIG

Validator Transaction Fee Example​

Transaction fees follow the same distribution pattern as block rewards. The fee example below adds a community tax step and uses the same voting power, commission, and self-delegation as the block reward case above.

Assume the following:

  • Validator Voting Power: 10%
  • Commission Rate: 5%
  • Self-Delegation: 20%
  • ZIGChain Community Tax: 2%
  • Block proposer has 100% signatures

There is a successful block that collects 1025.51020408 ZIG in fees.

  1. First, the 2% tax is applied, and the corresponding ZIG tokens go to the reserve pool.
Community Tax Deduction: 1025.51020408 * 2% = 20.51020408 ZIG go to the reserve pool.

Remaining Fees: 1025.51020408 - 20.51020408 = 1005 ZIGs remain to be distributed among validators.
  1. Your validator pool will receive part of the reward according to its voting power.
Validator Pool Reward = 1005 * 10% = 100.5 ZIGs
  1. Commission paid by delegators:
Delegator Commission = 100.5 * 80% * 5% = 4.02 ZIGs

Total Validator Earnings: 100.5 * 20% + 4.02 (commission) = 24.02 ZIGs

Delegators Earnings: 100.5 * 80% - 4.02 (commission) = 76.48 ZIGs
note

ZIGChain uses the Cosmos SDK Distribution Module. Older Cosmos SDK versions gave the block proposer a bonus reward. Those params were removed in v0.47. Check reward params on ZIGChain with the command below

zigchaind query distribution params \
--chain-id zigchain-1 --node https://public-zigchain-rpc.numia.xyz

Slashing​

Slashing on ZIGChain reduces bonded stake when validators break rules or miss uptime. This ZIGChain validators FAQ summarizes the main cases and CLI checks below. Both validator and delegator stake can be affected, which encourages careful operation.

Validators can face slashing under several conditions:

  • Double Signing: Signing two different blocks at the same height triggers penalties.
  • Downtime: Validators must remain online and available. If a validator goes offline for too long, their stake can be slashed.
  • Equivocation: Taking conflicting consensus actions hurts network safety and incurs penalties.

The slashing rate depends on how severe the violation is. It deters attacks and careless node operation.

Slashing formula:

Amount of slashing = slash factor * power at time of infraction

Get Slashing Parameters:

zigchaind query slashing params \
--chain-id zigchain-1 --node https://public-zigchain-rpc.numia.xyz
  • Jailtime: Validators that are slashed may also be jailed temporarily, preventing them from producing blocks or earning rewards until they are unjailed manually.

Upgrade Recovery​

If your validator node does not recover cleanly after an upgrade, you can roll back one block and restart the Cosmovisor-managed service:

sudo systemctl stop zigchaind-cosmovisor.service
~/.zigchain/cosmovisor/current/bin/zigchaind rollback --hard
sudo systemctl start zigchaind-cosmovisor.service

What each command does:

  1. sudo systemctl stop zigchaind-cosmovisor.service Stops the running Cosmovisor service so no process is writing state while rollback runs.
  2. ~/.zigchain/cosmovisor/current/bin/zigchaind rollback --hard Uses the currently active zigchaind binary and performs a hard rollback of local node state by one block to recover from certain upgrade/state errors.
  3. sudo systemctl start zigchaind-cosmovisor.service Starts the service again so the node can rejoin consensus from the rolled-back state.

If you are not using Cosmovisor, use:

sudo systemctl stop zigchaind.service
zigchaind rollback --hard
sudo systemctl start zigchaind.service
warning

Use rollback only when needed for recovery/troubleshooting, then monitor logs after restart to confirm normal syncing and consensus.

If rollback does not fix the issue, resync using State Sync Configuration or Snapshots. State sync and snapshots rebuild more chain data than a single-block rollback, so use them when rollback alone does not restore a healthy node.

References​