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 produce blocks and earn. It scales to hundreds of validators, because a large base of small validators can come and go without ever stalling finality.

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 validator set grow well past a small fixed committee.

The validator set

The active set tracks on-chain staking state each epoch. Bond the minimum, submit an epoch entry, and you are producing blocks the next epoch. It is computed deterministically from staking state using a BLAKE3-seeded shuffle over eligible validators, with the seed derived from the prior epoch, so every node arrives at the same set without a coordination round. The set is not capped at a small committee. It scales to hundreds of validators.

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. This is what makes it safe to grow the set. A large base of small, faucet funded validators can join, sign, and earn, and because each carries little stake weight, the set can churn (validators joining, dropping offline, rejoining) without ever threatening finality. The heavy, always on validators carry enough weight to keep finalizing on their own.

Block production slots rotate across the active set. With equal stakes the rotation is even across validators. External and community validators are first class here: they bond, 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 is eligible to validate:

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. Small validators earn rewards proportional to the blocks they produce and the finality votes they cast.

Concentration is handled by a per-block reward cap. Stake beyond the cap earns proportionally less, and the excess redistributes to other active validators. 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.