Post-quantum L1 chain
Quantum Resistant Ledger QRL
QRL mainnet is a post-quantum-native Proof-of-Work chain whose native addresses and transactions use mandatory XMSS hash-based signatures. Documentation, protocol definitions, source code, and mainnet observations support that no classical native ownership namespace or fallback transaction path exists. Native-asset migration is therefore complete by design, including for critical on-chain wallets. Proof-of-Work does not introduce validator-signature authentication, and no current quantum-vulnerable bridge, proof system, or other critical dependency was identified in the supplied record. Overall confidence is Medium because production XMSS audit coverage is old, the recent audit concerns future ML-DSA libraries, and detailed state-integrity and P2P documentation was not supplied. These gaps remain assurance limitations rather than identified current quantum-critical blockers.
PQ-NativePQ-ResistantMigration Complete by DesignHash-Based Signatures (XMSS)PoW L1
Category breakdown
QRI Factors
Algorithm & Implementation Assurance
18.5 / 20
Migration Mechanism, Governance & Ecosystem Coordination
15 / 15
Migration Status & Value-at-Risk
25 / 25
Production Cryptographic Protection
35 / 35
Security Assessment & Evidence Preparedness
5 / 5
Critical Quantum Blockers
- None identified for this report scope.
Key Risks
- XMSS signing requires reliable OTS-index state management; signer-state reuse or rollback can compromise an affected wallet even though it does not create a classical quantum-vulnerable fallback.
- Detailed documentation of current state-integrity, supply-binding, data-availability, and P2P mechanisms is limited, so these layers merit additional public review despite no identified quantum-vulnerable dependency.
- Any production deployment of Project Zond should be reassessed for PoS validator authentication, EVM account ownership, state commitments, bridges, and migration of existing XMSS-controlled accounts.
Assurance Notes
- Mandatory XMSS spend authorization and the absence of a classical native ownership namespace are supported by protocol documentation, public code, address definitions, mainnet explorer evidence, and historical independent review.
- Audit coverage is mixed. Historical core and XMSS reviews are stale but relevant, while the 2026 Halborn audit covers ML-DSA/Dilithium libraries rather than the production XMSS mainnet implementation.
- The supplied record does not directly document all current state-integrity, supply-binding, and data-availability mechanisms or their quantum assumptions. This limits confidence but, absent evidence of a vulnerable commitment or critical dependency, does not establish a current quantum-critical blocker or readiness cap.
- Current P2P identity and transport cryptography are not documented in detail. Under the QRI satisfied-by-design rule, this does not reduce readiness because peer identity is not evidenced as consensus-, spend-, bridge-, or custody-critical on the evaluated PoW chain and transactions are independently XMSS-authorized.
- No formal performance benchmark or dedicated quantum-specific incident-response playbook was supplied. These are assurance gaps rather than score-reducing quantum vulnerabilities.
- Project Zond is a future PQ-to-PQ transition outside current production scope. Its PoS validator authentication, EVM dependencies, and account transition require reassessment before production deployment.
- Canonical sources disagree on historical/current PoW algorithm naming, but both identify hash-based Proof-of-Work without validator-signature authentication; the discrepancy has no identified quantum-readiness impact.
Non-Scoring Caveats
- XMSS is stateful. Reusing an OTS index or restoring inconsistent signer state can irreversibly compromise the affected key; safe wallet and custody operation requires durable index persistence.
- The legacy Ethereum ERC-20 contract is a separate token-inheritance scope. More than 99% migration is reported, but the exact economically active residual balance is unresolved and nominal token-tracker supply must not be treated as vulnerable native QRL value.
- No active two-way bridge or unrestricted redeemable path exposing native QRL to the legacy Ethereum representation was identified in the supplied evidence.
- Historical core and XMSS audits are stale; the current Halborn review is scope-mismatched to production XMSS.
- Hash-based signatures produce approximately 3 kB transactions, but no formal current benchmark covering verification throughput, mempool effects, or archival growth was supplied.
- Current P2P identity/transport details and explicit state-integrity documentation were not supplied, although no related quantum-enabled path to asset theft, forgery, inflation, or consensus compromise was identified.
- No formal quantum-specific emergency-response playbook was identified.
- Future Project Zond properties neither establish nor detract from protection of the current production mainnet.
Evidence record
Claims and Caveats
Security Assessment & Evidence Preparedness
Public cryptographic inventory and quantum threat model
Claim: QRL publicly identifies XMSS/WOTS+ and associated hash and tree parameters as the native ownership mechanism and explains the quantum threat motivating its design.
Coverage basis: PQ-native preparedness supported by official documentation, the original whitepaper, protocol definitions, and implementation artifacts.
Implementation score: 1 · Evidence confidence: Medium
Issue classification: none · Score treatment: not applicable
Assurance: Evidence is distributed across documentation, code, and the whitepaper rather than consolidated into one formal layered inventory and threat model.
The record is strongest for ownership cryptography and less detailed for state-integrity and transport mechanisms.
Security Assessment & Evidence Preparedness
Public evidence record supporting the assessment
Claim: A public evidence record supports QRL's native XMSS design and production use.
Coverage basis: Official documentation, protocol definitions, source code, live mainnet observations, and independent-review references are publicly inspectable.
Implementation score: 1 · Evidence confidence: High
Issue classification: none · Score treatment: not applicable
Assurance: Audit recency is mixed, but current code and mainnet evidence independently support the central production claim.
Evidence coverage is weaker for P2P and state-integrity details.
Production Cryptographic Protection
Spend authorization / transaction signatures
Claim: Native mainnet spending is authorized exclusively with XMSS post-quantum signatures.
Coverage basis: Mandatory production path verified through documentation, protocol definitions, implementation code, and mainnet explorer observations.
Implementation score: 1 · Evidence confidence: High
Issue classification: none · Score treatment: not applicable
Assurance: Historical XMSS reviews are stale but relevant; current code and mainnet observations corroborate production use.
Future ML-DSA support is not required for current XMSS protection.
Production Cryptographic Protection
Account, address, public-key exposure, and key derivation
Claim: Native account and address design avoids classical long-exposure and on-spend public-key recovery paths.
Coverage basis: Address descriptors encode XMSS parameters, and observed native accounts and transactions use XMSS rather than classical public-key signatures.
Implementation score: 1 · Evidence confidence: High
Issue classification: none · Score treatment: not applicable
Assurance: OTS-index management remains an operational requirement but is not a classical public-key exposure path.
Production Cryptographic Protection
Consensus-critical authentication
Claim: The evaluated mainnet uses Proof-of-Work and has no validator, VRF, threshold-signature, or signed-finality authentication layer.
Coverage basis: Production sources identify hash-based Proof-of-Work block selection without validator public-key authentication.
Implementation score: 0 · Evidence confidence: High
Issue classification: none · Score treatment: not applicable
Assurance: The conclusion does not apply to future Project Zond PoS. Sources differ on PoW algorithm naming, but both support the absence of validator-signature consensus.
Production Cryptographic Protection
State-integrity and data-availability mechanisms
Claim: No quantum-vulnerable state-integrity, supply-binding, data-availability, pairing, or commitment dependency was identified, but the supplied record does not directly inventory all such mechanisms.
Coverage basis: The open-source production node and protocol definitions provide implementation evidence, while detailed cryptographic documentation for this layer is incomplete.
Implementation score: 1 · Evidence confidence: Low
Issue classification: assurance-only caveat · Score treatment: confidence-only
Assurance: No vulnerable pairing, trusted setup, commitment, bridge verification, or supply-binding path is evidenced. Direct documentation and audit coverage of this layer should be improved.
The absence of detailed documentation lowers confidence but does not establish a current quantum-critical vulnerability or unverifiable claimed mechanism requiring a cap.
Production Cryptographic Protection
Privacy and proof layers
Claim: The evaluated production mainnet is a transparent ledger without an identified shielded privacy or zero-knowledge proof layer.
Coverage basis: Protocol definitions and explorer behavior show transparent addresses and transactions, with no identified shielded pool, note system, nullifiers, viewing keys, or ZK settlement layer.
Implementation score: 0 · Evidence confidence: Low
Issue classification: none · Score treatment: not applicable
Assurance: The architectural absence is inferred from the supplied protocol and explorer record rather than an explicit privacy-layer declaration.
Any later privacy or proof layer would require separate assessment.
Production Cryptographic Protection
P2P transport, node identity, and peer authentication
Claim: P2P identity and transport are not evidenced as dependencies for native spending, block authorization, bridge settlement, or custody on the current PoW mainnet.
Coverage basis: Open-source PoW networking is evidenced, while asset authorization is independently enforced through mandatory XMSS transaction validation.
Implementation score: 1 · Evidence confidence: Low
Issue classification: assurance-only caveat · Score treatment: confidence-only
Assurance: Exact transport and node-identity cryptography was not supplied and should be documented; no current quantum-enabled asset-compromise path through it was identified.
Production Cryptographic Protection
Critical wallet, custody, HSM, signer, and hardware-wallet workflows
Claim: Production wallets and a dedicated Ledger application support native XMSS signing and stateful key operation.
Coverage basis: Official wallet documentation, signer-library persistence requirements, and Ledger support cover the mandatory production signature path.
Implementation score: 1 · Evidence confidence: High
Issue classification: operational/product caveat · Score treatment: note-only
Assurance: Safe custody depends on durable OTS-index persistence. Institution-specific HSM or exchange attestations were not supplied, but classical on-chain custody is unavailable by design.
OTS reuse is a serious signer-state hazard rather than an evidenced quantum-specific fallback.
Migration Status & Value-at-Risk
Percentage of economically relevant value-at-risk protected
Claim: Native QRL value is protected by mandatory XMSS ownership, with no classical native balance class requiring migration.
Coverage basis: PQ-native complete-by-design coverage for the native asset; the legacy ERC-20 representation is separate Ethereum token-inheritance scope.
Implementation score: 1 · Evidence confidence: High
Issue classification: none · Score treatment: not applicable
Assurance: The exact residual ERC-20 value is unresolved but does not establish vulnerable native-mainnet value.
Coverage applies only to native QRL on the evaluated mainnet.
Migration Status & Value-at-Risk
Critical wallets migrated, protected, or inherently PQ-native
Claim: Treasuries, exchanges, custodians, foundations, and other critical native holders must use XMSS for on-chain control.
Coverage basis: The protocol does not permit a classical native account path, and Ledger hardware-wallet support exists for XMSS custody.
Implementation score: 1 · Evidence confidence: High
Issue classification: none · Score treatment: not applicable
Assurance: Institution-specific operational attestations were not supplied, but QRI does not require them where classical on-chain custody is impossible.
Migration Status & Value-at-Risk
Legacy vulnerable pools identified, measurable, deprecated, migrated, frozen, or absent by design
Claim: No classical ownership pool exists within native QRL mainnet; the residual ERC-20 contract is separate from native scope and subject to a documented burn migration.
Coverage basis: The native chain was XMSS-based from genesis, while migration sources report that more than 99% of the legacy ERC-20 supply migrated through a one-way burn process.
Implementation score: 1 · Evidence confidence: High
Issue classification: operational/product caveat · Score treatment: note-only
Assurance: The exact active residual ERC-20 balance is unresolved and must not be inferred from nominal token-tracker supply.
No active two-way bridge or unrestricted native redemption path was identified.
- https://etherscan.io/token/0x697beac28B09E122C4332D163985e8a73121b97F
- https://www.theqrl.org/blog/qrl-primary-report-2024/QRL_Primary_Report_2024.pdf
- https://medium.com/the-quantum-resistant-ledger/qrl-token-migration-begins-b0d5b53f697f
- https://etherscan.io/token/0x697beac28b09e122c4332d163985e8a73121b97f
Migration Mechanism, Governance & Ecosystem Coordination
Public migration or protection roadmap
Claim: No ECC-to-PQC migration roadmap is required for the current native asset because mandatory PQ ownership has existed from genesis; a public QIP process and future PQ-to-PQ upgrade direction are documented.
Coverage basis: PQ-native complete-by-design treatment, supplemented by public governance and Project Zond roadmap materials.
Implementation score: 1 · Evidence confidence: Medium
Issue classification: none · Score treatment: not applicable
Assurance: Project Zond is roadmap evidence only and receives no current production-protection credit.
Migration Mechanism, Governance & Ecosystem Coordination
Migration accessibility and defaults
Claim: PQ account creation and transaction signing are mandatory defaults for all native users.
Coverage basis: Wallet documentation, address definitions, production code, and mainnet observations show only XMSS native accounts and transactions.
Implementation score: 1 · Evidence confidence: High
Issue classification: none · Score treatment: not applicable
Assurance: XMSS statefulness affects key-management usability but does not make the PQ path optional.
Migration Mechanism, Governance & Ecosystem Coordination
Migration enforcement and ecosystem coordination
Claim: Protocol validation prevents native fallback to classical signatures, enforcing PQ protection without participant-by-participant migration coordination.
Coverage basis: Address descriptors and transaction validation support only XMSS-based native authorization.
Implementation score: 1 · Evidence confidence: High
Issue classification: none · Score treatment: not applicable
Assurance: No active bridge exposing native QRL to a non-PQ ownership system was identified.
Migration Mechanism, Governance & Ecosystem Coordination
Emergency disclosure, incident response, or quantum governance
Claim: A public QIP process provides a governance path for protocol and cryptographic parameter changes.
Coverage basis: Formal improvement-proposal workflow is evidenced; no dedicated quantum-specific emergency-response playbook was supplied.
Implementation score: 1 · Evidence confidence: Medium
Issue classification: assurance-only caveat · Score treatment: confidence-only
Assurance: The absence of a dedicated quantum-specific incident-response playbook is a non-scoring assurance caveat because no current vulnerable fallback depends on it.
Algorithm & Implementation Assurance
Standardized, standards-track, or broadly reviewed PQC algorithm selection
Claim: Production QRL uses standardized, broadly reviewed XMSS hash-based signatures appropriate for post-quantum transaction authorization.
Coverage basis: IETF/NIST-aligned XMSS and WOTS+ are documented and implemented in open-source production libraries.
Implementation score: 1 · Evidence confidence: High
Issue classification: none · Score treatment: not applicable
Assurance: The current Halborn audit concerns ML-DSA rather than production XMSS, but XMSS is standardized and historically reviewed.
No hybrid classical dependency is required because no classical fallback exists.
Algorithm & Implementation Assurance
Independent cryptographic and implementation audit
Claim: Independent reviews exist for QRL core and post-quantum cryptographic components.
Coverage basis: The audit repository contains historical general and PQ-cryptography reviews; a 2026 Halborn review covers ecosystem ML-DSA/Dilithium libraries.
Implementation score: 1 · Evidence confidence: Medium
Issue classification: assurance-only caveat · Score treatment: confidence-only
Assurance: Historical XMSS/core audits are stale but relevant. The current ML-DSA audit is scope-mismatched to the evaluated production XMSS path.
Audit age and scope mismatch do not reduce readiness where public code and mainnet evidence verify the central XMSS property.
Algorithm & Implementation Assurance
Open-source, reproducible implementation
Claim: The production node and core XMSS libraries are publicly available as open-source implementations.
Coverage basis: Node, Python integration, C++ cryptographic library, Go signer library, and release artifacts are publicly inspectable.
Implementation score: 1 · Evidence confidence: High
Issue classification: none · Score treatment: not applicable
Assurance: Public code and CI support inspection and reproduction, although no independent deterministic-build attestation was supplied.
Algorithm & Implementation Assurance
Parameter agility and future upgrade path
Claim: QRL documents configurable XMSS parameters and a public path toward ML-DSA through governance and Project Zond materials.
Coverage basis: Address descriptors encode signature scheme, hash function, and tree height; public ML-DSA libraries and upgrade documentation provide a concrete future path.
Implementation score: 0.5 · Evidence confidence: Medium
Issue classification: operational/product caveat · Score treatment: note-only
Assurance: The evidence exceeds a conceptual roadmap, but it does not establish a deployed mainnet transition or complete existing-account migration procedure.
Future PQ-to-PQ upgrade uncertainty does not detract from current XMSS protection.
Algorithm & Implementation Assurance
Stateful-signature, side-channel, fault-injection, HSM, and custody implementation risks
Claim: Stateful XMSS signing risks are explicitly documented, and wallet and hardware-wallet workflows support OTS-state management.
Coverage basis: Signer libraries require safe state persistence, documentation describes OTS-index use, and Ledger hardware support is available.
Implementation score: 1 · Evidence confidence: High
Issue classification: operational/product caveat · Score treatment: note-only
Assurance: The supplied sources establish explicit state-management discipline but do not provide broad custody-operator compliance attestations.
Reusing an OTS index can compromise the affected key; signing systems must persist index state before broadcast and avoid backup rollback.
Algorithm & Implementation Assurance
Performance and resource-impact analysis
Claim: The resource impact of XMSS is publicly acknowledged, including approximately 3 kB transactions, but no formal comprehensive benchmark was supplied.
Coverage basis: Qualitative resource analysis and long-running mainnet deployment demonstrate practical use, without a quantified current benchmark artifact.
Implementation score: 0.5 · Evidence confidence: Low
Issue classification: assurance-only caveat · Score treatment: confidence-only
Assurance: No formal analysis covering verification throughput, mempool behavior, archival growth, and node requirements was supplied. No evidence indicates that resource costs prevent safe use of mandatory XMSS.
The missing formal benchmark is non-scoring under QRI unless it makes the PQ path unsafe or unusable.
Report metadata