What it is. Quranium is a blockchain built from day one to keep working after powerful quantum computers exist, rather than an older chain trying to patch that protection in later.
What we found. The protection is real at the design level, but the only working network we could independently inspect is a practice one, while the company talks about a live network we cannot confirm is running.
Why it matters. A holder's coins stay hard to steal even against a future quantum attacker, yet the project has no big-name custodian or bridge partner, keeps its core software private and unchecked by outsiders, and presents practice-network and partnership numbers in ways that read bigger than what is actually live, so treat the maturity and the headline figures with caution.
Quranium signs native transactions with SLH-DSA (the standardized SPHINCS+, FIPS 205, stateless hash-based), which Shor cannot break, but the only PQC-signing network reconstructible on-chain is a public testnet (the May 2025 'Convergence Layer'), counted on the foundation's own homepage as ~1.8M+ testnet transactions; a separate Feb 2025 mainnet-launch claim and a foundation-docs 'Core Layer' PoS mainnet (SLH-DSA at consensus, stated to replace BLS) are referenced with a genesis-block hash on a client-rendered explorer whose contents are not reconstructible from static HTML, so we withhold mainnet-traffic credit. The single fact a cryptographer needs: signing is pure post-quantum with no classical+PQ hybrid, so Gate 1a-Sig fails and the binding cap is the thin vendor ecosystem (no named custodian, no documented live PQ-safe bridge), which holds Migration Stage at 3; the FIPS 205 parameter set is undisclosed (12 sets exist), so the deployed NIST security category and signature footprint cannot be pinned, ML-KEM (FIPS 203) appears only for QSafe wallet-backup encryption rather than validator transport, and the L1 node code is closed with no published implementation audit.
Summary
Quranium scores QRI 37, Band 4 Architected, Migration Stage 3 (capped). Native transactions sign with SLH-DSA (standardized SPHINCS+, FIPS 205, stateless hash-based), which Shor cannot break: revealed public keys, dormant balances, and past signatures are forge-resistant by construction, independent of network maturity. The only PQC-signing network we verify on-chain is a public testnet (May 2025 'Convergence Layer'); the foundation's homepage counts ~1.8M+ as testnet transactions. A separate Feb 2025 mainnet claim and a foundation-docs 'Core Layer' PoS mainnet (SLH-DSA at consensus, stated to replace BLS) are referenced with a genesis block on a client-rendered explorer, but no public source supports a reconstructible mainnet PQC-traffic share, so we withhold mainnet-traffic credit and cannot confirm validator PQC-key adoption; the consensus label is itself in primary-source conflict (PoW vs PoS vs Proof-of-Respect BlockDAG). Three facts hold the score down. Signing is pure post-quantum with no classical+PQ hybrid, so Gate 1a-Sig fails (Stage cap 4). The vendor ecosystem is thin: the QSafe wallet is PQ-native (SLH-DSA signing, ML-KEM backups), but no custodian is named and no live PQ-safe bridge is documented, the binding cap at Stage 3. The SLH-DSA parameter set is undisclosed (FIPS 205 defines 12), so the deployed NIST security category and signature size are unconfirmed; transport encryption is undocumented, node code closed, no implementation audit published.
What the gates say
- Gate 1a, Hybrid signature: FAIL , Quranium is pure post-quantum by design: SLH-DSA (FIPS 205) is the sole native signing primitive, with no classical scheme to compose with. The chain markets 'no dependency on legacy cryptography' as a feature. There is 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 , on scope (ML-KEM (FIPS 203) is documented only for QSafe wallet recovery-phrase/private-key backup encryption, not for validator-to-validator gossip, RPC-to-client TLS, or any core-stack key exchange. Transport encryption primitives at the validator/RPC layer are not publicly specified. Where ML-KEM is used it is pure-PQ, not a documented classical+PQ hybrid KEM combiner. Either reading fails Gate 1a-KEM: no hybrid KEM combiner deployed in the core stack, and the one named PQ KEM use is wallet-backup scope, not transport.
- 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, official press releases, GitHub org, NIST FIPS publications, wallet docs, independent research and exchange-listing pages - so no dimension is unscorable. Material limitations: (a) the SLH-DSA parameter set, the ML-KEM parameter set, the transport-encryption stack, the validator-set composition, and the L1 node source code are NOT public, and no independent cryptographic audit is published; (b) the mainnet-vs-testnet status is itself in conflict across primary sources (a Feb 2025 foundation mainnet-launch claim vs. a foundation testnet launch in May 2025 vs. an independent 'pre-mainnet' characterization). Several Dim 5 / Dim 6 / Dim 7 sub-scores therefore rest on self-reported figures a third party cannot fully reconstruct. This thinness and the timeline conflict are reflected in conservative sub-scores and the +-7 chain CI rather than voiding sub-scores.
- Gate 3, Primitive naming: PASS , every primitive named exactly: SLH-DSA / SPHINCS+ per FIPS 205, ML-KEM per FIPS 203, EVM/Solidity execution; classical ECDSA secp256k1 / Ed25519 named only as the pass-through schemes QSafe uses for non-Quranium external chains. Notes: (a) the SLH-DSA and ML-KEM parameter sets are named generically because no public primary source discloses the specific FIPS 205 / FIPS 203 set - a documented evidence gap, not a naming failure; (b) the foundation's Feb 2025 mainnet press release uses the legacy name 'SPHINCS+' while later materials use the standardized name 'SLH-DSA' - 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: SLH-DSA addresses are hash-based and not forgeable by a CRQC. There is therefore no dormant-quantum-vulnerable-coin problem of the Bitcoin/Ethereum kind on the native chain. 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 'Quranium/private' Monero-fork repository (CryptoNote/RingCT, Ed25519, classical) under the project GitHub org (updated Dec 10 2025), which is publicly visible but unexplained by any primary source; 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% 62 / 100
The native signing primitive is named precisely (SLH-DSA per FIPS 205) and corroborated across the foundation site, official wallet docs, foundation press releases, independent research, and the FIPS 205 publication. Two deductions: the exact FIPS 205 parameter set (12 options: SHA2/SHAKE x 128/192/256 x small/fast) is not in any public primary source, and the internal hash instantiation and block-hash function are undocumented. A security-critical inventory should name the parameter set; it does not. (The Feb 2025 mainnet press release uses 'SPHINCS+'; later materials use 'SLH-DSA' - same scheme family.)
SLH-DSA (SPHINCS+ standardization, FIPS 205, published 2024-08-13, stateless hash-based) - native QRN transaction-signing primitive; deployed on the public testnet (the May 2025 'Convergence Layer') and claimed on a Feb 2025 mainnet launch and a foundation-docs 'Core Layer' PoS mainnet (the docs state SLH-DSA replaces BLS at the consensus layer); FIPS 205 parameter set NOT publicly disclosed (12 sets exist) · ML-KEM (Module-Lattice KEM, FIPS 203, finalized 2024-08) - QSafe Wallet recovery-phrase / private-key backup encryption only; parameter set (512/768/1024) NOT publicly disclosed · EVM / Solidity execution layer (Hardhat tooling per public smart-contracts-example and deploy-script-hardhat repos) · ECDSA secp256k1 / Ed25519 - pass-through only, used by QSafe for non-Quranium external chains (BTC/ETH/Solana), NOT on the Quranium-native account path · Ed25519 + RingCT (CryptoNote) - present only in an unexplained 'private' Monero-fork repo under the project GitHub org (updated Dec 10 2025); 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. Deduction reflects (a) the lattice-confidence caveat on ML-KEM (though it is only wallet-backup scope) and (b) the inability to confirm Grover-resistance margins without the SLH-DSA parameter set.
SLH-DSA (FIPS 205, native signing)→ PQ-safe hash (stateless; security rests on the underlying hash function's preimage/2nd-preimage resistance; Grover-weakened symmetric margin depends on the undisclosed parameter set)ML-KEM (FIPS 203, wallet-backup only)→ PQ-safe lattice KEM (lattice-confidence discount per Change 2 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-DL-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/signing path, so it does not count toward deployed signing-layer diversity. Note: the lattice-monoculture Diversity Cap targets LATTICE-monoculture specifically; Quranium's deployed signing surface is HASH-based, which 1c treats as less fragile than lattice-monoculture (which is hard-capped at 5). The literal cap does not fire; the single-family single-point-of-failure concern is noted.
SLH-DSA is NIST-finalized (FIPS 205, 2024-08-13). Its NIST security category (1, 3, or 5) depends entirely on the parameter set (128 -> cat 1, 192 -> cat 3, 256 -> cat 5), which is undisclosed, so the deployed category cannot be confirmed. ML-KEM (FIPS 203) similarly maps to cat 1/3/5 by parameter (512/768/1024), also undisclosed. Credit is given for using NIST-finalized standards (not merely 'selected'); the deduction reflects the inability to pin the deployed security category for either primitive.
SLH-DSA and ML-KEM are NIST-finalized standards (cryptanalytic Tier 3 per the 1e rubric: NIST PQC standardized). Deductions: the L1 node implementation is NOT open-source (only example Solidity contracts and a Hardhat deploy script are public), no independent cryptographic audit of Quranium's SLH-DSA implementation is published, 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 the absence of open code or an audit on a security-critical L1 is a material limitation.
2 Quantum Recovery Exposure weight 10% 50 / 100
Forge. Quranium native addresses sign with SLH-DSA (hash-based). 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 ECDSA/Ed25519 chains. The forge-resistance is a property of the primitive and holds regardless of mainnet/testnet maturity. Deductions: the specific parameter set is undisclosed, so the precise long-horizon margin cannot be confirmed; 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 scored because the verifiable signing network is substantially a testnet.
Forge. Dormant/cold QRN balances sit on SLH-DSA (hash-based) addresses, which are Shor-resistant by construction. There is no dormant-P2PK-style quantum-exposure problem of the Bitcoin kind, and no 'N million coins at quantum-vulnerable addresses' figure exists because native addresses are quantum-safe by design. Deductions for the unconfirmed parameter set, the unexplained classical Monero-fork repo (not scored as live, but a latent inconsistency if ever connected), and the unverified production-mainnet status (cold-balance value is mostly testnet).
Forge. Historical Quranium transaction signatures are SLH-DSA (hash-based) and remain unforgeable post-Shor; signed messages rest on hash-based security. Deductions: long-horizon validity depends on the undisclosed SLH-DSA parameter set's symmetric-security margin under Grover and on the undocumented internal hash function; and the bulk of the historical signatures are testnet transactions on the foundation's own accounting.
Decrypt (HNDL). Validator-to-validator and RPC-to-client transport encryption primitives are NOT publicly specified (no documented TLS version, cipher suite, or hybrid PQ KEM at the transport layer). ML-KEM is used for QSafe wallet backups, not transport. Absent a documented hybrid PQ KEM in the core stack, harvested transport ciphertexts would be decryptable once Shor breaks the classical key exchange. Scored low (consistent with classical-transport chains) because no transport PQ protection is documented.
3 Metadata, Anonymity & Confidentiality weight 13% 33 / 100
Anonymity. Quranium is an EVM-compatible, transparent ledger: sender, receiver, and amount are visible on the public QRN Scan explorer. Pseudonymous 0x addresses, comparable to Ethereum transparency. No native shielding, confidential transactions, or stealth addresses are documented on the main chain. (The unexplained Monero-fork 'private' repo is not a deployed feature of this chain.)
Anonymity. RPC/explorer infrastructure (QRN Scan; docs.qrnscan.com returned 403 at research time) and node operation appear foundation-operated; 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 Infura/Alchemy oligopoly (it is independent), but with no published node/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/EC 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 for an EC-based shielded chain. The de-anonymization that remains is the ordinary transparency of a public EVM 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 cMix/mixnet infrastructure, 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 chain is EVM-compatible, so contract-level verifier logic is in principle available, but no spec or governance process for primitive changes is published. Partial credit only.
Quranium is EVM-compatible, so ERC-4337 / EIP-7702 account-abstraction patterns are in principle available, and QSafe is a self-custody wallet with SLH-DSA signing + ML-KEM-backed backup/recovery (a documented key-backup mechanism). Deduction: no DEPLOYED PQ client-layer migration path with active mainnet tx volume distinct from the native signing is documented, AA support is inherited EVM 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 describes a sequence (Public Node Sale Dec 2024; mainnet-launch claim Feb 2025; 'Convergence Layer' testnet May 2025; a foundation-docs 'Core Layer' PoS mainnet with the L2 'Crust Layer' still in development), but no single coordinated mainnet consensus upgrade is reconstructible from public primary sources, the consensus label is itself in conflict (PoW vs PoS vs PoR/BlockDAG), and there is no public improvement-proposal registry. A single young, partly-testnet chain with no reconstructible coordinated mainnet upgrade is a thin positive.
Quranium is explicitly PURE post-quantum and markets 'no dependency on 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. Tension noted (as with other PQ-native chains).
Quranium deploys SLH-DSA, a STATELESS hash-based scheme, 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 explicitly cite the stateless property (vs stateful XMSS/LMS) as the reason for choosing SLH-DSA. The Stage-5 stateful-hash 90-day-operational-record prerequisite does NOT apply.
N/A. On every consensus reading in the sources (PoS Core Layer per the foundation docs, the PoW characterization in independent coverage, or the PoR/BlockDAG Crust L2), the validator/transaction signing primitive is SLH-DSA (a PQ-safe hash-based scheme). The foundation docs explicitly state SLH-DSA replaces BLS at the consensus layer, so there is NO Shor-vulnerable BLS aggregation or pairing/threshold scheme to assess - 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% 30 / 100
Mainnet PQC-traffic credit is largely WITHHELD. The 5a rubric measures '% of MAINNET signing traffic on PQC primitives'. The independently verifiable, transaction-bearing PQC-signing network is a public TESTNET (the May 2025 'Convergence Layer'); the foundation's own homepage reports the activity as '~1.8M+ Testnet Transactions', and an independent research review describes the project as pre-mainnet. A foundation press release (Feb 13 2025) claims a mainnet launch and the foundation docs describe a 'Core Layer' PoS mainnet, with a genesis block hash referenced on the public explorer (a client-rendered SPA whose contents are not reconstructible from static HTML), but no public primary source establishes a reconstructible mainnet PQC-traffic share. Credit (7/25) reflects: a verifiable PQC-signing primitive operating at scale on a public testnet, plus a foundation mainnet claim - but NOT a reconstructible '~100% mainnet PQC traffic' share. The prior 23/25 (based on '~100% native mainnet traffic') is corrected; the assertion that the mainnet-traffic cap does not fire on those grounds is withdrawn.
SLH-DSA verification is operating on a public network (testnet, plus a claimed mainnet) - the on-chain signing primitive is externally observable via the explorer, which is more than a design document. However the L1 node implementation is NOT open-source (the public GitHub org contains only Solidity example contracts, a Hardhat deploy script, a qsafe-download repo, and unexplained Monero/Trezor forks), so the merged PQC consensus-client code cannot be inspected, measured, or independently verified, and the network it runs on is substantially a testnet. Scored low.
The foundation docs describe a Proof-of-Stake 'Core Layer' (validators signing under SLH-DSA, which the docs say replaces BLS), and the May 2025 'Convergence Layer' testnet provides the verifiable signing activity; the consensus label is otherwise in source conflict (PoW vs PoS vs PoR/BlockDAG). Validator-PQC-key-adoption on a verified production mainnet cannot be reconstructed: the validator set size, distribution, and the share actively using PQC keys are NOT publicly disclosed on any path. Minimal credit for PQ-by-construction signing; the low value reflects the undisclosed validator data and the testnet basis of the verifiable deployment.
NOT voided. Quranium publishes named, dated milestones: Public Node Sale (Dec 2 2024), claimed mainnet launch (Feb 13 2025), Convergence Layer TESTNET + QSafe Wallet (May 2025), and subsequent ecosystem launches. Deductions: milestones are product/ecosystem launch dates rather than protocol-enforced flag-days or consensus-bound sunset dates; there is no published improvement-proposal registry; and the network the milestones back is substantially a testnet, with the mainnet milestone itself in source-conflict (see source_disagreement).
Announced-vs-shipped ratio ~3.0 (-> the 10-point Dim 5 deduction applies and the >2.0 washing threshold is crossed). Shipped and verifiable: SLH-DSA signing on a public testnet and QSafe ML-KEM-backed backups. Materially over-framed: the network has been publicly described as a 'live mainnet' while the verifiable PQC network is a testnet and an independent source calls the project pre-mainnet; the headline ~1.8M+ figure is a TESTNET figure; '70+ networks' (external chains use their own ECDSA/Ed25519; QSafe is a multi-chain wallet, not a multi-chain PQC upgrade); '110+ MOUs' / large partner figures (business-development claims); and the Trezor-firmware fork (public, last updated Jul 2024, no shipping confirmation). The core signing claim is real and on-chain-verifiable; the deployment-maturity and ecosystem framing outrun shipped reality. Below the 5.0 narrative-only threshold.
Deployment cost weakness. SLH-DSA signatures are large: per the published FIPS 205 sizes, SLH-DSA-SHA2-128s = 7,856 B (~123x the 64-byte Ed25519 baseline), and other parameter sets range up to 49,856 B (SLH-DSA-256f) - placing Quranium at or beyond the >38x band. Because the exact FIPS 205 parameter set is undisclosed, the precise multiplier cannot be pinned, but every SLH-DSA parameter set sits at the high end of the multiplier scale. No SNARK aggregation, data-availability offloading, or batching to reduce the effective per-block multiplier is documented. Scored 3/20: a non-zero floor only because the heavy footprint is the honest cost of strong hash-based PQ security on a transparent EVM ledger; the raw bytes-per-signature is worst-case.
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 and encrypts recovery-phrase backups with ML-KEM (confirmed on the wallet site). Scored above the set norm because the primary wallet IS quantum-safe rather than carrying a 'PQC roadmap'. Deductions: the wallet's cross-chain support for external networks (BTC/ETH/Solana) uses those chains' classical ECDSA/Ed25519 (not a PQC upgrade), there is no broad third-party (MetaMask/Phantom-class) ecosystem, and the SLH-DSA/ML-KEM parameter sets used by the wallet are undisclosed.
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, presumably, centralized exchanges. Worst tile alongside custodian/infra - a primary driver of the Supply-Chain cap.
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 ever have efficient MPC (contrast ML-DSA, which is 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.
RPC/explorer infrastructure (QRN Scan) appears foundation-operated; no top-3 third-party RPC provider publishes a Quranium-specific PQC roadmap. A 'trezor-hardware' firmware fork exists under the project GitHub org (last updated Jul 10 2024) but no press release or documentation confirms a shipping Quranium-Trezor hardware-wallet integration, so HSM/hardware support is unconfirmed. No TEE attestation chain is documented. With bridge, custodian, and infra all low, the dimension is capped 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% 29 / 100
The 'Convergence Layer' testnet and the foundation-docs Proof-of-Stake 'Core Layer' both imply a validator set, but the validator count, stake distribution, Nakamoto coefficient, and client diversity are NOT publicly disclosed on either the testnet or the claimed mainnet. 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/network launches exists (Node Sale Dec 2024; mainnet claim Feb 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/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 press releases; 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 IP organization, and named industry advisors; the project reports a Swiss-association structure. Strong, transparent leadership identification. Deductions: a named COO is not listed on the current team page (contra a prior reading), there is 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.
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 because the native signing layer is already hash-based and Shor-resistant.
X + Y vs Z, when does the math turn against you?
v3.1 demotes the X+Y vs Z timing test to a secondary signal, the headline output is Migration Stage. The timing test still answers the question: can this chain finish migrating before the threat lands?
Verdict
X + Y does NOT exceed Z for Quranium's signature layer as a cryptographic property - the deployed signing primitive is SLH-DSA (hash-based), which structurally mitigates the forge threat that drives X+Y>Z on classical L1s. Residual risk concentrates on (a) the undisclosed SLH-DSA parameter set, (b) classical/undocumented transport encryption (HNDL / Decrypt), (c) the absence of any hybrid composition, and (d) the unverified production-mainnet status, since a value-protection claim ultimately rests on a live, auditable production ledger rather than a testnet.
Z-compliance
The deployed signature primitive is a NIST-finalized standard (SLH-DSA, FIPS 205, 2024-08-13), so Quranium's signing layer is not exposed to the NIST IR 8547 (IPD) 2030 deprecation / 2035 disallowance of quantum-vulnerable public keys the way ECDSA/Ed25519 chains are. Open compliance items are the undocumented transport/KEM layer (HNDL), the absence of a hybrid-transition posture that CNSA 2.0 contemplates for the migration period, and the unverified production-mainnet status (a compliance claim rests on a live, auditable production network, not a testnet).
Source-disagreement disclosure
v3.1 requires every chain card to publish material divergences among authoritative sources, plus the delta-QRI under alternative weighting.
Primary sources conflict on whether Quranium has a live production mainnet. (a) A foundation press release dated 2025-02-13 ('Quranium Officially Launches Its Mainnet') states the mainnet is live and names the SPHINCS+ scheme as the core primitive; it does NOT specify a consensus mechanism. A genesis block hash is referenced on the public explorer (qrnscan.com), but the explorer is a client-rendered single-page app and the block contents are not reconstructible from its static HTML. (b) The foundation's CEO post and a foundation press release of 2025-05-28 launch the 'Convergence Layer' and explicitly call it a TESTNET ('has today launched its testnet'); the foundation homepage reports '~1.8M+ Testnet Transactions', and an independent outlet (Crowdfund Insider, 2025-06-01) repeats 'has launched its testnet'. (c) An independent research review characterizes Quranium as a 'pre-mainnet project' with 'a live testnet'. (d) A foundation partner Medium post asserts a 'quantum-secure PoW blockchain... in December 2024' and a 'PoS Convergence Layer... in May 2025', whereas the dated event of 2024-12-02 is a Public Node Sale (which itself describes nodes operating in 'Quranium's secure Proof-of-Stake chain'), not a mainnet genesis. This evaluation does NOT grant mainnet PQC-traffic credit, because a reconstructible mainnet signing-traffic share cannot be established from public primary sources. Deployment credit (Dim 5) is assigned to the verifiable public testnet and to the existence of a foundation mainnet claim plus a foundation-docs 'Core Layer' mainnet description, both at conservative levels. The earlier reading - that the May 2025 Convergence Layer is the 'live mainnet' signing ~100% of native traffic - is REFUTED by the foundation's own testnet framing.
The foundation homepage reports the figure as '1.8M+ Testnet Transactions' (explicitly testnet). No public primary source supports a '6M+ mainnet transactions' figure. The transaction count is therefore recorded as a testnet figure, and the difference is treated as a PQC-washing/maturity-framing concern rather than as evidence of mainnet traffic.
No public primary source specifies which FIPS 205 parameter set Quranium uses (SHA2 vs SHAKE instantiation; 128/192/256 security category; small 's' vs fast 'f' variant). FIPS 205 defines 12 parameter sets (3 security levels x SHA2/SHAKE x s/f). All public claims say 'SLH-DSA' or 'SPHINCS+' generically. The parameter choice materially affects signature size (SLH-DSA-SHA2-128s = 7,856 B per the standard's published sizes; larger sets up to 49,856 B), verification cost, and NIST security category. This evaluation scores the named-primitive credit but withholds full credit on 1a/1d/5f and widens the CI because the exact parameters cannot be reconstructed from non-foundation public sources.
QSafe Wallet documentation names 'ML-KEM' for recovery-phrase/backup encryption but does not specify ML-KEM-512 / -768 / -1024 (FIPS 203). Separately, ML-KEM is documented only at the wallet-backup layer, not at validator transport or RPC - the transport-encryption stack is undocumented. This is why Gate 1a-KEM fails on scope (a wallet-backup KEM is not a core-stack hybrid combiner) rather than passing.
The consensus label is in genuine primary-source conflict and cannot be pinned. (a) The foundation's Feb 2025 mainnet-launch press release names only the SPHINCS+ signing scheme and does NOT state a consensus mechanism. (b) The foundation docs (docs.quranium.org/consensus-layer) describe a 'Core Layer' mainnet running Proof-of-Stake 'based on concepts from Ethereum's Beacon Chain', with SLH-DSA at the consensus layer 'replacing BLS with SLHDSA', and a separate 'Crust Layer' (Layer 2, in active development) using a 'Proof-of-Respect (PoR)' consensus over a BlockDAG (Directed Acyclic Graph). (c) An independent review (Token Metrics) instead states 'a Proof-of-Work (PoW) testnet currently live'. (d) A foundation partner Medium post says the Dec 2024 launch was a 'PoW blockchain' and the May 2025 Convergence Layer was 'PoS'; the Dec 2 2024 Public Node Sale PR describes nodes operating in 'Quranium's secure Proof-of-Stake chain'. The prior reading that the Feb 2025 mainnet claim is specifically a 'PoW + BlockDAG hybrid' is NOT supported by that press release and is withdrawn; BlockDAG/PoR is documented as the future Crust L2, not the mainnet consensus. Net effect on scoring is unchanged: validator-PQC-key-adoption on a verified production mainnet cannot be reconstructed (5c held low), and the 4f BFT-aggregation concern remains N/A on every reading because the signing primitive is SLH-DSA (the docs explicitly replace BLS aggregation with SLH-DSA), not a Shor-vulnerable pairing/threshold scheme.
A 'private' repository (verbatim Monero fork: CryptoNote/RingCT, Ed25519, C++, updated Dec 10 2025) exists under the project GitHub org but 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.
The L1 node implementation is not in the public GitHub org (only Solidity example contracts, a Hardhat deploy script, a qsafe-download repo, and the unexplained Monero/Trezor forks are public), and no independent cryptographic audit of the SLH-DSA implementation is published. Self-reported figures (transaction counts, ~40,000+ wallets, validator set) cannot be independently reconstructed at the implementation level. This is reflected in conservative Dim 5 sub-scores (5b/5c) rather than a Gate-2 void, because the on-chain signing primitive itself is externally observable via the public explorer.
Delta-QRI under alternative weighting
Under an alternative weighting that down-weights Deployment (Dim 5) and up-weights Supply Chain (Dim 6) - the dimensions where Quranium is respectively strongest-in-primitive and weakest-in-ecosystem (Dim 5 to 12%, Dim 6 to 32%, others renormalized): QRI falls to ~32 (mid Band 4 Architected). Conversely, a weighting that credited the shipped PQC signing more heavily (Dim 5 -> 30%, Dim 6 -> 14%) yields QRI ~41 (low Band 5 Prototyped). Quranium is sensitive to the Deployment-vs-Supply-Chain weight split because it is an outlier on both axes: a genuinely PQ-safe shipped signing primitive on a (largely testnet) network, against a thin, unverified vendor ecosystem. The base case withholds mainnet-traffic credit, which is the single largest driver of the score relative to the prior evaluation.
Announcement-to-shipped ratio
Announced: 6. Shipped: 2. Ratio: 3.
Tag: >2.0 additional-cap threshold crossed. Shipped and verifiable: SLH-DSA signing on a public testnet (and a PQ-native QSafe wallet with ML-KEM-backed backups). Not verifiable as claimed: the network has been publicly described as a 'live mainnet' while the verifiable, transaction-bearing PQC network is a testnet and an independent source calls the project pre-mainnet; the headline transaction figure (~1.8M+) is a TESTNET figure on the foundation's own homepage, not a 6M+ mainnet figure; '70+ networks' (those external chains use their own ECDSA/Ed25519 - QSafe is a multi-chain wallet, not a multi-chain PQC upgrade); '110+ MOUs' / large partner figures (business-development agreements, not live technical PQC integrations); and the Trezor-hardware integration (a public firmware fork last updated Jul 2024, no shipping confirmation). Ratio ~3.0 -> the 10-point Dim 5 deduction applies AND the >2.0 washing-cap consideration is triggered (the headline signing claim is real and on-chain-verifiable, but the deployment-maturity and ecosystem framing materially outrun what is reconstructible). 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.