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

Each epoch, a rotating committee of approximately 100 validators is selected from the eligible candidate set. Selection uses a deterministic on-chain PRF seeded by recent block hashes — not a VRF, since PQ-safe VRFs are not yet production-ready.

Selection is stake-weighted: validators with more bonded stake (their own self-bond plus delegations from token holders) have proportionally higher chances of being selected each epoch. This is the standard mechanism that makes proof-of-stake economically secure.

The block proposer for each block is chosen round-robin within the committee for the duration of an epoch. Every active committee member proposes blocks in turn, then the committee rotates.

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 (placeholder: 500 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.