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-validatelumerad 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.
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...
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
Dropping below unbonds you. The active set is 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.
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.
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.keylumerad comet show-validator | jq -r .key# The two must be identical
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.
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.
