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

AntiQua

administrators

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

Member List

Update — `/linklist` in the Telegram group