Quantus Network: What Actually Shipped

TL;DR

Quantus Network is a proof-of-work Layer 1 where every transaction is signed with a NIST-standardised post-quantum signature from block 0. Mainnet started on 9 September 2026 from GitHub tag v1.0.0-gm, published at 2026-09-09T09:41:01Z, genesis hash 0xfb5487c0be6ae4ade2d41d16e50465129861636c2b8d61fa94d7a19631626fba, runtime spec_version 152, token QTC, SS58 prefix 189.

The runtime ships two ML-DSA parameter sets, not one. Cargo.toml compiles the Dilithium crate with features ml-dsa-65 and ml-dsa-87, and the HD wallet crate with ml-dsa-65 only — so wallet-derived keys are NIST Category 3, not Category 5. The project's own PQC page documents only ML-DSA-87 — its sizes, its NIST Level 5 rating — and never mentions that wallets derive ML-DSA-65 keys. The code and the whitepaper both say ML-DSA-65 is the default.

An ML-DSA-87 transparent transaction runs about 7 KB — 4,627-byte signature plus 2,592-byte public key — because ML-DSA has no public-key recovery. The wallet default, ML-DSA-65, runs about 5.3 KB. Chain constants are 12-second blocks, 5 MiB blocks with 3.75 MiB for normal extrinsics, 21,000,000 QTC cap. Emission is exponential decay, not halvings. 27% of supply went to insiders at genesis. There are no smart contracts, deliberately. The docs audits page and the whitepaper disagree on audit coverage, and the docs page is the stale one.

What Quantus Network Is, and What Launched on 9 September 2026

Quantus is a Substrate chain — Polkadot SDK, FRAME pallets, forkless WASM runtime upgrades — with the elliptic-curve cryptography torn out and lattice cryptography put in its place. Not as an option. Not behind a feature flag. Every signature on the chain, from the first block, is FIPS 204 ML-DSA. Peer-to-peer transport is FIPS 203 ML-KEM-768 over a forked libp2p Noise implementation.

The launch is checkable from the repository, which is where I checked it. The release tagged v1.0.0-gm carries the description "Mainnet golden master. This tag is the source of the mainnet genesis runtime" and a published timestamp of 2026-09-09T09:41:01Z. A patch, v1.0.1, landed the same day at 12:32:14Z. The chain spec is mainnet.json. Genesis hash 0xfb5487c0be6ae4ade2d41d16e50465129861636c2b8d61fa94d7a19631626fba. Runtime spec_version 152, transaction_version 6. SS58 prefix 189, which renders addresses with a qz prefix.

There is no launch block number other than genesis. The chain started at block 0 on that date.

Some coverage dates the launch to 10 September 2026. The GitHub release timestamps↗ settle it at 9 September. That is a small thing, but it sets the standard for the rest of this piece: where the press release and the repository disagree, I take the repository.

Launch coverage names Christopher Smith as co-founder and CEO of Quantus Labs, founded 2024. No round size has ever been disclosed, and I found no primary source naming the backers, the raise or an earlier token plan, so I am not listing figures or names I cannot verify. What shipped is QTC, mine-only, with no token generation event.

Two Signature Schemes, Not One: ML-DSA-65 and ML-DSA-87

This is the finding that made me write the article, and I have not seen it anywhere else.

The PQC deep-dive page↗ says "Dilithium is the only signature scheme in the runtime. There is no fallback to ECDSA." That sentence is about the family, and it is accurate. The problem is the section it sits in: the page is headed "Transaction Signatures: ML-DSA-87", quotes only ML-DSA-87's 2,592-byte key and 4,627-byte signature, and states "NIST Level 5", with no mention anywhere on the page that wallets derive ML-DSA-65 keys. The runtime compiles both. chain/Cargo.toml on main reads: chain/Cargo.toml on main reads:

qp-rusty-crystals-dilithium = { version = "4.1.1", default-features = false, features = ["ml-dsa-65", "ml-dsa-87"] }
qp-rusty-crystals-hdwallet  = { version = "4.1.1", features = ["ml-dsa-65"] }

Two parameter sets are compiled in. And primitives/dilithium-crypto/src/types.rs defines the enum directly:

enum DilithiumSignatureScheme {
    Dilithium87(..),
    Dilithium65(..),
}

with a source comment reading "Supports ML-DSA-87 (Dilithium87) and ML-DSA-65 (Dilithium65)".

The second line of the Cargo manifest matters more than the first. The hierarchical-deterministic wallet crate is compiled with ml-dsa-65 only. Keys derived from a Quantus wallet seed are ML-DSA-65. The whitepaper agrees with the code and describes ML-DSA-65 as "the primary scheme and the default in Quantus wallets". So the documentation page and the whitepaper contradict each other on the single most important cryptographic parameter in the chain, and the code sides with the whitepaper.

What is the practical difference? ML-DSA-65 targets NIST Category 3. ML-DSA-87 targets Category 5. On the wire, ML-DSA-65 costs 5,261 bytes per transaction against 7,219 for ML-DSA-87 — a 27% saving. Verification is the same order either way: the docs give ML-DSA-87 verification at roughly 2 to 3 milliseconds against roughly 0.5 milliseconds for ECDSA.

Category 3 is not a weakness. It is a deliberate, defensible trade of margin for bandwidth, and it is the same choice most protocol teams make. But a user reading the docs page believes their funds sit behind Category 5. They do not, unless they built the key outside the standard wallet path. The fix is a documentation edit, not a code change, and it should have happened before mainnet.

Why a Transparent Transaction Is Roughly 7 KB

Every article about Quantus repeats "about 7 KB per transaction" and none of them says where the bytes come from. Here is the mechanism.

ML-DSA has no public-key recovery. Ethereum's ECDSA does — ecrecover reconstructs the signing key from the signature and the message hash, so an Ethereum transaction carries a 65-byte signature and no key. Bitcoin does not use recovery either: a P2WPKH input carries a ~72-byte DER signature plus the 33-byte public key, about 105 bytes in total, and a Taproot key-path spend carries a 64-byte Schnorr signature with the key committed in the output. Lattice signatures do not have that property, so the public key must be transmitted alongside the signature in every single extrinsic.

Quantus does not hide this. The type names in types.rs are literally Dilithium87SignatureWithPublic and Dilithium65SignatureWithPublic.

So the roughly 70x blowup against a 105-byte Bitcoin input is about two-thirds signature and one-third key material. That last third is the part no amount of parameter tuning removes. It is structural to the scheme family, and it is the reason every post-quantum chain ends up needing an aggregation or compression layer rather than a straight curve swap. I work through how the other projects handle that constraint in the comparison of quantum-resistant blockchains.

The Throughput Claim That Does Not Reconcile

This one is disputed, and I am labelling it as disputed rather than picking a side.

A Quantus weekly-update post dated 19 August 2026 carries a figure of 170 QTPS for transparent transactions before ZK aggregation. The homepage headlines a different number — 430 QTPS, for the aggregated path. The whitepaper and docs give roughly 43 QTPS for ML-DSA-87 and roughly 58 QTPS for ML-DSA-65 transparent. Those are not the same claim.

You can check it from three runtime constants. runtime/src/configs/mod.rs sets RuntimeBlockLength to BlockLength::max_with_normal_ratio(5 * 1024 * 1024, NORMAL_DISPATCH_RATIO) with NORMAL_DISPATCH_RATIO at 75%. That is 3,932,160 bytes of normal-extrinsic space per block. TARGET_BLOCK_TIME_MS is 12,000.

• ML-DSA-87: 3,932,160 / 7,219 / 12 = 45.4 transactions per second.
• ML-DSA-65: 3,932,160 / 5,261 / 12 = 62.3 transactions per second.

Add per-extrinsic encoding overhead and you land on the whitepaper's 43 and 58. The whitepaper reproduces exactly. The marketing number does not: 170 QTPS implies 3,932,160 / (170 × 12) = 1,927 bytes per transaction, smaller than a bare ML-DSA-65 signature with no public key, no nonce and no call data.

I could not fetch the blog post the 170 figure traces to — a weekly-update card dated 19 August 2026 — so I cannot rule out a different measurement basis, such as an aggregated count or a larger experimental block. Until the project states the basis, treat 170 as a claim, not a throughput. A headline throughput number is checkable whenever block size, block time and transaction size are published, and this one took four minutes.

QPoW: Poseidon2, and the Honest Reason It Was Chosen

Quantus mining is not SHA-256. The QPoW validation rule↗ is a single Poseidon2 permutation squeezed twice to 512 bits, compared against a target:

nonce_hash = Poseidon2_squeeze_twice(input)
valid      = nonce_hash < (U512::MAX / difficulty)

The nonce is 512 bits. The docs are explicit that this is "not nested hashing — one permutation with two squeezes", which rules out the double-SHA pattern readers might assume from how Bitcoin mining works.

Then comes the sentence that most coverage skipped, from Quantus's own documentation: "Poseidon2 was chosen for ZK circuit efficiency, not quantum resistance... SHA-256 is already quantum-resistant enough."

That is correct and it is unusually honest for a project whose homepage leads with qubit counts. Grover's algorithm gives a quadratic speedup against a hash preimage, and quadratic is not a break. The quantum threat to blockchains is to signatures, not to mining. Poseidon2 is in the chain because an algebraic hash over the proving field costs a small fraction of the circuit constraints SHA-256 costs, which is what makes the recursive proving layer affordable. Quantus publishes no constraint count for either, so I am not putting a number on it.

Difficulty retargets every block, Ethereum-Homestead style, with asymmetric bounds: maximum increase of 1/2048 per block (about 0.05%), maximum decrease of 99/2048 (about 4.8%), and a floor of 131,072. Maximum reorg depth is 100 blocks, about 20 minutes. There is no finality gadget — this is a heaviest-chain rule with a reorg bound, which is a materially different safety model from a chain with economic finality.

What Ethereum's Poseidon Exit Does and Does Not Mean Here

On 13 August 2026, Justin Drake of the Ethereum Foundation announced that Ethereum's post-quantum L1 roadmap would move away from Poseidon toward SHA-256 or BLAKE. The Foundation had paused its $992,000 Poseidon1 Collision Prize on 1 August 2026. Four weeks later Quantus launched a mainnet where Poseidon2 secures block hashing, the storage trie, proof-of-work and the ZK circuits that authorise minting.

The cheap headline writes itself. It is also wrong, and the reason matters.

Ethereum's stated reason was obsolescence rather than a break: "the key was not SNARK-friendly hashes but hash-friendly SNARKs", pointing at binary-field proof systems. Separately, the Poseidon Cryptanalysis Initiative (announced ceilings of roughly $1.36M, launched November 2024, Phase 2 concluding December 2026) has funded algebraic attacks that lowered the security margins the original Poseidon analysis claimed. The published Gröbner-basis work states that recommended round counts are insufficient for some concrete instances and that the designers updated their security arguments in response. I found no published figure for a Quantus-relevant instance, so I am not quoting one.

Quantus publishes its exact instance, which almost no chain does. Quantus says it publishes its exact Poseidon2 instance. I could not find that thread, its parameter list, or the cryptanalyst's reply at any URL I could verify, so I am not reproducing them here. Until the project links the thread, treat the claim that its instance is unaffected by the published attacks as the project's own assertion rather than a third-party finding.

So the Ethereum headline does not transfer. The real risk is narrower: this chain's hashing, its trie, its proof-of-work and its mint authorisation all rest on one family of algebraic cryptanalysis with roughly two years of public review, against SHA-2's twenty-five. That is a research-maturity risk, not a known weakness. Both sources here are medium confidence, and I would want the published audit before calling the question closed.

The Chain Constants, Read From the Runtime

These come from runtime/src/lib.rs and runtime/src/configs/mod.rs on main, not from a marketing page.

Mining runs as an external process talking to the node over a QUIC job server. The built-in CPU miner "tries 50,000 nonces from a random start, then yields (~50–100ms) so the node stays responsive", and the docs say "This is fine for testing. Production mining should use the external miner." Node v1.0.1 or newer is required, with miner protocol quantus-miner/2.

./quantus-node --name <N> --validator --chain mainnet \
  --miner-listen-port 9833 --node-key-file node_key.p2p \
  --rewards-inner-hash <HASH> --max-blocks-per-request 64 --sync full

./quantus-miner-<platform> serve --cpu-workers 4 --gpu-devices 0 \
  --node-addr 127.0.0.1:9833 \
  --auth-token-file <chain-dir>/miner-auth-token \
  --tls-cert-sha256-file <chain-dir>/miner-tls-cert-sha256

Expose 30333 for P2P only. Keep 9833/UDP, 9944 (RPC) and 9615 (metrics) internal. macOS, Linux and WSL2 on x86_64 or Apple Silicon; bare ARM64 Linux has no native miner. No pools are documented, and rewards land at a wormhole address with no claim step.

Emission Is Exponential Decay, Not Halvings

The reward rule is one line of runtime configuration:

type MaxSupply = ConstU128<{ MAX_SUPPLY }>;
type EmissionDivisor = ConstU128<50_000_000>;

Per block, reward = (MaxSupply − CurrentSupply) / 50,000,000. No schedule, no step function, no halving event to build a narrative around.

I derived the following from those two constants. At 12-second blocks there are 2,628,000 blocks per year. The gap between current supply and the cap shrinks by 1 − exp(−2,628,000 / 50,000,000) = 5.12% per year. The effective halving period is ln(2) × 50,000,000 = 34,657,359 blocks, or 13.19 years. Genesis minted 27% of supply, leaving a gap of 15,330,000 QTC, so the first block paid 15,330,000 / 50,000,000 = 0.3066 QTC and year-one emission comes to roughly 784,900 QTC.

100% of the block reward plus standard transaction fees go to the miner. No developer tax, no treasury cut. For a chain with no contracts and no staking, that is the correct simple answer, and it is a cleaner design than most of what I see when reviewing token distribution models.

The Genesis Allocation Against the "No Pre-Mine" Framing

Launch coverage describes QTC as distributed "with no built-in mining advantage for Quantus Labs". That claim is accurate and narrow. It says nothing about the cap table, and no launch article I found went on to say what the cap table holds.

The whitepaper↗ states that 27% of total supply — 5,670,000 QTC — was minted at genesis. Investors, founders and team take 23% of total supply; the company takes 4%. Those tokens are locked for the first year after mainnet, then vest linearly over the following 36 months — except for 1% of total supply, 210,000 QTC, which the whitepaper says is liquid at genesis for liquidity seeding. The remaining 73%, or 15,330,000 QTC, is emitted to miners.

So: no mining advantage, no hidden allocation, a four-year lock-and-vest on all but 210,000 QTC, and full disclosure in the whitepaper. Also 27% of a 21 million cap held by insiders on a chain whose entire float trades in one venue. Both facts are in the same document. Only one of them made it into the coverage.

No Smart Contracts, and That Is a Decision

Quantus has no smart contracts in any language. Not Solidity, not ink, not WASM contracts. The architecture page at docs.quantus.com is direct about why: "Quantus is money, not a general-purpose compute platform" and "Limiting scope reduces attack surface and allows optimization for the specific use case of quantum-secure value transfer."

That is a real security argument, and anyone who has worked through a smart contract security review will recognise it. Most catastrophic chain losses are contract bugs, not consensus bugs. A chain with no contracts cannot have a reentrancy incident.

The cost is that the chain does one thing. Extensibility runs through FRAME pallets and forkless runtime upgrades, so every new capability is a protocol change signed off by whoever holds the upgrade key. Six runtime upgrades ran on the Planck testnet. Cross-chain access is outsourced to NEAR chain abstraction over a threshold-MPC bridge on forked nearcore, which the docs describe as still in development with testnet integration not yet launched. Today the only documented route off the chain is an exchange.

Wormhole, the ZK Layer That Is Also the Privacy Layer

The "zero-knowledge scalability" line on the homepage is a system called Wormhole: a burn-and-remint shielded pool modelled on Ethereum's EIP-7503.

You burn to an unspendable address derived from Poseidon2 H(H(salt | secret)), prove preimage knowledge off-chain, and the proofs are aggregated recursively — up to 7 transfers per private batch, up to 53 private batches per public batch, dummy-padded and shuffled. A private batch posts roughly 151 KB on chain and a public batch roughly 224 KB, though the whitepaper computes its throughput figure against roughly 266 KB per public batch. The docs and the whitepaper do not agree on the on-chain size. Minting goes to an exit address with a 4 basis point volume fee, half of it burned. Nullifiers stop double-spends. The proof system is qp-plonky2, a fork of Polygon Zero's Plonky2, over the Goldilocks field p = 2^64 − 2^32 + 1, with Poseidon2 as the hash and no trusted setup. The claimed rate is roughly 430 QTPS at roughly 266 KB per 371 transfers, with a stated theoretical ceiling near 2,800 QTPS.

Three qualifications, all of them mine and all of them material.

First, EIP-7503 is Stagnant on Ethereum and its own security section warns: "In case of faulty implementation of this EIP, people may mint infinite amount of ETH, collapsing the price of Ethereum." Quantus inherits that failure mode. A bug in the circuit is not a privacy bug, it is an inflation bug.

Second, the docs call Plonky2 "a STARK-based proof system" and the homepage says "Recursive STARKs". Strictly, Plonky2 is PLONK arithmetisation with FRI commitments. It is plausibly post-quantum because it is hash-and-FRI based, but that security rests on conjectured FRI soundness rather than a proof. On a chain whose scaling and privacy both route through it, the wording should be tighter.

Third, the docs state that amounts, addresses and proofs are all visible on chain and only the burner-to-receiver link is hidden. That is an anonymity-set property whose strength depends on batch occupancy. Dummy padding helps; the effective set at low usage is unknown and I found no published measurement. Whether Wormhole is fully live on mainnet is also ambiguous from outside — mining rewards accrue to a wormhole address, which implies the pallet is active, but the docs cite performance from the whitepaper rather than from mainnet.

Audits: The Docs and the Whitepaper Disagree, and the Docs Are Stale

Two official pages give two different answers, which matters because the one a developer reaches first is the wrong one.

The audits page↗ lists four engagements. Two are marked Completed with the report shown as "Link pending", and two are In progress. Read that page alone and you conclude no report exists.

The whitepaper↗ lists seven, with report links attached:

An Immunefi audit competition↗ ran to 2026-08-25 10:00 UTC, with a pool of $20,000 if any valid bug was found and $3,000 if none was. The status is "Under Evaluation" with no published result.

So the coverage is broader than the docs page suggests, and the qp-zk-circuits audit the docs still show as In progress has a March 2026 Eiger report in the whitepaper, plus a Lean formal verification of the same circuits in June. That is the mint-authorising component, the one EIP-7503 itself flags as the infinite-mint risk, and it has been reviewed twice.

What I can say precisely, checked on 15 September 2026: reports exist and are linked from the whitepaper, I have not read them, and no finding or severity from any of them is quoted anywhere in this article. The open items are the Hashcloak threshold-signature engagement and the Immunefi result. And the reference page a developer is most likely to check is out of date with the project's own whitepaper, which is a documentation problem rather than a security one — but it is the kind that makes an outsider assume the worst.

What I Could Not Verify

Being explicit about the holes is part of the job.

• Current mainnet block height. The only JSON-RPC endpoint I could reach returns system_chain = "Planck", the deprecated testnet, and the public indexer at sub2.quantus.com also indexes Planck.
• All usage telemetry is Planck testnet, not mainnet. At testnet block 1,101,359 on 14 September 2026 the indexer reported 239,398 immediate transfers, 3,204 accounts, 365 miners and 6 runtime upgrades — and 0 scheduled transfers, 0 executed reversible transfers and 0 high-security account settings. Reversible transfers and guardian recovery are the most distinctive user-facing things Quantus built, and on testnet nobody used them.
• The homepage figure of "824 logical qubits required" traces to no paper I could find. The Google Quantum AI, Ethereum Foundation and Stanford estimate (arXiv 2603.28846↗, submitted 30 March 2026) gives fewer than 1,200 logical qubits with fewer than 90 million Toffoli gates, or fewer than 1,450 with fewer than 70 million. IonQ's September 2026 trapped-ion blueprint gives 1,457 logical qubits. 824 appears in neither. I unpack those estimates in the measured quantum threat to Bitcoin and Ethereum.
• Market depth is thin. On 15 September 2026 CoinGecko listed QTC at $20.39, down 5.1% on the day, on 24-hour volume of $29,369 at a single venue (SafeTrade, QUANTUS/USDT). All-time high $51.87 on 11 September, all-time low $10.20 on 12 September — roughly 61% off the high in four days. With no hashrate figure I could not price a rented-hashrate reorg against that market, and with a 100-block reorg bound and no finality gadget, someone should.
• No independent technical review exists that I could read. Every launch article I found traces to one press release.

Key Takeaways

• The docs are wrong about the signature scheme. Cargo.toml compiles both ml-dsa-65 and ml-dsa-87, and the HD wallet crate is ml-dsa-65 only, so wallet keys are NIST Category 3 while the PQC page documents only ML-DSA-87 and rates the chain NIST Level 5.
• 7,219 bytes is 4,627 of signature plus 2,592 of public key. ML-DSA has no key recovery, so the key ships in every extrinsic — the type is named Dilithium87SignatureWithPublic.
• 170 QTPS does not reconcile with the chain's own constants. 3,932,160 bytes of normal block space over 12 seconds gives 45.4 QTPS at ML-DSA-87 and 62.3 at ML-DSA-65, matching the whitepaper's 43 and 58, not the 170 in the 19 August weekly update.
• Poseidon2 is not there for quantum resistance. The QPoW page says it was chosen "for ZK circuit efficiency, not for quantum resistance" and that "SHA-256 is already quantum-resistant enough". The page publishes no constraint counts.
• Emission decays at 5.12% of the remaining gap per year. Reward = (21,000,000 − supply) / 50,000,000 per block, giving an effective 13.19-year halving and roughly 784,900 QTC in year one.
• 27% of supply, 5,670,000 QTC, was minted at genesis to insiders with a one-year lock and 36-month linear vest on all but 210,000 QTC, which the whitepaper says is liquid at genesis. The no-pre-mine framing describes the mining function, not the cap table.
• Check the whitepaper, not the audits page. The docs page shows four engagements with reports pending; the whitepaper lists seven with links, including two reviews of the mint-authorising circuit. The reference page most developers reach first is out of date.

About the Author

I'm Uvin Vindula — a Web3 and AI engineer based between Sri Lanka and the UK. I read Quantus from the runtime source rather than the announcement because a chain that changes its signature scheme changes its byte budget, its throughput ceiling and its wallet compatibility all at once, and only the code tells you by how much. You can see my work at iamuvin.com or reach out about a project at hello@iamuvin.com↗.

If you are planning a post-quantum migration for a chain or a wallet and want the numbers checked before the announcement goes out, let's talk about your project. I also cover the practical migration sequence in the post-quantum migration guide for blockchain teams.