AntiQua

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:

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.

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:

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:

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:

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

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

Running a node and seeing peers disappear? Before you go hunting for a firewall problem: most of what looks like a ban isn't one. This post lists exactly what earns a ban score in the AntiQua network, what only gets dropped, and how to tell the two apart.

TL;DR

• Every peer has a misbehaviour score. At 100 it gets banned. Below 100 is not a ban – the peer stays connected.
• 24 hours for full nodes, 1 hour for light and inbound peers.
• Rate limits don't ban. Too many messages? The message is dropped and that's the end of it.
• Two things ban you on the spot: failing the header checkpoint gate (+150) and parking more than 500 unconfirmed headers on a peer (+100).
• Behaving well earns credit back, but it never lifts a ban that has already started.

The threshold

Ban score >= 100  ->  banned
Ban score <  100  ->  nothing happens

That second line matters more than it looks. A score of 95 is not "almost banned" in any operational sense – your peer is connected, syncing and relaying exactly as before. Scores accumulate, they don't degrade your connection on the way up.

Light peers get the short ban on purpose: they sit behind mobile networks where the IP changes anyway, so a long ban would mostly punish whoever inherits the address next.

Bans are written to disk, so they survive a restart.

There is no manual ban. The node has no admin path that bans an address on the spot – reaching 100 through the scores below is the only way anyone gets banned. No operator, no plugin, no config file.

The two that ban you outright

Both are above the threshold on their own, deliberately.

The first: a peer that can't produce a valid checkpoint anchor is either running something that isn't this chain, or feeding you a fabricated history. There is no charitable reading of that.

The second is about memory. Headers you can't confirm sit in a cache. A peer that keeps stuffing that cache without ever delivering anything that checks out is filling your RAM, whether by malice or by being thoroughly broken. Either way you want it gone.

Two layers, two outcomes

Penalties come from two different places, and they don't behave the same way:

So a malformed frame ends the connection then and there, while an oversized inventory list only costs the message. Both add to the same score.

Protocol and handshake violations

None of these happen by accident on a healthy peer. They're the shapes a malformed or hostile client produces.

Sync, proofs and key rotation

The +60 only triggers under real conditions: at least 8 headers sent, and fewer than 20 % of them confirmed inside the window. A handful of misses costs nothing.

The +10 for an implausible height catches a specific lie – a peer claiming the chain is half a million blocks further along than it is, hoping you'll chase it.

Encrypted messaging and multisig

The topic messaging layer – the one carrying encrypted messages and multisig confirmations – has its own penalties. They follow one pattern: rate limits are cheap, forged signatures are not.

A bad signature is the expensive one because there's no innocent explanation. An oversized topic name is a broken client; a message signed with a key that doesn't verify is someone trying something.

Substitution vs. honest extras

This is the distinction worth understanding, because it separates an attack from an ordinary sync hiccup.

When your node sends a GetData request, it remembers which block hashes it asked for. Any block that comes back with a different hash counts as a mismatch. What happens next depends on the whole response, not on the mismatch alone:

Attack — score +30 per block:
the response contained mismatches, and not a single block you asked for, and no compact stubs either. Somebody answered a specific request with entirely different blocks. That's a substitution attempt.

Ordinary — no score at all:
the response contained at least one block you actually requested, plus extras. The extras are simply discarded. This happens constantly and legitimately: tip gossip, a retried announcement, a compact block's parent.

Also no score:
a compact stub instead of a full body; an empty headers response; a request that came back holding only headers you already had; headers that fall outside the checkpoint horizon. All of these are re-requested or quietly closed.

That last group is deliberate, and the reasoning in the code is worth repeating: a node catching up from genesis will legitimately produce batches full of headers you already know. Counting those toward the unconfirmed cache limit would ban honest peers for the crime of being helpful. So they don't count.

In one line: the right block plus noise is a normal peer. Only noise, when you asked for something specific, is an attack.

What is NOT banned

Worth stating explicitly, because these are exactly the situations operators come asking about:

If your node is losing peers and none of the scored events above appear in your log, you're looking at the wrong cause. Check your own connectivity, your port forwarding, and whether you're behind a NAT that drops idle connections.

Arriving with the next node release

One group of penalties is written but not yet in the build the network is running: malformed compact block traffic (a compact block with no header, a prefill entry carrying no transaction, transaction-index lists that are empty or out of range) and light client requests whose block query is neither a height nor a hash.

Today those messages are dropped without a score. After the next release build they cost between +10 and +35. Nothing an ordinary node or wallet sends is affected – these are shapes that only a broken or hostile client produces. Watch the Core Changelog for the release.

What stays unscored either way: a compact block that needs a follow-up request, a reconstruction that falls back to a normal GetData, a block that simply isn't held locally, and a peer that never answers the capability handshake (it's treated as a full node and life goes on).

Earning credit back

Credit never lifts an active ban. Once a ban is running, good behaviour reduces nothing – the clock has to expire. The credits exist so that a peer which occasionally trips a small penalty doesn't slowly accumulate its way to 100 over days of honest operation.

Eclipse protection: slots per subnet

An eclipse attack means surrounding your node with peers that all belong to the attacker, so you only see the chain they want you to see. The cheapest way to do that is to bring many addresses from one network block. So the number of peers from a single IPv4 /16 is capped:

Light clients get 16 for a practical reason: mobile carriers put huge numbers of customers behind shared address space, so a whole city can share one /16. Three slots would be full before breakfast, and gossip is skipped for light peers anyway, so they can't be used to feed you a false view of the chain the way a full peer could.

Slot budgets overall: 150 full peers by default, 32 light, 256 for archive nodes, a hard ceiling of 512 – and at most 75 unauthenticated inbound connections, a number that deliberately does not grow when you scale the others up.

Separately, your node watches its own peer diversity: fewer than 5 distinct subnets across at least 8 peers flags a possible eclipse. That's a warning, not a ban of anyone – it tells you to add peers from elsewhere.

The second score – and what it actually does

Everything above is the P2P layer: protocol violations, score 100, 24 hours, real disconnects.

The consensus module keeps a second, much tighter score for chain-level misbehaviour – a double-spend attempt costs 8, a replay 6, the threshold is 10, it decays by a point a minute and entries expire after 30 minutes.

What it does not do, today, is disconnect anyone. That score is written into the consensus module's own table and logged. Nothing in the networking code reads it back to drop a peer. So if you're looking for the reason a connection went away, this isn't it – check the P2P scores above.

It is useful for a different purpose: those log lines tell you a peer has been sending you double-spends, which is worth knowing even when the node keeps talking to it. If you see them repeatedly from the same address, that's a case for looking at the peer yourself.

If you think you've been banned unfairly

1. Look for the actual scored reason in the log. Every penalty above writes one.
2. If the reason is a rate limit, a dropped message or a closed connection without a score: that isn't a ban, keep looking.
3. If it's +150: your node and the peer disagree about history. Check you're on the right network, and that your build has the checkpoint flag compiled in – a build without it is not consensus-compatible with release nodes. (What the checkpoints do)
4. If it's +100: that peer buried you in headers it never backed up. Usually a broken or badly out-of-date node rather than an attacker.
5. Consensus log lines about double-spends are not the reason your peer disappeared.

Questions about a specific log line? Post it below – with the surrounding lines, the reason string is what matters.

— Blythex

Every now and then someone tries to send a few hundred satoshi and the wallet refuses. Nothing is broken – you've hit consensus rule #13, the dust limit. Here is exactly what it does and why it exists.

TL;DR

• The floor is 1,000 satoshi (0.00001 AQA). An output below that makes the whole transaction invalid.
• It's rejected, not collected. A dust output doesn't quietly go to the miner – the transaction never enters the mempool.
• Tiny change becomes tip. Leftover under 1,000 satoshi is added to the miner's tip instead of creating a coin.
• Mining rewards are the one exception – coinbase outputs may be smaller.
• The reason is storage, not economics: every output lives in the UTXO set of every full node, forever.

The rule

Any output below 1,000 satoshi (0.00001 AQA) is invalid.

That's it. A fixed floor in satoshi – not a formula, not a percentage, not something your node calculates from current traffic. Every node on the network uses the same number, so every node reaches the same verdict on the same transaction.

Note that this is not how Bitcoin does it. There, the dust threshold depends on the size of the output and the current fee rate, so it moves. On AntiQua it is one constant.

Why 1,000 – the real reason

It isn't about "too small to be worth anything". It's about who has to remember it.

Every unspent output goes into the UTXO set – the list of all spendable coins – and every full node keeps that list in memory and on disk for as long as the coin remains unspent. That list is the part of a blockchain that never shrinks on its own.

Without a floor, anyone could create millions of one-satoshi outputs for almost nothing and force every node on the planet to carry them indefinitely. That's not a theoretical worry: it's one of the cheapest denial-of-service attacks against a UTXO chain, and it has been used against others.

AntiQua has a second reason on top. Post-quantum signatures are big – several kilobytes per input. A coin worth 500 satoshi would cost far more in fees to spend than it is worth, so it would simply never be spent. It would sit in every node's UTXO set forever as pure dead weight.

There's a neat coincidence here: the minimum fee for a typical post-quantum payment (about 10 KiB at 100 satoshi per KiB) lands at roughly 1,000 satoshi – the same number as the dust limit. That's not the same rule, and the two are not linked in the code. But it does show the floor sits about where a coin stops being economically spendable.

What your wallet does instead

You will rarely meet this rule head-on, because the wallet handles it before you see it:

• Leftover change below 1,000 satoshi: no change output is created at all. The remainder is added to the tip. The miner gets it, you don't get a coin that would cost more to spend than it holds.
• Leftover up to 50,000 satoshi may optionally be folded into the tip as well – same reasoning, your choice.
• Anything above that comes back to you as a normal change output.

So if you ever wonder why the fee on a transaction is a little higher than the lane you picked: that's your own leftover, not a surcharge. (More in the fee post)

The one exception

Block validation allows coinbase outputs – the ones paying the miner – to fall below the limit. Everything else is held to the floor, including:

• ordinary payments
• contract transfers and contract change
• the identity output created when you deploy a contract
• relay lottery payouts (their minimum is the dust limit)

The exception exists for a plumbing reason, not a privilege: the coinbase is created by the miner inside the block and never passes through the mempool, where the check normally happens.

Not to be confused with

Frequently asked

Can I collect lots of dust and spend it together?
There is no dust in your wallet to collect – the transaction that would have created it was rejected. You can hold many small-but-valid coins, and those you can consolidate, but consolidating costs the input factor. Do it once when the chain is quiet.

Will the limit ever change?
The code notes it could be adjusted later by soft fork. Today it's a constant, and nothing in the node reads it from a config file. Any change would go through a network upgrade and be announced in the Core Changelog first.

I really want to send someone 500 satoshi.
Send 1,000. It is 0.00001 AQA.

Questions below.

— Blythex

Hey everyone

A forum is more than a place to post – for a project like AntiQua it has to be safe, private and usable for people from all over the world. Off-the-shelf plugins only got us part of the way there, so we built our own. This post walks you through every plugin we developed ourselves: why it exists and what it does for you.

Everything below runs on our own server. No tracking services, no third-party translation APIs, no data brokers.

1. Seed Protection

Why we built it
The number one way people lose crypto in communities is not a hack – it's a moment of panic. Someone's wallet won't sync, they ask for help and paste their recovery words into a post. Or a "support agent" sends a friendly DM asking for them. We wanted the forum itself to step in before that happens.

What it does

• Blocks recovery phrases in posts – topics, replies, edits and titles are checked before anything is saved. It understands our own post-quantum AIP-39 standard (24, 36 and 48 words, including checksum verification) as well as classic BIP-39 phrases, in all ten official wordlist languages.
• Blocks post-quantum private keys – ML-DSA and ML-KEM secret keys are recognised by their standardised size, whether pasted as hex or Base64. Transaction hashes and public keys are not affected.
• Protects your chats – without reading them. Before a chat message leaves your device, your own browser checks it and asks "Are you sure?" if it looks like a seed phrase or key. Nothing about this check is ever sent to our server. We do not scan, log or monitor private messages. Period.
• Scam warnings – if a message or post asks for your recovery phrase, pushes remote-access tools like AnyDesk, or promises to "double your coins", you'll see a warning right above it. This also runs only in your browser, and it speaks 12 languages.
• Impersonation protection – nobody can register or rename themselves to something that looks like a team member (think BIythex with a capital I, lookalike characters from other alphabets, or names like "Official Support").

Reminder: The AntiQua team will never ask for your recovery phrase, your private key or remote access to your computer. Anyone who does is a scammer.

2. Translate Button

Why we built it
Post-quantum security is a global topic, and good ideas shouldn't get lost because they were written in a different language. At the same time, we didn't want to ship your posts off to Google or DeepL.

What it does

• Every post has a translate button (next to Reply). One click translates the post – and the topic title for the first post – into your language. One more click shows the original again.
• Translation runs on LibreTranslate, self-hosted in its own container on our server. Your text never leaves AntiQua infrastructure.
• Supported languages: English, German, Spanish, French, Italian, Dutch, Polish, Portuguese, Russian, Turkish, Ukrainian and Chinese.
• Smart target language – your chosen forum language wins; if you never set one, your browser's language is used.
• Code stays code – code blocks, @mentions and links are left untouched, so commands and addresses are never "translated" into nonsense.
• Translations are cached, so popular posts load instantly for the next reader.

Honest note: this is machine translation. It's great for understanding a post, not for publishing a legal contract.

3. Legal Pages

Why we built it
A serious project needs a serious foundation. We wanted a legal notice, a privacy policy and community guidelines that describe what this forum actually does – not a generic template copied from somewhere.

What it does

• Adds the Legal notice, the Privacy policy and the Community guidelines – linked in the footer of every page.
• Every page is available in German and English with a one-click language toggle.
• The privacy policy documents the real data flows of this installation: self-hosted translation, local-only chat checks, what we store and for how long.
• You can withdraw your reCAPTCHA consent directly on the privacy page at any time.

4. Identicons

Why we built it
Rows of identical grey default avatars make it hard to tell who is who. We wanted every member to have a recognisable face from day one.

What it does

• Generates a unique, crisp 512 px identicon for every member who hasn't uploaded a picture.
• Your own uploads and your GitHub avatar are never overwritten – the identicon only fills the gap.

5. Emoji Packs

Why we built it
Emojis are half of how a community talks. We wanted full control over which packs are loaded and an easy way to add our own.

What it does

• Admins get a clear overview of every loaded emoji pack, including attribution and licence.
• Custom packs can be added simply by dropping images into a folder – no code required.
• Adds the emoji button to Quick Reply, so you don't have to open the full editor just to send a

Also under the hood

Besides our own plugins, we maintain fixes for several community plugins we rely on – for example reCAPTCHA v3 support that only loads after you give consent, a cleaner admin view for two-factor authentication, and a fully translated mentions admin panel. Every change is version-controlled on our own Git server, so updates never silently undo them.

Our principles in one line

Self-hosted. Privacy first. Built for a global post-quantum community.

We'll keep posting updates like this here in Development. Replies are very welcome: bugs, ideas, wishes – let us hear them

Cheers,
Blythex

Mining secures the chain. But a blockchain also needs nodes that pass things along – transactions, blocks, compact-block help. That work costs bandwidth and uptime, and on most chains it pays exactly nothing.

AntiQua pays for it. 4,000,000 AQA – 7.14 % of the total supply – belong to the Relay Reward Lottery, and the rules are enforced by consensus, not by a server we run.

How it works

Every block from height 5 onwards can pay 1.5 AQA to exactly one registered relay node. The payout is the second output of that block's coinbase, right next to the miner's reward – as public and verifiable as any other transaction.

Who wins is not decided by us and not by a queue:

1. All eligible candidates are sorted by their payout address
2. The winner's index is drawn from SHAKE-256 over the previous block's hash, with its own domain tag AQA/RELAY-LOTTERY-IDX/v1
3. Every node computes the same winner and rejects a block that pays someone else

If there is no eligible candidate, nobody gets a relay payout for that block – and the miner keeps the fees untouched.

How to register

Registration is an on-chain transaction, not a setting in a config file. It carries three things:

Bond	at least 0.5 AQA, locked in a dedicated output. The coin must already belong to your payout address, and coinbase coins need their 100 confirmations first
Proof-of-work	a RandomX (light) proof with its own domain AQA/RELAY-REG-POW/v3, over a block hash from the last 12 blocks. Difficulty scales with the number of candidates (target: 100)
Ownership proof	the transaction must spend a coin that belongs to the payout address, so nobody can register an address they don't control

In the desktop wallet that's the Node Rewards view; the CLI equivalent is relay register <payout address> after loading your wallet.

Not on Android. The Android build has no RandomX, so registration there fails by design. Use the desktop wallet or the CLI.

From registration to your first chance

Block H        registration is included
H + 6          activation_height – the candidate exists
H + 12         first block you can actually win (bias guard)
H + 1,440      registration expires (~10 days mainnet, ~2 days testnet)

After a win, your payout address has to sit out 144 blocks – about a day on mainnet – before it can win again. So a single node cannot collect block after block, and an expired registration simply drops out: the reward follows nodes that are actually online.

What it pays, and for how long

The budget is not created in one block like the ecosystem funds. It trickles out block by block, and every node tracks exactly how much has been emitted so far.

What protects the draw – and what doesn't

Honest engineering means naming the limits too.

What is protected:

• The bond makes mass registration expensive, and the proof-of-work makes it slow
• At most 5 registrations per block, and at most 32 waiting in the mempool
• Activation delay and bias guard (6 + 6 blocks) stop last-minute registrations aimed at the very next draw
• Cooldown of 144 blocks per payout address
• Fail-closed validation: if a node cannot check the bond, the block is rejected. A coinbase paying the wrong winner, or paying the miner too much, is invalid

What is not fully solved, and we say so openly:

• The draw uses the previous block's hash. A miner who is building that previous block can, in principle, grind it so that the next block favours their own node. This is a known, documented limitation of the current design, not an oversight. The bias guard does not remove it.

We consider that acceptable for now: the gain per block is 1.5 AQA, grinding costs real hashing, and the cooldown caps how often one address can benefit. If it ever becomes worthwhile, the seed can be hardened – and any such change would be announced in the Core Changelog first.

How to check it yourself

• Block detail in the explorer shows the relay winner and whether the payout came from the budget or from the fee fallback
• Coinbase breakdown of the block carries relay_lottery_sat and the winner address
• In the desktop wallet: the Node Rewards view shows candidates, budget and your own status

Where it fits in

Who	Gets paid	From
Miners	block reward + all fees in the block	42,000,000 AQA over the halvings
Relay nodes	1.5 AQA per block	4,000,000 AQA, then 5 % of fees
Ecosystem funds	one-time, in blocks #1–#4	10,000,000 AQA

More: AntiQua Tokenomics · How Fees Work

Questions?

Wondering whether your VPS is enough, how long the registration proof-of-work takes, or what happens when your node goes offline? Ask below.

— Blythex

Found a bug? Missing a feature? From today there's a proper place for it.

BugHive is live: https://bugs.antiqua-blockchain.com

It's our own bug tracker – self-hosted, open to read for everyone, and wired to the same team that writes the code.

One space per part of AntiQua

Project	What belongs there
Core	NodeCore: consensus, P2P, mempool, mining, wallet logic
Windows Desktop	the desktop wallet
Windows CLI	command-line node and wallet
Linux	node and wallet on Linux
Android	the Android app
Forum	this forum and our own plugins

Inside each project you'll find Bugs, Features and Backlog – backlog meaning "accepted, but not scheduled yet". So you can see not only what's broken, but also what's planned.

How to report something useful

You need an account to write, and you sign in with Telegram – no password, no e-mail address.

A good report takes two minutes and saves hours:

What happened:
What I expected:
Steps to reproduce:
Version / platform:

Screenshots help – just make sure they don't show a recovery phrase, a private key or a balance you'd rather keep to yourself.

Search first. If your issue already exists, a comment with your details is worth more than a second report.

Security bugs: please, not in public

If you found something that could cost people money – consensus, signatures, wallet, node – do not post the details publicly, neither here nor in BugHive.

• Report it through the Security category so we can fix it first
• In BugHive, reports labelled security are removed from public lists on the server; the direct link and the comments return "not found". Only the team and the reporter can see them.
• Responsible reports are what the Bug Bounty Fund (3,000,000 AQA) exists for – the details are in the tokenomics post

What's public

Reading is open to everyone, also without an account: projects, bugs, features, comments. Only writing needs a login. Keep that in mind when you attach logs – blur what shouldn't be public.

Staying up to date

Changes to BugHive itself are posted in the BugHive Changelog here in Development. Click the bell icon there and choose Watching if you want to follow along.

Go and try it: https://bugs.antiqua-blockchain.com – even a small report helps. Every bug that gets found before mainnet is one that never costs anyone a coin.

— Blythex

Hey everyone

This thread is the official changelog for BugHive, our own bug tracker at https://bugs.antiqua-blockchain.com. Whenever something changes there, it gets posted here as a new entry, newest at the bottom.

If you report bugs, request features or just want to follow how AntiQua is built, this is the one thread to keep an eye on.

What BugHive is

BugHive is where bugs, feature requests and planned work live – separate from the forum, so discussions stay here and tracked issues stay there.

Every project has its own space:

Project	What belongs there
Core	NodeCore: consensus, P2P, mempool, mining, wallet logic
Windows Desktop	the desktop wallet (GUI)
Windows CLI	command-line node and wallet
Linux	node and wallet on Linux
Android	the Android light wallet
Forum	this forum and our own plugins

Within a project you'll find Bugs, Features and Backlog – backlog meaning "accepted, but not scheduled yet".

What gets posted here

• New features in BugHive itself – new views, filters, workflow changes
• New projects added to the tracker
• Security and access changes – who can see what
• Maintenance – downtime, migrations, data cleanups
• Process changes – how to report, what a status means

How every entry is structured

So you can tell at a glance whether something affects you, each entry follows the same format:

BugHive update – date
Type: Feature · Fix · Security · Maintenance
Action required: No / Yes – what you need to do

What's new – short summary
Details – the changes in full

Never miss an update

Click the bell icon on this topic and choose Watching. You'll get a notification every time a new entry is posted here.

Reporting safely

• Never post exploit details for a security bug in public – not in BugHive, not in the forum. Report it through the Security category so the team can fix it first.
• Reports labelled security in BugHive are hidden from public lists and links. Only the team and the reporter can see them.
• Never share your recovery phrase, private keys or passwords in a bug report. Blur them in screenshots and log files.
• Everything else in BugHive is publicly readable, also without an account. Keep that in mind when you attach logs.

Questions & discussion

To keep this changelog clean and easy to read, replies are closed here. Got a question or an idea? Open a new topic here in Development – we read everything.

Cheers,
Blythex

What does it cost to send AQA? Who gets that money? And how does AntiQua stop spam without making everyone pay for it?

This post explains the AntiQua fee system exactly as it works in the node software today – no marketing numbers, just the rules the network enforces. Every number below was re-checked against the NodeCore source in September 2026.

TL;DR

• A tiny base fee + your tip. Every transaction pays a small, fixed minimum of 100 satoshi per KiB – a typical post-quantum payment about 0.00001 AQA. On top, you choose a tip: a higher tip gets you confirmed faster.
• Every fee goes to the miner. Nothing is burned, nothing goes to a hidden account.
• More inputs cost more – because every input carries a large post-quantum signature.
• Spam is stopped with work, not money: from the 6th pending transaction, your wallet has to solve a tiny proof-of-work.
• Everything is exact: all amounts are whole satoshi – no rounding, no floating point.

What a fee actually is

On AntiQua, the fee isn't a separate field you can fake – it's simply what's left over:

fee = sum of inputs − sum of outputs

Everything you don't send to a recipient or back to yourself as change is the fee, calculated to the exact satoshi (1 AQA = 100,000,000 satoshi). The node checks that this amount covers everything the transaction requires – otherwise it's rejected.

The fee is also part of the transaction hash: if you change the fee, you get a new transaction ID. Nobody can alter it on the way.

Base fee + your tip

Your fee has two parts:

1. The base fee – a fixed minimum set by consensus: 100 satoshi (0.000001 AQA) per started KiB of transaction size. "Started" is literal: 9,194 bytes round up to 9 KiB. A typical post-quantum payment is around 9–10 KiB, so the base fee is roughly 900–1,000 satoshi – about 0.00001 AQA. It applies to every transaction from block 1 on.
2. The tip – whatever you add on top for the miner:

• Low tip – still valid (even a tip of 0 is accepted, as long as the base fee is covered; the dust limit and spam protection still apply), but you may wait longer when blocks are busy
• Higher tip – miners pick your transaction first

Fixed, not adjustable: the base fee depends only on the block height – no node, miner or admin can raise it on the fly or tune it to its own mempool. The consensus code allows a ceiling of 1,000× the minimum, but the active value is the minimum, and nothing in the node moves it. Changing it would require a network upgrade, announced in the Core Changelog first.

Real example from our testnet milestone: sending 10 AQA with a 0.01 AQA tip – the miner collected the fees on top of the block reward, the receiver got exactly 10 AQA. (See the milestone post) That payment was made before the base fee went live – today the wallet would add about 0.00001 AQA on top.

What your wallet suggests

You don't calculate any of this by hand. The wallet adds the base fee automatically (it comes out of your change) and offers three lanes:

Lane	What it does
Economy	No extra tip at all – just the base fee. Fine when you're not in a hurry.
Recommended	The median tip per KiB that the network is currently paying, never less than the base rate.
Next block	The 90th percentile of current tips, at least one step above Recommended.

When the wallet has seen no recent traffic – an empty or fresh mempool – it falls back to the base rate for Recommended and twice that for Next block.

These lanes are wallet policy, not consensus. Another wallet may suggest different numbers; the network only enforces the base fee.

What happened to the relay fee?

Older wallet builds showed a third field called relay fee, and our earlier testnet posts mention it. It no longer has any role. The node requires zero for relay: the amount a transaction must cover is base fee + tip (+ contract deployment fee), nothing else.

The name always caused the same misunderstanding, so to be clear: a relay fee never went to relay nodes. Relay nodes are paid only through the Relay Reward Lottery – 1.5 AQA per block from its own 4 million AQA budget, never out of your transaction.

In practice: if your wallet still shows the field, leave it at 0 and use the tip. The tip is strictly better anyway: both raise your fee rate equally, but only the tip counts as the tie-breaker when two transactions have the same score.

Footnote: once the lottery budget is used up (in roughly 50 years), 5 % of all fees in a block go to the lottery winner. That's a share of the block's total fees – not "the relay fee goes to relays".

Why more inputs cost more

Every coin you spend (an input) has to be signed – and post-quantum signatures are big, several kilobytes each. A transaction that gathers many small coins is heavy for every node on the network. So the required fee grows with the number of inputs:

The factor applies to base fee and tip together, and it also lowers a transaction's priority in the mempool – it sits in the divisor of your fee rate, so a heavy transaction ranks below a light one paying the same absolute amount.

Practical tip: if your wallet has lots of tiny coins, consolidate them once in a quiet moment. At five inputs you are paying double the floor on every send.

Change that disappears into the tip

Sometimes a payment leaves a few hundred satoshi over. Your wallet will not hand that back as change, and that is deliberate:

• Leftover below 1,000 satoshi always becomes extra tip. An output that small would be invalid anyway – see the dust limit.
• Leftover up to 50,000 satoshi may optionally be folded into the tip instead of creating a new coin, to keep your wallet from filling up with crumbs that cost more to spend later than they are worth.
• Anything larger comes back to you as a normal change output.

So if the fee on your receipt looks slightly higher than the lane you picked: that is your own leftover change, not a surcharge.

Who gets confirmed first

Miners sort waiting transactions by a simple score:

1. Fee per KiB – how much you pay relative to the size of your transaction
2. Divided by the input factor – heavy transactions rank lower
3. Contract deployments get a small boost (see below)

On a tie: the higher tip wins, then the older transaction, then the smaller hash. Completely deterministic – no favourites.

The mempool holds up to 50,000 transactions or 500 MiB, whichever comes first.

What if I pay too little?

Then the transaction never enters the mempool, and a transaction that is not in the mempool is never passed on to anyone. You get an error straight away – FEE_TOO_LOW if the amount misses the policy floor, FEE_INSUFFICIENT if it covers the floor but not everything the transaction owes.

There is no second, lower "minimum relay fee" hiding behind this one. What the floor says is what the network takes.

And no, a light node isn't a way around it. A transaction gossiped in from a light client runs through exactly the same check as any other – the light path only serialises the fee fields, it never applies a floor of its own.

Where the money goes

Every fee in a block goes to the miner who found it:

Miner reward = block reward (50 AQA, halving) + all fees in the block

• Nothing is burned. Fees don't disappear, they pay the people securing the network.
• Relay nodes are paid separately – through the Relay Reward Lottery, 1.5 AQA per block from its own 4 million budget, not by taking a cut of your fee. (Details in the tokenomics post)
• In the far future – once the lottery budget is used up after roughly 50 years – 5 % of the block fees go to the relay winner, the rest stays with the miner.

Spam protection without making everyone pay

Making fees high enough to stop spam would make the network expensive for everyone. AntiQua keeps the base fee tiny and adds a separate limit instead:

1. Micro proof-of-work

• Your first 5 pending transactions are completely normal.
• From the 6th pending transaction (from the same sender), each one must carry a small proof-of-work – its hash needs 14 leading zero bits. For a normal user that's a blink; for someone trying to flood the network with thousands of transactions, it adds up fast.

2. A hard ceiling per sender

• The same owner can have at most 25 unconfirmed transactions waiting at once. Number 26 is refused with QUOTA_EXCEEDED until some of them confirm.
• That is the real admission limit, and it's the same number in the mempool and in the node's submit check. If you have read about 100, 200 or 1,000 anywhere: those numbers exist in older material but no code path enforces them.

Both are node policy, not consensus: they govern what a node accepts into its own mempool and passes on.

Plus the dust limit: outputs smaller than 0.00001 AQA are invalid, so nobody can clog the chain with worthless crumbs. How the dust limit works

Smart contract deployment fees

Deploying a smart contract adds a small, fixed deployment fee on top – depending on the template:

The deployment fee can rise up to 5× when the chain is busy – calculated only from on-chain data (block timing and number of contracts), so every node arrives at exactly the same number. Deployments also get a 15–25 % priority boost in the mempool, so contracts don't get stuck. Calling a contract later costs a normal transaction fee.

The rules in one place

1. Fee = inputs − outputs, exact to the satoshi, part of the transaction hash
2. Base fee 100 sat per KiB (consensus, from block 1) + your tip. There is no relay fee any more – the node requires zero for relay
3. More inputs → higher fee factor and lower priority; the factor hits base fee and tip together
4. Leftover change below 1,000 satoshi always becomes tip
5. 100 % of fees to the miner, nothing burned – relays are paid by the lottery
6. Micro proof-of-work from the 6th pending transaction; at most 25 unconfirmed per sender
7. Contract deployments: small fixed fee by template, up to 5× under load

Questions?

Wondering what fee to set, or how this compares to Bitcoin or Ethereum? Ask below – happy to explain.

— Blythex

How many AQA will ever exist? Who gets them – and how can you check that we keep our word?

This post lays out the AntiQua tokenomics in plain language: the total supply, how new coins are created, how the Relay Reward Lottery pays node operators, what the four ecosystem funds are for, and the rules that bind them. Everything here is enforced by the node software or verifiable on-chain – you shouldn't have to trust us, you should be able to check.

The big picture

Total supply: 56,000,000 AQA – a hard cap, enforced by consensus. The node rejects anything that would exceed it.

Allocation	Amount	Share
Mining rewards	42,000,000 AQA	75.00 %
Relay Reward Lottery	4,000,000 AQA	7.14 %
Charity Fund	4,000,000 AQA	7.14 %
Bug Bounty Fund	3,000,000 AQA	5.36 %
Dev Fund	1,500,000 AQA	2.68 %
Server & Infrastructure Fund	1,500,000 AQA	2.68 %

More than 82 % of all coins go to the people who run the network – 75 % to miners, another 7 % to relay nodes. There is no allocation for VCs. The remaining ~18 % keeps the project secure, running and useful to the world.

Mining: 42 million AQA, earned block by block

• Starting reward: 50 AQA per block
• Halving: every 420,000 blocks – the first one at block height 420,005
• Target block time on mainnet: 10 minutes → a halving roughly every 8 years, twice as long as Bitcoin
• Reward floor: the reward never drops below 0.1 AQA – miners always get paid, until the hard cap is reached

On testnet, blocks come every 2 minutes, so everything there runs five times faster – the 8-year figure applies to mainnet.

Relay Reward Lottery – 4,000,000 AQA

Miners aren't the only ones keeping AntiQua alive. Nodes that relay transactions and blocks do essential work too – so they get their own reward.

How it works:

• Register your node with a small bond of 0.5 AQA. A registration stays valid for 1,440 blocks (about 10 days on mainnet) and becomes active after 6 blocks.
• Every block from height 5 on pays 1.5 AQA to one registered relay node – as a second output of the block's coinbase, right next to the miner's reward.
• Fair rotation: a winner has to sit out for 144 blocks (about a day on mainnet) before winning again, and built-in guards prevent anyone from flooding or biasing the draw.
• Long-lasting: at 1.5 AQA per block, the 4 million budget lasts around 50 years on mainnet. After that, relays keep earning 5 % of the block fees.

Every lottery payout is part of a block – public and verifiable like any other transaction. The full rules – bond, registration, cooldown and the guards against gaming – are in Relay Reward Lottery. Running a full node? Relay lottery participation is switched on by default in the node config.

How the funds are created: in the open, one block each

The genesis block stays clean: it only contains the genesis message and the normal 50 AQA block reward. No fund money is hidden in it.

Right after genesis, the four ecosystem funds are created in four separate, dedicated blocks. In each of them, the block's coinbase is the fund – nothing else:

Block #0   Genesis           genesis message + 50 AQA mining reward
Block #1   Bug Bounty Fund   3,000,000 AQA
Block #2   Charity Fund      4,000,000 AQA
Block #3   Dev Fund          1,500,000 AQA
Block #4   Server Fund       1,500,000 AQA
Block #5+  mining            50 AQA per block + 1.5 AQA relay lottery

After block #4 the funds are closed for good – there are no further fund blocks, ever. Apart from these four one-time blocks, new AQA can only be created by mining and the relay lottery. No hidden mint, no admin key that prints coins.

The four funds – and the rules that bind them

Bug Bounty Fund – 3,000,000 AQA · Multi-sig 2-of-3

A post-quantum blockchain has to be battle-tested. This fund pays security researchers who find and responsibly report vulnerabilities, and finances professional security audits.

Severity	Guideline reward
Critical	up to 300,000 AQA
High	30,000 – 100,000 AQA
Medium	5,000 – 30,000 AQA

Available on demand – no vesting, because a critical bug can't wait for the next quarter. Every payout needs 2 of 3 signatures.

Charity Fund – 4,000,000 AQA · Multi-sig 2-of-3

Our way of giving back. The community votes on where the money goes, with a focus on environment, education and open source.

• Locked in an on-chain vesting contract: 250,000 AQA per quarter, 16 quarters, 4 years – starting with the fund block at mainnet launch
• Quarterly community vote on the recipients
• Every release needs 2 of 3 signatures

Dev Fund – 1,500,000 AQA · Single-sig, vested

Building a blockchain from scratch costs years of work and real money – servers, tools, audits. This fund recognises the initial development and keeps full-time development going.

• The full 1.5 million goes into an on-chain vesting contract
• Released linearly over 4 years – no big dump possible

Server & Infrastructure Fund – 1,500,000 AQA · Single-sig, vested

A network needs infrastructure: DNS seeders, archive and full nodes around the world, backups and redundancy.

• 250,000 AQA available right away to get the infrastructure running
• The remaining 1,250,000 AQA released linearly over 5 years

Enforced by the node software: the fund blocks are only created if Bug Bounty and Charity point to multi-sig addresses and Dev and Server to single-sig addresses – anything else is rejected. The vesting contracts use the VESTING template built into NodeCore.

How the fund keys are protected

• Cold storage – fund wallets are created and signed on offline machines that never touch the internet
• Separated backups – recovery phrases are stored on paper in several physically separate locations
• Public announcements of large transfers – before they happen
• Quarterly transparency reports here in the forum: balance of every fund, every payout with amount, purpose and transaction hash, charity votes, current mining reward and how much of the relay budget has been paid out

Verify it yourself

Once mainnet is live, anyone can check with a node or the block explorer:

• Block #0 – clean genesis, 50 AQA
• Blocks #1–#4 – exactly 3M / 4M / 1.5M / 1.5M AQA to the four fund addresses
• Every block from #5 – 50 AQA mining reward (halving) + 1.5 AQA relay output
• Fund addresses – every balance and every outgoing transaction

Fund addresses & explorer links – coming soon.
The official mainnet addresses of all four funds will be published after the key ceremony, together with links to the AntiQua block explorer, so you can check every balance and every transaction yourself. We'll add them to this post and announce them in Announcements. Until then: any "fund address" you see anywhere else is not official.

The fine print

Your turn

Questions, doubts, ideas? This is exactly the place for them – good tokenomics survive tough questions. Ask below.

— Blythex

Hey everyone

This thread is the official changelog for the AntiQua core – NodeCore, the node software that runs the AntiQua network. Whenever we ship something worth knowing about, it gets posted here as a new entry, newest at the bottom.

If you run a node, test the network or simply want to follow how the protocol evolves, this is the one thread to keep an eye on.

What gets posted here

• Releases – new NodeCore versions and what changed
• Security & hardening – fixes and improvements to cryptography, consensus and validation
• Performance & networking – sync, P2P, mempool and resource usage
• Breaking changes – anything node operators have to act on, always clearly marked
• Network milestones – testnet resets, upgrades and other events that affect the whole network

How every update is structured

So you can tell at a glance whether something affects you, each entry follows the same format:

NodeCore vX.Y.Z – date
Type: Release · Hotfix · Security
Action required: No / Yes – what you need to do

What's new – short summary
Details – changes, fixes, notes for node operators

Never miss an update

Click the bell icon on this topic and choose Watching. You'll get a notification every time a new core update is posted here.

Questions & discussion

To keep this changelog clean and easy to read, replies are closed here. Got questions, found a bug or want to discuss a change? Just open a new topic here in Development – we read everything.

Stay safe: Only trust release information from official AntiQua channels. The team will never send you node or wallet files via private message, and will never ask for your recovery phrase or private keys.

Cheers,
Blythex

September 18 was a big day for AntiQua.

In less than two hours, our public testnet crossed three milestones – every transaction signed with ML-DSA-87 (Dilithium), the NIST post-quantum signature standard, mined into real blocks and accepted by our public archive node.

TL;DR

• First post-quantum payment confirmed on-chain
• First 2-of-2 multi-signature wallet funded
• First multi-sig spend – two independent post-quantum signatures, verified and confirmed

First single-signature spend

18 Sep 2026, 16:06 CEST

A simple payment of 10 AQA from a mining payout address to a fresh AIP-39 wallet (our 24/36/48-word recovery standard), with a 0.01 AQA tip and a 0.001 AQA relay fee.

• Path: wallet send → signed transaction → mempool → mined → confirmed by the archive node
• Transaction size: ~9.4 KB (post-quantum signatures are big – more on that below)
• Confirmed in block #112
• Receiver balance after confirmation: 10.000000 AQA

tx     9e353fb5ba5c1af53ec726946a4ef41a93c3152bc652a89148b8281f4388600a
block  #112  ea98a8b5bf5ca0288d277f96300bd841ad5fd06ada2c51c4e41cef8ee947ef9b

Multi-sig wallet funded

18 Sep 2026, 16:46 CEST

We created a 2-of-2 multi-signature wallet on testnet – funds can only move when both key holders sign – and sent 10 AQA into it.

tx     2d4df3e35cabbd89ef3da8b4fb4f56a31f375e1761a34ad169f464156f88d60e
block  #127  831935a282b0a417baedefd68b097ad5a9aade33a64e619e047a7ddb3f3f3320

First multi-sig spend

18 Sep 2026, 18:04 CEST – the big one.

Two signers each loaded their own wallet, built one transaction together and signed it independently with their own ML-DSA-87 keys. The node checked both signatures before accepting it:

verify_multisig_input [SUCCESS]: enough signatures present (2/2 required)

The spend went into the mempool, was mined into block #130, broadcast to the network and accepted by the archive node.

tx     d57ab29312337aa64958f84fefcfc6141487e666eb09cfcb0529706e08d1544f
block  #130  ccb98b6b6438dff6e76492d624e777d454c7d18262e136109638bffc242180a7

And the numbers add up to the last decimal:

For the developers among you, this is the whole flow in our node CLI:

walletload <signer-1>
walletload <signer-2>
mscreate 2 testnet
mstx ms 2 <receiver> 5 0.01 0.001
mssign last 0 0
mssign last 0 1
mine 1

What we had to fix to get there

Multi-sig didn't work on the first try – the archive node rejected our transactions with a hash mismatch. We tracked it down to two independent bugs:

1. Fee set after hashing. The multi-sig builder calculated the transaction hash first and set the fee afterwards – so the hash no longer matched the transaction body. Now the fee is set first, then the hash is computed.
2. Multi-sig fields lost on the wire. The network serializer only sent the basic input fields and silently dropped the multi-sig data (required signatures, signer keys and signatures). The receiving node filled in defaults and computed a different hash. You can see it in the numbers: the transaction packet grew from 656 bytes (broken) to 15,232 bytes (complete), and the block from 12,888 to 27,464 bytes.

The fix: hashing, the mempool and the network now use one single serialization path, so they can never disagree again. A dedicated regression test makes sure the truncated format is rejected and the full format round-trips cleanly.

Why these sizes matter

A post-quantum signature is much larger than a classic Bitcoin signature – that's the price of security against quantum computers. One single-sig payment is ~9.4 KB, a 2-of-2 multi-sig transaction ~15 KB.

This is exactly why AntiQua was designed from day one with compact commits and checkpoints to keep the chain lean over time. If you missed it, read Why Post-Quantum? The Threat is Real.

What this does not prove yet

We'd rather be honest than hype. These milestones were done with the node CLI on testnet. Still ahead:

• Multi-sig in the desktop wallet (GUI)
• Multi-sig in the Android light wallet against the live chain
• Larger setups like 2-of-3 or 3-of-5
• Compact block relay (currently switched off)
• Mainnet – of course

We'll keep posting progress in the Core Changelog.

Questions about the transactions, multi-sig or post-quantum signatures? Ask below – we're happy to go into the details.

— Blythex

Welcome to Support

Something not working? You're in the right place. This category is for wallet, account and transaction problems – and nobody here expects you to be an expert. The community and the team read every topic.

To get help fast, please take two minutes and read this first.

Rule number one: never share your recovery phrase

Never post your recovery phrase (seed phrase) or private keys – not in a topic, not in a chat, not "just to check". Anyone who has them can empty your wallet.

The AntiQua team will never ask for them, and will never ask for remote access to your computer. If someone does, it's a scam – please report them to the team.

This forum actively protects you: posts containing a recovery phrase or a private key are blocked automatically, and chats show you a warning before anything is sent.

How to ask a good question

1. One problem, one topic. Please open a new topic for your question instead of replying to someone else's – it keeps answers clear for both of you.

2. Use a clear title.
"Help!!!"
"Desktop wallet stuck at 'Synchronizing' after update"

3. Tell us the basics. Copy this into your topic and fill it in:

Wallet / app:     Desktop / Android / other
Version:          e.g. 1.2.0
Operating system: e.g. Windows 11, Android 14
What happened:
What I expected:
Steps to reproduce:
Error message:

4. Add a screenshot of the error if you can – often it says more than a long description. Double-check it doesn't show a recovery phrase or private key.

5. Logs help – but check them first. Before pasting a log file, take a quick look for anything private. Wallet addresses and transaction IDs are public and fine to share.

Is this the right category?

• Wallet, account or transaction problem → right here in Support
• Running a node or mining → Mining & Nodes
• You found a bug in the code → Development
• You found a security vulnerability → please do not post details publicly. Send a private message to a team member instead, so we can fix it before anyone can exploit it.

Write in your own language

You don't have to write in English. Every post has a translate button next to Reply – others can read your question in their language, and you can read the answers in yours.

Found the solution?

Please post what fixed it before you move on – even if you solved it yourself. The next person with the same problem will thank you.

Cheers,
Blythex

Welcome to the official AntiQua community forum

This is the home base for everyone building, running or simply curious about AntiQua – a blockchain designed from the ground up for the post-quantum era. Whether you're a developer, a miner, a cryptography nerd or just found us today: you're in the right place.

AntiQua at a glance

Cryptography	NIST Level 5 – ML-DSA-87 signatures, ML-KEM-1024 key exchange, SHAKE-256 hashing
Consensus	RandomX Proof of Work
Supply	56,000,000 AQA – hard cap, 75 % mined + 7 % node rewards
Launch	Fair launch · clean genesis block · no VC allocation · funds multi-sig or vested
Codebase	Built from scratch – no forks, no shortcuts
Status	Testnet live since March 31, 2026

New here? Start reading

1. Why Post-Quantum? The Threat is Real – why today's blockchains are at risk and what AntiQua does differently
2. AIP-39 – Our Post-Quantum Mnemonic Standard – how your seed phrase stays quantum-resistant
3. AntiQua Testnet is Live – where the network stands today
4. Repository Overview – NodeCore, Desktop Wallet and Android Wallet
5. Tokenomics – the 56M AQA supply, the Relay Reward Lottery, the four funds and the rules that bind them
6. Security Audit History – our external audits and what came out of them

Find your way around

• Announcements – official news from the core team
• Technology – post-quantum cryptography, consensus and protocol internals
• Development – NodeCore, wallets, code and bug reports · follow the NodeCore Changelog
• Mining & Nodes – running a node and mining AQA with RandomX
• Support – stuck? Read How to Get Help Fast, then ask away
• Economics & ICO – tokenomics, supply and distribution
• Security – audits, hardening and responsible disclosure
• Community – introductions and everything else

Your first steps

• Say hello in Introduce Yourself – tell us who you are and what brought you here
• Watch the NodeCore Changelog (bell icon → Watching) to get notified about every core update
• Write in your own language – every post has a translate button next to Reply
• Have a quick look at our Community guidelines – short and to the point

Stay safe: The AntiQua team will never ask for your recovery phrase, your private keys or remote access to your computer. Anyone who does is a scammer – please report them.

We're building AntiQua in the open, and this forum is where it happens. Ask questions, challenge our decisions, report bugs, share ideas – we read everything.

Glad to have you here.

— Blythex, Lead Developer

Hey, and welcome to AntiQua!

Whether you write code, run a miner, read NIST papers for fun, or simply believe that your money should stay yours – even in a world with quantum computers – you belong here.

This is the place to say hello. No question is too basic, no background too unusual. Everyone started somewhere.

Tell us about yourself

Just reply to this topic. If you're not sure what to write, copy this and fill in whatever you like – every line is optional:

Nickname:
Where I'm from:        (country or region is plenty)
How I found AntiQua:
What I'm into:         mining / running a node / development /
                       cryptography / economics / just curious
My background:         developer, miner, student, trader, ...
One thing I'd love to see in AntiQua:

Write in your own language if you prefer. Every post has a Translate button, so the rest of us can still read along.

Stay safe while you say hi

A few simple habits keep you and your coins protected:

• Never share your recovery phrase or private keys – not here, not in chats, not with "support". This forum blocks them automatically, but don't rely on that alone.
• Keep personal details to yourself. No real address, phone number or private e-mail needed – a nickname is perfect.
• Be careful with private messages. The team will never message you first asking for funds, keys, or "verification". Offers of airdrops, investments or "recovery services" in DMs are scams.
• Official news only comes from the Announcements category. If it's not there, it's not official.

Where to go next

You want to…	Go here
Understand what AntiQua is	Welcome to the AntiQua Community Forum
Learn why post-quantum matters	Why Post-Quantum? The Threat is Real
Get help with a problem	Support – start with How to Get Help Fast
Mine or run a node	Mining & Nodes
Talk code and protocol	Development · Technology
Discuss tokenomics	Economics & ICO
Report a vulnerability	Security

Please take a minute to read the forum rules – they're short, we promise.

I'll go first

I'm Blythex. I work on the AntiQua core and look after this forum and our Git. I read every introduction here – so say hi, tell us what brought you, and don't be shy about asking questions.

Glad you're here. Let's build something that lasts.

AntiQua has undergone two full external audit rounds:

NightShift Audit — 47 findings identified and remediated.
Draikoon Audit — 11 findings, all CRITICAL and HIGH resolved.

Production security decisions include: hard-abort on plaintext key handling, mempool RBF lockout, DNS eclipse fallback seeders, and mnemonic export PIN protection.

Bug bounty program incoming. Details to follow.

AntiQua ships with seven built-in smart contract templates, all tested (257/257 passing) :

• NFT
• Escrow
• Token
• Voting
• TimeLock
• RecurringPayment
• Vesting

Custom contracts beyond these templates are on the roadmap. Discussion welcome.

AntiQua spans three repositories:

NodeCore (C++) — The full node. P2P networking, UTXO model, mempool, smart contract VM, RandomX PoW, ACRP chat layer.

Desktop Wallet (C# WPF) — Full-featured Windows wallet with transaction history, smart contract interaction, and encrypted ACRP messaging.

Android Wallet (Kotlin) — Mobile node + wallet. Runs a full AntiQua node on your phone.

All three are developed simultaneously. No forks. Every line written from scratch.

Bitcoin uses BIP-39 mnemonics backed by secp256k1 keys — fundamentally incompatible with post-quantum cryptography. AntiQua implements AIP-39, a custom mnemonic standard designed around ML-DSA-87 key material.

Your seed phrase on AntiQua is quantum-resistant from word one.

Almost every blockchain in use today secures your coins with elliptic-curve signatures (ECDSA or EdDSA). They are fast, compact and safe against every computer we have today. Against a large quantum computer running Shor's algorithm, they are not safe at all.

AntiQua was designed from day one on the assumption that this threat is not hypothetical – it's a matter of when. Here is what that means in practice.

What a quantum computer actually breaks

Not everything in a blockchain is equally at risk. The real problem is signatures, not hashing:

Building block	Used for	Quantum attack	Impact
ECDSA / EdDSA	Signing transactions	Shor's algorithm	Broken – the private key can be computed from the public key
RSA, ECDH	Encryption, key exchange	Shor's algorithm	Broken
SHA-256, SHA-3	Hashing, addresses, mining	Grover's algorithm	Weakened – effective security roughly halved (256 → ~128 bit), still considered safe
AES-256	Symmetric encryption	Grover's algorithm	Weakened the same way, still considered safe

In plain words: whoever controls a large enough quantum computer can derive your private key from your public key – and sign transactions as if they were you.

Why "not yet" is not a good excuse

1. Public keys live on-chain forever.
On most blockchains, your public key becomes visible the moment you spend from an address – and it stays in the chain history permanently. Every coin behind an exposed public key is a target the day a capable quantum computer exists. That includes millions of coins already sitting in such addresses today.

2. Migrating a live blockchain takes years.
Switching the signature scheme of an existing network needs consensus, new wallets, exchange support – and every single holder moving their funds. Coins whose owners lost their keys or stopped paying attention can never be moved to safety.

3. The standards are already here.
In August 2024, NIST published the first post-quantum standards: FIPS 203 (ML-KEM) and FIPS 204 (ML-DSA). NIST's transition plan proposes to deprecate quantum-vulnerable algorithms like RSA and elliptic-curve cryptography after 2030 and disallow them after 2035. The rest of the industry is starting its migration now.

4. Attackers can wait.
"Harvest now, decrypt later" is not science fiction: data and public keys collected today can be attacked the day the hardware is ready.

How AntiQua handles it

AntiQua doesn't bolt post-quantum cryptography onto an old design. It is the design:

Layer	AntiQua uses	Standard
Signatures	ML-DSA-87	FIPS 204 · NIST security category 5
Key encapsulation	ML-KEM-1024	FIPS 203 · NIST security category 5
Hashing	SHAKE-256	FIPS 202 (SHA-3 family)
Seed phrases	AIP-39	our own post-quantum mnemonic standard
Proof of Work	RandomX	CPU-friendly, ASIC-resistant mining

NIST security category 5 is the highest level NIST defines: breaking it must be at least as hard as brute-forcing a key for AES-256.

And because post-quantum signatures are there from the genesis block, there is no legacy signature scheme to migrate away from – no future hard fork just to become quantum-safe.

The honest part: where the cost is – and how we contain it

Post-quantum security isn't free. The keys and signatures are much larger than what Bitcoin or Ethereum use:

A naive design would store all of that forever, on every node. AntiQua doesn't. Signatures are expensive once – on the wire and when a block is first accepted. After that, the network works with hashes, compact commits and checkpoints.

Verify once, then commit compact

When a block is connected, every transaction is verified in full – including its ML-DSA signature. What gets written to the ledger afterwards is a compact record: the 32-byte transaction hash, inputs, outputs and amounts – without signature and public key. The Merkle root and the block header hash bind that record to the verified original. Full and light nodes therefore store the proof of validation, not the proof itself.

Commitments instead of bodies in gossip

Block announcements carry transaction commitments – again 32 bytes per transaction. The full block with all signatures only goes to a subset of verifying nodes, or to whoever explicitly requests it.

Checkpoints instead of re-checking history

• UTXO snapshots every 5,000 blocks record the state hash, total coin supply and UTXO root. A starting node syncs from the latest snapshot – checking proof of work, Merkle roots and transaction hashes – instead of re-verifying every historical signature.
• Finality checkpoints every 100 blocks are signed by miners and confirmed by a quorum. Once a height is finalized, reorganisations before it are locked. That's a handful of large signatures for finality – not millions of transaction signatures on disk.

Why this stays secure

The check always happens before anything is discarded: a compact record is only valid because the full transaction was accepted first. Archive nodes keep the complete bodies, so anyone who needs the original – for an initial sync or a wallet – can fetch it and verify it again against the committed hash.

In short: post-quantum signatures cost bandwidth and CPU once. Storage stays lean. And even if it didn't: storage gets cheaper every year – a stolen private key never gets un-stolen.

Let's talk

Questions, doubts, counter-arguments? That's exactly what this category is for. Happy to go deep on any part of the stack – ask away

Want more? Read how AIP-39 keeps your seed phrase quantum-resistant, or check our Security Audit History.

— Blythex

As of March 31, 2026, the AntiQua testnet went live with four simultaneous nodes syncing correctly across Hetzner, home node, and two Android devices.

The full stack is operational:

• NodeCore (C++)
• Desktop Wallet (C# WPF)
• Android Wallet (Kotlin)
• ACRP encrypted chat layer on port 20557

Stay tuned.