What it is. QRL is a cryptocurrency network designed at its launch eight years ago to withstand future quantum computers, rather than added on as a fix later like most other chains.
What we found. Its live network is already built to survive a quantum attack today, so even coins that have sat untouched in old wallets for years cannot be stolen by a quantum computer the way most chains' coins eventually could.
Why it matters. The protection itself is done, so what limits QRL now is reach and openness: it is hard to buy, store with a third party, or move between platforms because few wallets, exchanges, and custody firms connect to it, and every balance and payment on it is public for anyone to see.
QRL is the only chain in this evaluation whose live mainnet signs nearly all transactions under a post-quantum primitive: XMSS (eXtended Merkle Signature Scheme, stateful, hash-based, SHA-256 internal, W-OTS+ one-time signatures, pre-RFC-8391 with partial parameter overlap, not SP 800-208 compliant), in production since the June 2018 mainnet launch. Because XMSS rests on SHA-256 preimage resistance rather than discrete logs, Shor's algorithm does not forge it, so revealed public keys, dormant balances, and historical signatures stay unforgeable at the signature layer, and the Mainnet-Traffic cap that binds nearly every other L1 does not fire. The binding constraint is the Supply-Chain cap: three of four vendor tiles (bridge, custodian, RPC/HSM/infra) publish no post-quantum roadmap, holding Migration Stage at 3. The single fact a cryptographer needs: QRL is pure post-quantum by design with no classical-plus-PQ hybrid to compose (Gate 1a-Sig FAIL, QRI cap 60, non-binding since raw QRI is 54), and the EVM Proof-of-Stake successor QRL 2.0 / Project Zond, signing under ML-DSA-87 per FIPS 204, is testnet-only (Testnet V2 launched March 2026; mainnet gated on a Trail of Bits full-protocol audit).
Summary
QRL is the only chain whose live mainnet signs nearly all traffic under a post-quantum primitive: XMSS (stateful, hash-based, SHA-256 internal, W-OTS+ one-time signatures, partial RFC 8391 overlap, pre-RFC, not SP 800-208 compliant), in production since the June 2018 launch. Because XMSS rests on SHA-256 preimage resistance, Shor's algorithm does not forge it, so revealed public keys, dormant balances, and historical signatures stay unforgeable, the strongest forge posture in the set. The Mainnet-Traffic cap that binds nearly every other L1 does not fire. The binding constraint is the Supply-Chain cap: bridge, custody, and RPC or HSM vendors publish no post-quantum roadmap, holding Migration Stage at 3. QRL is pure post-quantum by design with no classical-plus-PQ hybrid to compose, so Gate 1a-Sig fails (QRI cap 60, non-binding since raw QRI is 54). Nodes reject any transaction reusing a one-time-signature key index at block validation, the gold standard for stateful schemes. The deployment weakness is signature size: XMSS at h=10 runs about 2.5 KB and ML-DSA-87 4,627 bytes, tens of times ECDSA secp256k1 or Ed25519, with no aggregation. The EVM Proof-of-Stake successor QRL 2.0 / Project Zond signs under ML-DSA-87 per FIPS 204 but is testnet-only (Testnet V2 launched March 2026; mainnet awaits a Trail of Bits full-protocol audit).
What the gates say
- Gate 1a, Hybrid signature: FAIL , QRL is pure post-quantum by design: XMSS on v1 mainnet, ML-DSA-87 per FIPS 204 on Zond testnet. No classical+PQ AND-composition or OR-composition exists or is planned - there is no classical scheme to compose with. This is the canonical pure-PQ replacement that Gate 1a-Sig disqualifies, even though QRL reaches it via a PQ-native architecture rather than a plug-and-play swap. Consequence: QRI cap 60, Stage cap 4.
- Gate 1a, Hybrid KEM: FAIL , QRL v1 P2P transport is classical with no documented hybrid PQ KEM; QRL 2.0/Zond has begun ML-KEM per FIPS 203 integration for the P2P layer per the 2026-05-15 and 2026-05-29 weeklies, but as a pure-PQ KEM with no documented classical+PQ hybrid combiner, and it is not yet deployed on the testnet network. Either reading fails Gate 1a-KEM: currently no PQ KEM deployed, planned KEM is pure-PQ not hybrid.
- Gate 1b, Commit-to-hash: COND , no OR-composition / 1-of-2 hybrid declared; QRL is single-scheme PQ at any layer
- Gate 2, Evidence reconstruction: PASS , every sub-score reconstructible from public artifacts in 48h: theqrl.org blog/press/weekly, docs.theqrl.org, RFC 8391, FIPS 204/205/203, theQRL GitHub repos go-qrllib/go-zond/qrysm/audits, Halborn audit press release, Google Quantum AI whitepaper, qrlhub.com, pkic.org/members
- Gate 3, Primitive naming: PASS , every primitive named exactly: XMSS pre-RFC-8391 with partial RFC 8391 parameter overlap / W-OTS+ OTS / SHA-256 deployed-mainnet internal hash (sha256 2X) with SHAKE_128/SHAKE_256 as reserved descriptor options, RandomX PoW, ML-DSA-87 / Dilithium5 / FIPS 204, SLH-DSA / SPHINCS+-256s / FIPS 205, Falcon-1024 / FN-DSA / FIPS 206 IPD not finalized, ML-KEM / FIPS 203
Burn-vs-rescue policy on file
Declared option b, Rescue via trustless snapshot + signed-claim migration (QRL v1 -> Zond). QRL has a declared, documented migration policy for the v1->v2 transition (not a classical-key-freeze policy, since QRL has no quantum-vulnerable keys to freeze). Per Project Zond materials: at a predetermined block height a final snapshot of the PoW QRL chain is taken; a smart contract on Zond mainnet holds the snapshot balance data; a user provides their new Zond address and signs a message with their existing XMSS address, the contract verifies the XMSS signature and transfers the full balance. Described as automated, trustless, and explicitly non-emergency because the original QRL chain is already quantum-safe (holders migrate at their own pace). There is no dormant-quantum-vulnerable-address problem of the Bitcoin/Ethereum kind because cold XMSS balances are already Shor-resistant; the migration is a chain-architecture change (PoW->PoS, account model), not a quantum-defence freeze.
Seven dimensions
Each dimension scores 0–100 internally; the weighted roll-up produces the QRI.
1 Cryptographic Exposure weight 15% 74 / 100
QRL publishes an unusually complete and precisely-named primitive inventory across both the live v1 chain (XMSS, SHA-256, SHAKE_128, RandomX) and the Zond chain (ML-DSA-87 / FIPS 204, SPHINCS+-256s / FIPS 205, Falcon-1024, ML-KEM / FIPS 203). Small deduction because the Zond signature-scheme story is internally inconsistent across QRL's own docs (SPHINCS+-primary vs ML-DSA-87-primary), and the v1 XMSS is pre-RFC rather than a clean RFC 8391 / SP 800-208 deployment.
XMSS (eXtended Merkle Signature Scheme, hash-based, stateful; W-OTS+ one-time signature within chained XMSS trees; deployed v1 mainnet address format is sha256 2X i.e. SHA-256 internal per the QRL address scheme; partial RFC 8391 parameter overlap, pre-RFC implementation, not SP 800-208 compliant) - QRL v1 mainnet signature scheme since 2018-06-26 · SHA-256 (canonical hash function for the only utilized v1 mainnet address format, sha256 2X) · SHAKE_128 / SHAKE_256 (reserved descriptor-supported hash-function options in go-qrllib, non-RFC for SHAKE_128; not the deployed v1 mainnet default - SHA-256 is) · RandomX (CPU-optimized Proof-of-Work hash, ASIC/GPU-resistant; QRL v1 consensus) · ML-DSA-87 (the FIPS 204 final form of the parameter set formerly named CRYSTALS-Dilithium5, lattice-based, NIST Category 5; public key 2,592 B, secret key 4,896 B, signature 4,627 B vs 4,595 B for the pre-FIPS Dilithium variant per go-qrllib) - QRL 2.0/Zond launch signature scheme, merged across the Zond stack on testnet · SPHINCS+-256s / SLH-DSA (FIPS 205) - implemented in go-qrllib, verifiable but not issuable; deferred post-mainnet per most recent sources (source disagreement noted) · Falcon-1024 (FN-DSA; FIPS 206 IPD, NOT finalized) - P2P layer, in progress, not merged as of 2026-05-29 · ML-KEM (CRYSTALS-Kyber, FIPS 203) - integration begun for Zond P2P layer per 2026-05-15 and 2026-05-29 weeklies Essentially the entire signing surface is PQ-safe on both the live chain (XMSS, hash-based) and the planned chain (ML-DSA-87, lattice). No Shor-breakable signature primitive at consensus or transaction layer on the live mainnet. Deduction reflects Grover-weakening of SHA-256/SHAKE_128 and the lattice-confidence caveat on the planned ML-DSA-87 mainnet and ML-KEM P2P layer.
XMSS (hash-based)→ PQ-safe with Grover-caveat (security rests on SHA-256 preimage/2nd-preimage resistance; Grover-weakened but Category-1+ at deployed tree params)SHA-256→ Grover-weaken (256-bit -> ~128-bit security)SHAKE_128→ Grover-weaken (QRL-specific hash variant)RandomX (PoW)→ Grover-weaken (PoW hashpower halving under Grover; not a signing primitive)ML-DSA-87 (FIPS 204)→ PQ-safe lattice (Category 5; lattice-confidence discount per Change 2)SPHINCS+-256s / SLH-DSA (FIPS 205, deferred)→ PQ-safe hash (stateless)Falcon-1024 / FN-DSA (planned P2P)→ PQ-safe lattice (FIPS 206 IPD, not finalized)ML-KEM (FIPS 203, planned P2P)→ PQ-safe lattice KEM
On the LIVE mainnet, exactly one PQ family is deployed: hash-based (XMSS). Per the 1c rubric, '1 hash-only = 10'. The planned Zond mainnet adds a second family (lattice, ML-DSA-87) and post-mainnet a third (SLH-DSA, a second hash scheme), which would score 15-20 once deployed at consensus / Dim 5 level - but those are testnet-only today, so they do not count toward deployed diversity. Note: the Diversity Cap targets LATTICE-monoculture specifically; QRL's current single-family is HASH-based, which the rubric treats as less fragile than lattice-monoculture (which is hard-capped at 5).
XMSS is a NIST-recognized hash-based family (RFC 8391 / SP 800-208 lineage) though QRL's deployment is pre-RFC. ML-DSA-87 maps to NIST Category 5 (highest). The 2026-05-29 weekly documents an address-format upgrade from 48 to 64 bytes across go-qrllib/qrysm/go-qrl/hyperion/qrvmone to achieve complete NIST Security Level 5. SLH-DSA (deferred) spans Categories 1-5 by parameter set. Deduction: ML-DSA-87 mainnet is not yet live; the current mainnet category rests on XMSS tree params rather than a NIST-categorized PQC signature.
Library provenance: theQRL/go-qrllib (Go crypto library), with ML-DSA-87 and a second NIST-standardized package audited by Halborn (2026-04-03): 13 findings, all Informational, all resolved; core signing/verification/key-generation logic validated as correct, ML-DSA-87 verified against NIST ACVP test vectors in CI. XMSS has a production track record since 2018; QRL reports 100% code coverage achieved across essential cryptographic libraries go-qrllib/qrypto.js/wallet.js (stated in both the 2026-03-06 weekly - which also revealed Trail of Bits as the auditing vendor - and the 2026-04-03 weekly; the frozen crypto-library repo set is named in the 2026-02-13 code-freeze weekly). Deductions: the Halborn audit covered the crypto LIBRARIES, not the full protocol/consensus (Trail of Bits full-protocol audit ongoing, not complete); no machine-checked formal verification (Formosa/EasyCrypt-class) is cited for QRL's specific implementation; constant-time posture is not independently third-party validated in public; ML-DSA-87 and XMSS are both cryptanalytic Tier 3 (NIST/RFC-standardized).
2 Quantum Recovery Exposure weight 10% 77 / 100
Forge. QRL addresses are XMSS (hash-based). Revealing an XMSS 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 risk that dominates ECDSA/Ed25519 chains. Small deduction: XMSS is a one-time-signature tree, so OTS-index reuse (if a wallet is mismanaged across backups/devices) degrades security to a grindable state (per go-qrllib, a reused index lets an attacker forge signatures for any message); the network rejects duplicate-index transactions at block validation, but a compromised or mismanaged signer is the residual surface.
Forge. Dormant/cold QRL balances sit on XMSS addresses, which are Shor-resistant by construction. Unlike Bitcoin's lost Satoshi-era P2PK coins or dormant Ed25519 balances, QRL cold funds are not forgeable by a future CRQC at the signature layer - a property corroborated by a third-party primary source: the Google Quantum AI cryptocurrency whitepaper ('Securing Elliptic Curve Cryptocurrencies against Quantum Vulnerabilities', published 2026-03-30, co-authored with Ethereum Foundation / academic researchers) lists QRL among the chains that 'rely exclusively on post-quantum cryptography' (alongside Mochimo and Abelian) and cites it as an early-mover example. The narrower phrase 'a presently post-quantum secure blockchain' is QRL's own press-release characterization of that paper, not a verbatim Google quote. This is the strongest cold-key posture in the set. Minor deduction for the theoretical OTS-reuse degradation path and the OTS-exhaustion fund-lock risk.
Forge. Historical QRL transaction signatures are XMSS (hash-based) and remain unforgeable post-Shor. Signed messages, multisig spends, and the planned v1->v2 migration claim-signatures all rest on hash-based security. Deduction: the future Zond mainnet will sign under ML-DSA-87 (lattice), which carries the lattice-confidence caveat for very-long-horizon validity, and SHA-256 internal Grover-weakening slightly trims margins.
Decrypt (HNDL). QRL v1 node-to-node P2P transport and RPC are classical (no documented hybrid PQ KEM); harvested transport ciphertexts would be decryptable once Shor breaks the classical key exchange. QRL 2.0/Zond has BEGUN ML-KEM (FIPS 203) integration for the P2P layer (2026-05-15 and 2026-05-29 weeklies) but it is not deployed on the network and is pure-PQ rather than a hybrid combiner. Scored above the set's typical 4-9 because a concrete PQ KEM is in active integration with a named primitive, but well below full credit because nothing is deployed and there is no hybrid construction.
3 Metadata, Anonymity & Confidentiality weight 13% 34 / 100
Anonymity. QRL v1 is a transparent, pseudonymous ledger (account-balance model) and Zond is an EVM-derived account ledger. Public addresses, public balances, public transaction graph; the QRL block explorer (explorer.theqrl.org) exposes all transactions, OTS-key usage, and balances. No native shielding, no confidential transactions, no stealth addresses. Comparable to Bitcoin/Ethereum transparency.
Anonymity. QRL is a small independent network (~900 nodes, 12 mining pools per the roadmap); RPC is served by QRL Foundation nodes plus community full nodes and mining pools (e.g. HeroMiners, MiningOcean). It does not depend on Infura/Alchemy/QuickNode-class oligopoly providers, so top-3 RPC concentration is structurally low, but exact shares are unpublished and node metadata-retention policy is undeclared (zero credit on that component). Mempool gossip is openly observable.
Anonymity. QRL is an isolated chain with its own native coin (not an ERC-20); it is not integrated with LayerZero/Wormhole/Axelar/CCIP/Stargate and is absent from major bridge networks. The cross-chain correlation surface is therefore small (low bridge-linkability exposure) - scored moderately as low-exposure-by-isolation rather than as deliberate privacy engineering. Liquidity reaches external chains only via centralized exchanges (e.g. MEXC), which are fully correlating.
Confidentiality. A QRL strength relative to EC chains. QRL has no discrete-log/EC privacy primitives (no ElGamal ring signatures, no EC zk-SNARKs), so Shor does NOT retroactively de-anonymize QRL 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 ledger (already visible, not Shor-dependent). Not full credit because QRL has no privacy layer to protect in the first place - it scores well on 'no Shor-breakable privacy crypto' but offers no positive confidentiality.
Anonymity. No on-chain mixer, no commit-reveal shuffle, no cMix/mixnet infrastructure, no batch-ordering. QRL provides no structural anonymity-set mechanism.
4 Migration Architecture weight 10% 59 / 100
QRL's crypto-agility is realized partly as a whole-chain successor (v1 PoW/XMSS -> Zond PoS/ML-DSA-87) and partly as an address-descriptor model (qrlhub.com / roadmap: 'the address descriptor identifies which scheme an account uses; new NIST-approved algorithms can be adopted as standards evolve; no emergency hard fork needed'). Demonstrated in testnet practice: the address format was upgraded 24->48->64 bytes across the full repo set within roughly two weeks each time. Deduction: the headline agility is delivered by launching a new chain plus trustless migration, not by an in-place EIP-7702/8141-style versioned-signature hot-swap on the existing v1 chain; the descriptor model is demonstrated on testnet only.
QRL 2.0/Zond is EVM-compatible (Hyperion, a post-quantum Solidity superset; QRVM execution environment), so ERC-4337 / EIP-7702 account-abstraction and smart-contract-wallet patterns are available, and Hyperion/QRVM can host ML-DSA-87 verifier logic. The v1->v2 migration is itself a per-user opt-in signed XMSS claim. Deduction: no DEPLOYED PQ client-layer migration path with active mainnet tx volume (Zond is testnet); AA is inherited capability, not yet exercised on a live PQ mainnet.
QRL v1 mainnet has operated since 2018-06-26 with coordinated node upgrades and no contested forks; v1.x underwent two independent security audits (Red4Sec, X41 D-Sec). The defining upgrade - the v1->Zond PoW->PoS + signature transition - is specified (snapshot + trustless claim contract) but NOT yet executed, so the track record for a migration of THIS magnitude is unproven. Solid but not maximal.
QRL is explicitly PURE post-quantum and 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 - not because QRL is unprepared, but because the dimension rewards classical+PQ co-signing, which QRL by design does not and will not do. Tension noted: QRL is penalized here precisely for being further along (PQ-native) than the hybrid-transition model assumes.
QRL deploys a STATEFUL hash-based scheme (XMSS) at the transaction layer, so this sub-score is in scope and is QRL's standout architectural strength. Protocol-level enforcement: QRL network nodes REJECT any transaction that reuses an OTS key index during routine block validation (not merely application-level - if the OTS key index used to sign is already known to the blockchain, the node rejects the transaction). The web wallet reconstructs the current XMSS tree index from on-chain transaction history (WASM-compiled qrllib run locally in the browser), propagates each transaction to multiple nodes, and refuses to re-sign until it has seen the tx in the mempool/block. Backup/restore guidance and the requirement to persist the updated OTS index before broadcast are published. Default tree height h=10 (1,024 OTS slots); larger heights and Slave-key/Hypertree extensions documented. Near-full credit; small deduction because multi-device state SYNC remains a wallet-layer responsibility (the chain catches reuse, but a user can still lock funds by exhausting OTS keys, and cross-device coordination is not protocol-enforced sync).
N/A. QRL v1 uses Nakamoto-style RandomX PoW (non-aggregating consensus). QRL 2.0/Zond is a PoS chain with the qrysm consensus/beacon client (Ethereum-derived; mirrors Ethereum's post-Merge two-layer design per the qrlhub.com architecture page, with go-zond/gzond as execution layer and qrysm as consensus layer), but its consensus/validator signatures are ML-DSA-87 (a PQ-safe lattice scheme, per Zond architecture and roadmap), NOT Shor-vulnerable BLS12-381 aggregation - so the 4f concern (a Shor-breakable signature-aggregation path at consensus) does not apply. 4f weight (20) redistributes across 4a-4e. Dimension score = (9+11+10+3+14)/80 * 100 = 58.75 -> 59.
5 Deployment Execution weight 22% 73 / 100
QRL v1 mainnet (live since 2018-06-26) signs ~100% of transactions under XMSS, a PQ-safe hash-based primitive. The 5a rubric measures '% of mainnet signing traffic on PQC primitives (hybrid or pure)' - QRL is ~100% pure-PQ. Roadmap network stats (retrieved 2026-06-02): 3,266,500 block height, 2,023,509 transactions since genesis, 13,436 wallets - all XMSS-signed. This is the highest 5a in the evaluation set by orders of magnitude (vs IOTA 0%). The Mainnet-Traffic cap therefore does NOT fire. One-point deduction: the value-store chain is mature but low-throughput, and the headline PQ chain people associate with QRL's future (Zond/ML-DSA-87 EVM) is testnet-only, so 'mainnet PQC' here is the v1 XMSS chain specifically.
XMSS signature verification is fully merged and in production in the QRL v1 core node (theQRL/QRL, theQRL/go-qrllib) - shipped consensus-client PQC code, not testnet-only. ML-DSA-87 verification is merged across the Zond stack (go-zond execution client, qrysm consensus client, go-qrllib, Hyperion/QRVM) but on testnet, with 100% code coverage reported across go-qrllib/qrypto.js/wallet.js. Near-full credit because, uniquely in the set, there is PQC signing code running in a LIVE mainnet consensus client today.
QRL v1 consensus is PoW (RandomX) - block production is hashing, not signing - so there are no 'validator PQC signing keys' at v1 consensus; however ~100% of USER transaction signing on the live chain is XMSS (PQ). QRL 2.0/Zond PoS validators will sign with ML-DSA-87 (qrysm; required for staking validators per roadmap), but only on testnet. Scored mid-range: full user-signing-key PQ adoption on the live chain, but Zond validator PQ keys are testnet-only and v1 has no validator signing layer to adopt PQC at.
NOT voided (5a > 0). QRL publishes named, dated, verifiable milestones with shipped artifacts: public devnet (2022-12), beta-testnet (2024-01), Testnet V1 (2025), code freeze across 6 repos (2026-02-13, per the 2026-02-13 weekly), Trail of Bits revealed as the auditing vendor (2026-03-06 weekly), 100% code coverage achieved across essential cryptographic libraries go-qrllib/qrypto.js/wallet.js (stated in the 2026-03-06 and 2026-04-03 weeklies), Testnet V2 launch (2026-03-31, Zug), Halborn crypto-library audit complete (2026-04-03), 64-byte / NIST-Level-5 address upgrade across 5+ repos (go-qrllib/qrysm/go-qrl/hyperion/qrvmone; 2026-05-29, in review). Strong milestone discipline backed by shipped code. Deduction: the mainnet date is explicitly 'post-audit, TBD' rather than a protocol-enforced flag-day, and the future milestones are not consensus-enforced sunset dates.
Announced ~= shipped. QRL has signed real mainnet transactions under a PQ-safe primitive (XMSS) since 2018; its PQ claims are backed by deployed, on-chain-verifiable bytes - the inverse of narrative-only chains. Ratio ~1.0, no deduction. Minor caveat retained because the ML-DSA-87 Zond mainnet is announced + testnet-shipped but not yet mainnet-shipped; the washing ratio for the lattice claim specifically should be re-checked at Zond mainnet launch.
QRL's deployment weakness. Per go-qrllib, XMSS (h=10) signatures are ~2,500 bytes (~39x the 64-byte ECDSA/Ed25519 baseline); ML-DSA-87 signatures are 4,627 bytes (~72x baseline, the largest of the ML-DSA family at Category 5); SPHINCS+-256s is 29,792 bytes. Both deployed/planned signing schemes sit at or above the >38x band, and QRL deploys NO SNARK aggregation, data-availability offloading, or batching to bring the effective per-block multiplier down (tx max broadcast size raised to 16 KB, max tx packet size 256 KB per the 2026-04-10 weekly to accommodate the footprint). No user-laggard decay-rate reporting. Scored 3/20: a non-zero floor only because the footprint is fully disclosed and is the honest cost of strong PQ security, but the raw bytes-per-signature is the worst-case end of the multiplier scale.
6 Supply Chain Vendor Readiness weight 22% 22 / 100
QRL's first-party wallets are PQ-native by construction: the QRL web wallet (wallet.theqrl.org, WASM-compiled qrllib executed locally in-browser), desktop wallet, and Chrome-extension wallet all sign with XMSS today (moving to ML-DSA-87 on Zond), and Ledger Nano S/X firmware supports QRL XMSS addresses (with a documented OTS-key limit - hardware memory restricts the internal tree to h=8 / 256 OTS keys - and a fund-lock caveat once a tree's keys are exhausted). Scored well above the set norm because the primary wallet IS quantum-safe rather than carrying a 'PQC roadmap'. Deductions: the third-party wallet ecosystem is thin, Ledger integration is constrained by hardware OTS limits, and there is no broad MetaMask/Phantom-class support.
QRL is an isolated independent chain not integrated with LayerZero, Wormhole, Axelar, CCIP, or Stargate, and none of those bridge vendors publish a QRL-specific PQC roadmap. Cross-chain movement happens via centralized exchanges (e.g. MEXC), which are classical. QRC-20 on Zond is described as a future possibility, not a live bridge. No PQ-safe bridge infrastructure exists for QRL. Worst tile alongside custodian/infra - drives the Supply-Chain cap.
Minimal institutional-custody footprint. QRL is absent from Fireblocks, BitGo, and Anchorage public supported-asset/custody pages, and none publish a QRL-specific PQ custody roadmap. The chain's primary custody path is self-custody via first-party wallets and Ledger hardware wallets. No documented custodian-MPC path for QRL's PQ signature schemes (note: ML-DSA is MPC-amenable in principle, but no QRL custodian has implemented it).
RPC is served by QRL Foundation nodes and community/mining-pool nodes (~900 nodes, 12 pools per the roadmap); the 2026-04-03 weekly describes qrl-infra phase 1 (automated AWS deployment + monitoring + spammer node), and the 2026-05-15 weekly notes CI/CD supply-chain hardening. Ledger Nano S/X HSM-line devices support QRL XMSS via the Ledger app, but Ledger publishes no QRL-named PQ firmware roadmap. No TEE attestation chains in QRL's path, and no third-party RPC provider (Infura/Alchemy/QuickNode class) publishes a QRL offering. Cross-tile weak-link: with bridge/custodian/infra all low, the dimension is capped by its weakest tiles - this is what fires the Supply-Chain cap (3 of 4 tiles lack top-3 vendor PQC roadmaps -> Migration Stage <= 3).
7 Governance & Coordination weight 8% 44 / 100
QRL v1 uses RandomX PoW (CPU-optimized, ASIC/GPU-resistant) with community mining pools (HeroMiners, MiningOcean) and solo mining; ~900 nodes and 12 mining pools per the roadmap. It is a small network and the Nakamoto coefficient / pool-share distribution is not published by the QRL Foundation. QRL 2.0/Zond moves to PoS with a validator/staking set, but that is testnet-only with no published validator count or stake distribution. Modest decentralization, undocumented concentration metrics.
Coordinated node upgrades since the 2018 mainnet, no contested forks, and a long multi-year Zond development cadence (devnet 2022 -> beta-testnet 2024 -> Testnet V1 2025 -> Testnet V2 2026-03-31), with the network stress-tested at 952 transactions per block (April 2026). The defining high-stakes coordination event (the v1->v2 PoW->PoS + signature migration) is specified but not yet executed, so cadence-under-pressure is partly unproven.
Clear named coordination lead: the QRL Foundation (Die QRL Stiftung), a Swiss non-profit registered in Zug, Switzerland (press datelines 2026-03-31, 2026-04-03), and a confirmed PKI Consortium member tagged PQC ('supporting open-source post-quantum blockchain development'). Strong, transparent leadership for a chain of its size.
QRL's entire thesis is proactive PQ defence (PQ from genesis), a positive structural signal, but it has NOT executed a crypto migration under live adversarial pressure - there has been no attack-driven emergency fork. The proactive posture is credited modestly; a true adversarial-coordination test is absent.
No canary, honeypot, rate-limit spending rule, or cryptographic tripwire is documented - and QRL arguably needs none for the forge threat, since its signatures are already PQ-safe. Scored 0 per rubric (no mechanism documented), with the note that the dimension is less relevant to a PQ-native chain.
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 QRL's signature layer - it is the rare chain already inside the risk window for value protection. The forge threat that drives X+Y>Z on classical L1s is structurally mitigated by hash-based signing. Residual risk concentrates on (a) lattice-confidence for the planned ML-DSA-87 Zond mainnet, (b) classical P2P/KEM transport (HNDL Decrypt), and (c) the unlaunched-mainnet execution gap for Zond.
Z-compliance
Inside the compliance window for the dominant value-protection threat: XMSS is a NIST-recognized hash-based family (RFC 8391 / SP 800-208 lineage), so QRL v1 mainnet is not exposed to the NIST IR 8547 (IPD) 2030/2035 disallowance of quantum-vulnerable public keys the way ECDSA/Ed25519 chains are. Primary jurisdiction CH/EU (Die QRL Stiftung, Zug, Switzerland): QRL already satisfies the substance of QV-PK disallowance for its signature layer; the open item is KEM/transport (no hybrid PQ KEM deployed yet) and the unlaunched Zond ML-DSA mainnet.
Source-disagreement disclosure
v3.1 requires every chain card to publish material divergences among authoritative sources, plus the delta-QRI under alternative weighting.
QRL's own materials disagree on the Zond launch signature scheme. An earlier strategy post ('Embracing SPHINCS+: A Strategic Shift for QRL Project Zond', theqrl.org) states SPHINCS+/SLH-DSA (FIPS 205) will be primary, replacing stateful XMSS to remove OTS-index tracking. More recent and more numerous sources (the 'Audit Ready Q1 2026' blog, the 2026-03-31 Testnet V2 press release, qrlhub.com, the Halborn audit of ML-DSA-87, and all 2026 weeklies including the 2026-05-29 64-byte / NIST-Level-5 address upgrade across go-qrllib/qrysm/go-qrl/hyperion/qrvmone) consistently state ML-DSA-87 (CRYSTALS-Dilithium, FIPS 204, NIST Category 5) is primary at launch, with SLH-DSA deferred post-mainnet (go-qrllib SPHINCS+-256s is verifiable but not issuable). This evaluation follows the most recent and most numerous evidence (ML-DSA-87 primary at mainnet launch; SLH-DSA post-mainnet). This disagreement is the main driver of the +-5 CI.
Some secondary sources and roadmap language frame 'Zond mainnet' as imminent or implied; primary QRL sources (audit-ready blog, weeklies) are explicit that mainnet is contingent on completion of a full Trail of Bits protocol audit AFTER Testnet V2 (frozen 2026-02-13, launched 2026-03-31). As of the evaluation date, Zond is testnet-only; the only LIVE QRL mainnet is the 2018 PoW/XMSS chain. All Dim 5 mainnet-traffic credit is assigned to the v1 XMSS chain, NOT to unlaunched Zond.
QRL marketing frequently describes its XMSS as 'RFC 8391'. The authoritative go-qrllib README states the implementation predates RFC 8391 (published August 2018) and is not intended as a general RFC-compliant implementation; overlapping parameter sets (XMSS-SHA2_10_256, XMSS-SHAKE_256_10_256) cross-verify bidirectionally with the RFC reference, while QRL-specific SHAKE_128 is non-RFC and NIST SP 800-208 refinements are intentionally not applied (to preserve mainnet address compatibility). Accurate characterization: pre-RFC XMSS with partial RFC 8391 parameter overlap, not SP 800-208 compliant. This is a precision issue, not a security flaw; security properties are substantively similar to RFC 8391 for the overlapping parameter sets.
The Diversity Cap is written specifically for lattice-monoculture (SIKE-precedent single-point-of-failure). QRL's LIVE mainnet is a hash-based monoculture (XMSS only), which Dim 1c treats as less fragile than lattice-monoculture (hash-only = 10 vs lattice-only hard-capped at 5). The planned Zond mainnet would add a lattice family (ML-DSA-87) and later SLH-DSA (a second hash family). The literal cap does not fire; the single-family-on-current-mainnet concern is noted but is hash-based, not lattice-based.
QRL's address descriptor reserves three hash-function options for XMSS: SHA2-256 (HF=0), SHAKE-128 (HF=1), SHAKE-256 (HF=2). The QRL Docs address-scheme page states that, at present, only one address format is utilized on v1 mainnet: 'sha256 2X' (SHA-256 internal). go-qrllib also exposes a QRL-specific non-RFC SHAKE_128 variant retained for compatibility, and the RFC-overlapping cross-verify parameter sets are XMSS-SHA2_10_256 and XMSS-SHAKE_256_10_256. We therefore treat SHA-256 (not SHAKE) as the deployed v1 mainnet hash; SHAKE variants are descriptor-supported but not the deployed default. This is a precision distinction with no score impact: all options are Grover-weakened symmetric hashes at Category-1+ tree params.
QRL describes qrysm as the Zond consensus/beacon client and documents an architecture that mirrors Ethereum's post-Merge two-layer design (go-zond/gzond execution layer + qrysm consensus layer). The repository name and Ethereum-derived beacon architecture strongly imply a fork of the Prysm client, but we found no QRL primary source that states 'fork of Prysm / Prysmatic Labs' verbatim. We therefore characterize qrysm as 'Ethereum-derived' rather than asserting a specific upstream fork. No score impact (4f is N/A regardless: consensus signatures are ML-DSA-87, not BLS12-381).
The 2b cold-key sub-score leans on third-party corroboration from the Google Quantum AI cryptocurrency whitepaper (2026-03-30). Verification of the paper's actual language: it lists QRL among the chains that 'rely exclusively on post-quantum cryptography' (alongside Mochimo and Abelian) and names it as an early-mover example. It does NOT use the phrase 'a presently post-quantum secure blockchain' verbatim - that wording originates in QRL's own Halborn-audit press release paraphrasing the paper. We treat the paper as corroborating QRL's exclusive-PQ signature posture (which it does), and have removed the misattributed verbatim quote. No score change: the underlying corroboration holds. Residual caution for cryptographers: the paper's endorsement is about QRL relying exclusively on PQC, not an independent audit of XMSS parameter security.
Delta-QRI under alternative weighting
QRL is unusually sensitive to the Deployment-vs-Supply-Chain weight split because it is an outlier on both axes (strongest in the set on Dim 5, near-weakest on Dim 6). Under an alternative weighting that down-weights Deployment (Dim 5 -> 12%) and up-weights Supply Chain (Dim 6 -> 32%), QRI falls to ~47 (still Band 5-6). Conversely, a weighting that credited shipped-mainnet-PQC more heavily (Dim 5 -> 30%) lifts QRI to ~58 (top of Band 6). The L1-default weighting (Dim 5 22% / Dim 6 22%) yields QRI 54.
Announcement-to-shipped ratio
Announced: 6. Shipped: 6. Ratio: 1.
Tag: none, ratio <= 1.5; QRL has shipped PQ-safe mainnet signing (XMSS) continuously since 2018 - announcements are backed by deployed, on-chain-verifiable primitives. Caveat: the ML-DSA-87 Zond mainnet is announced + frozen + testnet-shipped but NOT yet mainnet-shipped, so the washing ratio for the lattice claim specifically should be re-checked at Zond mainnet launch.
Peers in the L1 profile
9 chains closest to Quantum Resistant Ledger (QRL) by Stage then QRI.