Validator FAQ
Answers to the most common questions from validators joining the Monolythium network.
Registration
Why can't I use monod tx staking create-validator?
The standard Cosmos SDK create-validator command is blocked on Monolythium by a circuit breaker in the custom x/validator module. This was implemented to enforce the burn-deposit requirement that all validators must meet.
Use monod tx mono register-validator instead:
monod tx mono register-validator \
--pubkey=$(monod tendermint show-validator) \
--moniker="my-validator" \
--self-delegation=100000000000000000000000alyth \
--burn-deposit=100000000000000000000000alyth \
--commission-rate="0.10" \
--commission-max-rate="0.20" \
--commission-max-change-rate="0.01" \
--from=validator-operator \
--chain-id=<chain-id> \
--gas=auto \
--gas-adjustment=1.5 \
--gas-prices=0.025alyth
The --burn flag triggers a MsgBurn in the same transaction as MsgCreateValidator, which is how the protocol enforces commitment. If you attempt staking create-validator, the transaction will be rejected at the ante handler.
See Registration for full step-by-step instructions.
What's the registration burn?
Registration requires 200,000 LYTH total:
| Component | Amount | What Happens |
|---|---|---|
| Burn deposit | 100,000 LYTH | Permanently destroyed. Non-refundable. |
| Self-delegation | 100,000 LYTH | Staked. Subject to slashing. Returned on unbonding. |
| Total | 200,000 LYTH | Required in a single transaction |
The burn is a one-time proof of commitment. You do not get it back under any circumstances.
Why does the JSON format look different from standard Cosmos?
Monolythium uses Proto JSON format for validator creation messages, which differs from the Amino JSON you may be used to from other Cosmos chains.
Key differences:
| Field | Standard Cosmos | Monolythium (Proto JSON) |
|---|---|---|
| Stake amount | "amount" | "value" |
| Validator info | Flat fields | Nested "description" object |
| Commission | Decimal strings ("0.10") | Integer strings ("100000000000000000" for 10%) |
| Structure | "commission_rates" | Nested "commission" object |
For example, 10% commission in Proto JSON is "100000000000000000" (10^17), not "0.10". This is because commission values use 18-decimal fixed-point representation internally.
Unless you are constructing raw JSON transactions, the CLI flags (--commission-rate="0.10") handle the conversion for you. Only worry about Proto JSON if you are building transactions programmatically.
Where do I get the canonical app.toml?
Download the official configuration from the networks repository:
curl -sL https://raw.githubusercontent.com/monolythium/networks/prod/testnet/app.toml \
-o ~/.mono/config/app.toml
Do not rely on the app.toml generated by monod init. It produces default Cosmos SDK values that have incorrect EVM configuration for Monolythium. Specifically, the EVM JSON-RPC settings, gas cap, and API namespaces will be wrong. Always replace it with the canonical version from the networks repo.
Slashing & Downtime
What happens if my node goes offline?
Downtime is tracked by a sliding window of recent blocks:
| Parameter | Testnet Value |
|---|---|
| Signed blocks window | 100 blocks |
| Min signed per window | 50% (50 blocks) |
| Downtime slash | 1% of staked tokens |
| Jail duration | 10 minutes minimum |
| Mainnet params | TBD (governance) |
If you miss more than 50 out of 100 consecutive blocks, your validator is slashed 1% and jailed for a minimum of 10 minutes.
Brief network hiccups or a few missed blocks will not trigger slashing. The 50% threshold over a 100-block window provides a reasonable buffer for transient issues.
How do I unjail my validator?
After the jail period expires, submit an unjail transaction:
# Using monod
monod tx slashing unjail \
--from validator-operator \
--chain-id <chain-id>
# Using Monarch CLI
monarch validator unjail
Before unjailing, fix the underlying issue that caused the downtime. If the same problem persists, you will be jailed again.
What's the difference between jailed and tombstoned?
| State | Cause | Recovery | Action |
|---|---|---|---|
| Jailed | Downtime (missed blocks) | Temporary | Fix issue, wait for jail period, submit unjail tx |
| Tombstoned | Double-signing | Permanent | Cannot recover. Must create entirely new validator with new keys. |
Jailing is a warning. Tombstoning is permanent expulsion from the validator set for that key.
Can I run a backup validator node to avoid downtime?
No. Running two nodes with the same validator key is the single most dangerous thing you can do. If both nodes sign blocks at the same height, this constitutes double-signing and results in:
- 5% slash of all staked tokens (yours and your delegators')
- Permanent tombstone (no recovery, no unjail)
There is no "hot standby" configuration that is safe with raw validator keys. If you want high availability, use a remote signing solution like TMKMS or Horcrux, which ensures only one signature is produced per height regardless of how many nodes are running.
See KMS for setup instructions.
Commission
How does commission work?
Commission is the percentage of delegator rewards that the validator keeps as compensation for running infrastructure. It does not affect your own staking rewards.
Example with 10% commission:
- Block produces 100 LYTH in rewards for your validator's delegators
- You keep 10 LYTH as commission
- Delegators share the remaining 90 LYTH proportionally
Commission is set at registration time with three parameters:
| Parameter | Meaning | Can Change? |
|---|---|---|
commission-rate | Current commission percentage | Yes, within limits |
commission-max-rate | Absolute ceiling | No, permanent |
commission-max-change-rate | Max adjustment per day | No, permanent |
Can I change my commission rate?
Yes, but with constraints:
- You can raise or lower your rate up to
max-change-rateper day - You can never exceed
max-rate, which is locked permanently at registration - Changes take effect immediately
# Using monod
monod tx staking edit-validator \
--commission-rate="0.12" \
--from validator-operator \
--chain-id <chain-id>
# Using Monarch CLI
monarch validator edit --commission-rate 0.12
Choose your max-rate and max-change-rate carefully at registration. These cannot be modified after the validator is created. Setting max-rate too low limits your future flexibility. Setting it too high may deter delegators.
Active Set
How many validators can be active?
The active set is limited to 53 validators, ranked by total stake (self-delegation plus delegations from others). Only active validators participate in consensus and earn rewards.
There is no limit on how many validators can register. Validators outside the top 53 exist in an inactive state.
What if I drop out of the active set?
If your total stake falls below the 53rd-ranked validator:
| Effect | Details |
|---|---|
| Rewards | Stop immediately |
| Slashing | Not at risk (not signing blocks) |
| Delegation | Remains intact, not unbonded |
| Re-entry | Automatic when stake exceeds 53rd validator |
You are not penalized for being in the inactive set. Your delegations remain, and you re-enter the active set automatically if your stake increases above the threshold.
How is the block proposer selected?
The proposer for each block is selected based on voting power (total stake). Validators with more stake propose blocks more frequently.
Monolythium uses LythiumBFT's quadratic proposer selection, which means proposal frequency scales with the square root of voting power rather than linearly. A validator with 4x the stake proposes only 2x as often, resulting in a more equitable distribution of proposer fees across the validator set.
Operations
Where are my node logs?
# Using systemd (standard installation)
journalctl -u monod -f
# Using Monarch CLI
monarch logs
# Last 100 lines only
journalctl -u monod -n 100 --no-pager
How do I check if I'm signing blocks?
Query your signing info to see missed blocks and jail status:
# Get your validator consensus public key
monod comet show-validator
# Query signing info
monod query slashing signing-info $(monod comet show-validator)
The output shows:
| Field | Meaning |
|---|---|
start_height | Block height when you started signing |
index_offset | Current position in the signing window |
jailed_until | Timestamp if jailed (past = not jailed) |
tombstoned | true if permanently banned |
missed_blocks_counter | Blocks missed in current window |
You can also check your validator status on Monoscan.
My node says "catching up" — should I register as a validator?
No. Do not register your validator until your node is fully synced.
If you attempt to register while your node is still catching up:
- Monarch CLI blocks this automatically for your safety
- If you bypass Monarch and register via
monoddirectly, your validator will immediately start missing blocks - Missing blocks during sync leads to jailing and slashing
# Check sync status
monod status | jq '.sync_info.catching_up'
# Must return "false" before registering
# Monarch checks this for you
monarch status
Depending on chain height, syncing can take hours to days. Use state sync or a snapshot to speed up the process. See Join Network for sync options.
Related
- Registration — Step-by-step validator creation
- Slashing — Slashing parameters and prevention
- Best Practices — Operational guidelines
- KMS — Remote signing with TMKMS/Horcrux
- Economics — Revenue and cost analysis