Quantum Resistant Ledger QRL

Claim: QRL is PQ-native with XMSS from genesis. Whitepaper, documentation, and GitHub provide full cryptographic inventory. No classical native ownership namespace exists.

Coverage basis: PQ-native native asset; complete-by-design

Implementation score: 1 · Evidence confidence: High

Issue classification: none · Score treatment: not applicable

Assurance: Documentation and whitepaper are public and comprehensive. Open-source code repository confirms XMSS-only signature scheme.

• https://docs.theqrl.org/what-is-qrl
• https://github.com/theQRL/QRL
• https://github.com/theQRL/Whitepaper/blob/master/QRL_whitepaper.pdf

Claim: Multiple independent audits (Red4Sec, x41 D-Sec, Halborn), open-source code, mainnet explorer, and NIST standardization provide public evidence.

Coverage basis: PQ-native native asset; complete-by-design

Implementation score: 1 · Evidence confidence: High

Issue classification: none · Score treatment: not applicable

Assurance: Multiple audits across different auditors and timeframes. Halborn (2026) is current for crypto library. Red4Sec and x41 D-Sec (2018) are stale but relevant for mainnet XMSS design.

• https://github.com/theQRL/audits
• https://www.theqrl.org/blog/red4sec-security-audit-concludes-a-summary/
• https://medium.com/the-quantum-resistant-ledger/x41-d-sec-audit-79d5243f0874
• https://www.halborn.com/audits/qrl-quantum-resistant-ledger/qrl-quantum-resistant-ledger-37d3f1
• https://explorer.theqrl.org/

Claim: All native QRL transactions use XMSS (NIST-approved, IETF-specified) hash-based post-quantum signatures. No ECDSA, EdDSA, BLS, or Schnorr signatures exist for native spend authorization.

Coverage basis: PQ-native; mandatory XMSS from genesis block

Implementation score: 1 · Evidence confidence: High

Issue classification: none · Score treatment: not applicable

Assurance: XMSS implementation is open-source and verifiable. Audited by x41 D-Sec (2018) specifically for XMSS cryptography and Ledger code. Mainnet blocks since June 2018 confirm XMSS-only signatures.

• https://docs.theqrl.org/what-is-qrl
• https://github.com/theQRL/QRL
• https://github.com/theQRL/QRL/blob/master/src/qrl/crypto/xmss.py
• https://www.theqrl.org/

Claim: QRL addresses use an extensible address format with XMSS public keys built in from genesis. No classical address types or key-derivation paths exist. No long-exposure ECC public keys are present on the native chain.

Coverage basis: PQ-native; XMSS-based address format only

Implementation score: 1 · Evidence confidence: High

Issue classification: none · Score treatment: not applicable

Assurance: Address format is documented as 'extensible address format with quantum security built in from the genesis block.' No classical address namespace exists on the native chain.

XMSS public keys embedded in addresses are hash-based and quantum-resistant. No ECC public-key exposure exists for native accounts.

• https://docs.theqrl.org/what-is-qrl
• https://www.theqrl.org/
• https://github.com/theQRL/QRL

Claim: QRL mainnet uses Proof-of-Work (cryptonight, later upgraded to randomX via QIP-009). No validator signatures, BLS threshold signatures, VRFs, or finality signatures exist in the consensus mechanism.

Coverage basis: PoW consensus; no validator authentication applicable

Implementation score: 1 · Evidence confidence: High

Issue classification: none · Score treatment: not applicable

Assurance: PoW consensus is hash-based and not vulnerable to Shor's algorithm. RandomX (upgraded from cryptonight) was audited by x41 D-Sec. The consensus mechanism does not rely on quantum-vulnerable digital signatures.

• https://github.com/theQRL/QRL
• https://github.com/theQRL/qryptonight
• https://www.theqrl.org/qips/qip009/
• https://medium.com/the-quantum-resistant-ledger/get-ready-for-qrl-launch-b078963d035e

Claim: QRL uses hash-based state commitments. No KZG commitments, pairing-based proofs, or quantum-vulnerable accumulators are used in the protocol. Supply integrity is bound by hash-based signatures and Merkle tree structures.

Coverage basis: Hash-based state; no pairing/KZG dependencies

Implementation score: 1 · Evidence confidence: High

Issue classification: none · Score treatment: not applicable

Assurance: QRL's state integrity relies on hash-based Merkle trees and XMSS signatures. No quantum-vulnerable pairing or KZG assumptions exist. Quantum computers cannot break hash preimage resistance at a scale that threatens chain integrity.

• https://github.com/theQRL/QRL
• https://docs.theqrl.org/what-is-qrl
• https://github.com/theQRL/Whitepaper/blob/master/QRL_whitepaper.pdf

Claim: QRL is a transparent ledger with no shielded transaction privacy layer, ZK proofs, note encryption, viewing keys, or stealth addresses. The ephemeral messaging layer uses Dilithium and Kyber but is not a transactional privacy layer.

Coverage basis: Not applicable - no privacy layer

Implementation score: 1 · Evidence confidence: High

Issue classification: none · Score treatment: not applicable

QRL does support ephemeral messaging using Dilithium and Kyber, but this is not a privacy layer for transaction shielding.

• https://www.theqrl.org/
• https://medium.com/the-quantum-resistant-ledger/get-ready-for-qrl-launch-b078963d035e
• https://docs.theqrl.org/node/configuration/

Claim: QRL's P2P layer for node discovery and peer communication currently uses classical cryptography. Node identity in the P2P mesh is not spend-authorization, consensus, bridge, or custody-critical.

Coverage basis: Satisfied by design; P2P identity not asset-critical

Implementation score: 1 · Evidence confidence: High

Issue classification: operational/product caveat · Score treatment: note-only

Assurance: P2P classical cryptography could theoretically enable eclipse or DoS attacks by a quantum adversary, but such attacks cannot forge transactions, steal assets, or compromise consensus finality. ML-KEM integration is planned as a defense-in-depth improvement.

QRL Weekly (2026-May-15) states: 'ML-KEM implementation has begun, it will be used in P2P layer.' This confirms the current P2P layer has not yet been upgraded to PQC but also that the project is actively addressing this as a non-critical enhancement.

• https://docs.theqrl.org/node/configuration/
• https://www.theqrl.org/weekly/2026-may-15/
• https://github.com/theQRL/QRL

Claim: QRL supports XMSS-based wallets on web, desktop (Windows/Mac/Linux), mobile (iOS/Android), and Ledger hardware wallets (Nano S, Nano X, Nano S+). All custody paths use PQ-secure XMSS signatures.

Coverage basis: PQ-native; all wallet paths use XMSS

Implementation score: 1 · Evidence confidence: High

Issue classification: none · Score treatment: not applicable

Assurance: Ledger hardware wallet support for a stateful PQ signature scheme (XMSS) is a significant operational achievement. The x41 D-Sec audit (2018) covered Ledger code specifically.

• https://www.theqrl.org/
• https://docs.theqrl.org/use/wallet/overview
• https://docs.theqrl.org/use/wallet/ledger/overview/
• https://support.ledger.com/article/360019184453-zd

Claim: QRL is PQ-native. 100% of native QRL value-at-risk is protected by XMSS from genesis. No classical native ownership namespace exists. The legacy ERC-20 token is a separate scope with no active bridge to native QRL.

Coverage basis: PQ-native; complete-by-design; ≥99% native coverage

Implementation score: 1 · Evidence confidence: High

Issue classification: none · Score treatment: not applicable

Assurance: Mainnet explorer (explorer.theqrl.org) confirms active block production (block height > 2.5M as of 2026). Emission at approximately 74% of max supply (78.3M of 105M). All on-chain value is PQ-protected by construction.

Exact percentage of unmigrated ERC-20 tokens is not independently verified but does not affect native QRL scope. Even 100% unmigrated ERC-20 tokens would represent a separate legacy artifact, not native QRL value-at-risk.

• https://docs.theqrl.org/what-is-qrl
• https://www.theqrl.org/markets/
• https://explorer.theqrl.org/
• https://medium.com/the-quantum-resistant-ledger/automatic-token-migration-complete-15f9b8b9b9b9

Claim: All native QRL wallets (treasuries, exchanges, custodians, foundations) use XMSS addresses. The protocol design prevents creation or import of classical-vulnerable native addresses.

Coverage basis: PQ-native; all native wallets are XMSS-based by protocol requirement

Implementation score: 1 · Evidence confidence: Medium

Issue classification: none · Score treatment: not applicable

Assurance: Medium confidence because specific exchange/custodian attestations are not individually documented in available evidence. However, the protocol-level enforcement (only XMSS addresses can hold native QRL) makes classical custody impossible by construction.

• https://docs.theqrl.org/what-is-qrl
• https://www.theqrl.org/markets/

Claim: No classical-vulnerable native QRL addresses, UTXOs, or accounts exist. The ERC-20 token is a separate legacy artifact that has been migrated/burned. No active bridge links ERC-20 to native QRL.

Coverage basis: PQ-native; legacy classical namespace proven not to exist by design

Implementation score: 1 · Evidence confidence: High

Issue classification: none · Score treatment: not applicable

Assurance: Multiple official sources confirm QRL is an independent L1 blockchain, not an ERC-20 token. The EnQlave/wQRL project has been retired. No active bridge or two-way wrapper to Ethereum or any quantum-vulnerable system exists for native QRL as of the evaluation date.

• https://docs.theqrl.org/what-is-qrl
• https://www.theqrl.org/markets/
• https://medium.com/the-quantum-resistant-ledger/automatic-token-migration-complete-15f9b8b9b9b9
• https://www.theqrl.org/blog/announcing-ethereum-enqlave-quantum-security-for-the-ethereum-blockchain/
• https://www.theqrl.org/blog/an-update-on-enqlave/

Claim: QRL is PQ-native; ECC-to-PQC migration is not applicable. The QRL 1.x to QRL 2.0 (Zond) upgrade is a PQ-to-PQ transition with a published roadmap and active testnet.

Coverage basis: PQ-native for ECC migration; documented PQ-to-PQ upgrade path

Implementation score: 1 · Evidence confidence: High

Issue classification: none · Score treatment: not applicable

Assurance: QRL 2.0 Testnet V2 is live as of March 2026. The migration process (snapshot, smart contract, user-initiated claim) is documented in draft form in community AMAs. Mainnet launch date is TBD pending audit completion.

• https://www.theqrl.org/roadmap/
• https://www.theqrl.org/blog/qrl-2.0-building-the-bridge-to-the-next-era/
• https://www.theqrl.org/press/qrl-launches-testnet-v2-for-its-postquantum-evmfriendly-blockchain/

Claim: PQ-native by design. All native account creation produces XMSS-based addresses by default. Wallet tooling (web, desktop, mobile, Ledger) supports only XMSS. No classical account creation path exists.

Coverage basis: PQ-native; PQ accounts are default and only option

Implementation score: 1 · Evidence confidence: High

Issue classification: none · Score treatment: not applicable

Assurance: Multiple wallet platforms (web, desktop, mobile, Ledger hardware) all use XMSS exclusively. No fallback to classical key formats exists in any supported wallet.

• https://docs.theqrl.org/use/wallet/overview
• https://docs.theqrl.org/use/wallet/ledger/overview/
• https://www.theqrl.org/

Claim: PQ-native by design. The protocol enforces XMSS-only signatures. No vulnerable signing path exists to deprecate, freeze, or disable. No coordination needed to prevent unsafe fallback into classical systems.

Coverage basis: PQ-native; protocol-enforced XMSS-only; no vulnerable fallback exists

Implementation score: 1 · Evidence confidence: High

Issue classification: none · Score treatment: not applicable

Assurance: Protocol-level enforcement is verifiable from source code. No bridge or wrapper contracts are active for the evaluated native scope.

• https://github.com/theQRL/QRL
• https://docs.theqrl.org/what-is-qrl

Claim: QRL has published security contacts and has demonstrated responsiveness to external audit findings across multiple engagements. No formal quantum-specific incident-response playbook is publicly documented.

Coverage basis: General security process; no published quantum-specific IR playbook

Implementation score: 1 · Evidence confidence: Medium

Issue classification: assurance-only caveat · Score treatment: confidence-only

Assurance: QRL has security contacts (support@theqrl.org, press@theqrl.org) and has demonstrated responsive remediation of audit findings. The Halborn audit (2026) noted 'seamless' collaboration and that all findings were addressed. However, no formal quantum-specific incident-response playbook, vulnerability disclosure policy, or emergency governance process for cryptographic breaks is publicly documented. Per QRI Section 7.4, this is a note-only caveat because the absence of a formal playbook does not create a current quantum-vulnerable path. For PQ-native assets, lack of formal IR playbook should not reduce QRI Score per QRI Section 7.1.

The QRL Improvement Proposal (QIP) process and on-chain voting mechanism (developed 2021) provide governance infrastructure that could be leveraged for quantum-related decisions.

• https://www.theqrl.org/
• https://www.theqrl.org/blog/red4sec-security-audit-concludes-a-summary/
• https://www.theqrl.org/press/halborn-audit-validates-qrls-postquantum-cryptography-library/

Claim: QRL mainnet uses XMSS, which is NIST-approved (NIST SP 800-208) and IETF-specified. The QRL 2.0 crypto library (qrypto.js) implements ML-DSA-87 (FIPS 204). Ephemeral messaging uses Dilithium and Kyber.

Coverage basis: NIST-standardized XMSS for all mainnet signatures; ML-DSA-87 in crypto library

Implementation score: 1 · Evidence confidence: High

Issue classification: none · Score treatment: not applicable

Assurance: XMSS was approved by NIST as a post-quantum signature standard (NIST SP 800-208). ML-DSA-87 (FIPS 204) is validated in the Halborn-audited qrypto.js library. Ephemeral messaging uses NIST round-3/standardized candidates.

XMSS (stateful hash-based) and ML-DSA-87 (lattice-based) are both NIST-approved post-quantum standards. No bespoke or weakly reviewed algorithms are used.

• https://docs.theqrl.org/what-is-qrl
• https://www.theqrl.org/
• https://www.halborn.com/audits/qrl-quantum-resistant-ledger/qrl-quantum-resistant-ledger-37d3f1
• https://csrc.nist.gov/publications/detail/sp/800-208/final

Claim: Three independent audits: Red4Sec (2018, 7 weeks, 67 findings), x41 D-Sec (2018, XMSS cryptography focus), Halborn (March 2026, qrypto.js library, 13 informational findings, zero cryptographic vulnerabilities).

Coverage basis: Multiple independent audits across codebase, cryptography, and library

Implementation score: 1 · Evidence confidence: High

Issue classification: assurance-only caveat · Score treatment: confidence-only

Assurance: Halborn (2026) is current for the qrypto.js library covering ML-DSA-87 and Dilithium5. Red4Sec and x41 D-Sec (2018) are stale but relevant for the mainnet XMSS implementation. The XMSS cryptographic design has not changed and is independently verifiable via NIST standardization. The Halborn audit found zero cryptographic vulnerabilities and included a 2.4M-input fuzzing campaign with zero false accepts. Per QRI Section 6.4: 'Stale but relevant audit of the same quantum-critical design: No QRI deduction by itself. Confidence normally capped at Medium unless other current review exists.' The current Halborn audit for the crypto library partially offsets the staleness of the 2018 audits, but the current mainnet node codebase has not undergone a recent end-to-end independent audit.

The Halborn audit scope covers the qrypto.js JavaScript library (ML-DSA-87/Dilithium5), which is intended for QRL 2.0, not the current Python-based QRL 1.x mainnet node directly. The 2018 audits covered the current mainnet codebase comprehensively but are 8 years old. The mainnet XMSS implementation is open-source and verifiable.

• https://github.com/theQRL/audits
• https://www.theqrl.org/blog/red4sec-security-audit-concludes-a-summary/
• https://medium.com/the-quantum-resistant-ledger/x41-d-sec-audit-79d5243f0874
• https://www.halborn.com/audits/qrl-quantum-resistant-ledger/qrl-quantum-resistant-ledger-37d3f1
• https://www.theqrl.org/press/halborn-audit-validates-qrls-postquantum-cryptography-library/

Claim: QRL core node, wallet, explorer, and cryptography libraries are all open-source under MIT License. Available on GitHub with active commit history. Latest release: v4.0.6 (March 2026).

Coverage basis: MIT-licensed open-source; public GitHub repositories

Implementation score: 1 · Evidence confidence: High

Issue classification: none · Score treatment: not applicable

Assurance: The QRL GitHub organization contains 80+ repositories. Core node repository has 30 contributors, 71 releases, and active maintenance (latest release v4.0.6, March 2026). The Halborn audit noted that build artifact reproducibility should be improved (committed dist files don't match fresh rebuild), but this is an informational finding that has been addressed.

• https://github.com/theQRL/QRL
• https://github.com/theQRL/block-explorer
• https://github.com/theQRL/qryptonight
• https://github.com/theQRL/audits

Claim: QRL's address format includes cryptographic descriptors enabling future algorithm upgrades. The QRL 2.0 roadmap includes ML-DSA-87 at launch with SPHINCS+ post-mainnet. XMSS tree height is configurable.

Coverage basis: Extensible address format documented; crypto-agile design

Implementation score: 1 · Evidence confidence: High

Issue classification: none · Score treatment: not applicable

Assurance: Extensible address format with cryptographic descriptors was implemented before mainnet launch. QRL 2.0 address format includes 3-byte cryptographic descriptors and 'Q' prefix. The project explicitly states 'Because the QRL 2.0 address model is inherently crypto-agile, SLH-DSA, and other future signature algorithms, can be seamlessly integrated after the network is live.'

• https://docs.theqrl.org/what-is-qrl
• https://www.theqrl.org/roadmap/
• https://www.theqrl.org/blog/qrl-2.0-building-the-bridge-to-the-next-era/
• https://github.com/theQRL/QRL

Claim: XMSS is a stateful signature scheme requiring OTS index tracking. QRL wallets track OTS state, display remaining signatures, and the block explorer shows OTS usage. Ledger hardware wallet integration provides hardware-level protection for signing state.

Coverage basis: Stateful XMSS with wallet-based OTS tracking; Ledger hardware support

Implementation score: 0.75 · Evidence confidence: High

Issue classification: operational/product caveat · Score treatment: score-reducing

Assurance: OTS index tracking is a known operational requirement for XMSS. QRL wallet tooling and block explorer provide OTS visualization. However, users can exhaust their OTS keys without creating a replacement, leading to permanent loss of signing capability for that address. This is not a quantum-attack vulnerability (quantum computers cannot exploit OTS statefulness to forge signatures) but it is an operational risk. QRL 2.0 plans to introduce stateless SPHINCS+ (SLH-DSA) to eliminate this concern.

Scored at 0.75 rather than 1.00 because XMSS statefulness creates a real operational risk of permanent fund lockup if OTS keys are exhausted without a replacement wallet. This is mitigated by wallet software and documentation, but the risk remains inherent to the stateful signature scheme. The QRI spec (Section 9.5) specifically calls out 'stateful-signature safety' including 'anti-reuse controls and signing-state discipline for XMSS/LMS-style schemes' as a scorable subfactor.

• https://docs.theqrl.org/use/tools/explorer/overview
• https://docs.theqrl.org/use/wallet/ledger/overview/
• https://github.com/theQRL/QRL
• https://www.reddit.com/r/QRL/comments/7eqwz3/

Claim: QRL documentation acknowledges XMSS transaction sizes (~3KB), longer key generation times, and larger signature sizes compared to ECDSA. The QRL GitHub README explicitly documents these characteristics.

Coverage basis: Documented performance characteristics; no independent formal benchmark

Implementation score: 1 · Evidence confidence: Medium

Issue classification: assurance-only caveat · Score treatment: confidence-only

Assurance: The GitHub README states: 'Hash-based signatures means larger transactions (3kb per tx, binary), longer keypair generation times and the need to record state of transactions.' No formal independent performance benchmark has been published. The network has been operating since 2018 with approximately 900 active nodes globally, demonstrating practical viability. Per QRI Section 7.4, lack of a formal performance benchmark is a note-only caveat unless resource constraints prevent safe use of the PQ path, which is not the case here.

• https://github.com/theQRL/QRL
• https://docs.theqrl.org/what-is-qrl