Validators

Last reviewed: 2026-09-18

Network: LITHO Mainnet only (lithosphere_9005-1).

This section covers validator requirements, staking rules, activation, and verification. Detailed onboarding steps are provided in:

• CLI onboarding
• Web onboarding (validator.litho.ai)

Canonical network values

Stop if any downloaded artifact, chain ID, or endpoint differs from the table above.

Requirements

Infrastructure

• Dedicated Linux VPS with at least 8 vCPU, 24 GB RAM, and 250 GB free SSD.
• Stable public address for P2P or an approved private-sentry connection.
• Time synchronization, firewalling, SSH keys, monitoring, and alerting.
• Approved genesis and exact reviewed lithod binary.
• Fully synchronized node with catching_up: false.

Identity and custody

• Unique node ID and consensus public key.
• Secure backups of priv_validator_key.json, node_key.json, and the latest priv_validator_state.json.
• An operator wallet whose key is held by its owner. The wallet key must not be stored on a shared validator host or submitted to any onboarding portal.
• Validator moniker, website/identity if used, security contact, and description.

Funding and policy

• Operator wallet balance covering the approved self-delegation plus fees.
• Initial commission, maximum commission, maximum daily change, and minimum self-delegation approved before signing.
• Current mainnet minimum commission rate: 5%.
• Current onboarding allocations use 10,000–25,000 LITHO. This is an operator policy range, not a protocol-wide minimum stake.

Staking rules

The chain uses ulitho for staking, allows up to 100 validators in the active set, and has a 21-day unbonding period. A validator registration includes an initial self-delegation and a self-declared minimum self-delegation. The current onboarding template sets that minimum to 1ulitho.

There is currently no global on-chain minimum such as 10,000 LITHO for registration. A candidate becomes active when its bonded voting power places it in the active validator set. The onboarding stake can be changed before the transaction is signed by updating the approved record, funding amount, and transaction. A different portal policy can be configured without changing the chain; enforcing a new universal minimum on-chain requires an approved chain change.

Security rules

• Never share a mnemonic, private key, priv_validator_key.json, signing state, wallet export, or unrestricted management endpoint.
• Never reuse a consensus key or restore an older signing-state file over a newer one; either can cause double signing.
• Activate validators one at a time and observe each before continuing.
• Treat funding, transaction signing, and broadcasting as separate reviewed actions.

References

• Repository mainnet genesis and R1 deployment records.
• Cosmos SDK staking model and MsgCreateValidator behavior: docs.cosmos.network/sdk/latest/modules/staking/README