Create Validator
Create a secured wallet, fund it, and register your validator on lumera-mainnet-1.
Prerequisites
Your node must be running and fully synced before you register. Check it first.
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. On mainnet use the file backend, which encrypts keys on disk behind a passphrase.
Do not use the test backend on mainnet. It stores keys in plaintext. Anyone who reads the filesystem takes your funds. That includes a backup, a snapshot, or a compromised process. The file backend prompts for a passphrase on every signing operation. That friction is the point.
For larger stake, keep the operator key off the validator. Generate and sign from a separate secured machine, or use a Ledger hardware wallet with --ledger. The operator key only signs occasional transactions. It does not have to live beside the node.
Step 2: Create a Wallet
You are prompted to set a keyring passphrase. Then you see your address and a 24-word mnemonic.
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.
Staking queries use the lumeravaloper1... form.
Step 3: Fund the Wallet
There is no mainnet faucet. Transfer LUME to the account address from Step 2 from an exchange or an existing wallet.
Confirm it arrived.
The protocol minimum is 1 LUME, which is 1,000,000 ulume, plus fees. The active set is capped at 50 validators and ranked by total stake. To actually enter it you need enough stake to displace the smallest bonded validator. Check the current floor before you commit.
Send a small test transfer first and confirm it lands before you move your full stake. An address typo is unrecoverable.
Step 4: Create the Validator
Cosmos SDK v0.50 takes a JSON file rather than individual CLI flags. Build it.
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 means 1 ulume, not 1 LUME. Dropping below unbonds you |
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.
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
| 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 at 50 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.
Once bonded, check that you are signing.
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
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.