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.

Use the CLI flags

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

uyarı

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.

bilgi

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)

Never run duplicate validators

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-rate per 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

uyarı

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 monod directly, 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

Let the node finish syncing

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.

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

Registration​

Why can't I use monod tx staking create-validator?​

What's the registration burn?​

Why does the JSON format look different from standard Cosmos?​

Where do I get the canonical app.toml?​

Slashing & Downtime​

What happens if my node goes offline?​

How do I unjail my validator?​

What's the difference between jailed and tombstoned?​

Can I run a backup validator node to avoid downtime?​

Commission​

How does commission work?​

Can I change my commission rate?​

Active Set​

How many validators can be active?​

What if I drop out of the active set?​

How is the block proposer selected?​

Operations​

Where are my node logs?​

How do I check if I'm signing blocks?​

My node says "catching up" — should I register as a validator?​

Related​