Consensus & Validators

Canonical reference · Estimated read time: 10 minutes

Why Tendermint-style BFT

We considered three families of consensus algorithm:

• Tendermint-style BFT. Instant finality, well-understood, widely deployed (Cosmos, Celestia). Strong reference implementations exist. Fits a small-committee design that bounds bandwidth — exactly what we need for post-quantum signatures.
• Algorand-style VRF lottery. Better at very large validator sets, more complex. PQ-safe VRFs are not yet production-ready.
• Pure longest-chain PoS. Probabilistic finality, simpler crypto, worse UX. Wallets have to explain "transactions can be reorged."

Tendermint won on three criteria: instant finality (great UX), load-bearing prior art (Cosmos has been running it at scale for years), and the bounded committee size that's structurally compatible with PQC signature overhead.

The rotating committee

The active committee is capped at 100 validators per epoch (~4 hours at 2-second blocks). Membership uses a hybrid model:

• Stable core (50 slots) — the top 50 bonded validators by stake, every epoch. They're the always-on infrastructure layer.
• Rotating reserve (50 slots) — randomly selected each epoch from the bonded-but-not-core pool. Eligibility requires a submitEpochEntry transaction during the prior epoch's entry window — a cheap proof that the validator is online.

Selection uses a deterministic on-chain PRF (BLAKE3-seeded Fisher-Yates) over the eligible pool, seeded from the prior epoch's last block hash. Every node arrives at the same committee without a coordination round-trip.

BFT quorum is stake-weighted, not count-weighted. A block commits when validators representing 2/3 of total active-committee stake have signed — not 2/3 of the validator count.

How a block becomes final

When you submit a transaction, this is what happens:

1. The transaction is POSTed to any full node, which validates it and fans it out over HTTP to every configured peer mempool.
2. The active block proposer picks transactions from its mempool, validates each one (signature check, nonce, balance, gas), and bundles them into a candidate block.
3. The proposer broadcasts the candidate block to the rest of the committee.
4. Pre-vote. Each committee member checks the candidate block and broadcasts a pre-vote signed with their ML-DSA-65 key.
5. Pre-commit. If 2/3 of committee voting power pre-votes for the same block, each committee member broadcasts a pre-commit.
6. Commit. If 2/3 of committee voting power pre-commits, the block is finalised. No reorgs are possible.

The finalised block carries the pre-commit signatures from the committee — roughly 100 ML-DSA-65 signatures, ~330 KB of signature data per block. That number is the reason the committee is capped at ~100.

Cryptography

All consensus signatures (pre-vote, pre-commit, block proposals) use ML-DSA-65 (Dilithium3). Block hashes use BLAKE3. Address derivation is BLAKE3(pubkey)[0:20] with an EIP-55-style mixed-case checksum.

No signature aggregation in v1. Dilithium doesn't aggregate, and PQC aggregation schemes aren't standardised yet. We compensate by capping committee size. For the full cryptographic story, see Post-Quantum Cryptography.

Permissionless after genesis

At genesis, the initial validator set is seeded by the incentivised testnet conversion. After that, anyone who meets two criteria is eligible:

• Bond the minimum self-stake (32,000 VLD at mainnet launch — subject to governance).
• Run the Valdium node binary in validator mode.

No KYC, no whitelist, no governance vote, no approval process. Stake-weighted lottery means even small validators have a chance of being selected each epoch.

Service nodes

Valdium has two distinct node roles, both shipped in the same CLI binary:

• Consensus validators bond stake, sit on the rotating BFT committee, vote on blocks, and are slashable. They earn a fixed share of the block reward.
• Service nodes have no validator stake and no consensus slashing risk. They provide useful work — RPC requests, transaction relaying, historical data serving. They earn micro-fees from a dedicated pool funded by a fraction of the base fee pre-burn.

Default install runs in service-node mode — zero risk, small steady earnings. Bonding stake "promotes" a node into the consensus validator candidate set.

Tradeoffs we accept

• Bounded validator count. ~100 active validators per epoch is smaller than Ethereum's hundreds of thousands. We accept this because it's the only way PQC signatures fit inside a residential bandwidth budget.
• No raw-TPS chase. We are explicitly not optimising for maximum throughput.
• No bytecode-level EVM compatibility. JSON-RPC works; Solidity doesn't.