Consensus & Validators

A rotating ~100-validator committee, stake-weighted quorum, and finality the moment 2/3 of voting power signs off. Why this shape, and what it trades away.

TL;DR. Tendermint-style BFT proof-of-stake with a rotating ~100-validator committee, selected each epoch by stake-weighted lottery. Permissionless after genesis. Finality lands once 2/3 of committee voting power signs — no reorgs.

Aevum runs Tendermint-style BFT proof-of-stake with a rotating ~100-validator committee, chosen each epoch by a stake-weighted lottery. It's permissionless after genesis for anyone bonding the minimum stake. Finality lands the moment 2/3 of committee voting power signs off — no reorgs, no waiting for confirmations to stack up.

Why Tendermint-style BFT

Three families of consensus got evaluated.

Tendermint-style BFT gives instant finality, has years of production mileage across Cosmos and Celestia, and has a strong reference implementation in CometBFT. A bounded committee also happens to be exactly what post-quantum signature overhead needs.

Algorand-style VRF lottery scales to bigger validator sets, but production-ready post-quantum-safe VRFs don't really exist yet — adopting it would mean inventing cryptography Aevum doesn't need to invent.

Pure longest-chain PoS (Ouroboros-style) is cryptographically simpler but only gives probabilistic finality. Reorgs and reversible transactions are a bad experience to ship on purpose.

Tendermint won on three points: instant finality, proven production deployments, and a bounded-committee structure that happens to fit post-quantum signature overhead without extra invention.

The rotating committee

The active committee caps at 100 validators per epoch — roughly 4 hours, at 5-second blocks. Membership is a hybrid model, balancing infrastructure-grade stability against room for retail operators to actually get in:

• Stable core (50 slots) — the top 50 bonded validators by stake, every epoch. Unconditional, always-on infrastructure.
• Rotating reserve (50 slots) — randomly selected each epoch from bonded-but-not-core validators who submitted an submitEpochEntry transaction during the prior epoch's entry window. Selection uses a deterministic on-chain pseudo-random function (BLAKE3-seeded Fisher-Yates), seeded from the prior epoch's final block hash — every node arrives at the same committee independently, with no coordination needed.

Quorum is stake-weighted, not count-based: blocks commit once 2/3 of total active-committee stake signs, not 2/3 of validator count. That means high-stake infrastructure can keep producing blocks even if a chunk of smaller retail validators go offline — and it means any outside stake above 1/3 of the total is genuinely load-bearing, not decorative.

Block proposers are chosen by stake-weighted determinism — BLAKE3(height || round) mod totalStake — so a validator with 2× the stake proposes roughly 2× as often. Rotating-reserve selection uses the same hash-mod-stake math.

How a block becomes final

1. Full nodes receive POSTed transactions, validate them, and relay them across peer mempools over HTTP
2. The current proposer selects mempool transactions, validates each one (signature, nonce, balance, gas), and assembles a candidate block
3. The proposer broadcasts the candidate to the committee
4. Pre-vote — committee members validate the candidate and broadcast ML-DSA-65 pre-vote signatures
5. Pre-commit — once 2/3 of voting power pre-votes identically, members broadcast ML-DSA-65 pre-commit signatures
6. Commit — once 2/3 of voting power pre-commits identically, the block finalizes and joins the chain. No reorgs are possible.

A finalized block carries pre-commit signatures from roughly 100 validators — around 330KB of signature data. That number is exactly why the committee caps near 100: bigger committees would push finalization overhead past what residential broadband can carry.

Cryptography

All consensus signatures — pre-vote, pre-commit, block proposals — use ML-DSA-65 (Dilithium3), the NIST FIPS 204 post-quantum scheme. Blocks hash with BLAKE3. Addresses derive as BLAKE3(pubkey)[0:20] with an EIP-55-style checksum. See Post-Quantum Cryptography for the full detail.

v1 doesn't use signature aggregation — Dilithium doesn't support it, and standardized post-quantum aggregation schemes don't exist yet. Capping the committee size is how that gap gets absorbed.

Permissionless after genesis

The genesis validator set comes from converting incentivized testnet participants (Phase 3 of the rollout). After that, joining requires exactly two things:

1. Bonding a minimum self-stake of 50,000 AEV
2. Running the Aevum node binary in validator mode

No KYC, no whitelist, no governance vote, no approval step. The stake-weighted lottery means small validators get real, if proportionally smaller, odds of entering the rotating reserve. A diminishing-returns soft cap above 100,000 AEV per validator discourages — without hard-blocking — concentrating stake into one identity; exact numbers are still being tuned against real data.

Service nodes

Two node roles run on the same CLI binary with very different risk profiles.

Consensus validators bond stake, sit in the rotating BFT committee, vote on blocks, carry slashing risk, and earn a share of the block reward.

Service nodes bond nothing and carry zero consensus slashing risk. Same software, different mode: serving RPC requests, relaying transactions, serving historical data, generating light-client proofs. They earn micro-fees from a pool funded by a slice of the pre-burn base fee — pool routing is planned infrastructure, not yet active on testnet.

The default install runs in service-node mode: no slashing exposure, modest steady earnings. Bonding stake is what elevates a node into validator-candidate territory — which is what makes it possible for someone to participate meaningfully from a laptop with zero downside first.

Tradeoffs we accept

• Bounded validator count — ~100 active per epoch, thousands of standby candidates, well short of Ethereum's hundreds of thousands. This is the direct cost of post-quantum signature overhead within residential bandwidth.
• No raw-TPS optimization — the design isn't chasing a benchmark number over decentralisation and security.
• No bytecode-level EVM compatibility — JSON-RPC compatibility gets you MetaMask and ethers.js, not a drag-and-drop port of a Solidity contract.
• No privacy or ZK features in v1 — deliberately deferred, not forgotten.
• No sharding or native Layer-2 in v1 — one chain, well understood, first.