What it is. Quranium is a young blockchain designed from scratch to resist future quantum computers, rather than an older network adding that protection later.
What we found. Its token has still not launched, about a year past the date the project set for it, and an outside security tracker still lists the project as pre-launch.
Why it matters. Anyone putting money in is trusting the company's own account of its security, because no outside party has been able to verify the protection in use.
Quranium authenticates all user transactions and consensus messages with SLH-DSA (SPHINCS+) 256f per FIPS 205, a stateless hash-based scheme at NIST security category 5 with a 64-byte public key and a 49,856-byte signature, so the native signing layer carries no Shor exposure; the SHA2-versus-SHAKE instantiation stays undisclosed, and the only transaction-bearing network with a public activity figure is a testnet, with no mainnet PQC-signing share reconstructible from any public source. Signing is pure post-quantum with no classical+PQ hybrid composition, so Gate 1a-Sig fails and caps Stage at 4, and the mainnet-traffic cap with 5a at 0% plus the voided 5d bind Migration Stage at 2.
Summary
Quranium scores QRI 35, Band 4 (Architected), Migration Stage 2. The QRN MiCAR token whitepaper (notified 2025-08-29) states that all user transactions and consensus messages authenticate with SLH-DSA (SPHINCS+) using the 256f parameter set, which fixes NIST security category 5, a 64-byte public key and a 49,856-byte signature, the largest of the 12 parameter sets FIPS 205 defines. The SHA2-versus-SHAKE instantiation and the chain’s block-hash function stay undisclosed. Deployment evidence points to a testnet: the foundation’s explorer domain redirects to a testnet subdomain, the homepage headline figure counts testnet transactions, the Layer 1 mainnet launch sits unchecked on the roadmap, and the whitepaper states three times that exact figures cannot be provided prior to mainnet launch. Against that stands a 2025-02-13 industry-outlet announcement of a live mainnet, which no public source reconciles. With no reconstructible mainnet PQC-traffic share we score 5a at 0, void 5d, and derive Stage 2. ML-KEM (FIPS 203) is documented only for QSafe wallet backup, parameter set undisclosed, and no protocol-level KEM or transport cipher suite is specified, which leaves harvest-now-decrypt-later exposure. A CertiK audit closed 2025-08-16; the report is Non Disclosed and the node source is closed.
Forge. Forge-dominant by construction: this chain secures value and operations with signatures, so the principal quantum risk class is forgery of spends and attestations, and there is no harvest-now component for forgery - a public key alone would suffice for an attacker. What distinguishes Quranium within that class is that the deployed signature scheme is hash-based (SLH-DSA), which Shor does not break, so the Forge subtotal is high (51/75, meaning low exposure) rather than low. The Decrypt subtotal (4/25) is where the exposure actually sits: transport and RPC confidentiality is undocumented, so harvest-now-decrypt-later applies to any classical key exchange in the unspecified transport stack.
6 announced → 2 shipped on mainnet under a named primitive. >2.0 additional-cap threshold crossed. Shipped and verifiable (2): SLH-DSA (SPHINCS+) 256f signing documented as the sole signing primitive on a public testnet; the PQ-native QSafe wallet ('Every transaction uses SLH-DSA'; 'ML-KEM encryption keeps your recovery phrase future-proof and secure'). Announced or over-framed, not verifiable as claimed (6): (1) a 'live mainnet' signing under SLH-DSA (2025-02-13 announcement headlined 'Quranium Officially Launches Its Mainnet'; roadmap 'Quantum-secure PoW Mainnet live' item marked completed) while the foundation's own explorer domain redirects to a testnet subdomain, the homepage counts '1.8M+ Testnet Transactions', the roadmap still shows 'Mainnet Launch of Quranium Layer 1' unchecked as of 2026-08-19, the whitepaper states three times that exact figures cannot be provided prior to mainnet launch, and an independent security tracker still lists the project as Pre-Launch with token launch date not available; (2) '70+ networks' / 'Integrated with 70 other major chains including BTC, Ethereum, Solana' on the homepage, while the wallet's own product site lists Bitcoin, Solana, EVM and Quranium, and those external chains sign with their own ECDSA secp256k1 / Ed25519 - QSafe is a multi-chain wallet, not a multi-chain PQC upgrade; (3) a 'Post-quantum cross-chain bridge' (roadmap Q4 2025, unchecked as of 2026-08-19, no named primitive, no spec, no shipped artifact); (4) a 'Post-quantum P2P Communication protocol' (roadmap H1 2026, unchecked, no named primitive or spec); (5) '110+ MOUs' on the homepage against 30 named strategic partners on the ecosystem page with no published total - business-development counts using inconsistent definitions, not live technical PQC integrations; (6) the Trezor-hardware integration (a public fork of a Trezor hardware-design repository, last updated 2024-07-10, with no shipping confirmation in any documentation or announcement). Honest-disclosure credit: the whitepaper names the 256f parameter set and the audit completion date - the primitive claims themselves are specific and real. Ratio 3.0 -> the 10-point Dim 5 deduction applies AND the >2.0 washing cap (QRI <= 65) is triggered. Below the 5.0 narrative-only threshold: the core SLH-DSA signing claim is genuinely shipped on a public network..
What the gates say
- Gate 1a, Hybrid signature: FAIL , Quranium is pure post-quantum by design: SLH-DSA (SPHINCS+) 256f per FIPS 205 is the sole native signing primitive for both user transactions and consensus messages per the foundation's MiCAR whitepaper, whose technical-standards section names 'Post-quantum signatures: SLH-DSA (SPHINCS+) for transaction and consensus key material' as the only protocol-level cryptographic standard and describes the design as avoiding reliance on elliptic-curve assumptions. There is no classical scheme to compose with, and no documented AND-composition (2-of-2) or OR-composition (1-of-2) hybrid signing. This is the canonical pure-PQ replacement that Gate 1a-Sig disqualifies, even though Quranium arrives there via a PQ-native architecture rather than a plug-and-play swap. Consequence: QRI cap 60, Stage cap 4.
- Gate 1a, Hybrid KEM: FAIL , no hybrid KEM combiner is documented anywhere in the core stack. ML-KEM (FIPS 203) is documented with a specified use only at QSafe wallet recovery-phrase / private-key backup encryption; the MiCAR whitepaper contains no occurrence of ML-KEM, Kyber, or any KEM at all, and its technical-standards section names SLH-DSA as the sole protocol-level cryptographic standard. The 2025-05-28 testnet launch announcement does name 'NIST-approved SLHDSA signatures and ML-KEM encryption' at network level and describes a 'Decentralized P2P Stack: Inspired by devp2p/libp2p, enhanced with post-quantum protections', but it names no transport cipher suite, no TLS version, no ML-KEM parameter set and no combiner construction, so no transport KEM can be reconstructed from it. On either reading Gate 1a-KEM fails: where a PQ KEM is documented with a use it is pure-PQ at wallet-backup scope, and where PQ transport protection is asserted it is unspecified.
- Gate 1b, Commit-to-hash: COND , no OR-composition / 1-of-2 hybrid declared; Quranium is single-scheme PQ at the native signing layer
- Gate 2, Evidence reconstruction: COND , ITIONAL PASS (each dimension has >= 3 public artifacts - foundation site and ecosystem page, the MiCAR token whitepaper, the GitHub org, NIST FIPS 203/205 publications, wallet product site, an independent security-tracker page, the auditor's own engineering blog, and dated launch announcements - so no dimension is unscorable. Material limitations: (a) the SHA2-vs-SHAKE instantiation of SLH-DSA-256f, the ML-KEM parameter set, the transport-encryption stack, the block-hash function, the validator-set composition and the L1 node source code are NOT public, and the CertiK audit report is marked Non Disclosed, so implementation-level claims cannot be reconstructed; (b) the mainnet-vs-testnet status is in unresolved conflict, with a 2025-02-13 announcement and a completed roadmap item asserting a live mainnet on one side, and the foundation's own testnet-redirecting explorer, testnet-labelled headline transaction count, unchecked 'Mainnet Launch of Quranium Layer 1' roadmap item, thrice-repeated 'prior to mainnet launch' whitepaper language and an independent Pre-Launch tracker listing on the other; (c) one project press release could not be re-fetched (three timeouts), so no figure resting on it is carried. Several Dim 5 / Dim 6 / Dim 7 sub-scores therefore rest on self-reported figures a third party cannot fully reconstruct. This is reflected in conservative sub-scores and the +-6 chain CI; the only void applied is 5d, per the v3.1 5a = 0 condition.
- Gate 3, Primitive naming: PASS , every primitive named exactly: SLH-DSA (SPHINCS+) 256f per FIPS 205 - NIST security category 5, 64-byte public key, 49,856-byte signature per FIPS 205 Table 2; the SHA2-vs-SHAKE instantiation is undisclosed, so the exact FIPS 205 name narrows to SLH-DSA-SHA2-256f or SLH-DSA-SHAKE-256f rather than 1 of 12; ML-KEM per FIPS 203 (parameter set 512/768/1024 undisclosed, wallet-backup scope); execution in the 'Quranium Virtual Machine' (QVM), a Solidity / JSON-RPC Ethereum-tooling-compatible environment; classical ECDSA secp256k1 / Ed25519 named only as the pass-through schemes QSafe uses for non-Quranium external chains. The 2025-02-13 mainnet announcement uses the legacy name 'SPHINCS+' while later materials and the whitepaper use both names - same scheme family.
Burn-vs-rescue policy on file
Declared option f, Undeclared (and largely not applicable by construction). Quranium has not published a quantum-vulnerable-address policy because, by design, its native account path has no Shor-vulnerable keys to freeze or rescue: native accounts are secured by SLH-DSA, a hash-based scheme that a CRQC does not forge. There is therefore no dormant quantum-vulnerable-coin problem of the kind that arises where dormant balances sit on exposed elliptic-curve public keys. The undeclared status is scored as option (f) for completeness, but the underlying exposure that the burn-vs-rescue policy addresses is structurally absent for the native ledger. The unresolved surface is the 'private' repository under the project GitHub org - a verbatim fork of the Monero codebase (CryptoNote / RingCT, Ed25519, C++, last updated 2025-12-10 and dormant since) - which is publicly visible but unexplained by any primary source, including the MiCAR whitepaper; if it ever ships as a connected product it would introduce classical-curve exposure that no public policy currently addresses.
Seven dimensions
Each dimension scores 0–100 internally; the weighted roll-up produces the QRI.
1 Cryptographic Exposure weight 15% 71 / 100
The native signing primitive is named precisely (SLH-DSA per FIPS 205) and corroborated across the foundation site, official wallet docs and product site, the MiCAR token whitepaper, the auditor's engineering blog, and the FIPS 205 publication itself. The whitepaper discloses the parameter set - 'using the 256f parameter set' - narrowing FIPS 205's 12 options to 2 (SLH-DSA-SHA2-256f or SLH-DSA-SHAKE-256f); both share one row of FIPS 205 Table 2, so NIST security category 5, a 64-byte public key and a 49,856-byte signature are pinned. Remaining deductions: the SHA2-vs-SHAKE hash instantiation and the chain's block-hash function are undocumented, and the ML-KEM parameter set (512/768/1024) is undisclosed. (The 2025-02-13 mainnet announcement uses 'SPHINCS+'; later materials use 'SLH-DSA' - same scheme family.)
SLH-DSA (SPHINCS+ standardization, FIPS 205, published and effective 2024-08-13, stateless hash-based), parameter set 256f per the foundation's MiCAR token whitepaper (SLH-DSA-SHA2-256f or SLH-DSA-SHAKE-256f; NIST security category 5; 64-byte public key; 49,856-byte signature; SHA2-vs-SHAKE instantiation undisclosed) - native QRN transaction-signing AND consensus-message primitive, including validator-registry operations; deployed on the public testnet (the May 2025 'Convergence Layer') and claimed for a mainnet whose launch the foundation's own roadmap still shows unchecked · ML-KEM (Module-Lattice-Based KEM, FIPS 203, published 2024-08-13, Module-LWE) - QSafe Wallet recovery-phrase / private-key backup encryption; parameter set (512/768/1024) NOT publicly disclosed; absent from the whitepaper's protocol-level technical standards, and asserted at network level in a 2025-05-28 testnet announcement without any transport specification · Quranium Virtual Machine (QVM) execution layer - Solidity contracts and JSON-RPC-style endpoints per the whitepaper; Hardhat tooling per the public smart-contracts-example and deploy-script-hardhat repos · ECDSA secp256k1 / Ed25519 - pass-through only, used by QSafe for non-Quranium external chains (the wallet's own site lists Bitcoin, Solana and EVM alongside Quranium), NOT on the Quranium-native account path · Ed25519 + RingCT (CryptoNote) - present only in an unexplained 'private' repo under the project GitHub org, a verbatim fork of the Monero codebase (last updated 2025-12-10, dormant since); not documented as deployed on the live network The entire native signing surface is PQ-safe: SLH-DSA (hash-based) carries no Shor-breakable signature primitive at the transaction or consensus layer, and the whitepaper confirms consensus messages (block proposals, attestations, validator-registry operations) are signed with SLH-DSA, 'replacing elliptic-curve signatures'. The 256f disclosure pins NIST category 5, resolving the prior inability to confirm the security-strength margin. Remaining deduction reflects the lattice-confidence caveat on ML-KEM (wallet-backup scope) and the undisclosed SHA2-vs-SHAKE instantiation.
SLH-DSA (FIPS 205, native signing, 256f)→ PQ-safe hash (stateless; security rests on the underlying hash function's preimage and second-preimage resistance; the 256f parameter set carries NIST security category 5, the highest category FIPS 205 Table 2 assigns)ML-KEM (FIPS 203, wallet-backup scope)→ PQ-safe lattice KEM (Module-LWE; the per-primitive lattice-confidence discount applies in principle, but it sits at the wallet-backup layer, not the signing or consensus path)ECDSA secp256k1 / Ed25519 (external pass-through only)→ Shor-break via discrete log without pairings (NOT on the Quranium-native path; applies only to external chains QSafe routes to)
On the deployed network exactly one PQ family is used at the signing layer: hash-based (SLH-DSA). Per the 1c rubric, '1 hash-only = 10'. ML-KEM (lattice) is present but at the wallet-backup layer, not the consensus or signing path, so it does not count toward deployed signing-layer diversity. The Cryptographic-Diversity Cap targets lattice-monoculture with no hash-based or code-based fallback; Quranium's deployed signing surface is hash-based, which the same rubric scores at 10 rather than the lattice-only hard cap of 5. The literal cap does not fire; the single-family single-point-of-failure concern is noted.
SLH-DSA is NIST-finalized (FIPS 205, published and effective 2024-08-13 - a final FIPS, not a selection). The MiCAR whitepaper's 256f disclosure pins the deployed NIST security category at 5: both remaining candidates (SLH-DSA-SHA2-256f and SLH-DSA-SHAKE-256f) sit on the same FIPS 205 Table 2 row at category 5, resolving the prior finding that the deployed category could not be confirmed. Remaining deductions: ML-KEM (FIPS 203) maps to category 1/3/5 by parameter set (512/768/1024), still undisclosed for the QSafe wallet-backup use, and the exact 1-of-12 FIPS 205 parameter-set name (SHA2 vs SHAKE instantiation) is still not stated.
SLH-DSA and ML-KEM are NIST-finalized standards (cryptanalytic tier 3a per the 1e rubric: finalized FIPS, no discount). A CertiK security audit was completed with a final report delivered 2025-08-16, attested by two independent parties across three artifacts (the auditor's engineering blog and project-tracker page; the foundation's MiCAR whitepaper), superseding the prior 'no independent cryptographic audit' finding; partial deployed-verifier credit applies. The SLH-DSA-specific scope of that work rests on the auditor's blog alone, which states the engagement 'included a review of the project's core SLH-DSA implementation'; the whitepaper describes it more broadly as a codebase audit and the tracker page gives no scope. Remaining deductions: the audit report and findings are marked Non Disclosed and the tracker shows a code-security sub-score of 50%, the L1 node implementation is NOT open-source (only Solidity examples, a Hardhat deploy script, a wallet-download repo, a brand-kit repo and two unexplained forks are public), no machine-checked formal verification or constant-time posture is cited for the specific implementation, and the library provenance (whether liboqs / PQCA-derived or in-house) is undocumented. A hash-based signing scheme is implementation-forgiving relative to lattice timing leaks, but closed code plus a non-disclosed audit on a security-critical L1 remains a material limitation.
2 Quantum Recovery Exposure weight 10% 55 / 100
Forge. Quranium native addresses sign with SLH-DSA (SPHINCS+) 256f (hash-based, NIST category 5). Revealing an SLH-DSA public key on-chain does NOT enable Shor-based key recovery, because hash-based signatures are not broken by Shor. This inverts the active-key forgery risk that dominates elliptic-curve signing layers, and the forge-resistance is a property of the primitive that holds regardless of mainnet or testnet maturity. The 256f disclosure resolves the prior parameter-set deduction (category 5 is the highest category FIPS 205 Table 2 assigns). Remaining deductions: the account model is EVM-style with 0x addresses where wallet-layer key handling is the residual surface, and the value-at-stake is lower than a production reading because the verifiable signing network is a testnet.
Forge. Dormant and cold QRN balances sit on SLH-DSA (hash-based) addresses, which are Shor-resistant by construction. There is no dormant-balance quantum-exposure problem of the kind that arises where an unmoved output has already published an elliptic-curve public key, and no 'N million coins at quantum-vulnerable addresses' figure exists because native addresses are quantum-safe by design. The 256f disclosure (category 5) resolves the prior unconfirmed-parameter-set deduction. Remaining deductions: the unexplained classical Monero-fork repo (dormant, not scored as live, but a latent inconsistency if ever connected) and the unresolved production-mainnet status (cold-balance value is testnet on the reconstructible record).
Forge. Historical Quranium transaction signatures are SLH-DSA (hash-based) and remain unforgeable post-Shor; signed messages rest on hash-based security. The 256f disclosure pins the symmetric-security margin at NIST category 5, resolving the prior margin deduction. Remaining deductions: the SHA2-vs-SHAKE instantiation and the chain's internal hash function are still undocumented, and the bulk of the historical signatures are testnet transactions on the foundation's own accounting.
Decrypt (harvest-now-decrypt-later). No transport-encryption specification is public: no TLS version, no cipher suite, no named KEM parameter set and no combiner construction is documented for validator-to-validator or RPC-to-client sessions. The one PQ KEM with a documented use, ML-KEM, is used for QSafe wallet backups. A 2025-05-28 testnet announcement asserts 'ML-KEM encryption' at network level and a devp2p/libp2p-inspired P2P stack 'enhanced with post-quantum protections', but names nothing reconstructible, and the MiCAR whitepaper contains no occurrence of ML-KEM or any KEM at all, so no transport PQ protection can be scored under evidence-only rules. Absent a documented hybrid PQ KEM in the core stack, harvested transport ciphertexts would be decryptable once Shor breaks the classical key exchange. The foundation roadmap lists a 'Post-quantum P2P Communication protocol' for H1 2026, unchecked as of 2026-08-19 - announced, not shipped, no credit.
3 Metadata, Anonymity & Confidentiality weight 13% 33 / 100
Anonymity. Quranium runs a transparent, EVM-tooling-compatible ledger: sender, receiver and amount are visible in the public QRN Scan explorer, and accounts use pseudonymous 0x addresses in the standard EVM transparency model. No native shielding, confidential transactions or stealth addresses are documented on the main chain, and the whitepaper's technology sections describe no privacy feature. (The unexplained Monero-fork 'private' repo is not a deployed feature of this chain.)
Anonymity. RPC and explorer infrastructure appears foundation-operated: the QRN Scan explorer domain redirects to a testnet subdomain, its page is a single-page-application shell with no data in the served HTML, and its documentation host was not publicly reachable at research time. The validator set size and distribution are not publicly disclosed, and no validator metadata-retention policy is published (zero credit on that component per the 3b rubric). The chain does not depend on the dominant third-party RPC providers (it is independent), but with no published node or RPC concentration data and an undeclared retention policy, only partial credit on the gossip-observability component is defensible.
Anonymity. Quranium is a young independent chain with its own native coin (QRN); no live PQ-safe bridge to external chains is documented, and QSafe's multi-chain support routes to external chains via their own native signing (a wallet feature, not a bridge with shared bookkeeping). The cross-chain correlation surface is therefore small by isolation rather than by deliberate privacy engineering; scored moderately as low-exposure-by-isolation.
Confidentiality. This is a relative strength: Quranium uses no discrete-log or elliptic-curve privacy primitives at the native layer (no ElGamal ring signatures, no EC zk-SNARKs), so Shor does NOT retroactively de-anonymize Quranium history at the cryptographic layer the way it would on an EC-based shielded ledger. The de-anonymization that remains is the ordinary transparency of a public EVM-style ledger (already visible, not Shor-dependent). Not full credit because Quranium offers no positive confidentiality layer to protect in the first place.
Anonymity. No on-chain mixer, no commit-reveal shuffle, no mixnet infrastructure and no batch-ordering is documented for the live chain. The unexplained Monero-fork repo (CryptoNote ring signatures) is not connected to the main chain by any public source and is not credited here.
4 Migration Architecture weight 10% 51 / 100
No formal crypto-agility mechanism (versioned signature types, in-protocol algorithm switch) is publicly documented for changing the SLH-DSA parameter set or adding a second scheme without a hard fork. The MiCAR whitepaper documents a named 'Quranium Improvement Proposal' (QIP) process with a five-step lifecycle, a soft-fork versus hard-fork distinction, and an expedited path with enhanced disclosure and a defined rollback plan for urgent security situations; the foundation roadmap lists a 'QIP Community Governance Portal launch' for H1 2026, still unchecked as of 2026-08-19. This is an announced governance framework, not a crypto-agility mechanism: primitive changes still route through fork governance, no QIP registry or completed QIP is publicly findable, and there is no verifiable production instance of an algorithm switch. The one named QIP instance in the whitepaper is a base-fee and burn model it describes interchangeably as 'QIP-1559-style' and 'EIP-1559-style', and which the same document says 'may be activated by governance' - it is not activated. The chain's execution environment supports Solidity, so contract-level verifier logic is in principle available. Partial credit unchanged.
Quranium's execution environment is Ethereum-tooling-compatible, so ERC-4337 / EIP-7702 account-abstraction patterns are in principle available, and QSafe is a self-custody wallet with SLH-DSA signing plus an ML-KEM-encrypted backup and recovery mechanism. Deduction: no DEPLOYED PQ client-layer migration path with active mainnet transaction volume distinct from the native signing is documented, account-abstraction support is inherited execution-environment capability rather than an exercised PQ-migration flow, and per-user key-rotation primitives are not specifically documented.
Track record is thin and partly unverifiable. The foundation's own roadmap sequences the networks (PoW testnet H1 2024; a 'PoW Mainnet live' item Q1 2025; 'PoS Layer Testnet' Q2 2025; Layer 1 mainnet launch Q3 2025, still unchecked as of 2026-08-19), and the MiCAR whitepaper confirms PoS with SLH-DSA-signed consensus messages as the current design, so the three-way consensus-label conflict largely resolves into a sequence. What that sequence shows, however, is a new PoS network launched as a testnet, not a coordinated consensus upgrade of a live mainnet: no single coordinated mainnet consensus upgrade is reconstructible from public primary sources. The whitepaper documents a named QIP upgrade process, but it is described, not exercised: no QIP registry, numbered proposal or completed QIP was found, and the roadmap's 'QIP Community Governance Portal' (H1 2026) is unchecked. A documented-but-unexercised process does not establish a track record, so 4c scores 6.
Quranium is explicitly PURE post-quantum: the whitepaper describes SLH-DSA as used 'in place of elliptic-curve signatures' and the project markets the absence of legacy cryptography as a feature. It cannot ship a classical+PQ hybrid composition because it has no classical scheme to compose with. Under the v3.1 hybrid-mandatory framing this scores low - the dimension rewards classical+PQ co-signing readiness, which Quranium by design does not pursue. The tension between a PQ-native architecture and a hybrid-mandatory rubric is noted here rather than scored away.
Quranium deploys SLH-DSA, a STATELESS hash-based scheme (FIPS 205 is titled the Stateless Hash-Based Digital Signature Standard), so per the 4e rubric ('chains using only stateless schemes score full 15 by default') this sub-score is full credit. The chain's public materials cite the stateless property, contrasted with stateful XMSS and LMS, as the reason for choosing SLH-DSA. The Stage-5 stateful-hash 90-day-operational-record prerequisite does NOT apply.
N/A. The MiCAR whitepaper confirms consensus is Proof-of-Stake with all consensus messages (block proposals, attestations, validator-registry operations) signed with SLH-DSA, 'replacing elliptic-curve signatures' - so there is NO Shor-vulnerable BLS aggregation or pairing/threshold scheme to assess, on this or any earlier consensus reading in the sources. The 4f concern does not apply. 4f weight (20) redistributes across 4a-4e. Dimension score = (7+10+6+3+15)/80 * 100 = 51.25 -> 51.
5 Deployment Execution weight 22% 14 / 100
Mainnet PQC-traffic credit is WITHHELD IN FULL and the sub-score is 0. The 5a rubric measures '% of MAINNET signing traffic on PQC primitives, measured from chain data'. No mainnet chain data is reconstructible. The independently verifiable, transaction-bearing PQC-signing network is a public TESTNET: the foundation's own 2025-05-28 announcement states the project 'has launched its testnet'; the homepage reports '1.8M+ Testnet Transactions' word-for-word unchanged as of 2026-08-19; the ecosystem page lists a live test-token faucet; and the foundation's own block-explorer domain redirects to a testnet subdomain titled 'Testnet - Quranium (QRN) Blockchain explorer'. A 2025-02-13 announcement and a completed 'PoW Mainnet live' roadmap item assert a live mainnet, but the same roadmap still shows 'Mainnet Launch of Quranium Layer 1' (Q3 2025) and 'TGE & Exchange listings' (H1 2026) unchecked, the whitepaper states three times that exact figures cannot be provided prior to mainnet launch, and an independent security tracker still classifies the project as Pre-Launch with token launch date not available. The reconstructible mainnet PQC-traffic share is therefore 0%. SLH-DSA signing is not verifiably observable at scale on any public network: the explorer serves a single-page-application shell with no block or transaction data in its HTML, and the node implementation is closed, so no third party can verify a signature byte. Testnet PQC activity is recognized where the framework places it - Migration Stage 2 - not as mainnet-traffic points.
The 5b rubric measures bytes or lines of PQC merged into the most-used consensus client, with testnet-only code deducted. None of that is measurable here: the L1 node implementation is NOT open-source (the public GitHub org contains a brand-kit repo, Solidity example contracts, a Hardhat deploy script, a wallet-download repo, an unexplained Monero fork and a Trezor hardware-design fork), and the audit report and findings are Non Disclosed, so the merged PQC consensus-client code cannot be inspected, measured or independently verified. The signing primitive is not externally observable via the explorer: the explorer redirects to a testnet subdomain and serves a single-page-application shell with no chain data in its HTML. What survives is genuine but thin third-party evidence that a real implementation exists and was examined: a completed CertiK audit with a final report delivered 2025-08-16, whose engagement the auditor's own blog says 'included a review of the project's core SLH-DSA implementation', on a network that is a testnet on the reconstructible record.
The MiCAR whitepaper confirms a Proof-of-Stake design in which validators join the active set by 'registering SLH-DSA (SPHINCS+) validator keys', with consensus messages including validator-registry operations signed under SLH-DSA, and the May 2025 'Convergence Layer' testnet provides the operating network. Validator-PQC-key adoption on a verified production mainnet cannot be reconstructed: no production mainnet is independently confirmed, and the validator set size, distribution and the share actively using PQC keys are NOT publicly disclosed on any source, including the whitepaper. Minimal credit for PQ-by-construction validator keys.
VOIDED. The v3.1 condition states that 5d is zero when 5a = 0 (no shipped mainnet PQC traffic), on the rationale that milestones without shipped mainnet code are publishing, not engineering. 5a is 0, so the void applies on the literal rule. Independently, the milestone-delivery track record is negative: the chain's own dated TGE/mainnet target (September 2025, stated in its regulatory filing and as a Q3 2025 roadmap item) has slipped roughly 11 months with no public reschedule, and the roadmap's Q4 2025 'Post-quantum cross-chain bridge' and H1 2026 'TGE & Exchange listings' items are likewise unchecked, so full 5d credit would be unavailable even if the sub-score were not voided. Dated milestones do exist (public node sale December 2024; Convergence Layer TESTNET plus QSafe Wallet May 2025; subsequent ecosystem launches); none are protocol-enforced.
Announced-vs-shipped ratio 3.0 (6 announced / 2 shipped): the 10-point Dim 5 deduction applies and the >2.0 washing threshold is crossed. Shipped and verifiable: SLH-DSA (SPHINCS+) 256f documented as the sole signing primitive on a public testnet, and the QSafe wallet (SLH-DSA signing, ML-KEM-encrypted backups). Materially over-framed: the network has been publicly described as a live mainnet (2025-02-13) and a 'PoW Mainnet live' roadmap item is marked completed, while the foundation's own explorer redirects to a testnet subdomain, its homepage headline figure is '1.8M+ Testnet Transactions', its roadmap still shows the Layer 1 mainnet launch unchecked as of 2026-08-19, its regulatory filing states three times that exact figures cannot be provided prior to mainnet launch, and an independent security tracker still lists Pre-Launch. Also announced but not shipped: a 'Post-quantum cross-chain bridge' (roadmap Q4 2025, unchecked) and a 'Post-quantum P2P Communication protocol' (roadmap H1 2026, unchecked). Also over-framed: '70+ networks' (the wallet's own product site lists Bitcoin, Solana, EVM and Quranium, and external chains sign with their own ECDSA secp256k1 / Ed25519); '110+ MOUs' against 30 named ecosystem partners with no published total; the Trezor hardware-design fork (public, last updated 2024-07-10, no shipping confirmation). Honest-disclosure credit: the whitepaper names the 256f parameter set and the audit completion date - the primitive claims themselves are specific and real. Score 8/15. Below the 5.0 narrative-only threshold.
Deployment cost weakness, confirmed against the standard rather than assumed. The whitepaper's 256f disclosure pins the signature footprint at 49,856 bytes per signature - the value FIPS 205 Table 2 gives for both remaining candidates, SLH-DSA-SHA2-256f and SLH-DSA-SHAKE-256f, and the largest signature size in that table. That is 779x the 64-byte compact Ed25519 baseline the 5f rubric uses, far beyond the rubric's >38x band. No SNARK aggregation, data-availability offloading, batching, or transaction-weight de-penalization to reduce the effective per-block multiplier is documented; the whitepaper acknowledges the problem only as a research focus area ('ongoing scalability research to offset larger post-quantum signature footprints'). Per the rubric (>38x = 0), scored 0/20.
6 Supply Chain Vendor Readiness weight 22% 18 / 100
Quranium's first-party wallet is PQ-native by construction: QSafe (browser extension) signs native QRN transactions with SLH-DSA ('Every transaction uses SLH-DSA') and encrypts recovery-phrase backups with ML-KEM, both stated on the wallet's own product site, which also confirms full self-custody. Scored above a roadmap-only posture because the primary wallet IS quantum-safe rather than carrying a 'PQC roadmap'. Deductions: the wallet's cross-chain support for external networks uses those chains' classical ECDSA secp256k1 / Ed25519 and is not a PQC upgrade (the wallet's own site lists Bitcoin, Solana and EVM alongside Quranium, against a '70+ networks' claim on the foundation homepage); there is no broad third-party wallet ecosystem of the MetaMask or Phantom class; and the ML-KEM parameter set used by the wallet is undisclosed (the SLH-DSA parameter set is now disclosed at protocol level as 256f).
No live PQ-safe bridge to external chains is documented. Quranium is not integrated with LayerZero, Wormhole, Axelar or CCIP as a PQ-safe bridge, and none of those bridge vendors publish a Quranium-specific PQC roadmap. Cross-chain movement is via QSafe's multi-chain wallet (classical signing on the destination chains) or centralized venues. Worst tile alongside custodian and infra - a primary driver of the Supply-Chain cap. The foundation roadmap lists a 'Post-quantum cross-chain bridge' and a 'Quantum-secure BTC & ETH reserve protocol' for Q4 2025, both still unchecked as of 2026-08-19 with no named primitive, spec or shipped artifact - announced, not shipped, no credit.
No institutional custodian (Anchorage, BitGo, Fireblocks) is publicly named for QRN, and none publishes a Quranium-specific PQ custody roadmap. Per the Dim 6 6c rubric, SLH-DSA is flagged as unlikely to have efficient MPC (contrast ML-DSA, which is more MPC-amenable), so a custodian-MPC path for Quranium's pure-SLH-DSA signing is structurally hard and is not documented. Minimal institutional-custody footprint. The MiCAR whitepaper records an INTENT ('Quranium Association intends to seek admission to trading on Kraken'), and the foundation ecosystem page names Bybit among 30 strategic partners with no role specified; neither is a live listing, a custody arrangement, or a PQC-relevant custody or exchange roadmap, so no credit moves.
RPC and explorer infrastructure appears foundation-operated, and the explorer domain currently redirects to a testnet subdomain; no top-3 third-party RPC provider publishes a Quranium-specific PQC roadmap. A 'trezor-hardware' repository exists under the project GitHub org - a fork of a Trezor hardware-design repository, last updated 2024-07-10 - but no announcement or documentation confirms a shipping Quranium-Trezor hardware-wallet integration, so HSM and hardware support is unconfirmed. No TEE attestation chain is documented. With bridge, custodian and infra all low, the dimension is held down by its weakest tiles - this fires the Supply-Chain cap (3 of 4 tiles lack top-3 vendor PQC roadmaps -> Migration Stage <= 3).
7 Governance & Coordination weight 8% 30 / 100
The 'Convergence Layer' testnet and the whitepaper's Proof-of-Stake design both imply an active validator set, but the validator count, stake distribution, Nakamoto coefficient and client diversity are NOT publicly disclosed for either the testnet or the claimed mainnet, and the MiCAR whitepaper - which discloses the association's registration identifiers and management body by name - likewise discloses no validator count, distribution or concentration data. With no public concentration data on a young foundation-launched chain, only minimal credit is defensible; the absence of any validator-distribution disclosure is itself a governance-transparency weakness.
A cadence of product and network launches exists (public node sale December 2024; a mainnet claim February 2025; Convergence Layer testnet May 2025; subsequent ecosystem launches), but no single corroborated coordinated MAINNET consensus upgrade is reconstructible, and no fork has been coordinated under live adversarial or time pressure. Moderate-to-thin cadence for a young chain; the high-stakes coordination test under attack pressure is absent.
Clear named coordination lead: the CEO and co-founder is publicly identified and quoted across announcements; the MiCAR whitepaper documents the Swiss association's management body by name (president/CEO, COO, CTO and a fourth committee member) with an exact legal entity identifier, dossier number and registered address; a Co-CTO and Chief Product Officer are named on the official team page; a publicly listed advisory board includes a recognized cryptographer (the founder of a privacy-network project), a former head of an international intellectual-property organization, and named industry advisors. The current team page lists a named COO, corroborated by the whitepaper's management-body list, so no COO deduction applies. Deduction retained: the CTO's surname differs between the whitepaper and the current team page, unreconciled across two foundation primary sources, and the team page carries a second Co-CTO who is absent from the whitepaper's management body. Remaining deductions: no named PQC working-group lead distinct from corporate leadership, and the coordination structure is a centralized startup rather than an open foundation with a published technical mandate.
Quranium's thesis is proactive PQ defence (PQ-native from genesis), a positive structural signal, but it has NOT executed a cryptographic migration under live adversarial pressure - there has been no attack-driven emergency fork. The proactive posture is credited modestly; a true adversarial-coordination precedent is absent. The MiCAR whitepaper's expedited emergency QIP path is an announced mechanism, not a precedent, and does not move this sub-score.
No canary, honeypot, rate-limit spending rule or cryptographic tripwire is documented in Quranium's consensus or governance materials. Scored 0 per the rubric, with the note that the canary mechanism is less relevant to the forge threat here because the native signing layer is already hash-based and Shor-resistant.
Source-disagreement disclosure
v3.1 requires every chain card to publish material divergences among authoritative sources, plus the delta-QRI under alternative weighting.
For a live mainnet: (a) a 2025-02-13 industry-outlet announcement headlined 'Quranium Officially Launches Its Mainnet' states the project 'has officially launched its mainnet' and names the SPHINCS+ scheme (it names no consensus mechanism); (b) the foundation homepage roadmap marks 'Quantum-secure PoW Mainnet live' (Q1 2025) as completed; (c) the whitepaper's audit field states material findings 'were addressed prior to mainnet launch', a past-tense construction. Against a live mainnet: (d) the foundation's 2025-05-28 'Convergence Layer' announcement states the project 'has launched its testnet'; (e) the foundation homepage reports '1.8M+ Testnet Transactions' as its headline activity figure and the ecosystem page lists a QRN Faucet ('Claim free QRN test tokens') as a live product; (f) the foundation's own block-explorer domain redirects to a testnet subdomain whose page title reads 'Testnet - Quranium (QRN) Blockchain explorer' (that page is a single-page-application shell, so no block or transaction data is reconstructible from its HTML either); (g) the same homepage roadmap lists 'Mainnet Launch of Quranium Layer 1' (Q3 2025), 'Post-quantum cross-chain bridge' (Q4 2025) and 'TGE & Exchange listings' plus 'Mainnet Upgrade: Post-quantum Financial Infrastructure' (H1 2026) as unchecked upcoming items; (h) the MiCAR whitepaper's sustainability-indicator methodology states three separate times that 'Exact figures cannot be provided prior to mainnet launch, as consumption will depend on realised network activity' and that 'Any values disclosed before launch are indicative only'; (i) an independent security tracker classifies the project as Pre-Launch with token launch date not available and market cap not available as of 2026-08-19, roughly 11 months past the whitepaper's own September 2025 TGE/mainnet target. The whitepaper is internally inconsistent on this point: the bullet 'TGE / Mainnet: Targeted September 2025, with QRN genesis allocation and staking live at launch' sits under a heading reading 'Past Milestones (Completed Initiatives)' while being worded as a target and followed by a 'Near-term (post-TGE)' bullet, so the heading and the content point in opposite directions and the bullet is not by itself proof that the mainnet had not launched. The load-bearing pre-launch evidence is instead the thrice-repeated 'prior to mainnet launch' methodology language, the unchecked roadmap item, the testnet-redirecting explorer and the independent Pre-Launch tracker listing. Caveat cutting the other way: the roadmap also shows 'Certik Audit complete' and 'DeQUIP grant program launch' as unchecked although both occurred in 2025, so the roadmap is at least partly stale and is read alongside the other sources rather than alone. No public source establishes a reconstructible SLH-DSA signing-traffic share on any network the foundation calls a mainnet. This evaluation treats the reconstructible mainnet PQC-traffic share as 0%, scores 5a at 0, voids 5d per the v3.1 condition, and derives Migration Stage 2 from the 5a stage table.
The foundation homepage reports its headline activity as '1.8M+ Testnet Transactions' - explicitly testnet - identical word-for-word between 2026-06-02 and 2026-08-19, alongside '40,000+ Wallets', '110+ MOUs' and '200k+ Community'. No public primary source establishes a mainnet transaction count. A '6M+ transactions' figure attributed to an April 2026 project press release is not carried: that release could not be retrieved (three consecutive timeouts on the wire-service URL, no alternate copy available), so neither it nor the claims resting on it, including the '200+ global partners' partner count, are used as sources here.
The QRN MiCAR token whitepaper (foundation primary source, notified 2025-08-29) states that all user transactions and consensus messages are authenticated with SLH-DSA (SPHINCS+) 'using the 256f parameter set'. FIPS 205 Table 2 defines 12 parameter sets ({SHA2, SHAKE} x {128, 192, 256} x {s, f}); '256f' narrows the field to 2 candidates (SLH-DSA-SHA2-256f or SLH-DSA-SHAKE-256f). Both candidates share the same row of FIPS 205 Table 2 - n = 32, h = 68, d = 17, a = 9, k = 35 - and therefore an identical signature size (49,856 bytes, the largest in that table), an identical 64-byte public key and an identical NIST security category (5), so the deployment-relevant facts are pinned even though the exact 1-of-12 name is not. No undisclosed-parameter-set deduction applies in 1a/1b/1d or Dim 2, and 5f is scored on the confirmed footprint rather than on an assumption. Still open: the SHA2-vs-SHAKE hash instantiation and the chain's block-hash function. Note on scope: FIPS 205 itself records that additional SLH-DSA parameter sets may be approved in future NIST Special Publications, so '12' is the count that standard defines, not a permanent ceiling on the scheme.
QSafe Wallet documentation and product site name 'ML-KEM' for recovery-phrase and private-key backup encryption but do not specify ML-KEM-512 / -768 / -1024 (FIPS 203), re-confirmed unchanged as of 2026-08-19. The MiCAR whitepaper contains no occurrence of ML-KEM, Kyber, or any key-encapsulation mechanism, and its technical-standards section names only 'Post-quantum signatures: SLH-DSA (SPHINCS+) for transaction and consensus key material' as a protocol-level cryptographic standard - corroborating from the foundation's own regulatory filing that ML-KEM is wallet-product scope, not core-protocol scope. Cutting the other way, the 2025-05-28 testnet launch announcement does assert network-level ML-KEM ('using NIST-approved SLHDSA signatures and ML-KEM encryption') and a 'Decentralized P2P Stack: Inspired by devp2p/libp2p, enhanced with post-quantum protections'. Because that announcement names no transport cipher suite, TLS version, ML-KEM parameter set or combiner construction, it does not establish a reconstructible transport KEM. Gate 1a-KEM fails on both readings: a wallet-backup KEM is not a core-stack hybrid combiner, and an unspecified 'post-quantum protection' at the P2P layer is not a documented one.
The MiCAR whitepaper states consensus is Proof-of-Stake with stake-weighted randomized leader election, validator staking and non-custodial delegation, that validators join the active set by 'registering SLH-DSA (SPHINCS+) validator keys', and that all consensus messages (block proposals, attestations and validator-registry operations) are signed with SLH-DSA, 'replacing elliptic-curve signatures'. The foundation homepage roadmap (fetched 2026-08-19) sequences the networks: 'Quantum-secure PoW Testnet' (H1 2024), 'Quantum-secure PoW Mainnet live' (Q1 2025), 'Launched PoS Layer Testnet' (Q2 2025), then 'Mainnet Launch of Quranium Layer 1' (Q3 2025, unchecked). Read together, the three-way conflict (PoW vs PoS vs 'Proof-of-Respect' over a BlockDAG) resolves to a sequence rather than a contradiction: PoW for the 2024-to-early-2025 networks, PoS with SLH-DSA-signed consensus for the May 2025 testnet and the pending Layer 1 mainnet, and 'Proof-of-Respect' over a BlockDAG documented only as a future L2 layer. Residual divergence, not verifiable from a retrievable source: a third-party research write-up stated 'a Proof-of-Work (PoW) testnet currently live', and a December 2024 public node-sale announcement described nodes operating in a 'Proof-of-Stake chain' before the roadmap's PoS testnet date; neither source was publicly retrievable during this verification, so both are recorded as unresolved rather than relied upon. Net scoring effect: 4f is N/A on every reading (SLH-DSA, not a Shor-vulnerable pairing or threshold scheme, signs consensus messages), and validator-PQC-key adoption on a verified production mainnet cannot be reconstructed, so 5c is low.
A 'private' repository under the project GitHub org, described there as 'private, untraceable cryptocurrency', written in C++ and last updated 2025-12-10, is a verbatim fork of the Monero codebase (CryptoNote / RingCT, Ed25519). It is never referenced in any official communication. Its relationship to the main chain - sidechain, future feature, or abandoned experiment - is unresolved by any primary source. It is NOT scored as a deployed privacy feature (no public evidence connects it to the live network); it is flagged as a divergence because, if connected, it would introduce classical Ed25519 / RingCT exposure inconsistent with the chain's pure-PQ positioning. As of 2026-08-19 the repository shows no update activity since 2025-12-10 and is not mentioned anywhere in the MiCAR whitepaper.
A CertiK security audit was completed, with a final report delivered 2025-08-16. The attestation rests on two independent parties across three artifacts: the auditor (its engineering blog, published 2026-08-04, and its project-tracker page) and the foundation. The scope claims differ between them and must not be merged: the auditor's blog states that 'CertiK's security work with Quranium included a review of the project's core SLH-DSA implementation'; the foundation's MiCAR whitepaper states only that 'CertiK completed a full security audit of the Quranium codebase on August 16, 2025' and that material findings were addressed; the tracker page records an audit status of Completed with a final-report-delivered date and gives no scope detail at all. So the SLH-DSA-specific scope rests on the auditor's own blog alone. What remains true and load-bearing: the audit report and its specific findings are marked Non Disclosed on the tracker page, which also shows a code-security sub-score of 50%; no findings summary is published by the foundation despite the whitepaper stating one 'will be linked'; the L1 node implementation is still not public (the GitHub org's six public repositories are a brand kit, the unexplained Monero fork, Solidity contract examples, a Hardhat deploy script, a wallet-download repo and a Trezor hardware-design fork, and the only addition in the window is the brand kit); and self-reported figures (transaction counts, 40,000+ wallets, validator set) cannot be independently reconstructed at the implementation level. 1e and 5b credit reflects 'audit conducted, attested, findings undisclosed' rather than 'no audit'.
The MiCAR whitepaper (notified 2025-08-29) names the co-founder and CTO as 'Yaduvendra Singh Yadav' and lists him as a member of the association's management body; the foundation's current team page (fetched 2026-08-19) instead lists 'Yaduvendra Mukherjee' as Co-CTO and co-founder. Same given name and founding role, different surname, across two foundation primary sources roughly a year apart; no public source reconciles the discrepancy. The current team page separately lists a second Co-CTO who does not appear in the whitepaper's management body. The current team page also lists a named COO, corroborated by the whitepaper's management-body list and its issuer-management field. Flagged as a governance data-quality divergence; scored as a small 7c deduction, not a void.
The foundation homepage carries superlative claims we do not adopt and do not score: 'Quranium is the first L1 to adopt SLH-DSA', 'The World's First Quantum-Secure Layer-1 Blockchain Built for Financial Institutions', and a 'World's First Quantum-secure SuperApp' product line. No public source establishes priority for any of these, and LayerQu does not publish precedence claims we cannot prove. They are recorded here so that a reader who encounters them on the project's own site knows they were seen and deliberately excluded from the score.
Delta-QRI under alternative weighting
This evaluation is not sensitive to the Deployment-vs-Supply-Chain weight split, because Dim 5 (14) sits close to Dim 6 (18): down-weighting Deployment to 12% and up-weighting Supply Chain to 32% yields QRI 35, and the inverse tilt (Dim 5 to 30%, Dim 6 to 14%) also yields QRI 35. The largest remaining single driver is the mainnet-traffic question itself: if a production mainnet with a reconstructible SLH-DSA signing-traffic share were independently established, 5a/5b/5c/5d and the stage would re-open upward, subject to the Gate 1a-Sig Stage cap 4 and the supply-chain cap.
Announcement-to-shipped ratio
Announced: 6. Shipped: 2. Ratio: 3.
Tag: >2.0 additional-cap threshold crossed. Shipped and verifiable (2): SLH-DSA (SPHINCS+) 256f signing documented as the sole signing primitive on a public testnet; the PQ-native QSafe wallet ('Every transaction uses SLH-DSA'; 'ML-KEM encryption keeps your recovery phrase future-proof and secure'). Announced or over-framed, not verifiable as claimed (6): (1) a 'live mainnet' signing under SLH-DSA (2025-02-13 announcement headlined 'Quranium Officially Launches Its Mainnet'; roadmap 'Quantum-secure PoW Mainnet live' item marked completed) while the foundation's own explorer domain redirects to a testnet subdomain, the homepage counts '1.8M+ Testnet Transactions', the roadmap still shows 'Mainnet Launch of Quranium Layer 1' unchecked as of 2026-08-19, the whitepaper states three times that exact figures cannot be provided prior to mainnet launch, and an independent security tracker still lists the project as Pre-Launch with token launch date not available; (2) '70+ networks' / 'Integrated with 70 other major chains including BTC, Ethereum, Solana' on the homepage, while the wallet's own product site lists Bitcoin, Solana, EVM and Quranium, and those external chains sign with their own ECDSA secp256k1 / Ed25519 - QSafe is a multi-chain wallet, not a multi-chain PQC upgrade; (3) a 'Post-quantum cross-chain bridge' (roadmap Q4 2025, unchecked as of 2026-08-19, no named primitive, no spec, no shipped artifact); (4) a 'Post-quantum P2P Communication protocol' (roadmap H1 2026, unchecked, no named primitive or spec); (5) '110+ MOUs' on the homepage against 30 named strategic partners on the ecosystem page with no published total - business-development counts using inconsistent definitions, not live technical PQC integrations; (6) the Trezor-hardware integration (a public fork of a Trezor hardware-design repository, last updated 2024-07-10, with no shipping confirmation in any documentation or announcement). Honest-disclosure credit: the whitepaper names the 256f parameter set and the audit completion date - the primitive claims themselves are specific and real. Ratio 3.0 -> the 10-point Dim 5 deduction applies AND the >2.0 washing cap (QRI <= 65) is triggered. Below the 5.0 narrative-only threshold: the core SLH-DSA signing claim is genuinely shipped on a public network.
Peers in the L1 profile
9 chains closest to Quranium by Stage then QRI.