Consensus & Validators

TL;DR

Asentum uses Tendermint-style BFT proof-of-stake with a rotating ~100-validator committee selected each epoch by stake-weighted lottery. The protocol is permissionless after genesis — anyone who bonds the minimum stake is eligible. Finality lands as soon as 2/3 of committee voting power has signed off, which means near-instant finality with no chain reorganizations. The 100-validator committee size is the load-bearing design choice that makes post-quantum signatures fit inside a residential bandwidth budget.

Why Tendermint-style BFT

We considered three families of consensus algorithm:

• Tendermint-style BFT. Instant finality, well-understood, widely deployed (Cosmos, Celestia, many chains). Strong reference implementations exist (CometBFT). Fits a small-committee design that bounds bandwidth — which is exactly what we need to fit post-quantum signatures.
• Algorand-style VRF lottery. Better at very large validator sets, more complex. PQ-safe VRFs are not yet production-ready, so we'd be inventing crypto we don't want to invent.
• Pure longest-chain PoS (Ouroboros-style). Probabilistic finality, simpler crypto, worse UX. Wallets have to explain "transactions can be reorged" and that's the wrong UX trade for a chain that's trying to feel premium.

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 each at 5-second blocks). Membership is determined by a hybrid model designed to give big infrastructure operators a stable seat AND give small retail operators real turns at producing blocks:

• Stable core (50 slots) — the top 50 bonded validators by stake, every epoch. They're the always-on infrastructure layer; their slots are unconditional.
• Rotating reserve (50 slots) — randomly selected each epoch from the bonded-but-not-core pool. Eligibility requires a submitEpochEntry transaction during the entry window of the prior epoch — a cheap proof that the validator is online and ready. Selection uses a deterministic on-chain PRF (BLAKE3-seeded Fisher-Yates) over the eligible pool, with the seed derived 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. This means a few high-stake infrastructure validators can keep producing blocks even if many small-stake retail validators are temporarily offline. When external stake grows past 1/3 of total, external availability becomes load-bearing — at which point the chain has truly decentralized.

The block proposer for each block is chosen stake-weighted via BLAKE3(height || round) mod totalStake — validators with higher stake propose proportionally more often. With equal stakes the rotation looks random-but-fair across the committee; with unequal stakes a 2× whale proposes 2× as often as a 1× peer. Same hash-mod-stake math is used for the rotating-reserve selection.

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 for the current round 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 signed with their ML-DSA-65 key.
6. Commit. If 2/3 of committee voting power pre-commits for the same block, the block is finalized and added to the chain. No reorgs are possible.

The finalized 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: any larger and consumer-grade residential broadband can't keep up with finalization overhead.

Cryptography

All consensus signatures (pre-vote, pre-commit, block proposals) use ML-DSA-65 (Dilithium3), the NIST FIPS 204 post-quantum signature scheme. 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 standardized yet. We compensate by capping committee size — see above.

For the full cryptographic story, see Post-Quantum Cryptography.

Permissionless after genesis

At genesis, the initial validator set is seeded by the incentivized testnet conversion (Phase 3 of the rollout). After that, anyone who meets two criteria is eligible to be a validator:

1. Bond the minimum self-stake (50,000 ASE).
2. Run the Asentum node binary in validator mode.

That's it. No KYC, no whitelist, no governance vote, no approval process. Stake-weighted lottery means even small validators have a chance of being selected — they just have a smaller chance per epoch than larger ones.

Diminishing-returns soft cap above 100K ASE per validator. Stake above the cap earns proportionally less reward, discouraging hoarding into a single validator identity without preventing it outright. (Final cap is a placeholder pending real-data tuning.)

Service nodes

Asentum has two distinct node roles with different security and reward models, 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 run the same node software in a different mode and provide useful work — RPC requests, transaction relaying, historical data serving, light-client proof generation. The design is for service nodes to earn micro-fees from a dedicated pool funded by a fraction of the base fee pre-burn; the pool routing is planned work, not yet live on the current testnet.

Default install runs in service-node mode — zero risk, small steady earnings. Bonding stake "promotes" a node into the consensus validator candidate set. Service nodes are how desktop users participate without taking on slashing risk.

Tradeoffs we accept

• Bounded validator count. ~100 active validators per epoch (with thousands of standby candidates) 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 optimizing for maximum throughput. The design target is decentralization and security, not benchmark wins.
• No bytecode-level EVM compatibility. JSON-RPC compatibility means MetaMask and ethers.js work, but Solidity contracts don't run unmodified. Contracts must be JavaScript.
• No privacy / ZK in v1. Privacy features are deliberately deferred. The chain is fully transparent.
• No sharding or L2 native support in v1. A single, simple, well-understood chain ships first.