How a Block Becomes Valid: AntiQua Consensus in Plain Words

Blythex

What does it actually take for a block to be accepted? Why do mining rewards sit locked for 100 blocks? And why doesn't AntiQua retarget difficulty every 2,016 blocks like Bitcoin?

This post walks through the consensus rules as the node enforces them today. Every number was read out of the NodeCore source in September 2026 – nothing here comes from a whitepaper that might have drifted from the code.

TL;DR

Proof-of-Work, two stages: a fast hash against the target, plus RandomX keyed to the previous block.
Difficulty adjusts every single block (ASERT), not every two weeks.
50 AQA per block, halving every 420,000 blocks. Hard cap 56 million AQA, ever.
Mining rewards are locked for 100 blocks – roughly 17 hours on mainnet.
A reorg deeper than 30 blocks is refused outright, whatever work it claims to carry.
1 confirmation is enough to spend. 6 is what wallets and exchanges treat as settled.

Proof-of-Work, in two stages

A valid block has to clear two different hashes, and they do different jobs.

Stage one – the fast hash. The block header is hashed with double SHAKE256 to 32 bytes, and that has to come out below the target encoded in the block's nBits. This is the familiar part: lower target, more attempts needed.

Stage two – RandomX. The same block must also produce a valid RandomX digest. RandomX is memory-hard: it runs a small randomly generated program through a couple of gigabytes of working memory, which is something general-purpose CPUs do well and purpose-built ASICs do badly. The key for that program is the hash of the previous block, so it changes with every block and nobody can precompute anything.

There's an asymmetry built in that matters for anyone running a node:

	Memory	Used for
Mining	Full dataset (~2 GiB)	Producing blocks, fast
Verifying	Light mode	Checking other people's blocks

Both arrive at the same digest. That's the whole point: mining is expensive, checking is cheap. A node validating the chain doesn't rebuild a 2 GiB dataset for every block it sees. When your node loads its existing chain from disk it's cheaper still – it replays the stored digest rather than recomputing it.

On phones: the Android build compiles without RandomX entirely. It's a light client – it verifies headers and its own transactions, and it cannot mine. That isn't a restriction someone added, it simply doesn't contain the machinery.

Every non-genesis block also carries an ML-DSA-87 signature from the miner – the same post-quantum signature scheme used for transactions.

Difficulty: ASERT, every block

Bitcoin recalculates difficulty every 2,016 blocks, which is roughly two weeks. If hash power drops sharply the day after an adjustment, the chain crawls until the next one.

AntiQua uses ASERT instead, and it recalculates for every single block:

target = anchor_target × 2^((elapsed − ideal_elapsed) / half_life)

In words: measure how far ahead or behind schedule the chain is, and adjust exponentially. Blocks coming too fast tighten the target smoothly; blocks coming too slowly loosen it. There is no cliff to fall off and no fortnight to wait.

	Mainnet	Testnet
Target block time	600 s (10 min)	120 s (2 min)
Half-life	6 hours	72 minutes
Median-time window	10 blocks	10 blocks

The half-life sets how aggressive the correction is: a chain running one half-life behind schedule gets its target doubled.

One thing that trips people up when reading the code: there's a legacy field named difficulty_adjustment_interval sitting at 10,000. It is not a Bitcoin-style retarget interval and it has no say in consensus. ASERT is the only thing that sets nBits. Likewise, the "difficulty" number you see in explorers is a display value derived from the target – readable for humans, meaningless to the protocol.

Timestamps: you can't lie much

Two rules bound a block's timestamp, and they pull in opposite directions:

It must be strictly greater than the median of the last 10 blocks' timestamps. That stops a miner dragging time backwards to make difficulty look easier.
It must be no more than one hour in the future. That stops the opposite trick.

Together they leave a narrow, self-correcting window. A block outside it is rejected at validation, not merely frowned upon.

Transactions have a separate, looser rule – up to two hours ahead is accepted into the mempool. Don't confuse the two; they're different checks in different places.

The block reward, and where 56 million comes from

The first five blocks are special. After that, it's regular mining forever:

Height	Reward	What it is
0	50 AQA	Genesis
1	3,000,000 AQA	Bug bounty fund
2	4,000,000 AQA	Charity fund
3	1,500,000 AQA	Development fund
4	1,500,000 AQA	Server and infrastructure fund
5 and up	50 AQA	Mining, halving from here

The four fund blocks are the whole reason the supply chart has a step at the start – 10 million AQA was issued in four blocks, publicly, at known heights, into known addresses. There is no hidden issuance anywhere else, and the node enforces that: if a coinbase ever tried to mint more than the schedule allows, the block is rejected.

Halving happens every 420,000 mining blocks, counted from height 5. So the first halving lands at height 420,005, not 420,000 – a small detail that matters if you're writing a supply calculator. The reward halves by integer division until it reaches a floor of 0.1 AQA.

The total is capped in code:

56,000,000 AQA  =  42 M mining  +  10 M funds  +  4 M relay lottery

That cap isn't decorative. If a block's reward would push total issuance past it, the node sets the reward to zero and the block still has to be valid without it.

On top of the mining reward, a block may carry an extra coinbase output of up to 1.5 AQA for the Relay Reward Lottery – paid from its own 4 million budget, not out of the mining share.

Confirmations: 1, 6, and 100

Three different numbers, three different jobs:

Depth	Meaning
1	Enough to spend an output again. The tip block counts as one confirmation.
6	What wallets and exchange integrations treat as settled.
100	Coinbase maturity – how long a mining reward stays locked.

The 100-block lock on mining rewards exists because the tip of a chain is the part that can still be replaced. If a miner could spend a reward immediately and the block were then orphaned, those coins would have come from a block that no longer exists. A hundred blocks is far beyond any realistic reorg.

At target block times that's about 16.7 hours on mainnet and 3.3 hours on testnet – assuming the chain holds its pace, which is an assumption and not a promise.

One more rule people hit in practice: you can't chain a transaction onto another transaction that is still sitting in the mempool. An input needs at least one confirmation. Spend, wait for a block, then spend the change.

Reorgs: a hard ceiling, not a preference

Most chains accept whatever branch carries the most work, however deep the switch. AntiQua refuses past a point:

Depth	What happens
20 blocks	Warning in the log – possible network partition
30 blocks	Refused. The node will not reorganise this deep, whatever work is offered
288 blocks	Considered final; undo data gets pruned below this

A reorg 30 blocks deep is not a normal event on a healthy network – it's either a serious partition or someone with enough hash power to rewrite half a day. In both cases stopping and alerting is better than silently rewriting history. The node stops.

PoS checkpoints: a bolt, not a second consensus

Every 100 blocks, the network forms a checkpoint. This is the part most easily misread, so plainly:

Proof-of-Work alone decides which blocks are valid. Checkpoints don't mint, don't vote on blocks, and carry no stake weight. They are a bolt against deep reorgs, and what they measure is mining activity: how many blocks each miner produced in the window of the last 100 heights. A checkpoint is confirmed when miners representing more than 51 % of that window agree on it.

A second phase requires a minimum number of distinct miners – 3 on mainnet, 2 on testnet – so a single miner can't confirm checkpoints alone during quiet periods.

For anyone building from source: the checkpoint system sits behind a compile flag. A build without it logs a loud warning at startup and is not consensus-compatible with release nodes – it's missing the reorg bolt entirely. If you compile your own node, leave the flag on.

How a node catches up

Sync is header-first: headers come down before bodies, so a node can check the chain of work before downloading anything heavy. Caps keep that from being abused: at most 2,000 headers per response, no more than 4,096 unconfirmed headers pending, and from 100 blocks in, the checkpoint gate has to be satisfied before the sync goes on. Failing that gate is the single most expensive thing a peer can do – see the ban system post.

One distinction that shows up in logs: a compact stub is not a full block. A block counts as a complete body only when it actually carries its transactions, merkle root and signature. Stubs get re-requested rather than accepted – and a peer sending one is not penalised for it.

Spam protection at the node level

Separate from fees, and separate from block PoW: a sender's first 5 pending transactions pass normally. From the sixth, each one has to carry a tiny proof-of-work – 14 leading zero bits on its hash. Unnoticeable once, expensive ten thousand times.

This is node policy about what enters a mempool, not a consensus rule about what may go in a block. (More in the fee post)

The rules in one place

Two-stage PoW – double SHAKE256 against the target, plus RandomX keyed to the previous block
ASERT adjusts difficulty every block; 600 s target on mainnet, 120 s on testnet
Timestamp above the 10-block median, at most 1 hour ahead
50 AQA per block from height 5, halving every 420,000 (first at 420,005), floor 0.1 AQA
56 M AQA hard cap: 42 M mining, 10 M funds in blocks 1–4, 4 M relay lottery
1 confirmation to spend, 6 for settled, 100 for mining rewards
30 blocks is the hard reorg ceiling; checkpoints every 100 blocks bolt it down
Header-first sync; a compact stub is never a full body

Questions?

Miner wondering about ASERT behaviour after a hash-rate swing? Exchange operator asking why 6 and not 60? Ask below.

— Blythex