AntiQua

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

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.

	Duration
Full node	24 hours
Light / SPV / inbound	1 hour

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

Score	Reason
+150	During initial sync, the header checkpoint gate failed – the PoS anchor is missing or doesn't match
+100	More than 500 unconfirmed headers pending from one peer

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:

Layer	What it sees	What it does
Socket	The raw frame: length, encryption, message identifier	Scores and disconnects immediately
Dispatch	The parsed message: contents, sizes, counts	Scores and drops the message

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

Score	Reason	Disconnects?
+50	Frame length of zero, or larger than the 4 MiB limit	yes, at the socket
+40	Message wrapper failed verification	yes, at the socket
+40	Header chain link broken	no
+35	Announce commitment claims an absurd transaction count	no
+30	Encryption failed to decrypt	yes, at the socket
+30	Message identifier doesn't match what the frame claims	yes, at the socket
+30	Handshake response failed verification	no
+30	Headers arrive out of order	no
+30	Far too many blocks in one message	no
+25	Payload empty after a successful verify	socket layer: yes
+25	Oversized headers, GetData or peer list	no
+20	Oversized inventory batch, invalid block inside a blocks message, transaction queue overflow	no
+15	A second hello after the handshake already finished, inventory flooding	no
+10	Replayed handshake response, invalid transaction payload, duplicate difficulty update	no
+5	Handshake seen-set capacity, empty rekey payload	no

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

Score	Reason
+30 per block	Pure GetData substitution – see below
+60	Headers you requested went largely unconfirmed within a 10-minute window
+25	Light client proof: merkle root doesn't match your header, or the proof is invalid
+20	Key rotation request out of sequence
+15	Light client proof: amount or recipient doesn't match
+15	Key rotation replay (sequence number too low)
+10	Announced a block height more than 500,000 above your tip
+10	Ping flooding, empty rekey ciphertext
+10	Pong nonce mismatch – not for inbound or SPV peers
+5	Key rotation rate limit, rekey response with nothing pending, malformed relay announcement

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.

Score	Reason
+5	Rate limit on subscribe, publish, fetch or forward
+10	Topic name oversized
+15	Payload oversized, missing message id, missing publisher key
+20	Missing or malformed public key
+25	Bad key length, binding mismatch, invalid signature length
+30	Bad signature on a publish, a forward or a multisig confirmation

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:

Situation	What happens
Too many messages per second	Message dropped. No ban. 60/s normally, 400/s while syncing
Handshake queue full	Dropped and logged, no penalty
An unknown message type from an older peer	Warning in the log, no penalty
Compact stub instead of a full body	Re-requested, no penalty
Extra hashes alongside a correct block	Extras discarded, no penalty
A GetData job with no hash list at all	Blocks discarded, no penalty
Empty headers response, or one with only headers you had	Re-asked, no penalty
Headers outside the checkpoint horizon	Node waits for a block to connect, no penalty
A second hello in the same session	Ignored
Late pong from a mobile or SPV peer	No penalty – late pongs are normal on mobile
Reconnect from a phone that changed network	No penalty, that's the expected pattern
An error while serving GetData	Connection closed, no penalty
Key rotation when the key material is missing locally	Connection closed, no penalty
Checkpoint, challenge, attestation, receipt and mempool-status messages	Logged or dropped, never scored
Any score below 100	Nothing at all

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	For
−5	A valid pong
−25	Confirmed headers during initial sync

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:

	Full nodes	Light clients
Inbound per /16	3	16
Outbound per /16	2	2

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

Look for the actual scored reason in the log. Every penalty above writes one.
If the reason is a rate limit, a dropped message or a closed connection without a score: that isn't a ban, keep looking.
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)
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.
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

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

What you see	Which rule
"Fee too low"	The fee floor, a different rule entirely
An output of exactly 0	Rejected as an invalid amount, before dust is even checked
A mining reward under 1,000 sat in a block	Allowed – the coinbase exception
An old coin of 1,200 sat you still hold	Perfectly spendable. The rule applies when an output is created, never retroactively

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

Blythex

Update — `/linklist` in the Telegram group

The bot learned one more thing: ask it for the official links and it posts them.

Type /linklist in the group, in a topic, or in a private chat with @AntiQua_Blockchain_Bot. Back come the five addresses that are actually ours:

AntiQua — official links
• Forum · Website · Git · BugHive · Discord
If a link is not on this list, it is not ours.

That last line is the whole point. Communities like ours don't usually lose money to clever exploits — they lose it to a lookalike domain posted by a friendly stranger. Having one list that anyone can summon in two seconds makes it cheap to check and awkward to fake.

Anyone can ask. It isn't an admin command. Someone new turns up, wonders where the repository is, types six characters, done.

It won't spam you. The list stays quiet until 50 messages have passed since the last time it appeared — counted per topic, so a question in one channel doesn't silence another. Ask too early and your message just gets a instead of a repeat.

Delete it and you can ask again. If someone clears the list out of the chat, the counter resets and the next request brings it straight back. Telegram doesn't tell bots when a message is deleted, so ours checks for itself — but only when it's about to say no, so it costs nothing the rest of the time.

Small feature. It exists because the alternative is someone pasting a fake forum link at 2 a.m. and nobody having a quick way to prove it's fake.

Blythex

Update — Telegram notifications are live

September 2026 · a new plugin joins the list above

You can now get your forum notifications on Telegram — if you want to. Nothing changes for anyone who doesn't: email and the bell keep working exactly as before, and this is off until you switch it on yourself.

Our bot is @AntiQua_Blockchain_Bot.

Connecting takes about ten seconds

Go to Settings in your profile and find the Telegram section.
Press Connect Telegram. A link appears — open it.
Press Start in Telegram. Come back; the page has already updated itself.

That's it. And notice what you didn't do: you never looked up a chat ID and never typed one anywhere.

That's deliberate, and it's the most important design decision in this plugin. If there were a field for your Telegram ID, someone could type in yours. Their forum notifications would then land on your phone — and since notification texts contain post content, whoever did it could choose the text. The forum would become a delivery channel for messages from a bot you trust. That is exactly how a good phishing message gets made.

So instead: you get a one-time link, you press Start, and Telegram itself tells the bot who you are. Entering someone else's ID isn't hard in this design — it's impossible, because the ID never passes through anyone's hands. The link works once, expires after ten minutes, and only its hash is stored in our database, never the link itself.

What will never arrive on Telegram

Password resets. Email confirmations. Two-factor codes. Those stay on email, permanently, with no setting to change it.

The reason is simple: if a password reset could be delivered to a messenger, then whoever controls your Telegram controls your forum account — and the email confirmation that your account is built on would be bypassed entirely. Convenience isn't worth that trade, so we didn't build the switch.

You choose what arrives

Each kind of notification has its own toggle:

when someone mentions you
replies in topics you follow
new topics in categories you watch
private messages
new followers, votes on your posts, group invitations
everything else

On top of that there's one master switch for Telegram delivery, and Disconnect removes everything. You can also send /stop to the bot — same effect, from wherever you happen to be.

It speaks your language

The bot picks your language in this order: whatever you select in the Telegram section, otherwise your forum language, otherwise the language your browser asked for when you connected, otherwise the forum default. All 14 forum languages are supported.

That third step matters for people who never set a language in the forum — the browser already knows, so the bot simply uses it instead of defaulting to English.

Small things that keep it pleasant

A cap per hour, so a heated thread doesn't turn into a ringtone marathon.
Quiet hours can be configured forum-wide.
Plain text only — no Markdown, no HTML. A topic title can't smuggle in bold "official" warnings or a fake link, because formatting simply isn't interpreted.
Buttons only point back here. A link that isn't on this forum's own address doesn't get a button at all.
Block the bot and delivery switches itself off instead of hammering away at a closed door.

What we store, and what we don't

Your chat ID, your display name, when you connected and which kinds you chose. That's all.

It disappears when you disconnect, when you send /stop, and when you delete your account. In server logs and in the admin overview the chat ID only ever appears shortened (****1570) — it's personal data, and it gets treated that way.

Tested the way we'd want it tested

Like the plugins above, this one ships with its own test suite — 59 tests, including the attacks we'd expect someone to try:

hijacking a chat that already belongs to another account
redeeming the same one-time link twice
using an expired or invented link
smuggling formatting or foreign links into a message
forcing delivery to someone who never connected
slipping past the hourly cap
getting the bot key to appear in an error message

All of them fail, which is the point.

Questions, or something behaving oddly? Reply here. If you'd rather not use Telegram at all, you genuinely don't have to — nothing about the forum requires it.

Blythex

I think that by the first quarter of 2027, the first nodes will be running on the testnet by users.

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

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:

All eligible candidates are sorted by their payout address
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
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


Reward per block	1.5 AQA from the relay budget
Total budget	4,000,000 AQA
First possible block	height 5
Duration	roughly 50 years on mainnet at 10-minute blocks
When the budget runs out	5 % of that block's fees go to the relay winner instead

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

Blythex

BugHive update – 20 Sep 2026
Type: Feature
Action required: No

What's new – six project spaces, issue types, a real backlog and protected security reports
Details – below

Projects – every part of AntiQua now has its own space: Core, Windows Desktop, Windows CLI, Linux, Android and Forum.

Issue types – every entry is now a Bug, a Feature or a Task. You pick the type when you create it.

Backlog is a real status – "accepted, but not scheduled yet". Each project has three views: Bugs, Features and Backlog, plus All entries. The board shows Backlog as its own first column.

Security reports are protected – entries labelled security are removed from public lists on the server, and the direct link and comments return "not found". Only the team and the reporter can see them.

Login via Telegram – no password needed. Two-factor authentication is available in your profile settings.

Reading is public – bugs, features and projects can be read without an account. Only creating and commenting needs a login.

Take a look: https://bugs.antiqua-blockchain.com

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

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:

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.
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:

Inputs	Fee factor
1	1.00×
2	1.05×
3	1.30×
4	1.60×
5 or more	2.00×

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:

Fee per KiB – how much you pay relative to the size of your transaction
Divided by the input factor – heavy transactions rank lower
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:

Template	Base deployment fee
Escrow	0.0001 AQA
Time-Lock	0.00015 AQA
Token · NFT · Vesting	0.0002 AQA
Voting	0.00025 AQA
Recurring payment	0.0003 AQA

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

Fee = inputs − outputs, exact to the satoshi, part of the transaction hash
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
More inputs → higher fee factor and lower priority; the factor hits base fee and tip together
Leftover change below 1,000 satoshi always becomes tip
100 % of fees to the miner, nothing burned – relays are paid by the lottery
Micro proof-of-work from the 6th pending transaction; at most 25 unconfirmed per sender
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

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

Era	Reward per block	Coins in this era	Share of mining supply
1	50 AQA	~21,000,000	50 %
2	25 AQA	~10,500,000	25 %
3	12.5 AQA	~5,250,000	12.5 %
4	6.25 AQA	~2,625,000	6.25 %
…	halving continues down to 0.1 AQA	…	…

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


Smallest unit	1 AQA = 100,000,000 satoshi
Dust limit	0.00001 AQA – smaller outputs are invalid
Coinbase maturity	mined coins become spendable after 100 blocks
Consensus math	all amounts are integers in satoshi – no floating-point rounding anywhere

Your turn

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

— Blythex

Blythex

NodeCore – Testnet milestone – 18 Sep 2026
Type: Network milestone · Fix
Action required: No for users – testnet node operators: run the current NodeCore build (older builds can't read multi-sig transactions on the wire)

What's new – first post-quantum payment and first 2-of-2 multi-sig spend confirmed on the public testnet
Details – below

Single-sig spend – 10 AQA sent with an ML-DSA-87 signature, confirmed in block #112
Multi-sig wallet – 2-of-2 wallet funded, block #127
Multi-sig spend – two independent ML-DSA-87 signatures verified (2/2), confirmed in block #130 and accepted by the archive node

Fixes

Multi-sig builder set the fee after computing the transaction hash → hash mismatch. Fee is now set first.
P2P serializer dropped the multi-sig fields (required signatures, signer keys, signatures) → receiving nodes computed a different hash. Hashing, mempool and network now share one serialization path.
New regression test: truncated transaction inputs are rejected, full ones round-trip.

Sizes – single-sig tx ~9.4 KB · 2-of-2 multi-sig tx ~15 KB · block with multi-sig spend 27.5 KB

Full write-up with all transaction and block hashes: Testnet Milestones: First Post-Quantum Payments and 2-of-2 Multi-Sig Confirmed On-Chain

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:

Wallet	Balance	Math
Receiver	15.000000 AQA	10 (milestone 1) + 5
Multi-sig	4.989000 AQA	10 − 5 − 0.01 tip − 0.001 fee

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:

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.
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

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

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

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

Blythex

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.

Blythex

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

Blythex

Posts

Proof-of-Work, in two stages

Difficulty: ASERT, every block

Timestamps: you can't lie much

The block reward, and where 56 million comes from

Confirmations: 1, 6, and 100

Reorgs: a hard ceiling, not a preference

PoS checkpoints: a bolt, not a second consensus

How a node catches up

Spam protection at the node level

The rules in one place

Questions?

The threshold

The two that ban you outright

Two layers, two outcomes

Protocol and handshake violations

Sync, proofs and key rotation

Encrypted messaging and multisig

Substitution vs. honest extras

What is NOT banned

Arriving with the next node release

Earning credit back

Eclipse protection: slots per subnet

The second score – and what it actually does

If you think you've been banned unfairly

The rule

Why 1,000 – the real reason

What your wallet does instead

The one exception

Not to be confused with

Frequently asked

Update — /linklist in the Telegram group

Update — Telegram notifications are live

Connecting takes about ten seconds

What will never arrive on Telegram

You choose what arrives

It speaks your language

Small things that keep it pleasant

What we store, and what we don't

Tested the way we'd want it tested

One space per part of AntiQua

How to report something useful

Security bugs: please, not in public

What's public

Staying up to date

How it works

How to register

From registration to your first chance

What it pays, and for how long

What protects the draw – and what doesn't

How to check it yourself

Where it fits in

Questions?

What BugHive is

What gets posted here

How every entry is structured

Never miss an update

Reporting safely

Questions & discussion

What a fee actually is

Base fee + your tip

What your wallet suggests

What happened to the relay fee?

Why more inputs cost more

Change that disappears into the tip

Who gets confirmed first

What if I pay too little?

Where the money goes

Spam protection without making everyone pay

Smart contract deployment fees

The rules in one place

Questions?

The big picture

Mining: 42 million AQA, earned block by block

Relay Reward Lottery – 4,000,000 AQA

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

The four funds – and the rules that bind them

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

Update — `/linklist` in the Telegram group