What it is. QRL is a small independent cryptocurrency, running since 2018, built from the start to keep working once quantum computers can break the math that guards ordinary crypto.
What we found. The protection is genuinely in use on the live network today rather than waiting on a future upgrade, and it comes with a handling rule ordinary crypto wallets do not have: each address can send only a set number of payments before it is used up, and coins left in a used-up address can never be moved.
Why it matters. What limits QRL now is reach rather than security: we found no large custody provider and no cross-chain bridge connected to it, and by the project's own count only a few hundred computers keep the network running.
QRL v1 mainnet has signed close to all of its transactions under XMSS since June 2018 (stateful hash-based, W-OTS+ chains over SHA2-256, default tree height h=10, SHAKE-128 kept for legacy addresses), a pre-RFC-8391 implementation that Trail of Bits recorded as not fully RFC 8391 compliant and that declines the NIST SP 800-208 expand_seed refinement to preserve v1 address compatibility, so it conforms to neither standard while Shor still forges nothing against it and the mainnet-traffic cap does not fire. The load-bearing fact is that nothing outside the protocol moved with it: QRL composes no classical-plus-PQ hybrid by design (Gate 1a-Sig and Gate 1a-KEM fail, QRI capped at 60 against a raw 54), the ML-DSA-87 (FIPS 204) successor QRL 2.0 / Zond is testnet-only with no published mainnet date, and the supply-chain cap holds Migration Stage at 3 because the bridge, custodian and RPC/HSM tiles publish no PQC roadmap.
Summary
QRL v1 mainnet, live since June 2018, signs close to all transactions under XMSS: stateful, hash-based, W-OTS+ chains over SHAKE-128 (SHA2-256 and SHAKE-256 selectable via the address descriptor), default tree height h=10 for 1,024 one-time keys, pre-RFC-8391, conformant to neither RFC 8391 nor SP 800-208. Security rests on the second-preimage resistance of the hash, so revealed keys, dormant balances and old signatures survive Shor, and nodes reject at block validation any transaction reusing a one-time key index. Consensus is RandomX proof-of-work, with no validator signing keys to migrate. Cost is size: about 2,500 bytes per XMSS signature at h=10, 4,627 for ML-DSA-87, 64 for Ed25519, no aggregation. QRL composes no classical-plus-PQ hybrid anywhere by design, so Gate 1a-Sig and Gate 1a-KEM fail and QRI is capped at 60, non-binding against a raw 54. The ML-DSA-87 (FIPS 204) successor QRL 2.0 / Zond is testnet-only (Testnet V2, March 2026, no mainnet date); ML-KEM-1024 (FIPS 203) is merged in go-qrllib but runs nowhere live. Trail of Bits’ July 2026 go-qrllib review closed all 15 findings, one High on XMSS hash-function validation, and made hedged ML-DSA signing the default; QRL puts the full-protocol audit at 50%. The supply-chain cap holds Migration Stage at 3: bridge, custodian and RPC/HSM tiles publish no PQC roadmap.
Forge. Forge-dominant: this chain secures value and operations with signatures, so the principal quantum risk class is forgery of spends/attestations. On QRL specifically that risk is structurally mitigated at the signature layer because the deployed scheme is hash-based rather than discrete-log-based, so the residual forge exposure is OTS state management rather than Shor. Decrypt/HNDL applies only to transport/RPC confidentiality, where no PQ KEM is deployed.
6 announced → 6 shipped on mainnet under a named primitive. none, ratio <= 1.5; QRL has shipped PQ-safe mainnet signing (XMSS) continuously since 2018 - announcements are backed by deployed, on-chain-verifiable primitives. The 2026-08-04 Trail of Bits announcement introduces no new primitive claim (XMSS and ML-DSA only) and is backed by merged remediation commits whose hashes match the fix-review appendix of the auditor's own report, so the count is unchanged. 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..
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. For QRL 2.0/Zond, go-qrllib merged a dedicated ML-KEM-1024 per FIPS 203 package on 2026-06-04, with zeroization, Wycheproof test vectors and fuzzers added 2026-06-08, and NIST ACVP verification for key generation, encapsulation and decapsulation; QRL's weekly snapshots state it is intended for the P2P layer, the library documents it as a primitive that is not wallet-integrated, it is a pure-PQ KEM with no documented classical+PQ hybrid combiner, and it is not deployed on Testnet V2 or any live network as of 2026-08-19. Either reading fails Gate 1a-KEM: currently no PQ KEM deployed, and the 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: the QRL Foundation's blog, press releases and weekly development snapshots; the QRL documentation site; the QRL block explorer; RFC 8391; NIST SP 800-208; FIPS 203, 204 and 205; NIST IR 8547 initial public draft; the theQRL GitHub organization's go-qrllib, go-zond, qrysm and audits repositories and their commit history; the Halborn audit press release; the Trail of Bits go-qrllib security assessment PDF published on Trail of Bits' own public publications repository; the Google Quantum AI cryptocurrency whitepaper of 2026-03-30; and the PKI Consortium members list
- Gate 3, Primitive naming: PASS , every primitive named exactly: XMSS pre-RFC-8391 with partial RFC 8391 parameter overlap / W-OTS+ OTS / SHA2-256 deployed-mainnet internal hash (address format sha256 2X) with SHAKE-128 and SHAKE-256 as reserved descriptor hash-function options, RandomX PoW, ML-DSA-87 / formerly Dilithium5 / FIPS 204 (hedged signing by default since go-qrllib commit 6c61398, 2026-05-19), SPHINCS+-256s on SHAKE-256s-robust (the non-simple tweakable-hash variant), as the pre-FIPS-205 SPHINCS+ submission and NOT SLH-DSA per FIPS 205, Falcon-1024 / FN-DSA / NIST-selected with FIPS 206 in development and no draft published, ML-KEM-1024 / 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). QRL's own 2026-03-31 Testnet V2 press release states that holders of QRL 1.x tokens will migrate to QRL 2.0 through a smart-contract-based process, removing reliance on a centralized migration mechanism; it does not publish the step-level mechanics. Community-maintained QRL documentation describes those mechanics as: at a predetermined block height a final snapshot of the PoW chain is taken; a contract on Zond holds the snapshot balance data; the user supplies a new Zond address and signs a message with the existing XMSS address; the contract verifies the XMSS signature and transfers the balance - described as automated, trustless, and explicitly non-emergency because the original QRL chain is already quantum-safe, so holders migrate at their own pace. We treat the first-party press-release framing as established and the step-level detail as community-sourced and not independently confirmed. 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% 76 / 100
QRL publishes a complete and precisely-named primitive inventory across both the live v1 chain (XMSS, SHA2-256, SHAKE-128, RandomX) and the Zond chain (ML-DSA-87 / FIPS 204, SPHINCS+-256s, Falcon-1024, ML-KEM-1024 / FIPS 203), with byte-exact key and signature sizes published in the library. Deduction because the Zond signature-scheme story was internally inconsistent across QRL's own materials (a 2025-07-01 post declaring a shift to SPHINCS+ versus later ML-DSA-87-primary statements), QRL's marketing has described the hash-based stateless scheme as SLH-DSA/FIPS 205 when the implemented object is the pre-FIPS SPHINCS+ submission, 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 with hash-function field SHA2-256; partial RFC 8391 parameter overlap on XMSS-SHA2_10_256 and XMSS-SHAKE_256_10_256, pre-RFC implementation, not SP 800-208 compliant) - QRL v1 mainnet signature scheme since the June 2018 launch · SHA2-256 (hash function of the only utilized v1 mainnet address format, sha256 2X; also used for the address and verification hashes in the address construction) · SHAKE-128 / SHAKE-256 (reserved descriptor hash-function options HF=1 and HF=2; SHAKE-128 is a QRL-specific pre-standardisation variant flagged by Trail of Bits as non-FIPS-compliant with reduced quantum security and documented as legacy-only; not the deployed v1 mainnet default - SHA2-256 is) · RandomX (CPU-optimized Proof-of-Work hash, ASIC/GPU-resistant; adopted via QIP 009, status Completed; 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 per go-qrllib; hedged signing enabled by default since commit 6c61398 on 2026-05-19; the pre-FIPS 'dilithium5' package was removed from go-qrllib on 2026-06-10) - QRL 2.0/Zond launch signature scheme, merged across the Zond stack on testnet · SPHINCS+-256s (SHAKE-256s-robust, the pre-FIPS-205 SPHINCS+ submission, NOT SLH-DSA per FIPS 205; public key 64 B, secret key 128 B, signature 29,792 B) - implemented in go-qrllib as a primitive; the wallet layer does not issue new wallets of this type and descriptor validation rejects it, pending QRL settling on a specific SLH-DSA parameter set · Falcon-1024 (FN-DSA; NIST-selected, FIPS 206 in development, no draft standard published) - stated in QRL weeklies as intended for the P2P layer and 'in progress' from 2026-04-24 through 2026-05-29; no Falcon merge appears anywhere in go-qrllib's commit history through its latest commit of 2026-06-19 · ML-KEM-1024 (CRYSTALS-Kyber, FIPS 203) - dedicated package merged into go-qrllib 2026-06-04, with zeroization, Wycheproof test vectors and fuzzers added 2026-06-08 and NIST ACVP verification of key generation, encapsulation and decapsulation; documented in the library as a primitive that is not wallet-integrated; stated in weeklies as intended for the Zond P2P layer; not deployed on any network 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 SHA2-256/SHAKE-128, the auditor-flagged reduced quantum security of the QRL-specific SHAKE-128 variant, 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 SHA2-256 preimage/2nd-preimage resistance; Grover-weakened but Category-1+ at deployed tree params)SHA2-256→ Grover-weaken (256-bit -> ~128-bit preimage security)SHAKE-128→ Grover-weaken; also flagged by the auditor as a non-FIPS parameter with reduced quantum security, documented legacy-onlyRandomX (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 (pre-FIPS-205 submission, deferred, non-issuable)→ PQ-safe hash (stateless)Falcon-1024 / FN-DSA (stated as planned for P2P; no code merged)→ PQ-safe lattice (FIPS 206 in development, no draft published)ML-KEM-1024 (FIPS 203, library-merged, P2P planned)→ 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 scheme (SPHINCS+-256s, a second hash-based construction), which would score 15-20 once deployed at consensus / Dim 5 level - but those are testnet-only or non-issuable today, so they do not count toward deployed diversity. Note: the Cryptographic-Diversity Cap targets LATTICE-monoculture specifically; QRL's current single-family is HASH-based, which the rubric treats as less fragile than lattice-monoculture (hard-capped at 5).
XMSS is the scheme family NIST specifies for stateful hash-based signatures in SP 800-208 (alongside LMS/HSS), and NIST IR 8547 lists XMSS/XMSS^MT among quantum-resistant rather than quantum-vulnerable signature standards - though QRL's own deployment deliberately does not apply the SP 800-208 refinements and so is not an SP 800-208 conformant instance. ML-DSA-87 maps to NIST Category 5 (highest). The 2026-05-15 and 2026-05-29 weeklies document an address-format upgrade from 48 to 64 bytes across go-qrllib, qrysm, go-qrl, hyperion and qrvmone 'to have complete NIST Security Level 5', merged in go-qrllib on 2026-05-19. The deferred SPHINCS+-256s parameter set targets the top category but is non-issuable and pre-FIPS. Deduction: ML-DSA-87 mainnet is not yet live, and the current mainnet security category rests on XMSS tree parameters in a non-SP-800-208-conformant implementation rather than on a NIST-categorized PQC signature.
Library provenance: theQRL/go-qrllib (Go crypto library, zero third-party dependencies, Go 1.25+). Two independent audits now touch the QRL cryptography stack. Halborn (announced 2026-04-03) audited two NIST-PQC-standardization-process signature packages - not named in the press release, and not described as including XMSS - reporting 13 findings, all Informational, all resolved, with core signing, verification and key-generation logic validated as correct. Trail of Bits (review 2026-04-13 to 2026-04-22, three engineer-weeks; fix review 2026-06-22; report dated 2026-07-08; announced by QRL 2026-08-04) assessed the XMSS and ML-DSA implementations, the exported API boundary and the wallet and legacy-wallet state-management paths against FIPS 204 and RFC 8391 / NIST SP 800-208, using structured, mutation-based and metamorphic fuzzers, mutation testing, NIST ACVP and Wycheproof ML-DSA vectors integrated into the Go test harness, cgo-backed equivalence testing against the C reference, cross-architecture generated-assembly inspection for secret-dependent branching, division/remainder instructions and constant-time-preserving codegen shape, and a bespoke C-to-Go operator-precedence analyzer built for the engagement. Result: 15 findings - 1 High (TOB-QRLLIB-13, invalid XMSS hash-function values producing degenerate interchangeable keys and signatures; resolved by validating the selected hash function and adding a default case), 0 Medium, 4 Low, 10 Informational - all 15 resolved and re-reviewed. The auditor's overall observation was that the codebase is well-organized and modular, the primitives strongly follow their specifications, and testing coverage is strong. Remediation shipped as merged code whose commit hashes match the report's fix-review appendix: ML-DSA signing moved from deterministic to hedged by default per FIPS 204 (6c61398, 2026-05-19), SPHINCS+ made invalid in wallet validation, descriptor metadata bound into the signing context, SHAKE-128 documented as legacy-only with reduced quantum security, ML-DSA secret-memory zeroization made consistent, nil-public-key panics eliminated, and CI actions pinned. XMSS has a production track record since 2018; QRL reports 100% code coverage across go-qrllib, qrypto.js and wallet.js (a QRL self-report, corroborated only qualitatively by the auditor). Deductions: the audits cover the crypto LIBRARY, not the full protocol/consensus (program reported at 50% by QRL, no independent figure); a High-severity key-degeneracy defect existed in the exported API of the library that underpins eight years of mainnet signing, and integration of that library into other codebases was explicitly out of audit scope; no machine-checked formal verification (Formosa/EasyCrypt-class) is cited for QRL's specific implementation; constant-time posture was inspected at the assembly level but not measured (no dudect-class result published); and the Zond ML-DSA-87 verifier is testnet-only, so deployed-verifier provenance earns no mainnet credit. Note on cryptanalytic tier: ML-DSA-87 is NIST-standardized (FIPS 204); XMSS is a standardized family (RFC 8391 / SP 800-208) but QRL's instance is deliberately non-conformant to both.
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 forgeable state - go-qrllib's own warning states that if the same index is used twice, even for different messages, an attacker can forge signatures for ANY message, and the QRL documentation states that an index exposed more than once means the address should be considered compromised and all funds moved. 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 dormant Pay-to-Public-Key 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: Resource Estimates and Mitigations', dated 2026-03-30) states that 'some blockchains, such as the Quantum Resistant Ledger (QRL), Mochimo and Abelian, rely exclusively on PQC', and separately that 'the QRL launched in 2018 stands out as post-quantum from inception. Its original design was based on the stateful post-quantum signature scheme known as XMSS'. The narrower phrase 'a presently post-quantum secure blockchain' is QRL's own press-release characterization of that paper, not a verbatim quote from it. Minor deduction for the OTS-reuse degradation path and the OTS-exhaustion fund-lock risk (once all key indexes in a tree are used, no further transactions can be made from that address and any funds left there are lost).
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 SHA2-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 per the 2026-05-15 and 2026-05-29 weeklies ('ML-KEM implementation has begun, it will be used in P2P layer'), but it is not deployed on the network and is pure-PQ rather than a hybrid combiner. Scored above the low single digits 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. Update 2026-08-19: the ML-KEM-1024 package was merged into go-qrllib on 2026-06-04, with zeroization, Wycheproof vectors and fuzzers on 2026-06-08 and NIST ACVP verification; the library documents it as a primitive that is not wallet-integrated. This firms up the evidence but changes nothing on the wire, since no live network uses it, so the score holds.
3 Metadata, Anonymity & Confidentiality weight 13% 33 / 100
Anonymity. QRL v1 is a transparent, pseudonymous ledger addressed by public account addresses carrying published balances and per-address OTS index state, and Zond is an EVM-derived account ledger. Public addresses, public balances, public transaction graph; the QRL block explorer exposes all transactions, OTS-key usage, and balances (the documentation instructs users to search an address in the explorer and select the OTS tab to see used OTS keys). No native shielding, no confidential transactions, no stealth addresses. A privacy feature exists only as an unimplemented improvement proposal (QIP 015, 'Implement privacy feature for QRL', status Draft/Incomplete). Comparable to Bitcoin/Ethereum transparency.
Anonymity. QRL is a small independent network - the QRL Foundation's published network panel reads 300 QRL nodes, 312 miners and 12 pools as of 2026-08-19, with the disclaimer that the statistics are pulled periodically and are not live. RPC is served by QRL Foundation nodes plus community full nodes and mining pools. It does not depend on Infura/Alchemy/QuickNode-class oligopoly providers, so third-party-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. At 300 nodes the 'many independent RPC endpoints' argument is weak.
Anonymity. QRL is an isolated chain with its own native coin (not an ERC-20); we found no integration with LayerZero, Wormhole, Axelar, CCIP or Stargate, and it 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 via centralized exchanges, which are fully correlating; this card names no specific exchange because no listing is confirmed by a primary source.
Confidentiality. A QRL strength relative to elliptic-curve 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; the only privacy work on record is an unimplemented improvement proposal (QIP 015, Draft/Incomplete).
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. First-party sourcing: the QRL roadmap states 'our blockchain includes the possibility to upgrade signature schemes (XMSS, SPHINCS, Falcon, + future) and through an address format update, support different cryptographic hash functions (SHA2_256, SHAKE_128, SHAKE256 etc)', and the documentation's address-scheme page confirms the descriptor's first three bytes encode the hash function, signature scheme and address format, with SHA2-256/SHAKE-128/SHAKE-256 enumerated and only sha256 2X currently utilized. Demonstrated in testnet practice: the address format moved 24 -> 48 (go-qrllib 2026-03-31) -> 64 bytes (2026-05-19, then across qrysm, go-qrl, hyperion and qrvmone by 2026-05-29). Deduction: the headline agility is delivered by launching a new chain plus a migration, not by an in-place versioned-signature hot-swap on the existing v1 chain; the descriptor model is exercised on testnet only; and the crypto-agility claim is undercut in practice by the fact that QRL deliberately declines the SP 800-208 refinement precisely because it would break existing v1 address compatibility.
QRL 2.0/Zond is EVM-compatible (Hyperion, a post-quantum superset of Solidity; QRVM execution environment), so ERC-4337 / EIP-7702 account-abstraction and smart-contract-wallet patterns are available in principle, 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); account abstraction is inherited capability, not yet exercised on a live PQ mainnet, and we found no QRL primary source demonstrating a deployed ERC-4337 flow on Zond.
QRL v1 mainnet has operated since June 2018 with coordinated node upgrades; QRL characterizes the record as continuous, exception-free operation with no contested forks (a first-party claim we did not independently measure). QRL 1.x underwent two independent pre-launch security audits by Red4Sec and X41 D-Sec, corroborated in both the 2026-03-31 Testnet V2 press release and the 2026-06-26 eight-year blog. The defining upgrade - the v1->Zond PoW->PoS + signature transition - is specified (snapshot + 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 PQ-native rather than mid-transition, which the hybrid-transition model does not anticipate.
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, verbatim from the node documentation: 'If the address OTS key used to sign the transaction is already known to the blockchain the node will reject the transaction, protecting the address from broadcasting a OTS key re-use.' This is block-validation enforcement, not merely application-level. The library documents the safe pattern explicitly - the updated index MUST be persisted to durable storage immediately after signing and BEFORE the signature is used or broadcast, with no concurrent signing and no state rollback - and the web wallet reconstructs the current XMSS tree index from on-chain transaction history (WASM-compiled qrllib run locally in the browser). Default tree height h=10 (1,024 OTS slots); the documented range runs h=8 (256, the Ledger hardware limit) through h=18 (262,144), with Slave-key extensions documented. Trail of Bits' review specifically asked whether XMSS index state management and persistence are handled correctly and produced no High or Low finding on the persistence logic itself; its wallet-layer findings concerned descriptor binding and dropped API documentation, both resolved. Small deduction because multi-device state SYNC remains a wallet-layer responsibility (the chain catches reuse, but a user can still permanently lock funds by exhausting OTS keys, and cross-device coordination is not protocol-enforced).
N/A. QRL v1 uses Nakamoto-style RandomX PoW (non-aggregating consensus). QRL 2.0/Zond is a PoS chain with an execution layer (go-zond) and a separate consensus/beacon client (qrysm), an Ethereum-derived two-layer design, but its consensus/validator signatures are ML-DSA-87 - QRL's 2026-06-26 blog states ML-DSA-87 is 'integrated across the full stack, including go-qrllib, go-zond, Qrysm, and the deposit contracts' - 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 June 2018) 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. The QRL Foundation's published network panel, read 2026-08-19, shows 4,225,792 block height at 60s blocktime, 2,485,330 transactions since genesis, 396,813,697.01 QRL volume since genesis and 19,714 wallets since genesis, all XMSS-signed; the panel carries the disclaimer that statistics are pulled periodically and are not live, and the panel figures are used as published. One-point deduction: the value-store chain is mature but low-throughput, and the PQ chain associated 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, and the v1 node repository remains actively maintained (last push 2026-08-08). 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 QRL reporting 100% code coverage across go-qrllib, qrypto.js and wallet.js (2026-03-06 weekly). Near-full credit because 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 sign with ML-DSA-87 via qrysm and the deposit contracts, but only on testnet, and no validator count or stake distribution is published for that 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 at which to adopt PQC. Not scored: there is no key-holding block producer here, so there is no validator key to adopt. Left out of the dimension total rather than counted as a zero. Post-quantum user-transaction signing is measured in 5a.
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 weekly), Trail of Bits revealed as auditing vendor plus 100% code coverage across go-qrllib/qrypto.js/wallet.js (2026-03-06 weekly), Testnet V2 launch (2026-03-31, Zug), Halborn crypto-library audit complete (2026-04-03), qrl-infra AWS phase 1 (2026-04-03 weekly), transaction size parameters raised to 16 KB broadcast / 256 KB packet (2026-04-10 weekly), 952-transactions-per-block stress test (2026-04-24 weekly), 64-byte address work initiated (2026-05-15) and finished across go-qrllib/qrysm/go-qrl/hyperion/qrvmone (2026-05-29). Further dated shipped artifacts confirmed in commit history: 64-byte addresses merged in go-qrllib and ML-DSA hedged signing enabled (both 2026-05-19), ML-KEM-1024 package merged (2026-06-04), zeroization and Wycheproof vectors (2026-06-08), pre-FIPS 'dilithium5' package removed (2026-06-10), Trail of Bits fix review of all 15 findings (2026-06-22), report dated 2026-07-08 and announced 2026-08-04, qrvmc version bump to 2.0.0 (2026-08-14 weekly). Strong milestone discipline backed by shipped code. Against that: the one forward-looking figure, audit-program completion, reads '50%' without movement across three separate publications spanning roughly seven weeks (the 2026-06-26 eight-year blog and the 2026-08-07 and 2026-08-14 weeklies), the mainnet date is 'post-audit, TBD' rather than a protocol-enforced flag-day, and no milestone is a consensus-enforced sunset date. A headline progress metric that does not move for seven weeks is weak milestone discipline on the one milestone that gates mainnet.
Announced approximately equals 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 rather than by roadmap language, and the remediation commits behind its most recent audit announcement match the hashes listed in the auditor's own fix-review appendix. Ratio ~1.0, no deduction on that basis. Minor caveat retained because the ML-DSA-87 Zond mainnet is announced and testnet-shipped but not yet mainnet-shipped, and because QRL marketing has at times described the deferred hash-based scheme as SLH-DSA/FIPS 205 when the implemented object is the pre-FIPS SPHINCS+ submission; the washing ratio for the lattice claim specifically should be re-checked at Zond mainnet launch.
QRL's deployment weakness. Per go-qrllib's published key-size table, XMSS (h=10) signatures are ~2,500 bytes (~39x a 64-byte Ed25519 / compact-ECDSA-secp256k1 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 the deployed and the 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 - instead the protocol was widened to accommodate the footprint (txMaxBroadcastSize raised to 16 KB and maxTxPacketSize to 256 KB per the 2026-04-10 weekly). No user-laggard decay-rate reporting. Scored 3/20: a non-zero floor only because the footprint is fully and precisely 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% 23 / 100
QRL's first-party wallets are PQ-native by construction: the QRL web wallet (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 hardware wallets support QRL XMSS addresses, with the QRL documentation recording the constraint directly - 'Ledger hardware memory limitations restrict the internal tree to this height' (h=8, 256 OTS keys) - and a fund-lock consequence once a tree's keys are exhausted. Scored well above a roadmap-only tile because the primary wallet IS quantum-safe rather than carrying a 'PQC roadmap'. The Trail of Bits go-qrllib assessment explicitly covered the wallet and legacy-wallet state-management paths, and its wallet-related findings (descriptor metadata not bound into signatures, SPHINCS+ accepted in wallet validation, security-critical XMSS signing warnings dropped by the wrapper API) were resolved and re-reviewed 2026-06-22; the 2026-08-07 weekly records qrl-wallet v1.9.1-beta in pre-release with 7 issues closed, an offline-wallet-generator v3 format with stronger encryption and password security, and qrl-cli moving to scrypt-derived AES-256-GCM encryption while retaining legacy-wallet-file compatibility. One point added for a third-party-audited wallet library plus dated first-party hardening. Not credited: QRL's own 2026-08-03 blog assertion about its web-wallet entropy sourcing, which no third party has examined. 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. Note on sourcing: the 2026-03-06 weekly's 'Ledger App integrated' line sits under the QRL Web3 (Zond) wallet, so it is not evidence for v1 XMSS Ledger support; the v1 Ledger constraint is sourced to the QRL documentation instead.
QRL is an isolated independent chain: we found no integration 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, 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. This is one of the three tiles that drive the Supply-Chain cap. Evidentiary note: this tile rests on an absence, established by not finding QRL on the vendors' public integration surfaces rather than by a vendor statement excluding it.
Minimal institutional-custody footprint. QRL was not found on Fireblocks, BitGo or 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). Evidentiary note: as with 6b, this tile rests on an absence rather than an affirmative vendor statement.
RPC is served by QRL Foundation nodes and community/mining-pool nodes - the published network panel reads 300 nodes, 312 miners and 12 pools as of 2026-08-19. The 2026-04-03 weekly describes qrl-infra phase 1 (automated AWS deployment plus monitoring and a spammer node for stress and load testing), and the 2026-05-15 weekly records CI/CD supply-chain hardening undertaken in light of supply-chain attacks elsewhere; the Trail of Bits engagement separately closed an unpinned-CI-action finding (TOB-QRLLIB-15) by pinning external GitHub action versions and adding Zizmor to CI. Ledger Nano HSM-line devices support QRL XMSS, 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 and infra all low, the dimension is held down 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% 43 / 100
QRL v1 uses RandomX PoW (CPU-optimized, ASIC/GPU-resistant, adopted via QIP 009) with community mining pools and solo mining. The QRL Foundation's published network panel reads 300 QRL nodes, 312 miners and 12 pools as of 2026-08-19, with the caveat that the statistics are pulled periodically and are not live. 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. A 300-node, 12-pool network with undocumented pool concentration supports limited decentralization credit.
Coordinated node upgrades since the June 2018 mainnet, no contested forks on QRL's own account, and a long multi-year Zond development cadence (devnet 2022 -> beta-testnet 2024 -> Testnet V1 2025 -> code freeze 2026-02-13 -> Testnet V2 2026-03-31), with the testnet stress-tested at 952 transactions per block at 21,000 gas per transaction (2026-04-24 weekly). 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 (CHE-229.731.700; press datelines 'ZUG, Switzerland' on 2026-03-31 and 2026-04-03), and a confirmed PKI Consortium member carrying the PQC working-group tag, listed as 'Die QRL Stiftung is a grant-awarding non-profit organisation that supports the development of post-quantum secure blockchain solutions' under the heading 'Supporting open-source post-quantum blockchain development'. Development is published continuously through dated weekly snapshots under a named author line (The QRL Core Contributors), and press, support and general contact addresses are published. Deduction: individual officers and a governance/decision procedure are not published alongside the entity.
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.
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 disagreed on the Zond launch signature scheme. A 2025-07-01 strategy post ('Embracing SPHINCS+: A Strategic Shift for QRL Project Zond') stated QRL was transitioning from stateful XMSS to SLH-DSA/SPHINCS+ (FIPS 205) to remove OTS-index tracking. More recent first-party sources consistently name ML-DSA-87 (FIPS 204, NIST Category 5) as primary at launch, with the hash-based scheme deferred. The decisive one is QRL's 2026-06-26 eight-year blog: 'the primary signature algorithm for QRL 2.0 is ML-DSA-87 (formerly Dilithium 5), a NIST-standardized post-quantum algorithm, integrated across the full stack, including go-qrllib, go-zond, Qrysm, and the deposit contracts.' The 2026-04-24 weekly independently confirms the library gate ('tightened Descriptor.IsValid() so only canonical ML-DSA-87 and SPHINCS+-256s wallet descriptors are accepted'), and go-qrllib's own standards notes state the wallet layer does not currently issue new SPHINCS+/SLH-DSA wallets and direct new wallets to ML-DSA-87. The 2026-03-31 Testnet V2 press release names no algorithm, referring only to 'NIST-approved post-quantum cryptographic primitives.' This evaluation follows ML-DSA-87 primary at mainnet launch, hash-based scheme post-mainnet. This disagreement remains a driver of the +-5 CI.
SPHINCS+-256s and SLH-DSA (FIPS 205) are not interchangeable names for QRL's hash-based stateless scheme. go-qrllib's own standards notes set out the difference: the implementation is the SPHINCS+ submission (pre-FIPS 205), specifically SHAKE-256s-robust (the non-simple tweakable-hash variant), and the library states that FIPS 205 differs from the SPHINCS+ submission in parameter-set details, that the wallet layer will not issue such wallets until QRL settles on a specific SLH-DSA parameter set, and that the parameter set may change once SLH-DSA is finalised for QRL. The implemented primitive is SPHINCS+-256s (SHAKE-256s-robust, the non-simple tweakable-hash variant, pre-FIPS-205 submission). QRL has no deployed or issuable SLH-DSA per FIPS 205. The primitive is deferred and non-issuable either way.
Some secondary sources and roadmap language frame 'Zond mainnet' as imminent or implied; primary QRL sources are explicit that mainnet is contingent on completion of the audit program after Testnet V2 (code freeze 2026-02-13, testnet launched 2026-03-31). The 2026-03-31 press release states plainly that 'mainnet launch is contingent on the successful completion of those audits' and gives no date. Re-checked 2026-08-19: the 2026-06-26 eight-year blog still describes QRL as being in 'the final phases of security audits' and mapping 'the road to mainnet'; the 2026-08-07 and 2026-08-14 weeklies show no launch and no 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 standards notes state 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 against the RFC 8391 reference in CI, while QRL-specific SHAKE-128 is non-RFC and NIST SP 800-208 refinements are intentionally not applied (adopting the SP 800-208 expand_seed change would alter the keypair derived from any seed and break v1 mainnet address compatibility). Trail of Bits independently confirms this: TOB-QRLLIB-1, 'XMSS implementation is not fully compliant with RFC 8391' (Low, resolved by rejecting unsupported parameter tuples). Accurate characterization: pre-RFC XMSS with partial RFC 8391 parameter overlap, not SP 800-208 compliant. This is a precision issue, not a demonstrated break; security properties are substantively similar to RFC 8391 for the overlapping parameter sets.
The Cryptographic-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 SPHINCS+-256s (a second hash-based scheme). 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: SHA2-256 (HF=0), SHAKE-128 (HF=1), SHAKE-256 (HF=2), and one address format (AF=0, 'SHA256 2X'). The QRL documentation's address-scheme page states verbatim: 'At the moment, only one address format is utilized, sha256 2X, however we support crypto-agility and the ability to later move to new hash schemes as the security landscape changes.' go-qrllib also exposes a QRL-specific non-RFC SHAKE-128 variant retained for compatibility, which Trail of Bits flagged as TOB-QRLLIB-7, 'SHAKE_128 is a non-compliant FIPS parameter with reduced quantum security' (Informational, resolved by documenting it as legacy-only and not recommended for new wallets). We therefore treat SHA2-256 as the deployed v1 mainnet hash; SHAKE variants are descriptor-reserved but not the deployed default. 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 mirroring Ethereum's post-Merge two-layer design (go-zond execution layer + qrysm consensus layer); QRL's own 2026-06-26 blog names go-zond and Qrysm as parts of the stack carrying ML-DSA-87. The repository name and Ethereum-derived beacon architecture strongly imply a fork of the Prysm client, and QRL weeklies repeatedly refer to merging 'upstream patches' into qrysm, 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 ('Securing Elliptic Curve Cryptocurrencies against Quantum Vulnerabilities: Resource Estimates and Mitigations', dated 2026-03-30, authored across Google Quantum AI, UC Berkeley, the Ethereum Foundation and Stanford). Verified against the paper itself. Its exact language: 'some blockchains, such as the Quantum Resistant Ledger (QRL), Mochimo and Abelian, rely exclusively on PQC'; and separately, 'the QRL launched in 2018 stands out as post-quantum from inception. Its original design was based on the stateful post-quantum signature scheme known as XMSS and it is currently adding support for the stateless post-quantum signature scheme called CRYSTALS-Dilithium and recently standardized by NIST under the name ML-DSA.' It does NOT use the phrase 'a presently post-quantum secure blockchain' - that wording originates in QRL's own Halborn-audit press release paraphrasing the paper, and the misattributed verbatim quote has been removed. No score change: the underlying corroboration holds, and the paper independently corroborates that Zond's ML-DSA support is still being added rather than deployed. Residual caution for cryptographers: the paper's statement is about QRL relying exclusively on PQC, not an independent audit of XMSS parameter security.
Verified directly against the auditor's own artifact. The 8-page public report is hosted on Trail of Bits' own public publications repository, titled 'The Quantum Resistant Ledger go-qrllib Library Security Assessment', dated July 8, 2026, prepared for Die QRL Stiftung by three named Trail of Bits consultants. Project timeline: kickoff 2026-04-06; review 2026-04-13 to 2026-04-22 (three engineer-weeks); draft readout 2026-04-23; final report 2026-05-13; final report with fix review 2026-07-08. Fix review dated 2026-06-22: 'of the 15 issues described in this report, The Quantum Resistant Ledger team has resolved all 15 issues.' Severity table: 1 High, 0 Medium, 4 Low, 10 Informational. Corroboration is two-sided (QRL press release plus the auditor's own channel), and the fix-commit hashes in the report's appendix match commits in go-qrllib's public history. Three precision points. First, Halborn's 2026-04-03 press release describes its scope as 'the two post-quantum digital signature packages at the heart of QRL's network, both implementing signature schemes approved by NIST as part of its post-quantum cryptography standardization process', which does not name XMSS and does not describe the stateful hash-based family standardized outside that process; there is no public evidence XMSS was ever in Halborn's scope. Second, the auditor's own framing is that 'the identified issues primarily affect the robustness of the exported cryptographic API rather than the correctness of the underlying primitives.' Third, this is a library-scope assessment of go-qrllib - integration of the library into other codebases was explicitly out of scope - and it is not the full-protocol/consensus audit; the '50% completion' figure for the wider audit program is QRL's own progress statement with no independent second source. No score rests on the 50% figure.
QRL's 2026-04-03 press release reports an independent Halborn audit finding no cryptographic vulnerabilities, with all 13 findings rated Informational and since resolved, and 'the core signing, verification and key generation logic validated as correct'. It describes the scope only as 'the two post-quantum digital signature packages at the heart of QRL's network, both implementing signature schemes approved by NIST as part of its post-quantum cryptography standardization process'. It does not name the two packages. Naming ML-DSA-87 as one of them is an inference, not a sourced fact, and is not carried. What is sourced: two NIST-PQC-standardization-process signature packages, 13 Informational findings, all resolved, and the full report stated to be available on the auditor's website (it was not publicly retrievable at that address). This constrains how much implementation-quality credit the Halborn artifact can carry for XMSS specifically: none.
A widely-cited QRL information site (the one carrying the Zond architecture and migration write-ups) is community-run, not a QRL Foundation property - it links out to the QRL official site as a separate destination. Claims resting only on it are weaker than the QRL Foundation's own blog, press releases, weeklies and documentation, which is what this card cites. One live contradiction is recorded: that site states SPHINCS+ is 'recognized at the wallet-descriptor level (canonical ML-DSA-87 and SPHINCS+-256s descriptors), with integration continuing toward and after mainnet', whereas go-qrllib's own standards notes state the wallet layer does not currently issue new SPHINCS+/SLH-DSA wallets and common wallet descriptor validation rejects the type, and Trail of Bits finding TOB-QRLLIB-4 ('Wallet allows SPHINCS+ as valid signature scheme') was resolved specifically by making SPHINCS+ invalid in wallet validation. We follow the library and the auditor. That site also carries promotional superlatives about QRL's operating record which this card does not adopt.
The QRL Foundation's published network-statistics panel read as follows on 2026-08-19: 4,225,792 block height at 60s blocktime, 2,485,330 transactions since genesis, 396,813,697.01 QRL volume since genesis, 19,714 wallets since genesis, 12 pools, 300 QRL nodes, 312 miners. A block height consistent with a 60-second interval since a June 2018 genesis is the reconstructible anchor, so secondary snapshots are treated as unreliable rather than merely stale. The panel itself carries the disclaimer 'Network statistics are pulled periodically and aren't live'. Sub-scores 3b, 6d and 7a rest on the published 300/312/12 figures. Cryptographers should treat any single reading of this panel as a point estimate, not a measured decentralization metric; QRL publishes no Nakamoto coefficient or pool-share distribution.
A 2026-08-03 QRL blog post ('Reflections on the COLDCARD RNG Exploit'), written in response to an unrelated hardware-wallet RNG bug in a Bitcoin-only device, asserts that QRL's v1 web-wallet seed generation has used 384 bits of OS-sourced entropy since 2018 and fails closed rather than degrading. No third-party audit of that specific entropy path was located; the Trail of Bits scope covered go-qrllib's XMSS and ML-DSA implementations, exported API boundary and wallet state-management paths, not browser wallet entropy sourcing. We record the post as a self-claim and credit no sub-score on it.
Delta-QRI under alternative weighting
QRL is sensitive to the Deployment-vs-Supply-Chain weight split because its Dim 5 (72) and Dim 6 (23) sit far apart. Under an alternative weighting that down-weights Deployment and up-weights Supply Chain (Dim 5 -> 12%, Dim 6 -> 32%, all other weights unchanged), QRI falls to ~49 (Band 5). Under a weighting that credits shipped-mainnet PQC more heavily (Dim 5 -> 30%, Dim 6 -> 14%, all other weights unchanged), QRI rises to ~58 (top of Band 6). The L1-default weighting (Dim 1 15%, Dim 2 10%, Dim 3 13%, Dim 4 10%, Dim 5 22%, Dim 6 22%, Dim 7 8%) yields a weighted total of 53.6, reported as QRI 54. The down-weighted figure is arithmetically ~49; both alternative weightings are stated explicitly so the numbers are reproducible.
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. The 2026-08-04 Trail of Bits announcement introduces no new primitive claim (XMSS and ML-DSA only) and is backed by merged remediation commits whose hashes match the fix-review appendix of the auditor's own report, so the count is unchanged. 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.