Research

This page is for researchers, universities, evaluators and partners. It lists what can be measured and reproduced today, where the method and the data are, and which questions are still open. Every number below comes from a published document with its method; none of them comes from an independent audit, which mainnet still requires.

Contents

• Crypto agility, end to end
• Post-quantum costs, measured
• Your own test network
• Testnet data
• Review material
• Open questions
• Collaborate

Crypto agility, end to end

Qanum treats no signature scheme as permanent (whitepaper §3.2, §6.2 and §6.5). Every key in an output carries its suite ID. A suite enters by height (suites5) and leaves new outputs by height (retire12); outputs created before stay spendable forever. Testnet runs both heights at 0, so it is level 5 from its genesis. On regtest both heights move with -testactivationheight=suites5@<h> and -testactivationheight=retire12@<h>, so the transition can be replayed.

The suite migration experiment runs that transition on a regtest network of four real qanumd nodes with the production verifier (liboqs): one miner, one user with level-1/2 coins, one node that never enforces the retirement and one that does not know level 5. The wallet moves its coins with migratesuites, the old suites are retired, and the chain is rolled back and forward across both heights. Every step is asserted (39 checks) and the measurements are written to results.json and summary.md.

First results (aarch64, 8 cores, 19 October 2026)

• Migration of a five-coin wallet: 4 transactions, 19,165 bytes, 383,300 jomas of fees at 20 jomas/byte, planned by a dry run before anything is sent.
• Retiring a suite is a soft fork: the node that does not enforce it keeps following the chain. Introducing one is not: the node that does not know level 5 stops at the first block that uses it.
• A rollback of 5 blocks across the retirement height took 486 ms, and restoring them 310 ms; the rules followed the height in both directions.

cargo build --release --locked --bin qanumd --bin qanum-cli
cd test/functional
# As a test (PASS or FAIL):
python3 qan_framework.py feature_suite_migration.py
# As an experiment, writing the measurements:
python3 feature_suite_migration.py --out /tmp/suite-migration

The experiment script and its write-up are in the main branch of the repository and ship with the next release. The pieces it drives, migratesuites and -testactivationheight, are in v0.9.0. Limits stated by the write-up: one machine, no real latency, minimum difficulty, a small wallet; multisig, vault and HTLC outputs are not migrated automatically.

Post-quantum costs, measured

A level-5 key and signature take about 7.2 KB, so Qanum prices authorization apart from base data and bounds the cryptographic work of a block with verify units (whitepaper §10). The verify-unit constants were set from these measurements. Each run is pinned to one core, one job at a time; the raw output and the machine state before and after are published, and the reduction rules are pinned by a test.

A block at the authorization-bytes limit (415 ML-DSA-87 spends) validates in 152 ms on the ARM big core and 553 ms on the little core, on one thread with every signature verified. The full tables cover key generation, signing, ML-KEM-1024, single transactions and full blocks.

• ARM measurements: method and tables.
• x86-64 measurements: method and tables.
• Raw data (JSON Lines and machine state): gold-core6.jsonl (env), silver-core2.jsonl (env), epyc-core1.jsonl (env), epyc-core3.jsonl (env).

cargo build --release --locked --example pq_bench
QANUM_BENCH_COMMIT=<commit> taskset -c <core> target/release/examples/pq_bench --out <file>.jsonl

Measurements on other processors are welcome: the budget bounds time, so the constants follow the slowest core.

Your own test network

• Regtest (P2P 28445, RPC 28338): blocks mined on demand at minimum difficulty, activation heights movable as above. See the user guide and the configuration reference.
• Functional test framework in Python (test/functional, 45 scripts in v0.9.0): starts real nodes, talks to them over RPC and asserts behaviour. A good starting point for new experiments.
• 2,276 test functions and 11 fuzz targets in v0.9.0, with the method and the full inventory in the test suite document.
• RPC for measurement: getblockstats, getchaintips, getpeerinfo, getnettotals, gettxoutsetinfo, invalidateblock and the rest of the RPC reference.

Testnet data

The public testnet has 75-second blocks and coins with no value. Two sources of data:

• The explorer: blocks and transactions, plus live pages for block statistics, difficulty history, mining summary and peers.
• Daily telemetry from a seed node, described below.

Daily telemetry (public)

A seed node records the chain and its own state every 5 minutes with read-only RPC calls (since 19 October 2026; the block history starts at the testnet genesis, 11 October 2026). Once a day the complete UTC days, up to yesterday, are published here under CC BY 4.0. Peer addresses and node identities are never recorded.

• summary.json: the figures above, for the last 7 and 30 days and for all days.
• daily.csv: one row per day (blocks, intervals, transactions, fees, peers, stale tips, reorgs, versions).
• blocks.csv: one row per block from genesis (time, interval, transactions, inputs, outputs, size, fees, subsidy, difficulty).
• README.txt: what every field means. LICENSE.txt: the license.

Suggested credit: Qanum testnet telemetry, https://qanum.org/research/. For now the two seed nodes do most or all of the mining, so stale-block and reorg counts are not representative of a larger network. This is still the history that §9.9 of the whitepaper calls for: it says the stale-block rate of a 75-second chain has not been measured yet.

Full telemetry (on request)

The 5-minute node snapshots (connections, peers per version and connection type, median ping, mempool, chain tips, uptime) and the detail of every stale tip and reorganization are available to research partners on request at partnerships [at] qanum [dot] org.

Review material

The repository also holds the consensus specification, the external audit package and the CVE and BIP registers; they open with it.

Open questions

Measurements that would feed decisions to be frozen before mainnet (the benchmark plan and whitepaper §9.9):

• Verify-unit costs on more processors, including low-power boards.
• The 75-second target block time against 90 seconds.
• Mempool pressure when authorization bytes, not base bytes, are the scarce resource.
• Stability of the anchored ASERT difficulty adjustment under hashrate swings.
• Bootstrap: full download against a verified snapshot.
• Quantum mining: published estimates of quantum hashing against the measured hashrate and stale rate.

Collaborate

Qanum is released under MIT OR Apache-2.0, so code, data and documents can be reused in research. For research collaboration, early source access or joint projects, write to partnerships [at] qanum [dot] org.