Consensus & Validators

TL;DR

Asentum runs a two-layer consensus. Aura handles block production: each validator in the active set gets timed slots and produces a block when its slot comes up. GRANDPA handles finality: a block is finalized once validators representing two thirds of staked weight have voted for it. Finality is stake weighted, not headcount weighted, and it trails the latest block by a few blocks rather than gating every block on a vote. The set is permissionless after genesis: bond the 500 ASE minimum and you are a validator candidate. Each epoch the chain fills a 100-seat signing committee by stake, and only seated validators produce blocks, cast finality votes and earn signing rewards. The candidate pool scales to hundreds of validators.

Why Aura plus GRANDPA

Earlier testnets ran a Tendermint-style engine where every block went through pre-vote and pre-commit rounds before it finalized. That gave instant finality, but it welded block production and finality into one round-based loop, and under real cross-continent latency those rounds could drift and stall the chain. v3 splits the two jobs apart:

• Aura (Authority Round) produces blocks. Each validator in the active set is assigned slots and produces a block when its slot arrives. Production never waits on a voting round, so a slow or offline validator costs at most a skipped slot, not a stalled chain.
• GRANDPA finalizes them. It votes on chains of blocks rather than one block at a time, and finalizes once two thirds of staked weight agree. Finality runs alongside production and trails it by a few blocks.

The payoff is graceful degradation. Under latency or churn, finality slows down instead of freezing, and the chain keeps producing blocks the whole time. This is the property that lets the candidate pool grow into the hundreds while finality stays steady.

The validator set

Bonding the 500 ASE minimum makes you a candidate, not a signer. The signing committee holds 100 seats, chosen each epoch by stake: the top 50 stakes take the core seats and the next stakes fill the reserve seats, 100 in total. When several validators tie at the cutoff, those seats rotate between them. The committee is computed deterministically from on-chain staking state, so every node arrives at the same set without a coordination round.

The cutoff moves as people bond. With a couple of hundred candidates it is currently about 1,350 ASE; check the live figure on the explorer's validators page. Validators below the cutoff stay waiting (dormant): they keep syncing but do not produce blocks, do not sign finality votes and do not earn signing rewards. Bond more ASE to move above the cutoff. A seated validator that submits its epoch entry signs from the next epoch.

Finality quorum is stake weighted, not count weighted. A block finalizes when validators representing two thirds of total staked weight have voted for it, not two thirds of the validator count. Because each small validator carries little stake weight, the committee can churn (validators joining, dropping offline, rejoining) without threatening finality. The heavy, always on validators carry enough weight to keep finalizing on their own.

Block production slots rotate across the seated committee. With equal stakes the rotation is even across validators. External and community validators are first class here: once their stake wins a seat they produce blocks, sign, and earn rewards proportional to what they actually do, from behind a home connection.

How a block becomes final

When you submit a transaction, this is what happens:

1. The transaction is POSTed to any node, which validates it and gossips it to peer mempools.
2. When a validator's Aura slot comes up, it picks transactions from its mempool, validates each one (signature, nonce, balance, gas), and produces a candidate block.
3. The block propagates across the network. Other validators import it and build on it, so production keeps moving without waiting for a vote.
4. GRANDPA finality runs alongside. Validators vote on the chain they have seen, signing with their ML-DSA-65 key. Once votes representing two thirds of staked weight agree on a block, that block and everything before it is finalized. Finalized blocks do not reorg.

Finality trails the latest produced block by a few blocks, typically a matter of seconds, rather than blocking every block on a synchronous vote. Wallets and explorers show both the latest block and the finalized head so you always know what is settled.

Cryptography

All consensus signatures (block production and GRANDPA votes) use ML-DSA-65 (Dilithium3), the NIST FIPS 204 post-quantum signature scheme. Block hashes use BLAKE3. Address derivation is BLAKE3(pubkey)[0:20] rendered as an ase1 bech32 string.

No signature aggregation yet. Dilithium signatures are large and do not aggregate, and post-quantum aggregation schemes are not standardized. Stake-weighted finality is what keeps this in budget: the chain finalizes on the votes of the highest-weight validators without waiting on every small one, so the finality proof stays bounded even as the set grows into the hundreds.

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

Permissionless after genesis

The initial validator set is seeded at genesis. After that, anyone who meets two criteria becomes a validator candidate:

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

That is it. No KYC, no whitelist, no governance vote, no approval process. To sign and earn signing rewards, a candidate also needs enough stake to clear the committee cutoff described in The validator set. Seated validators earn rewards proportional to the blocks they produce and the finality votes they cast.

Concentration is handled by a per-block reward cap. No validator earns more than 10% of a block's rewards, and the excess returns to the reward pool rather than being paid to anyone else. This discourages hoarding into a single validator identity without preventing it outright.

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, join the active set, produce blocks, cast GRANDPA finality votes, and are slashable. They earn a 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. That pool routing is planned work, not yet live on the current testnet.

Default install runs in service-node mode, which carries zero slashing risk. Bonding stake promotes a node into the validator candidate set. Service nodes are how desktop users can help run the network without taking on slashing risk.

Tradeoffs we accept

• A validator set in the hundreds, not the hundreds of thousands. Post-quantum signatures are large and do not aggregate yet, so finality overhead still grows with the number of signers. Stake-weighted finality pushes that ceiling up a long way, but the set is bounded by design.
• Finality is fast, not instant. It trails production by a few blocks instead of landing in the same step. We take that trade because it keeps the chain producing under latency instead of freezing.
• No bytecode-level EVM compatibility. JSON-RPC compatibility means MetaMask and ethers.js work, but Solidity contracts do not run unmodified. Contracts are written in JavaScript.
• No privacy or ZK yet. Privacy features are deferred. The chain is fully transparent.
• No sharding or native L2 yet. A single, simple, well-understood chain ships first.