This page reproduces docs/whitepaper.md from qanum-core v0.9.0 (release tag). Links to files that are not published on this site are shown as plain text until the source repository is public.

Architecture and Design Whitepaper

Draft aligned with the implementation and the consensus specification

Document status: architecture draft aligned with qanum-core v0.9.0 and with the companion consensus specification (spec.md) Purpose: describe what qanum is, what is implemented in the code, what is fixed at the design level, and what remains roadmap Note: this document is not a final consensus specification nor a public offering. Normative behaviour is the source in src/ and the tests that lock it.

Executive summary

qanum is a decentralized monetary network designed from the start for the post-quantum horizon. Its central thesis is that the next sovereign monetary layer should not be built as an overloaded general-purpose blockchain, but as a base layer specialized in custody, settlement, cryptographic security and robust self-custody, with scaling, advanced privacy and more complex execution pushed to higher layers or adjacent modules.

qanum adopts a UTXO model, Proof of Work consensus, a deliberately limited scripting policy based on native templates, and a roadmap where the base layer stays simple while high-frequency payments, advanced privacy and more expressive execution develop as higher layers or domains.

The running implementation is a Rust full node (qanumd / qanum-cli) with mandatory liboqs signature verification (crypto-oqs, startup self-test), an encrypted net_v2 stack, trustless UTXO snapshot sync (AIP-0001), native vault / recovery / HTLC flows, and a test inventory of 2,241 test functions (method and inventory in TESTSUITE.md).

1. Introduction and motivation

Quantum computing capable of compromising widely deployed classical primitives is not yet part of everyday infrastructure, but its mere plausibility forces decade-long horizons. Migration to new cryptographic schemes requires years of research, standardization, libraries, tooling, audits and social coordination.

Legacy monetary networks face several structural difficulties:

1. Historical dependence on classical primitives.
2. Social migration surface. Changing a live network’s cryptography is institutional as well as technical.
3. Fragile custody for the average user. Key loss and the absence of native recovery remain severe barriers.
4. Poorly conceived base-layer scaling. Many proposals try to solve mass payments, arbitrary contracts, strong privacy, governance and final settlement inside the same L1.

These difficulties are structural, not incidental: post-quantum authorization, per-block state commitments and an auth-sized cost model cannot be migrated onto a live monetary network without forking its social consensus as well as its code — which is why qanum is a new base layer rather than a modification of an incumbent (see docs/ARCHITECTURE.md, “Why a new chain — and not a fork of Bitcoin”).

qanum’s response is conservative: the base layer must be monetary, not a platform for everything. Sophistication is moved where risk can be isolated: wallets, payment layers, external compute domains, and network improvements.

The post-quantum requirement is also why several structures in this document exist at all. Roughly 7.2 KB of authorization data per spend with the level-5 suite ML-DSA-87 (a public key plus its signature; 3.7 KB with ML-DSA-44; the ML-DSA-87 seat is what sizes the per-input auth limit, §5.1) does not fit a classical block budget; it forces the split between base block data and per-input authorization data, and makes the auth side the binding constraint. The same cost reappears downstream: a consensus-level Verify Unit budget bounds per-block cryptographic work, the dust policy is priced in raw bytes because signatures dominate transaction weight, and historical signatures can be pruned selectively (-auth-prune-depth) because they live apart from the data they authorize. Remove the post-quantum requirement and these structures lose their reason to exist; they are consequences of the cryptography, not stylistic choices.

The same logic reaches the node’s operational footprint. A chain whose spends carry ~7.2 KB of authorization data accumulates historical weight several times faster than a classical one; full initial block download and archival storage are therefore structural costs of the post-quantum requirement, not incidental ones. This is why every header commits a state root (utxo_root, spec §10): it converts the UTXO set from something a node must rebuild into something a node can verify. The snapshot bootstrap (AIP-0001) is the operational consequence of the same paragraph — not a scalability feature bolted on. A fresh node receives the state at height H, re-checks it against the commitment carried by the PoW-validated header chain, and falls back to full download the moment any check fails. Like the structures above, it exists because the cryptography demands it: a classical chain does not need an in-chain state commitment to make bootstrap verifiable, and a post-quantum chain without one would have to choose between slow onboarding and trusted state distribution.

2. Goals and non-goals

2.1 Goals

• Post-quantum resistance from genesis
• Cryptographic agility for future migrations
• Safer self-custody through recovery paths, vaults and safer wallet defaults
• Base-layer security with a small, auditable design
• Modular scaling without inflating L1 complexity
• Practical privacy improvements starting at the operational and network level
• Monetary neutrality and minimal political governance over the base protocol

2.2 Non-goals

qanum does not attempt, in its current phase or its main thesis:

• to become an EVM chain or a general-purpose VM on the base layer
• to promise thousands of TPS on L1
• to solve strong-privacy problems (ring signatures, confidential amounts, stealth ledgers) at L1
• to govern itself as a token-vote monetary DAO
• to compete as a “do-everything” blockchain
• to add command aliases or duplicate RPC/CLI surfaces

These renunciations are part of the design.

3. Design principles

3.1 The base layer must be deliberately austere

A monetary layer meant to last decades must be small in scope, comprehensible, auditable, difficult to capture, and resistant to impulsive changes.

3.2 Cryptography must not be assumed eternal

qanum treats no primitive as sacred. It designs suite versioning, alternative spending paths, gradual migration, and an explicit deprecation path.

3.3 Self-custody is a protocol and wallet function

Reasonable defaults: no address reuse, separation between operational and recovery keys, automatic change rotation, compartmentalization between accounts or roles, safer custody policies.

3.4 Scaling by layers

The base layer settles and anchors value. Higher layers process frequent payments, aggregation, stronger privacy, richer execution, and specialized environments.

3.5 Base money should not behave like a hyperactive political platform

Monetary and consensus rules must change slowly, with friction, public technical review and conservative coordination.

4. General architecture

4.1 qanum Base

The UTXO base layer: validation, consensus, custody, settlement, UTXO state commitments, native spending policies.

4.2 qanum Vault

Security policies and flows: delayed spending, hot/cold separation, recovery paths, hardened self-custody. Implemented as native templates plus wallet builders (see §14, §18.4).

4.3 qanum Channels

A payment-channels layer for low-latency off-chain payments exists as an external, client-side project (qanum-channels) with its own release cycle. It is not implemented in qanum-core, and nothing here is consensus: a channel is a P2MULTI output like any other, and the L1 sees only its funding and its settlement. That separation is deliberate and is not expected to change — work at this layer must never require a consensus rule to accommodate it.

L1 dependencies

The channel layer consumes exactly the primitives L1 already provides — no new rule, no new flag, no relative timelock:

• P2MULTI 2-of-2 anchor — well within the 16-key cap (§5.1).
• HTLC template (§5.4) — revocable outputs and in-flight conditional payments, each carrying an absolute timeout_height.
• SIGHASH_ALL only (§6) — no ANYONECANPAY, NONE, or SINGLE is required.
• Canonical sequence = 0xffffffff (§3.2) — no relative lock is required; revocation is not lock-based.
• Full-RBF mempool (§19.6) — pre-signed fee tiers rely on always-available replacement.
• Auth budget — a 2-of-2 ML-DSA-87 spend carries 14,445 B of authorization data (1 + 2 × 7,222, §5.1), comfortably inside the per-input cap (131,072 B, §7.5) and the per-tx cap (1,000,000 B).

Channel state and the commitment shape

Channels are funded by a 2-of-2 anchor (§5.3). Every state transition produces one commitment transaction per seat, signed by both parties but retained only locally — a party persists the commitment it would publish and never the peer’s. That asymmetric retention is what makes revocation safe: a peer cannot publish an old commitment of the victim’s, and a cheating peer that publishes its own revoked state can be punished.

Each commitment spends the anchor into up to three kinds of outputs:

1. Broadcaster’s own balance — a revocable HTLC output: the counterparty can claim it by presenting the broadcaster’s per-commitment secret as the preimage; the broadcaster reclaims it through the refund branch after timeout_height = tip_at_signing + PENALTY_WINDOW (1,152 blocks = 24 h at the 75 s block time).
2. Counterparty’s balance — a plain P2PQK output, claimable immediately.
3. One output per in-flight HTLC, each with its own shorter absolute timeout_height (default per-hop delta 144 blocks = 3 h), so a pending conditional payment always resolves before broadcaster funds unlock.

Revocation without a relative lock

Revocation uses per-commitment secrets, the same primitive Lightning relies on, rather than any lock. At each transition both parties reveal their state-n secret to the counterparty; whoever publishes a revoked state exposes its revocable output to the holder of that secret, who spends it through the HTLC claim branch before the timeout — the entire balance the cheat claimed is forfeited.

The delay is carried as an absolute timeout_height inside the HTLC output, not as a relative lock on the L1 input. This is a deliberate simplification relative to Lightning’s OP_CHECKSEQUENCEVERIFY:

• Relative lock measures the delay from when the commitment actually confirms.
• Absolute height measures it from signing time; a pre-signed commitment broadcast past its timeout_height loses its penalty protection (the refund branch opens for the broadcaster).

The gap is harmless in practice because the 24-hour window is one whole day of blocks, the normal path is cooperative close or prompt force-close, and a local watchtower monitors continuously (below). It is stated here honestly because it is the one true tradeoff of this design.

Fee bumping: pre-signed RBF tiers

At each state both parties sign one commitment variant per fee tier — multipliers [1, 2, 4] of the signing-time base fee. If the mempool floor rises later, the broadcaster publishes a higher-fee replacement unilaterally. A tier is only offered when the fee it reserves stays under anchor / 8, so small channels keep an affordable close path even though a 2-of-2 commitment carries 14,445 B of authorization data alone. This works because L1 transactions carry no BIP125 opt-in signal: every transaction is replaceable by a conflicting one at a strictly higher feerate (§19.6).

In-flight HTLC routing and the local watchtower

HTLC timeouts use layered absolute heights: each hop adds one CHANNEL_TIMEOUT_DELTA (144 blocks / 3 h), so the payee can claim strictly before the payer’s refund, and an HTLC expired at hop N is refundable at every earlier hop. A small local watchtower — a pure decision engine running on the operator’s own machine with the operator’s own keys, no third party — monitors the chain and raises an action before a deadline: penalties as soon as a revoked commitment is seen (they race the full window), HTLC claims a full hour before their timeout, and refunds (which have no deadline) whenever they become due.

Position in this document

The channel layer earns no privileges from Base and no commitment in this roadmap. Its only claim on this document is the honest enumeration above: the L1 limits it depends on — output templates, auth budgets, the P2MULTI key cap (§5.1), the always-replaceable mempool (§19.6) — are written down here, because a higher layer cannot design against numbers that are not.

4.4 qanum Compute

Future direction for more expressive execution off L1: rollups, sidechains, specialized domains. Not implemented, and unlike §4.3 and §4.5 no external work on it exists. Nothing in this section is consensus or scheduled.

4.5 qanum Privacy

A gradual set of privacy improvements, in this order:

1. Implemented / operational: post-quantum encrypted transport (Noise hybridXX with X25519 + ML-KEM-1024, ML-DSA-87 node identities, TOFU), no-reuse wallet defaults, inventory trickle, echo suppression on block and tx relay.
2. Hardening line (network, not consensus): better relay privacy and eclipse resistance.
3. Not L1, parked: ring signatures, confidential amounts, and any scheme that hides value or the UTXO graph from a validating full node. Those belong to a future privacy domain that would settle to Base. They are not specified here and are not scheduled for the consensus templates. As with §4.3, prototype work on such a domain exists outside this repository; it settles to Base through ordinary templates, adds nothing to consensus, and its existence changes no commitment made in this document.

5. State model: UTXO with native templates

qanum uses the UTXO model because it fits discrete spending policies, isolates balances, and keeps monetary semantics simpler than a general-purpose account model.

5.1 Templates defined and enforced

Vault / P2R recovery delay is consensus-bounded to 144 ..= 5_256_000 blocks. Identical branch keys on two-path templates, HTLC timeout_height below creation height + 2 (which guarantees a non-empty claim window), and VAULT_PENDING unlock_height == 0 are consensus-invalid. Output payloads are capped at MAX_OUTPUT_PAYLOAD_BYTES = 16_384 in the validator, not only in the parser.

The P2MULTI key cap, and why it is not free

TPL_P2MULTI accepts 1 ≤ m ≤ n ≤ P2MULTI_MAX_KEYS = 16 (n > 16 is P2MultiKeyCountTooLarge; m outside 1..=n is P2MultiThreshold). Keys must be ML-DSA-44 or, from the suites5 activation height, ML-DSA-87 (one output may mix them), and strictly increasing by (suite_id, key_id), which also rules out duplicates — a duplicate would silently lower the real threshold.

The cap is not an independent policy dial. Spending an m-of-n output requires m signatures inside the auth entry of one input, bounded by MAX_AUTH_BYTES_PER_INPUT. At 1 + 2 + 1312 + 2420 = 3735 bytes per ML-DSA-44 seat and 1 + 2 + 2592 + 4627 = 7222 per ML-DSA-87 seat:

  budget 16_384  ->  1 + 4·3735  = 14 941 B   (ceiling 4)
  budget 65_536  ->  1 + 17·3735 = 63 496 B   (ceiling 17)
  budget 131_072 ->  1 + 18·7222 = 129 997 B  (ceiling 18 with ML-DSA-87 seats)

Raising the key cap without raising the per-input budget would produce outputs that are fundable and permanently unspendable, rejected with AuthLength — an error that never mentions multisig. constants::p2multi_max_spendable_keys() derives the ceiling rather than restating it, and a test fails if the two are ever set out of step.

The key_count field is a u8, so the wire format admits 255 keys: the limit is policy plus auth budget, not serialization. The permanent cost of a large n is the payload (2 + 34n), which lives in the UTXO set for the life of the output — 546 bytes at n = 16.

There is no general script versioning and no plan to add a ring / confidential template to this set.

5.2 Philosophy

L1 expressiveness is sufficient for money, security and advanced custody. It is not an arbitrary compute environment.

6. Post-quantum cryptography

6.1 Requirements

Maturity and standardization, auditability, reasonable verification cost, coexistence with future suites.

6.2 Implemented suites

The level-5 suites (NIST category 5) coexist with the first two in the code, so a chain can move from one level to the other without a flag day (crypto agility). They may appear only in outputs created from the suites5 activation height, and from the retire12 height new outputs, the coinbase included, may not use ML-DSA-44 or SLH-DSA-SHAKE-128s; spending old outputs is never gated, and a VAULT funded before the height can still be unvaulted. The anonymous coinbase pays ML-DSA-87 from the retire12 height. Testnet has both heights at 0: it is level 5 from its genesis, so no level-1/2 output ever exists on it. Regtest has suites5 at 0 and no retirement by default, both movable with -testactivationheight=suites5@<h> / retire12@<h> to exercise the transitions. Mainnet has no genesis yet; its schedule is set with it. P2PQK, P2MULTI (mixing allowed) and the VAULT hot key take ML-DSA-87; both HTLC branches and the VAULT cold key take both; a P2RKPQ pair stays within one level. For mainnet, the AIP condition of two independent audited implementations is still open: the node verifies with liboqs only.

Reserved, not implemented — IDs are stable and activation requires an AIP, two independent audited implementations and published consensus test vectors (spec §2.4): ML-DSA-65 0x0102, FN-DSA-512 0x0103, SLH-DSA-SHAKE-192s 0x0202.

Verification uses liboqs and is mandatory: the node does not build without the crypto-oqs feature, runs a known-answer self-test of every suite at startup and refuses to start if it fails. Non-verifying verifiers exist only in tests and in a regtest-only simulation build tagged -sim.

6.3 Hashes and domain separation

Chain hash and commitments: SHA3-256, the only hash in consensus. Outside consensus: SHA-256 and SipHash for BIP157/158 compact filters, HMAC/HKDF-SHA-256 in the wallet key store, SHA-512 in the Noise handshake and in the release checksums.

Domain separators:

• QANUM-SIGHASH-V1
• QANUM-MLDSA-V1
• QANUM-SLHDSA-V1
• QANUM-KEYID-V1 — key_id = SHA3(QANUM-KEYID-V1 ‖ suite_id_le ‖ pubkey)

Sighash covers SIGHASH_ALL only. birth_height is not in the sighash (by design: it is a chain property, not a signing input).

Quantum margin of the hashes. Every commitment above (chain hash, txid/wtxid, Merkle roots, utxo_root, key_id, sighash) is 256-bit SHA3. Grover’s algorithm [17] lowers preimage and second-preimage resistance to about 2^128 quantum hash evaluations, the margin NIST assigns to AES-256 key search (category 5) [20]. Collision resistance stays at the classical birthday bound of 2^128: quantum collision search gives no practical gain once its hardware cost is counted, and 2^128 is the margin NIST uses as category 2 and the one SHA-256 gives Bitcoin today. No hash change is needed for the post-quantum horizon. The wallet store at rest (AES-256-GCM, Argon2id) also keeps 128 bits against Grover; its weak point is the passphrase, not the cipher.

6.4 Transaction identifiers

• Non-coinbase txid = SHA3-256 of serialize_base() (no auth).
• wtxid = SHA3-256 of serialize_full() (includes auth).
• Coinbase txid = SHA3-256 of the full serialization.

A global signature cache (LRU, 50_000, keyed by wtxid) may skip liboqs on a hit. Height and path policy still run in validate_tx_no_crypto before that shortcut. The cache is cleared on reorg detach.

6.5 Cryptographic agility

Each template and each address operate over versioned suites so schemes can coexist, migrate, and be deprecated without rewriting the monetary layer.

7. Addresses and output format

qanum uses Bech32m addresses.

7.1 HRP per network

• mainnet: qn
• testnet: tqn
• regtest: rqn

7.2 Structure

An address encodes addr_version, template_id and payload. It is a compact reference to the template and its canonical payload, not a bare hashed public key.

P2PQK can encode ML-DSA-87 and ML-DSA-44 (suites::KeyRole::P2pqk). The SLH-DSA suites are stored as recovery keys and are not encoded as P2PQK strings (getnewaddress slhdsa returns {key_id, suite, note}).

7.3 Operational philosophy

No address reuse, change to fresh addresses, clear separation of roles and custody paths.

8. Scripting and L1 expressiveness

qanum rejects a general-purpose virtual machine on the base layer.

8.1 What L1 does support

Differentiated signature paths, limited multisignature, time locks, hash locks, recovery paths, delayed vaults, explicit spend policies — all as native templates plus contextual height rules.

8.2 What L1 does not intend

Turing-complete execution, EVM compatibility, stateful arbitrary contracts, general-purpose DeFi, ring / confidential ledgers, or hidden amounts.

9. Consensus: Proof of Work

9.1 Reasons

Relative neutrality, a link between security and verifiable external cost, less dependence on stake-based governance, good fit with an austere monetary layer.

9.2 PoW

• Work hash: SHA3-256(header.serialize()), 152-byte header
• Comparison: big-endian target
• Limit: POW_LIMIT_BITS = 0x1e0fffff
• Work: 2^256 / (target + 1) (nonzero at the limit)

bits must be the canonical compact encoding of a target in [1, POW_LIMIT]. Non-canonical encodings are rejected.

9.3 Target block time

• TARGET_BLOCK_TIME = 75 seconds
• BLOCKS_PER_YEAR = 420_480 (365 × 86400 / 75)

This interval is the ASERT spacing. It is a consensus constant. The miner’s template clock is not tip + 75; see §18.5.

9.4 Difficulty adjustment

Anchored ASERT (anchor derived from genesis):

• ASERT_HALF_LIFE = 172_800
• signed 16.16 exponent and a deterministic polynomial for 2^{frac/65536}
• raw target clamped to [1, POW_LIMIT], then recoded to canonical compact bits
• a past timestamp (negative Δt) hardens the target; it does not explode it
• evaluated at the parent: a block’s bits come from its parent’s timestamp and height, exponent = (t_parent − t_anchor − 75 · (h_parent − h_anchor)) / half_life, as BCH aserti3-2d computes from the previous block. A block’s own timestamp does not change its bits; the genesis’ child carries the genesis bits.

After a long idle, the first new block still carries the difficulty computed from its parent; the next one, whose parent is stamped late, typically sits at POW_LIMIT. That is the formula, not a bug. For the same reason a drop in hash power is priced one block later than with a rule on the block’s own time.

9.5 Time rules

• MTP: median of the last 11 parent timestamps (or fewer near genesis). timestamp <= MTP is invalid.
• Future window: timestamp > now + 2 hours is invalid (MAX_FUTURE_BLOCK_TIME_SECS).
• timestamp between MTP and the parent’s timestamp is valid; the ASERT bits do not depend on it (§9.4).
• Header version must be exactly 1.

9.6 Best chain

The active chain is the valid chain with the most accumulated work whose blocks are all stored. On equal work the tip seen first stays, and the node reorganizes only to a chain with strictly more work, as Bitcoin Core does (FindMostWorkChain, nSequenceId). The best header of the header DAG follows the same rule (Core m_best_header). A deep reorg (detach > 100) is accepted if it has more work; the node only raises a warning (log, RPC warnings, -alertnotify).

Two sibling blocks always have equal work: their bits come from the shared parent (§9.4), so the block seen first keeps the tip and a later sibling, whatever its timestamp, is stored as a side branch.

9.7 Coinbase maturity

COINBASE_MATURITY = 1152 blocks (~24 h at 75 s).

9.8 Chain-security parameters (no checkpoints)

There are no checkpoints, as in Bitcoin Core v30 (#31649): the chain is the valid chain with the most accumulated work, with no height below which a reorg is refused. What remains compiled per network cannot select a chain (docs/CHECKPOINT-POLICY.md):

• Header pre-synchronization (src/headers_presync.rs, Core #25717): a header chain below the anti-DoS threshold max(best header work − 1152 blocks of work, minimum_chain_work) is followed in bounded per-peer memory and stored only after its work crosses the threshold and a second download matches the first.
• Minimum chain work (src/constants.rs, Core nMinimumChainWork): 0 on every network today; a release sets a real value once the testnet chain has history. A node below it stays in IBD and serves no headers.
• assumevalid (src/constants.rs; none on every network today): post-quantum signature checks are skipped only for ancestors of that block, when it is on the best header chain with at least the minimum chain work and the block is buried under more than two weeks of work. PoW, structure, bits/MTP and the UTXO set are always verified. With an empty hash no signature check is skipped.

9.9 Quantum adversary and proof of work

Post-quantum signatures protect spending against Shor’s algorithm. They do not protect the nonce search, and no choice of hash function would: Grover’s algorithm [17] finds a header hash below the target with a quadratic speed-up, for SHA3-256 exactly as for SHA-256. Memory-hard or other PoW functions also keep a polynomial quantum advantage [19]. Qanum does not claim that its proof of work is quantum-resistant. Its position:

• The advantage is real but bounded. If one hash succeeds with probability p, Grover needs about 1/√p oracle calls instead of 1/p. Every call is a fault-tolerant evaluation of the whole hash circuit [20], and Grover parallelises badly: K quantum machines gain only √K. Published estimates put a quantum miner far below one current ASIC for years to come: about 13.8 GH/s at an optimistic fault-tolerant gate rate of 66.7 MHz [18].
• Difficulty adjustment absorbs it. Anchored ASERT (§9.4) retargets after every block, so a jump in hash power, quantum or classical, is priced in within hours, not after a 2016-block window.
• The residual risk is the classical one. For chain security, a quantum miner with a large share of the work is the same as an ASIC farm of that size: the majority-hashrate risk of §19 and THREAT-MODEL.md §1. On a young network, renting classical hash power is the more likely threat.
• New risk: more forks. A quantum miner gains by measuring its state early when a rival block appears. This correlates miners and can raise the stale-block rate [19]. The 75 s spacing cuts the useful Grover time per block, which shrinks the advantage of a small quantum miner, but has a higher natural stale rate than 10-minute blocks. Neither effect has been measured for Qanum. The countermeasure proposed in [19], a tie-break that penalises timestamps, is an open conjecture that needs precise clocks; Qanum does not adopt it. Equal-work ties go to the block seen first, as in Bitcoin (§9.6), so a late rival does not win a tie.
• Monitoring, not finality rules. Qanum adds no maximum reorg depth: that would be a checkpoint by another name (§9.8). Operators watch the stale rate with getchaintips and the deep-reorg warning, which the node logs, lists in the RPC warnings field and passes to -alertnotify (TESTNET-RUNBOOK.md §10).
• Review before mainnet. The PoW keeps SHA3-256: no other hash would resist better, and output length does not matter for mining (the target sets the difficulty). Before the mainnet parameter freeze the published estimates of quantum hashing are checked again against the network’s measured hashrate and stale rate (§20, Phase 3).
• Other hashes (txid, Merkle, utxo_root, key_id): see §6.3.

10. Resource accounting

A post-quantum network cannot measure block cost in bytes alone.

10.1 Dimensions

1. Base bytes and auth bytes (separated in the tx / block format)
2. Verify units

10.2 Implemented limits

10.3 Verify units

Measured costs (pre-release development build, examples/pq_bench on the build machine, aarch64, one core per run; raw data and method in docs/benchmarks/2026-10-14_9322200/): verifying ML-DSA-87 takes 167 µs on a Gold core and 545 µs on a Silver core, SLH-DSA-256s 1.89 ms and 6.67 ms. Against ML-DSA-44 = 100, ML-DSA-87 measures 283–286 units, SLH-DSA-128s 1466–1576 and SLH-DSA-256s 3200–3492, under the constants above, which leave room above the spread between rounds. A block at the auth-bytes limit (415 ML-DSA-87 spends) validates in 152 ms / 553 ms on one thread with every signature verified, and the verify-unit worst case (57 SLH-DSA-256s recoveries, two more than fit at 3600 VU) in 125 ms / 446 ms. Numbers are indicative; the VU costs above remain the consensus budget. On an x86-64 EPYC core (docs/benchmarks/2026-10-14_18ab169-epyc/) every check is faster (worst blocks 75–86 ms) but the SLH-DSA ratios are higher (2623–2687 and 5601–5902), because liboqs runs ML-DSA with vector code there and SLH-DSA in portable C. The budget bounds time, so the constants follow the slowest core.

11. UTXO set commitment

11.1 Key elements

Every header carries utxo_root. The tree commits, for each coin:

• value, template_id, payload, birth_height, flags (including coinbase)

BURN outputs never enter the set.

11.2 Engine actually used

Block validation uses ReconstructiveCommitmentEngine only. An incremental / cache-assisted engine exists in the code for experiments; consensus does not call it, and its cache is not a source of truth (it always recomputes if invoked). The three #[ignore] tests in the suite are two manual large-RAM benchmarks (chainstate_scale_benchmark, utxo_commitment_scale_benchmark) and the generator of the crypto self-test vectors (regenerate_self_test_vectors). None is a consensus hole.

11.3 Strategic value

Explicit commitments make the UTXO set verifiable at every height. The snapshot bootstrap (AIP-0001) uses them: a snapshot is checked against the utxo_root of a PoW-validated header, not against a hash shipped in the release as with Bitcoin Core’s assumeutxo [11].

12. Storage management and pruning

12.1 Cost of post-quantum signatures

An ML-DSA-87 public key + signature is about 7.2 kB (ML-DSA-44: about 3.7 kB), versus tens of bytes for a classical Schnorr signature. At equal transaction counts the chain grows faster unless auth data is treated separately.

12.2 Base/auth separation

Implemented in the block format. Auth can be stored and served differently from base data.

12.3 What is implemented today

• Atomic writes (tmp + write_all + sync_all + rename + directory fsync). Sensitive files use atomic_write_private (mode 0600): P2P identity key (p2p_identity.json), TOFU pins (peer_ids.json), addrman.json, banlist.json, wallet material.
• Undo records (magic QNUN, v2: a SHA3-256 checksum over the block hash and the record, checked before parsing; v1 records without a checksum are still read) are written before chainstate.bin. A reorg or invalidateblock proves the undo data it used: after the disconnections the UTXO set must have the common ancestor’s utxo_root. Damaged undo data is a local failure (no peer punished; a reorg that cannot disconnect stops the node). Missing or damaged undos of the last active-chain blocks are rebuilt on ChainManager::new.
• Chainstate snapshot magic QNSS, version 4 (v2/v3 legacy snapshots still load). Unusable snapshots (bad magic/version/EOF, non-minimal compact-size, oversized counts) rebuild from blocks; I/O / permission errors do not.
• Whole-block prune to .qnlp (-prune / -prune-depth, minimum 288 blocks as Bitcoin Core MIN_BLOCKS_TO_KEEP). A pruned node rebuilds missing recent undo data from its stored bodies (the .qnlp files keep inputs and outputs) and refuses reindex, since its pruned blocks keep no signatures.
• txindex, addressindex (format v2) and blockfilterindex are optional (default off). Whole-block prune (-prune) rejects txindex/addressindex at startup — an explorer node must keep full block data. blockfilterindex is accepted and survives pruning: the index keeps feeding live from connected blocks, but a rebuild cannot complete for blocks whose undo data was pruned — such blocks are skipped and the index reports itself not up to date, so NODE_COMPACT_FILTERS is not advertised (coinbase-only blocks rebuild without undo). All three indexes stay fully compatible with selective auth-data pruning (§12.4).

12.4 Selective auth-data pruning

Implemented (-auth-prune-depth=<N>): full blocks older than N confirmations are converted to base-only .qnlp files — historical non-coinbase signatures are discarded — while base data, undo data and the optional indexes (txindex, addressindex, blockfilterindex) are kept, so deep reorgs and explorer queries keep working. The coinbase retains its full auth (its txid covers the full serialization; pruning it would break the merkle root and txindex lookups). Such a node reports pruned: true, auth_pruned: true with auth_prune_depth in getblockchaininfo and advertises NODE_NETWORK only — it cannot serve full history to peers. Archive nodes that keep full history serve IBD.

12.5 Validation compatibility

Auth pruning does not weaken consensus: IBD still needs a source of full blocks (an auth-pruned node advertises NODE_NETWORK only), and a node that has already validated can drop old signatures and still serve the current UTXO set.

13. P2P network and transport

13.1 Current state (net_v2, protocol version 3)

• Post-quantum Noise transport, the only one: every connection runs the hybrid Noise XX handshake (X25519 + ML-KEM-1024, ChaChaPoly, SHA-512), then each side proves its ML-DSA-87 node identity by signing the handshake transcript, its own static keys and its role. Rekey every 1 GiB or 1 h per direction; 10 s handshake limit. There is no TLS and no plain-text P2P on any network.
• TOFU pins the peer’s peer_id (SHA3-256 of its ML-DSA-87 key, domain-separated) per SocketAddr (IP + port); only outbound and feeler handshakes create pins. An identity mismatch always rejects. A pin moves only through a signed succession: after rotatep2pidentity the old key signs the new one for 60 days, and a peer that pinned exactly the old identity follows it one step. Otherwise the operator runs removetofuentry. One connection per node identity.
• Length-prefixed framing (u32) + bincode, with a strict frame-size limit. No per-message checksum; the messages travel inside Noise transport frames (u16 length, AEAD-authenticated, up to 65 535 bytes), and the network magic is bound into the Noise prologue and the handshake (qan1 mainnet / qan4 testnet / qan3 regtest).
• Self-connection rejection via a local nonce.
• DNS seeds (-dnsseed / -nodnsseed), -seednode / -addnode.
• Inbound cannot fill maxconnections: 8 outbound slots reserved (56 inbound at the default 64). Inbound quota per /16 (IPv4) or /32 (IPv6) is max(8, maxconnections/4) → 16 at 64 (an extra defense; Core has none). There is no per-IP connection cap, as in Core. When the inbound slots are full, Bitcoin Core SelectNodeToEvict protects peers that are hard to imitate (diverse netgroups, lowest ping, recent novel tx and blocks, longest uptime) and evicts the youngest peer of the most-populated netgroup; if every inbound peer is protected, the newcomer is rejected. Loopback is never scored. Outbound candidates are 1-per-netgroup.
• Inventory trickle (buffered getdata) and echo suppression for MsgBlock and MsgTx.
• Addr.last_seen is clamped to [now − 30d, now + 10min].
• BIP157 compact-filter service when -blockfilterindex is on and the index is current (NODE_COMPACT_FILTERS). Limits: 1_000 filters, 2_000 filter hashes, checkpoints every 1_000 blocks.

13.2 Hardening line (not a missing property of the stack)

More private relay, stronger eclipse resistance, peer-metadata policy. These refine the existing encrypted network; they do not replace it.

13.3 Mempool (as implemented)

Caps: 40_000 entries (DEFAULT_MAX_MEMPOOL_ENTRIES) and DEFAULT_MAX_MEMPOOL_BYTES = 32_000_000 (32 MB ≈ ten minutes of full blocks at the 4 MB / 75 s absorption rate). Both are operator-configurable (maxmempool, maxmempoolentries), and docs/STORAGE.md publishes node profiles: a low-RAM domestic node may run 4–8 MB safely (the admission, eviction and expiry machinery below does not depend on the cap), while archive or exchange nodes may raise it for deeper fee buffers. Default min_fee_rate = 1 joma/byte (configuration file; a configured 0 is published honestly). Snapshots (mempool.bin, magic QNMP, format v5) persist the live policy, the orphan relay cache (the CVE-2024-52914 class) and the priority deltas; formats v1–v4 still load.

Replacement: every tx is replaceable (sequence = 0xffffffff is required). There is no BIP125 signal. A replacement must pay replaced_sum + min_fee_rate * size and a strictly higher feerate than the highest evicted tx. Eviction scores the descendant package. Entries older than 14 days (time != 0) are dropped on refresh; time == 0 (legacy) is kept. Rebuild after reorg uses the live min_fee_rate. Inbound FeeFilter is stored and honored: inventory announcements to a peer are filtered by its announced floor.

The orphan map is wired into accept/relay: cap MAX_ORPHANS = 100 (node-configurable, -maxorphantx), TTL ORPHAN_TTL_SECS = 15 min, O(1) resolution via orphan_parents, persisted in the mempool.bin snapshot (format v4 and later). Entries restored from an older snapshot with time == 0 never expire.

Package relay on the wire (announcing ancestor sets) is not implemented.

14. Advanced custody: Vaults and recovery

14.1 Vaults

VAULT / VAULT_PENDING support delayed hot spend, immediate cold recovery, cancel, and finalize after the unlock height. Wallet builders enforce branch ownership per named wallet.

14.2 Recovery

P2RKPQ separates the main path from a delayed recovery path (typically SLH-DSA).

14.3 Philosophy

Safer defaults and native templates. Not confiscation of inactive funds, not mandatory proof-of-life.

15. Scaling and higher layers

qanum does not promise thousands of TPS on the base layer.

15.1 Role of L1

Final settlement, high-value custody, opening and closing higher-layer structures, anchoring aggregated states.

15.2 Channels / compute

An external payment-channels project exists and works as a client-side layer (§4.3), but it is not consensus code: Base neither sees channel state nor has a rule that mentions a channel. An off-chain layer moves traffic off L1 — it does not raise what L1 itself can validate, and it required no new L1 rule (not even a relative lock; revocation uses per-commitment secrets with absolute heights, §4.3). Honest L1 throughput should be thought of in tens of TPS, and that is the number to plan against.

16. Monetary policy

Documented and frozen for mainnet genesis in docs/monetary-policy-decision-record.md.

16.1 Principles

Predictability, credibility, long-term security, low political discretion.

16.2 Parameters

• BLOCKS_PER_YEAR = 420_480
• INITIAL_SUBSIDY = 8 QAN (800_000_000 jomas)
• TAIL_SUBSIDY = 0.2 QAN
• decay per annual epoch: 10 %
• 1 QAN = 100_000_000 jomas

16.3 Subsidy

epoch = floor(height / 420480)
subsidy(epoch) = max(floor(INITIAL_SUBSIDY * 9^epoch / 10^epoch), TAIL_SUBSIDY)

There is no strict final hard cap. Emission decreases and then stays at the tail (~84_096 QAN/year). Supply when the tail is reached (epoch 36) is ~32.9 M QAN; the tail keeps adding thereafter.

As implemented (src/economics.rs), the computation is exact integer arithmetic: num = INITIAL_SUBSIDY, den = 1, both u128; each epoch applies checked_mul(9) / checked_mul(10) followed by a gcd reduction of the fraction; the result is max(num / den, TAIL_SUBSIDY). The exact tail is reached at epoch 36; the first checked overflow fires while computing epoch 41, whose exact value (10,642,235 jomas) is already below the tail and the sequence is monotonic, so returning TAIL_SUBSIDY there is exact, not an approximation.

16.4 Fees

100 % of fees to the block miner.

17. Governance

Low-intrusion. Protocol changes: public proposal, technical discussion, reference implementation, review, conservative activation. No tokenized on-chain governance of base consensus. The monetary layer must change slowly.

18. Current implementation status

A substantial Rust implementation. user_agent and getnetworkinfo.version are derived from CARGO_PKG_VERSION (/Qanum:<version>/).

18.1 Core

Binary parser (non-minimal compact-size rejected), txid/wtxid, sighash, merkle, reconstructive utxo_root, validator (height/path policy in no_crypto), PoW, anchored ASERT, header chain, chainstate, undo bound to vin.

18.2 Chain infrastructure

Block store and tree (RAM cache + persistent block_index.bin), header index with journal, undo store, graph-aware reorg, persisted mempool with post-reorg rebuild, whole-block prune, deferred chainstate snapshots (default interval 32), optional txindex / addressindex / filterindex.

18.3 P2P and sync

net_v2 as in §13: post-quantum Noise transport + TOFU on node identities, connman (reserved outbound, 1-per-netgroup outbound, inbound netgroup quota), DNS seeds, IBD invariance, single header-sync leader, download quotas, echo suppression, block-orphan lifecycle, side-branch detection, stall timeouts, decoupled scheduler↔connman backpressure, in-memory header serving, BIP157 serving when the index is current.

18.4 Wallet

Key store (Argon2id + AES-256-GCM, zeroize), named multi-wallet, scan and live balances across all custody templates, Bech32m, P2PQK / P2RKPQ / VAULT / HTLC builders, getnewaddress including SLH-DSA recovery keys, dump/import with suite-length and size caps, mining rewards to a key or P2PQK address.

18.5 Miner

A single constructor: miner_v2. src/miner.rs does not exist. Template timestamp is max(MTP + 1, adjusted_now) capped at now + 2h. Selection is ancestor-package fee/vu under the block budgets. Coinbase auth is height compact-size + QAN-MINER. Daemon (-gen, generatetoaddress) and offline mine-block / mine-blocks share this path.

18.6 RPC / CLI

JSON-RPC 1.0 style plus a native envelope for qanum-cli. No aliases, no duplicate commands. Extra positional parameters are rejected. Networks and default ports:

One P2P port per network, always encrypted. There is no plain-text P2P port: the node refuses to start with -plaintextport.

18.7 Tests and testnet

• 269 integration files with 1435 integration tests (2 #[ignore]; 1433 live) and 806 unit tests across 89 source files: 2,241 test functions by static count (method in TESTSUITE.md).
• The testnet genesis exists (timestamp 1_791_724_665 = 2026-10-11 13:17:45 UTC, bits 0x1d1f77e8, nonce 473_465_723, hash 0000000d925e437363cbb77b875e3198ca7360ffa7de8f3f4e386a3ef6dae1a2; it meets its own proof of work). Its block hash and merkle root are pinned in the source, as in Bitcoin Core’s chainparams, and a node whose built genesis differs refuses to start. Mainnet genesis is not defined.
• Signature verification with liboqs is mandatory on every network; the node does not start without it.

18.8 Specification track (proposals, not implemented)

The companion consensus specification (spec.md) writes down four proposals that are not implemented and change no consensus rule until an AIP activates them:

Until these are implemented and locked, higher layers must not design against them.

19. Risks and trade-offs

A consolidated threat model — adversary classes, attack costs, mitigations and accepted residuals — is maintained in docs/THREAT-MODEL.md.

19.1 More expensive post-quantum signatures

Mitigation: path separation, native templates, verify units, austere L1, selective auth-data prune (-auth-prune-depth).

19.2 Wallet and custody complexity

Mitigation: safe defaults, explicit templates, hot/cold separation, native flows.

19.3 Long-term security budget

Mitigation: PoW, decreasing curve, low permanent tail.

19.4 P2P transport

The P2P transport is post-quantum: a hybrid Noise handshake (X25519 + ML-KEM-1024) with ML-DSA-87 node identities. A classical X25519 key exchange alone would leave recorded traffic open to later decryption by a quantum computer (“harvest now, decrypt later”); because the session keys also depend on ML-KEM-1024, recorded traffic stays confidential unless both X25519 and ML-KEM-1024 are broken. Remaining work is hardening (relay privacy, anti-eclipse).

19.5 Incumbent network effect

Mitigation: complementary positioning as an austere PQ monetary base.

19.6 Always-replaceable mempool

Every transaction is RBF. That is the opposite of pinning: a higher-feerate conflict evicts. It is a deliberate policy, not an unfinished BIP125.

19.7 Quantum mining

The proof of work is not quantum-resistant, for any hash function (§9.9). Mitigation: per-block ASERT, stale-rate and deep-reorg monitoring; the residual risk is the same as a classical majority of hash power.

20. Indicative roadmap

Done

Rust node, chainstate, PoW + ASERT, wallet with OQS, net_v2 sync, RPC, encrypted transport, structured logging, getnewaddress, shared qanum.conf, adversarial RPC hardening, persistence hardening, mempool policy, unified miner, time/PoW tests.

Phase 2 remainder — wider public testnet

• Keep minimum chain work / assumevalid current on testnet each release; set mainnet values once it has history
• Further P2P hardening (private relay, anti-eclipse)
• Consolidated public documentation (this draft is a step)
• Wallet UX and operational fixes as they appear

Phase 3 — Mainnet preparation

• Final mainnet genesis and parameter freeze
• Quantum-mining review before the freeze (§9.9): published estimates against the measured hashrate and stale rate
• Audits, expanded fuzzing and benchmarks
• Auth-data pruning (operational) and archive-node service flags
• Formal operation of mainnet DNS seeds
• Address→keyid resolution improvements in the wallet

Not in this phase: command aliases.

Phase 4 — Advanced scaling and tooling

• Channels and payment pools — as L1 support only (nothing on this list is a consensus change; higher layers are built off Base, see §4.3)
• Hardware wallets
• Relay / policy improvements that do not change consensus
• Improved operational privacy

Phase 5 — Modular compute and strong privacy

• Richer execution domains and external validity
• Strong privacy off L1 (including any future ring / confidential design). Not specified, not scheduled for Base templates.

21. Conclusion

qanum is born from a simple conviction: the next great monetary infrastructure should not try to do everything in its base layer. It must be secure, austere, adaptable and designed to last.

Its proposal combines a verifiable UTXO base, PoW as an anchor of neutrality, post-quantum cryptography from genesis, an encrypted transport already in the stack, hardened multi-node sync, vaults and recovery as real self-custody, and a modular roadmap where advanced payments, stronger privacy and expressive compute live off L1.

The design reduces to three commitments: long-term security, safer self-custody and disciplined modularity. Every structure in this document should be read against them; how each component relates to prior art is recorded in ARCHITECTURE.md (provenance table) and BIP-REGISTER.md.

References

Standards and prior art used by this design. The provenance of each adopted component (what was re-parameterised, what was reimplemented clean-room) is tabulated in ARCHITECTURE.md.

Cryptographic standards

1. NIST FIPS 202 — SHA-3 Standard (2015). PoW hash (sha3_256(header)) and domain-separated hashing. https://doi.org/10.6028/NIST.FIPS.202
2. NIST FIPS 203 — Module-Lattice-Based Key-Encapsulation Mechanism Standard (ML-KEM, 2024). ML-KEM-1024 in the hybrid P2P handshake (§13.1, §19.4). https://doi.org/10.6028/NIST.FIPS.203
3. NIST FIPS 204 — Module-Lattice-Based Digital Signature Standard (ML-DSA, 2024). The ML-DSA-87 and ML-DSA-44 signing suites. https://doi.org/10.6028/NIST.FIPS.204
4. NIST FIPS 205 — Stateless Hash-Based Digital Signature Standard (SLH-DSA, 2024). The SLH-DSA-SHAKE-256s and SLH-DSA-SHAKE-128s suites. https://doi.org/10.6028/NIST.FIPS.205
5. T. Perrin — The Noise Protocol Framework, revision 34 (2018). Base of the P2P handshake (XX pattern, extended with ML-KEM in the hybrid form implemented by the clatter crate). https://noiseprotocol.org/noise.html

Ecosystem prior art

1. BIP-173 — Base32 address format for native v0-16 witness outputs (bech32). https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki
2. BIP-350 — Bech32m format for v1+ witness outputs. https://github.com/bitcoin/bips/blob/master/bip-0350.mediawiki
3. BIP-157 — Client Side Block Filtering. https://github.com/bitcoin/bips/blob/master/bip-0157.mediawiki
4. BIP-158 — Compact Block Filters for Light Clients (official test vectors used by the filter suite). https://github.com/bitcoin/bips/blob/master/bip-0158.mediawiki
5. ASERT — 2020-NOV-15 ASERT Difficulty Adjustment Algorithm (aserti3-2d), Bitcoin Cash upgrade specification. Re-parameterised here for 75 s target spacing and a 172 800 s half-life. https://upgradespecs.bitcoincashnode.org/2020-11-15-asert/
6. Assume UTXO — J. O’Beirne, The design of assumeutxo, Bitcoin Core design docs. The out-of-band-anchored UTXO-snapshot mechanism that AIP-0001 improves on by anchoring the state root in-chain (utxo_root per header, spec §10). https://github.com/bitcoin/bitcoin/blob/master/doc/design/assumeutxo.md

Companion documents in this repository

1. spec.md — technical specification (normative draft).
2. ARCHITECTURE.md — architecture, prior-art provenance table, and “Why a new chain”.
3. BIP-REGISTER.md — adopted de-facto ecosystem conventions, credited.
4. CVE-REGISTER.md — vulnerability history and fixes.
5. monetary-policy-decision-record.md — monetary options compared, with the exact subsidy computation.

Quantum adversary (§6.3, §9.9)

1. L. K. Grover — A fast quantum mechanical algorithm for database search, STOC 1996. https://arxiv.org/abs/quant-ph/9605043
2. D. Aggarwal, G. Brennen, T. Lee, M. Santha, M. Tomamichel — Quantum attacks on Bitcoin, and how to protect against them, Ledger 3 (2018). https://arxiv.org/abs/1710.10377
3. O. Sattath — On the insecurity of quantum Bitcoin mining, International Journal of Information Security 19 (2020). https://arxiv.org/abs/1804.08118
4. M. Amy, O. Di Matteo, V. Gheorghiu, M. Mosca, A. Parent, J. Schanck — Estimating the cost of generic quantum pre-image attacks on SHA-2 and SHA-3, SAC 2016. https://arxiv.org/abs/1603.09383

Appendix A — Parameters as implemented

Appendix B — Encrypted transport (not encrypted amounts)

The P2P transport is always encrypted and authenticated post-quantum: hybrid Noise XX (X25519 + ML-KEM-1024) and an ML-DSA-87 node identity, pinned trust-on-first-use per SocketAddr. A mismatch rejects; a planned rotation (rotatep2pidentity) carries a signed succession for 60 days so pins follow it, and operators clear any other pin with removetofuentry.

That encrypts the socket. Transaction amounts, templates and the UTXO graph remain public to every full node — by design, so the base stays auditable.

What remains a hardening goal is advanced relay privacy (trickle is already present, and inventory filtering by a peer’s FeeFilter is implemented) and eclipse mitigation. Those are network-stack work. They are not ring signatures and they are not confidential transactions.

Appendix C — Glossary

Terms used across this document and the companion specification.

• QAN — user-facing monetary unit. 1 QAN = 100 000 000 jomas.
• joma — smallest indivisible unit (the consensus arithmetic unit; subsidies and fees are expressed in jomas).
• epoch — 420 480 blocks (one year at the 75 s target). Subsidy per epoch: max(floor(8 QAN × (9/10)^epoch), 0.2 QAN), computed as a gcd-reduced fraction (monetary-policy-decision-record.md).
• template — a native spend condition identified by a type byte; templates replace general-purpose script (§5).
• authorization data (auth bytes) — the per-input signature material carried by a transaction; bounded by per-input, per-transaction and per-block limits.
• base/auth split — the separation of block and transaction data into a base part and an authorization part; what makes selective auth-data pruning possible.
• Verify Unit (VU) — consensus budget unit quantifying cryptographic verification cost; blocks are capped at 200 000 VU.
• coinbase maturity — 1 152 blocks must pass before a coinbase output is spendable.
• ASERT — the difficulty adjustment: genesis-anchored, 75 s target spacing, 48 h half-life (aserti3-2d, re-parameterised; see References).
• assumevalid — skipping signature checks for the ancestors of a compiled block hash during sync, as in Bitcoin Core; PoW and structural rules still apply, and it never selects the chain.
• TOFU — trust-on-first-use: a peer’s node identity (peer_id) is pinned on first outbound contact; later mismatches are rejected unless a signed succession moves the pin.
• HNDL — “harvest now, decrypt later”: recording encrypted traffic today to decrypt it once cryptanalysis advances; motivates the post-quantum transport.
• dust — an output below the relay threshold (44 jomas at the default minimum relay feerate); such outputs are not relayed.
• feerate — fee per raw byte; the policy ordering key for mempool admission and replacement.
• compact filter — a BIP-158-style summary of a block used by light clients (BIP-157 protocol).
• P2MULTI — the multisignature template; up to 16 keys per output, and the per-input auth limit is sized so that 16 ML-DSA-87 signers fit (§5.1).
• vault — the VAULT / VAULT_PENDING custody templates: a delayed hot spend and an immediate cold recovery (§14.1). P2RKPQ adds a delayed recovery path to a main key (§14.2).
• IBD — initial block download: the first sync from genesis (or the last snapshot) to the network tip.
• reorg — chain reorganization: switching to a heavier branch and undoing the displaced blocks.
• QNMP — the magic of the persisted mempool file (mempool.bin, format version 5).
• net_v2 — the current P2P stack: encrypted transport, header-first sync, block scheduler.