Create Validator

Create a wallet, fund it from the faucet, and register your validator on lumera-testnet-2.

Prerequisites

Your node must be running and fully synced before you register. Check it first.

lumerad status 2>&1 | jq '.sync_info | {latest_block_height, catching_up}'
# catching_up must be false

If you have not completed Node Setup, do that first.

Step 1: Set the Keyring Backend

On a headless server the default os keyring has no daemon to talk to. It will appear to hang. Set the backend to test so keys are stored as files on disk.

lumerad config set client keyring-backend test --skip-validate
lumerad config set client chain-id lumera-testnet-2 --skip-validate

The test backend stores keys unencrypted on disk. That is an acceptable trade-off for testnet. On mainnet, use file, which is passphrase-protected, or a hardware signer. See the mainnet guide.

Step 2: Create a Wallet

lumerad keys add validator

The output includes your address and a 24-word mnemonic.

- address: lumera1abc...
  name: validator

**Important** write this mnemonic phrase in a safe place.
word1 word2 word3 ... word24

Record the 24-word mnemonic offline, now. It is shown exactly once. Write it on paper or store it in a hardware backup. Never put it in a file on the server, a password manager sync, or a screenshot. Whoever holds this phrase controls your stake.

You have two addresses. They are two encodings of the same key.

# Account address. Receives tokens.
lumerad keys show validator -a
# lumera1...
 
# Operator address. Identifies the validator in staking commands.
lumerad keys show validator --bech val -a
# lumeravaloper1...

Staking queries use the lumeravaloper1... form.

Step 3: Fund the Wallet

Request testnet LUME. There are two options.

Faucet at faucet.astrostake.xyz/lumera
The Lumera Discord if the faucet is empty

Confirm it arrived.

lumerad query bank balances $(lumerad keys show validator -a)

You need at least 1 LUME, which is 1,000,000 ulume, for the minimum self-delegation. Request a little extra for fees.

Step 4: Create the Validator

Cosmos SDK v0.50 takes a JSON file rather than individual CLI flags. Build it.

cat > ~/validator.json <<EOF
{
  "pubkey": $(lumerad comet show-validator),
  "amount": "1000000ulume",
  "moniker": "my-validator",
  "identity": "",
  "website": "",
  "security": "",
  "details": "",
  "commission-rate": "0.10",
  "commission-max-rate": "0.20",
  "commission-max-change-rate": "0.01",
  "min-self-delegation": "1"
}
EOF
 
cat ~/validator.json

Set moniker to your own name. Raise amount to your intended self-delegation before you submit.

Field	Meaning	Notes
`pubkey`	Consensus public key	Read from `priv_validator_key.json` by `comet show-validator`
`amount`	Initial self-delegation	`1000000ulume` is 1 LUME
`commission-rate`	Your cut of delegator rewards	`0.10` is 10 percent
`commission-max-rate`	Ceiling on commission	Immutable after creation
`commission-max-change-rate`	Max change per 24 hours	Immutable after creation
`min-self-delegation`	Floor you must keep staked, in `ulume`	1 LUME. Active validators capped at 50

commission-max-rate and commission-max-change-rate can never be changed after creation. Delegators evaluate both. Setting the max rate too low limits you forever. Setting it too high deters delegation. Decide deliberately before you submit.

Older guides show --amount and --pubkey flags on create-validator. Those were removed in Cosmos SDK v0.50. They now fail. The JSON file above is the current form.

Submit the transaction.

lumerad tx staking create-validator ~/validator.json \
  --from=validator \
  --chain-id=lumera-testnet-2 \
  --gas=auto \
  --gas-adjustment=1.3 \
  --fees=10000ulume \
  -y

A successful broadcast returns code: 0. Any non-zero code means the transaction was rejected. The raw_log field explains why.

The commonly-cited --fees=5000ulume is often rejected with insufficient fees. Use 10000ulume or higher. You can also let the node compute the fee. Replace --fees with --gas-prices=0.025ulume.

Step 5: Verify

lumerad query staking validator $(lumerad keys show validator --bech val -a)

Status	Meaning
`BOND_STATUS_BONDED`	In the active set and signing blocks
`BOND_STATUS_UNBONDED`	Registered but not in the active set yet
`BOND_STATUS_UNBONDING`	Leaving the active set

A new validator normally starts unbonded. The active set is capped and ranked by total stake. You stay unbonded until your delegation is large enough to displace the smallest bonded validator.

Confirm the registered consensus key is the one your node actually signs with. If these differ, the validator will never sign a block no matter what its status says.

lumerad query staking validator $(lumerad keys show validator --bech val -a) -o json | jq -r .consensus_pubkey.key
lumerad comet show-validator | jq -r .key
# The two must be identical

Once bonded, check that you are signing.

lumerad query slashing signing-info $(lumerad comet show-validator)

missed_blocks_counter should stay near zero. tombstoned must be false.

Watch the first hour closely. If missed_blocks_counter climbs steadily, your node is not signing. Sustained downtime leads to jailing and a slash of your stake.

Verification Checklist

# Node healthy and synced
systemctl is-active lumera
lumerad status 2>&1 | jq -r .sync_info.catching_up          # false
 
# Validator registered
lumerad query staking validator $(lumerad keys show validator --bech val -a) \
  | jq '{moniker: .description.moniker, status, tokens, jailed}'
 
# Signing, once bonded
lumerad query slashing signing-info $(lumerad comet show-validator) \
  | jq '{missed_blocks_counter, tombstoned, jailed_until}'
 
# Balance left for fees
lumerad query bank balances $(lumerad keys show validator -a)

Back Up Everything

Before you walk away, make sure you have all three stored offline and test-restored.

The 24-word mnemonic from Step 2
~/.lumera/config/priv_validator_key.json
~/.lumera/config/node_key.json

Never restore priv_validator_key.json onto a second running machine. Two nodes signing with the same consensus key is double-signing. The network detects it, permanently tombstones the validator, and slashes the stake. When you migrate servers, confirm the old node is fully stopped and its key removed before the new one starts.

Prerequisites

Step 1: Set the Keyring Backend

Step 2: Create a Wallet

Step 3: Fund the Wallet

Step 4: Create the Validator

Step 5: Verify

Verification Checklist

Back Up Everything

Next Steps

Operations

Run a Supernode

Testnet Guide

On this page