Consensus

Monolythium uses LythiumBFT, a modified fork of CometBFT v0.38.19 that introduces quadratic proposer selection. This guide explains how consensus works.

Overview

Property	Value
Consensus engine	LythiumBFT (CometBFT fork)
Block time	2 seconds (target)
Finality	Deterministic (instant)
Active validators	53
Byzantine tolerance	1/3
Proposer selection	Quadratic (sqrt of voting power)

LythiumBFT Consensus

How It Works

LythiumBFT uses the same multi-round BFT voting process as CometBFT:

1. Propose    → Selected validator proposes a block
2. Prevote    → Validators vote on the proposal
3. Precommit  → Validators commit if 2/3+ prevoted
4. Commit     → Block finalized if 2/3+ precommitted

What's Different: Quadratic Proposer Selection

Standard CometBFT selects block proposers proportionally to their voting power — a validator with 10x the stake proposes 10x as often. LythiumBFT changes this by applying a square root transformation to the proposer priority calculation:

Standard CometBFT:  Proposal frequency ∝ votingPower
LythiumBFT:         Proposal frequency ∝ sqrt(votingPower)

This means:

Stake Multiple	Standard (Linear)	LythiumBFT (Quadratic)
1x (baseline)	1x proposals	1x proposals
4x stake	4x proposals	2x proposals
9x stake	9x proposals	3x proposals
16x stake	16x proposals	4x proposals

Key property: To double your proposal frequency, you need 4x the stake.

Why Quadratic Selection?

1. Reduces concentration: Large validators cannot dominate block production proportionally
2. Fairer fee distribution: The 10% of transaction fees going to block proposers is spread more evenly
3. Encourages decentralization: Diminishing returns on proposal frequency reduce incentive to consolidate stake
4. Preserves security: Voting power for consensus (prevote/precommit) remains linear — large validators still secure the network proportionally

Concrete Example

With three validators:

Validator	Stake	Voting Power	Linear Proposals	Quadratic Proposals
A	10M LYTH	90.09%	90.09%	70.62%
B	1M LYTH	9.01%	9.01%	22.32%
C	100K LYTH	0.90%	0.90%	7.06%

Validator A has 100x the stake of C, but only proposes ~10x as often (instead of 100x).

Deterministic Finality

Unlike probabilistic finality (Bitcoin, Ethereum PoW):

• Blocks are final once committed
• No reorganizations or reversions possible
• Safe to trust immediately after 1 block

This enables faster confirmation times for exchanges and applications.

Validator Set

Active Set

Only the top 53 validators by total stake participate in consensus:

Rank 1-53:  Active (earn rewards, sign blocks)
Rank 54+:   Inactive (no rewards, waiting)

Selection Criteria

Validators are ranked by total stake:

Total Stake = Self-Delegation + Delegations from Others

Dynamic Updates

The active set updates each block:

• Stake changes can move validators in/out
• No minimum stake to enter (just top 53)
• Transitions are immediate

Block Production

Proposer Selection

Each block has a designated proposer selected by LythiumBFT's quadratic algorithm:

Proposer Priority = sqrt(votingPower)

The validator with the highest accumulated priority is selected as the block proposer. The priority resets after proposing, cycling through validators.

Block Contents

A block contains:

• Header (chain ID, height, time, hashes)
• Transactions (Cosmos and EVM)
• Evidence (of validator misbehavior)
• Last commit (signatures from previous round)

Block Size

Maximum block size: 4 MB (4,194,304 bytes)

This limits transactions per block based on their size.

Voting Power

Calculation

Voting Power = Validator's Total Stake / Total Staked

Example with 390M total staked:

Validator	Stake	Voting Power
A	39M LYTH	10%
B	19.5M LYTH	5%
C	7.8M LYTH	2%

Significance

Voting power determines:

• Proposal frequency: Based on sqrt(votingPower) — quadratic
• Vote weight: Based on votingPower directly — linear (unchanged)
• Staking rewards: Based on stake weight — standard Cosmos proportional distribution

!!! important "Proposer ≠ Vote Weight" Quadratic selection only affects how often a validator proposes blocks. Voting weight in prevote/precommit rounds remains proportional to stake, preserving the BFT security model.

Liveness and Safety

Safety Guarantee

No conflicting blocks are finalized if:

Byzantine validators < 1/3 of voting power

With 53 validators, up to 17 can be Byzantine without breaking safety.

Liveness Guarantee

The chain continues producing blocks if:

Online honest validators > 2/3 of voting power

At least 36 honest validators must be online.

Block Time

Target: 2 Seconds

# In config.toml
[consensus]
timeout_commit = "2s"

Actual Times

Block times vary based on:

• Network latency between validators
• Proposal propagation time
• Voting round duration

Typical range: 1.8 - 2.5 seconds.

Rounds and Timeouts

If a round fails (proposer offline, network issues):

Round 0: timeout_propose = 3s
Round 1: timeout_propose = 3s + 500ms
Round 2: timeout_propose = 3s + 1s
...

Timeouts increase to allow recovery while maintaining progress.

Network Halts

When Does the Chain Halt?

The chain stops if:

• More than 1/3 voting power offline/unresponsive
• Network partition prevents 2/3 agreement

Recovery

When the issue is resolved:

1. Validators reconnect
2. Consensus resumes automatically
3. No manual intervention required

!!! important "No State Reversions" Monolythium does not support chain state reversions. Recovery is always forward-only through continued block production.

Slashing

Consensus violations result in slashing:

Downtime

Missing too many blocks:

Penalty: 0.01% slash
Jail: 10 minutes minimum
Recovery: Unjail transaction after jail period

Double-Signing

Signing conflicting blocks:

Penalty: 5% slash
Jail: Permanent (tombstoned)
Recovery: None - validator must re-register

Monitoring Consensus

Check Node Status

curl -s localhost:26657/status | jq '.result.sync_info'

View Validators

# Current validator set
curl -s localhost:26657/validators | jq

# Via CLI
monod query staking validators --status=BOND_STATUS_BONDED

Check Consensus State

curl -s localhost:26657/consensus_state | jq

Configuration

Key Parameters

# config.toml [consensus]
timeout_propose = "3s"
timeout_prevote = "1s"
timeout_precommit = "1s"
timeout_commit = "2s"

Validator-Specific

# Signing configuration
double_sign_check_height = 10

# Block proposal
create_empty_blocks = true
create_empty_blocks_interval = "0s"

Comparison to Other Consensus

Aspect	LythiumBFT	CometBFT (standard)	Nakamoto (PoW)	Ethereum PoS
Finality	Instant	Instant	Probabilistic	~15 min
Block time	2s	Varies	~10min	~12s
Validators	53	Varies	Unlimited miners	~500k
Proposer selection	Quadratic	Linear	Hash-based	Randomized
Energy	Low	Low	Very High	Low

FAQ

What happens if my validator misses a block?

Missing occasional blocks has no penalty. Extended downtime (configurable window) triggers jail.

Can finalized blocks be reversed?

No. LythiumBFT provides deterministic finality — committed blocks cannot be reversed without breaking >1/3 Byzantine assumption.

Why only 53 validators?

Balance between decentralization and performance. More validators increase latency; fewer reduces decentralization. 53 provides good security with sub-3-second finality.

What if 2/3 of validators collude?

They could halt the chain or double-spend. This is the fundamental trust assumption of BFT consensus. Stake-based incentives make this economically irrational.

How do I know a block is final?

Immediately. Once you see a block at height N, it's final. No confirmations needed.

What's the relationship between LythiumBFT and CometBFT?

LythiumBFT is a fork of CometBFT v0.38.19. The only modification is the proposer selection algorithm — changed from linear to quadratic (sqrt). All other consensus mechanics (voting, finality, slashing) remain identical.

Related

• Validators - Validator overview
• Slashing - Penalty details
• Requirements - Running a validator
• Governance Parameters - Adjustable parameters