PoW privacy chain
Monero XMR
Monero (XMR) is a PoW privacy chain whose production cryptographic stack is entirely dependent on elliptic curve cryptography (Ed25519-based CLSAG ring signatures, Pedersen commitments, Bulletproofs+) and is therefore vulnerable to Shor's algorithm across all critical layers: spend authorization, address/public-key exposure, state-integrity, and privacy. The Monero Research Lab has conducted extensive public quantum risk assessments since 2020, earning full marks in Security Assessment & Evidence Preparedness (5.0/5). The FCMP++ beta stressnet (May 2026) introduces forward secrecy for historical transaction privacy using post-quantum commitments, representing meaningful Stage 2 development activity, but it does not replace the ECC-based spend authorization that secures all active XMR. Jamtis-PQ (CSIDH-1024) is a research-stage addressing scheme for post-quantum encryption. No production PQ protection exists for any critical layer. The QRI Score of 10.4 reflects strong risk assessment preparedness combined with zero production quantum protection. All XMR value-at-risk remains quantum-vulnerable. A full PQ migration would require replacing Ed25519 spend authorization, redesigning Pedersen commitments and Bulletproofs+ under PQ assumptions, migrating stealth addressing to PQ key derivation, and coordinating a network-wide hard fork — none of which has progressed beyond research proposals.
Roadmap OnlyPartial Protection
Category breakdown
QRI Factors
Algorithm & Implementation Assurance
0 / 20
Migration Mechanism, Governance & Ecosystem Coordination
1.5 / 15
Migration Status & Value-at-Risk
1.5 / 25
Production Cryptographic Protection
2.41 / 35
Security Assessment & Evidence Preparedness
5 / 5
Critical Quantum Blockers
- Active production spend authorization remains entirely Ed25519/ECC-based (CLSAG ring signatures); all XMR spend paths are quantum-vulnerable via Shor's algorithm. This is the single most restrictive quantum-critical blocker (Readiness & Risk Cap: 40).
- Stealth addresses expose one-time public keys on-chain at transaction broadcast, creating a long-exposure quantum-vulnerable ownership path for all unspent outputs; an attacker with a CRQC can recover private keys from exposed public keys and steal funds.
- State-integrity mechanisms (Pedersen commitments, Bulletproofs+) and privacy layers (ring signatures, RingCT amount hiding) rely on ECC/DLP assumptions vulnerable to quantum attack; a quantum adversary could forge commitments (inflation risk), break amount confidentiality, and de-anonymize transaction graphs.
Key Risks
- Quantum key-recovery attack on exposed stealth-address one-time public keys: every Monero transaction broadcasts a one-time public key (tx pub key) on-chain, creating a permanent long-exposure attack surface. A CRQC-capable adversary can recover the private key from any exposed public key, enabling theft of all unspent outputs.
- Inflation via forged Pedersen commitments: if discrete log is broken, an attacker can open Pedersen commitments to arbitrary values, potentially creating XMR from nothing and breaking the supply-integrity guarantee.
- De-anonymization of the entire transaction graph: Shor's algorithm can break the linkability tag (key image) derivation, identifying the true spender within each ring signature and collapsing sender anonymity across the entire blockchain history.
- Amount confidentiality failure: RingCT amount hiding relies on Pedersen commitments; a quantum adversary could decrypt all historical and future transaction amounts.
- Wallet seed extraction from public addresses: Monero addresses contain public spend and view keys derived from Ed25519; quantum reversal of this derivation exposes the wallet seed and all associated funds.
- No migration path for existing unspent outputs: stealth addresses permanently expose one-time public keys; there is no current mechanism to migrate, freeze, deprecate, or burn quantum-vulnerable UTXOs.
- FCMP++ mainnet activation timeline is uncertain (6–12 months from May 2026 stressnet) and even after activation, it will not provide quantum-resistant spend authorization — only forward secrecy for past transaction privacy.
Assurance Notes
- Veridise audited the FCMP++ membership proof circuit (April–May 2025); the audit confirmed the proof system's soundness but did not assess quantum resistance, and FCMP++ is not yet on mainnet.
- Trail of Bits completed a review of the FCMP++ integration (May 11–22, 2026); the audit covers the proof system, CARROT key derivation, and codebase integration, but it is scoped to FCMP++ testnet code, not the quantum vulnerability of the current production system.
- A Monero fuzzing audit (MAGIC Grants, August 2025) covered RPC handlers; it is not relevant to quantum-critical cryptographic assessment.
- RandomX PoW was audited by 4 independent firms (Trail of Bits, X41 D-SEC, Kudelski Security, QuarksLab) in 2019; these audits cover the hash-based PoW but predate and do not address quantum threats to the transaction layer.
- No independent audit exists that specifically assesses the quantum vulnerability of Monero's current production cryptographic stack (Ed25519/CLSAG spend authorization, Pedersen commitments, Bulletproofs+). The ECC-only nature of production cryptography is, however, trivially verifiable from public source code.
- FCMP++ forward-secrecy design provides a quantum recoverability hedge for historical transaction privacy, but this does not constitute production quantum resistance.
- Jamtis-PQ (CSIDH-1024) is a research-stage addressing scheme for post-quantum encryption; no mainnet deployment or code integration exists.
- Monero has a general vulnerability disclosure process (HackerOne, security contacts) but no public quantum-specific incident-response playbook.
- No formal PQ performance/resource benchmark exists for Monero's production environment.
Non-Scoring Caveats
- FCMP++ beta stressnet launched May 6, 2026, and introduces forward secrecy for past transaction privacy using post-quantum commitments; this is a meaningful recoverability hedge but does not protect active spend authorization or future transactions. Mainnet activation is not yet scheduled (expected late 2026–early 2027).
- Jamtis-PQ (CSIDH-1024) addressing scheme is proposed but remains research-stage with no mainnet deployment or code integration. This constitutes a mitigation design/preparedness activity (Stage 2) but does not materially protect production users.
- The Monero Research Lab has conducted extensive public quantum risk research since at least 2020, including CCS-funded academic reviews; this demonstrates strong security awareness but does not translate to production protection.
- Several experimental wrapped/bridged XMR projects exist (Zero XMR on Base Sepolia testnet with ~961 XMR TVL, WrapSynth on Gnosis Chain, Wrapped Monero demo), but none have material production TVL or unrestricted two-way flow that would trigger the bridge Readiness & Risk Cap.
- Monero's privacy-preserving design (stealth addresses, ring signatures) makes precise address-level value-at-risk measurement infeasible without deanonymization; pool-level and protocol-state metrics must be used instead.
- The current mainnet release (v0.18.5.0 Fluorine Fermi, May 2026) contains no PQ cryptographic primitives for spend authorization, address derivation, or state-integrity.
- Post-quantum turnstile design for Carrot/FCMP++ enotes is a research proposal (Gist by jeffro256, Nov 2025) for future migration of existing enotes to a PQ-secure protocol, but is not implemented.
Evidence record
Claims and Caveats
Security Assessment & Evidence Preparedness
Public cryptographic inventory and quantum threat model
Claim: Monero Research Lab has published extensive quantum risk assessments since 2020, including a CCS-funded academic review (Insight Decentralized Consensus Lab, 2020) and ongoing research-lab discussions (GitHub issues #131, #151). The inventory covers ring signatures, stealth addresses, RingCT, Bulletproofs, and wallet seeds, identifying Shor's algorithm as the primary threat.
Coverage basis: Public research reports, GitHub discussions, and academic papers document the full cryptographic inventory and threat model
Implementation score: 1 · Evidence confidence: High
Issue classification: none · Score treatment: not applicable
Assurance: Multiple independent academic and community sources confirm the quantum vulnerability assessment. The 2020 Insight CCS review provides external validation.
Full marks earned here; Monero's quantum risk assessment is among the most thorough in the blockchain space.
Security Assessment & Evidence Preparedness
Public evidence record supporting the assessment
Claim: Evidence includes source code references, protocol specifications (CryptoNote whitepaper annotated), academic reviews, GitHub research-lab discussions, and reproducible analytics.
Coverage basis: Code, specs, academic papers, and community research artifacts are all publicly available
Implementation score: 1 · Evidence confidence: High
Issue classification: none · Score treatment: not applicable
Assurance: The evidence record is comprehensive, public, and independently verifiable.
The annotated CryptoNote whitepaper and main source repository provide primary-source confirmation of all cryptographic primitives.
Production Cryptographic Protection
Spend authorization / transaction signatures
Claim: All XMR spend authorization uses Ed25519-based CLSAG ring signatures (ring size 16 since hard fork v15, August 2022). No PQ or hybrid-PQ signature scheme is deployed on mainnet.
Coverage basis: Source code, protocol specification, and mainnet transaction data confirm exclusive ECC spend authorization
Implementation score: 0 · Evidence confidence: High
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Quantum blocker: Active production spend authorization remains entirely Ed25519/ECC-based (CLSAG ring signatures); all XMR spend paths are quantum-vulnerable via Shor's algorithm.
Assurance: The ECC-only nature of production spend authorization is trivially verifiable from the Monero source repository and confirmed by multiple independent analyses.
This is the single most restrictive quantum-critical vulnerability. Even after FCMP++ mainnet activation, spend authorization will remain Ed25519-based until a separate PQ migration.
Production Cryptographic Protection
Account, address, public-key exposure, and key-derivation design
Claim: Monero uses stealth addresses where each transaction exposes a one-time public key (tx pub key) on-chain. This creates a permanent long-exposure attack surface: every unspent output has its public key publicly visible, enabling offline quantum key-recovery attacks. Jamtis-PQ (CSIDH-1024) addressing is proposed but not implemented.
Coverage basis: Protocol design confirmed by CryptoNote specification and source code; the long-exposure vulnerability is verified by academic review
Implementation score: 0 · Evidence confidence: High
Issue classification: quantum-critical vulnerability · Score treatment: cap-applying
Quantum blocker: Stealth addresses expose one-time public keys on-chain at transaction broadcast, creating a long-exposure quantum-vulnerable ownership path for all unspent outputs.
Assurance: The long-exposure vulnerability is a direct consequence of Monero's stealth addressing design, confirmed by the CryptoNote specification and independent security analyses.
This is a particularly severe vulnerability because (a) every transaction creates a permanently exposed public key, (b) there is no time limit on the attack window, and (c) no migration mechanism exists for already-exposed outputs.
Production Cryptographic Protection
Consensus-critical authentication
Claim: Monero uses Proof-of-Work (RandomX) for consensus with no validator signatures, BLS threshold signatures, VRFs, randomness beacons, or finality signatures.
Coverage basis: Architectural design: Monero is a PoW chain with no validator set; RandomX is hash-based (quantum-safe against Shor's algorithm)
Implementation score: 1 · Evidence confidence: High
Issue classification: none · Score treatment: not applicable
Assurance: RandomX was audited by 4 independent firms in 2019 (Trail of Bits, X41 D-SEC, Kudelski Security, QuarksLab). The hash-based design (Blake2b + AES + random code execution) is quantum-safe against Shor's algorithm, though Grover's algorithm provides a quadratic speedup for hash preimage search.
This is correctly marked N/A, not satisfied by design, because the subfactor addresses a layer (validator/consensus authentication) that Monero's architecture genuinely does not have.
Production Cryptographic Protection
State-integrity and data-availability mechanisms
Claim: Monero's supply integrity relies on Pedersen commitments (RingCT) and Bulletproofs+ range proofs, both of which derive security from the discrete logarithm problem on elliptic curves. A quantum adversary could break these commitments, potentially enabling inflation.
Coverage basis: Source code and academic review confirm DLP-based state-integrity primitives
Implementation score: 0 · Evidence confidence: High
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Quantum blocker: State-integrity mechanisms (Pedersen commitments, Bulletproofs+) rely on DLP assumptions; a quantum adversary could forge commitments and create inflation.
Assurance: The Insight CCS academic review (2020) explicitly confirms: 'a quantum computer can fraudulently open a commitment to any value it desires, including negative values' and 'may be able to generate an apparently valid bulletproof without ever knowing the secret data.'
Blockchain immutability (hash-chain integrity) is quantum-safe due to hash-based PoW, but supply integrity (amount hiding and inflation prevention) is not.
Production Cryptographic Protection
Privacy and proof layers
Claim: Monero's privacy stack — ring signatures (sender anonymity), stealth addresses (receiver anonymity), RingCT (amount confidentiality), and Bulletproofs+ (range proofs) — all derive security from ECC/DLP assumptions and are vulnerable to Shor's algorithm.
Coverage basis: Protocol specification and academic review confirm all privacy layers are ECC-based
Implementation score: 0 · Evidence confidence: High
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Quantum blocker: All privacy layers (ring signatures, stealth addresses, RingCT, Bulletproofs+) are ECC/DLP-based and quantum-vulnerable; a quantum adversary can de-anonymize senders, decrypt amounts, and trace the transaction graph.
Assurance: Quantum Canary (February 2026) analysis explicitly confirms: 'FCMP++ is not a post-quantum computing security redesign... it won't change the category of mathematics under pressure.'
FCMP++ will improve the anonymity set size (from 16 to 150M+) but will not make the underlying proof system quantum-safe; the mathematics remains DLP-based.
Production Cryptographic Protection
P2P transport, node identity, and peer authentication
Claim: Monero's P2P network uses TCP connections for block and transaction propagation. Node identity is not cryptographically authenticated in a way that affects consensus, asset ownership, or finality.
Coverage basis: Architectural design: PoW consensus is independent of P2P node identity; P2P serves only block/tx propagation
Implementation score: 1 · Evidence confidence: Medium
Issue classification: none · Score treatment: not applicable
Assurance: While Monero nodes do use some cryptographic identifiers for peer management and DDoS protection, these are not consensus-critical. The satisfied-by-design claim is supported by the architectural separation between P2P networking and PoW consensus.
This treatment is consistent with QRI Section 7.1 architecture-specific guidance: for PoW chains without validator signatures, P2P node identity that is not consensus, spend, bridge, or custody-critical is satisfied by design.
Production Cryptographic Protection
Critical wallet, custody, HSM, signer, and hardware-wallet workflows
Claim: No PQ spend authorization path exists on mainnet, so wallets, custody solutions, HSMs, and hardware wallets cannot support PQ transaction signing. Ledger and Trezor maintain Monero support but only for classical Ed25519-based signing.
Coverage basis: Absence of any PQ signature scheme on mainnet means no wallet can support PQ signing
Implementation score: 0 · Evidence confidence: High
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Assurance: The CIDU article (May 2026) confirms that FCMP++ stressnet does not yet support hardware wallet, multisig, or watch-only wallet features. No production wallet supports any PQ signing path.
Wallet support for PQ signing is contingent on mainnet deployment of a PQ signature scheme, which does not exist.
Migration Status & Value-at-Risk
Percentage of economically relevant value-at-risk protected
Claim: 0% of XMR value-at-risk is protected from quantum key-recovery attacks. All ~18.4M XMR circulating supply is secured exclusively by ECC-based spend authorization and exposed through stealth address one-time public keys. No migration, freeze, deprecation, or burn path exists for vulnerable UTXOs.
Coverage basis: Protocol design: all outputs are secured by Ed25519-based CLSAG signatures with exposed one-time public keys; no PQ-protected value pool exists
Implementation score: 0.05 · Evidence confidence: High
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Quantum blocker: Material long-exposure quantum-vulnerable value exists (~100% of circulating supply) with no migration, freeze, deprecation, burn, recovery, or policy path.
Assurance: Monero's privacy design prevents precise address-level value-at-risk measurement, but the protocol-level assessment is unambiguous: every unspent output is secured by ECC-based signatures with an exposed public key. The coverage is effectively 0%.
Coverage falls in the <25% band (score 1 out of 20 per QRI 9.3.1). The privacy-preserving design means pool-level metrics must be used; the conclusion that all value is quantum-vulnerable is nonetheless robust.
Migration Status & Value-at-Risk
Critical wallets migrated, protected, or inherently PQ-native
Claim: No critical wallets (treasuries, exchanges, custodians, bridges, foundations, major protocols) have been migrated to PQ protection because no PQ spend authorization path exists on Monero mainnet.
Coverage basis: Absence of any PQ signature scheme on mainnet precludes wallet migration
Implementation score: 0 · Evidence confidence: High
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Assurance: No exchange, custody provider, or major XMR holder can migrate to PQ protection because the protocol does not support it. This is a derivative vulnerability of the absent PQ spend authorization.
This subfactor cannot be scored independently from the spend authorization subfactor; both are blocked by the same missing capability.
Migration Status & Value-at-Risk
Legacy vulnerable pools/accounts/UTXOs/contracts identified and measurable
Claim: Monero Research Lab and independent academic reviews have identified the vulnerable cryptographic mechanisms (ring signatures, stealth addresses, Pedersen commitments, Bulletproofs+). However, no measurable, deprecated, migrated, frozen, or burn path exists for quantum-vulnerable UTXOs.
Coverage basis: Academic and community research identifies all vulnerable primitives; no protocol-level mechanism exists to address vulnerable UTXOs
Implementation score: 0.25 · Evidence confidence: Medium
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Assurance: Identification is thorough at the mechanism level, but no measurable per-UTXO classification or deprecation path exists. The privacy design makes per-output attribution infeasible without deanonymization.
Partial credit (0.25) awarded for research-stage identification of vulnerable mechanisms. The absence of any deprecation, migration, or freeze mechanism prevents a higher score.
Migration Mechanism, Governance & Ecosystem Coordination
Public migration or protection roadmap with sequencing, activation criteria, and dependencies
Claim: Monero has conducted CCS-funded PQ research (2020) and maintains active research-lab discussions (issues #131, #151) exploring lattice-based, hash-based, and isogeny-based approaches. However, no concrete production migration roadmap with sequencing, activation criteria, and dependencies has been published. Jamtis-PQ and Seraphis are research-stage proposals only.
Coverage basis: Research discussions and proposals exist but lack production sequencing and activation criteria
Implementation score: 0.25 · Evidence confidence: Medium
Issue classification: quantum-critical uncertainty · Score treatment: score-reducing
Assurance: Research is substantive but remains at the proposal/discussion stage. No timeline, dependency graph, activation criteria, or sequenced migration plan exists for any PQ upgrade.
The 2020 CCS-funded research identified candidate approaches (Raptor linkable ring signatures, MatRiCT) but did not produce a deployment roadmap. FCMP++ is explicitly not a PQ migration roadmap.
Migration Mechanism, Governance & Ecosystem Coordination
Migration accessibility and defaults
Claim: No PQ/hybrid account creation, wallet tooling, transaction paths, custody paths, user-facing warnings, education, or migration prompts exist on Monero mainnet.
Coverage basis: Absence of any PQ infrastructure on mainnet
Implementation score: 0 · Evidence confidence: High
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Assurance: The absence of any PQ migration tooling is directly verifiable from the production wallet software (CLI v0.18.5.0, GUI) and the mainnet protocol.
No migration prompts, no PQ wallet mode, no hybrid account creation — zero migration accessibility in production.
Migration Mechanism, Governance & Ecosystem Coordination
Migration enforcement and coordination
Claim: No enforcement mechanisms exist for quantum migration. There is no deprecation of ECC-only outputs, no freeze mechanism, no disabled legacy signing, no restricted withdrawals, no unsafe-path blocking, and no mandatory migration deadline.
Coverage basis: No enforcement or coordination mechanisms exist on mainnet
Implementation score: 0 · Evidence confidence: High
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Assurance: Monero's hard fork mechanism provides a governance path for future enforcement, but no quantum-specific enforcement has been designed, proposed, or coordinated.
The deprecation of Custom Transaction Unlock Time (announced May 2026 for FCMP++) demonstrates Monero's ability to deprecate protocol features, but this capability has not been applied to quantum-vulnerable outputs.
Migration Mechanism, Governance & Ecosystem Coordination
Emergency disclosure, incident-response, or governance process for quantum-related vulnerabilities
Claim: Monero has a general vulnerability disclosure process (HackerOne, security contacts) and a mature hard-fork governance mechanism. However, no quantum-specific incident-response playbook has been published.
Coverage basis: General security process exists but no quantum-specific adaptation
Implementation score: 0.25 · Evidence confidence: Medium
Issue classification: assurance-only caveat · Score treatment: note-only
Assurance: The absence of a quantum-specific incident-response process does not by itself create a Readiness & Risk Cap (per QRI Section 8.2), but it is noted as an assurance gap.
Partial credit for the existing general vulnerability disclosure infrastructure. A quantum-specific playbook would improve preparedness but is not score-determining given the more fundamental absence of PQ production protection.
Algorithm & Implementation Assurance
Uses NIST-standardized, standards-track, or broadly reviewed PQC/hybrid-PQC algorithms
Claim: No NIST-standardized or broadly reviewed PQC algorithms are deployed in Monero's production spend authorization, address derivation, or state-integrity layers. Research has identified candidate approaches (lattice-based Raptor/MatRiCT, hash-based, CSIDH), but none are in production.
Coverage basis: Research proposals identify candidate PQ algorithms; no production deployment
Implementation score: 0 · Evidence confidence: High
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Assurance: Research into lattice-based alternatives (Raptor, MatRiCT) and CSIDH (Jamtis-PQ) is promising but remains at the proposal stage. No standardized PQ algorithm has been selected for implementation.
Score is 0.00 because no PQ algorithm is deployed or even selected for production implementation.
Algorithm & Implementation Assurance
Independent cryptographic and implementation audit for quantum-critical scope
Claim: No independent audit exists for quantum-critical production scope because Monero has no PQ implementation in production.
Coverage basis: Audits exist for development components but not for quantum-critical production scope
Implementation score: 0 · Evidence confidence: Medium
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Assurance: Existing audits are high-quality but scope-mismatched: they cover FCMP++ components (not yet in production) and RandomX PoW (not the quantum-vulnerable transaction layer). No audit has specifically assessed the quantum vulnerability of Ed25519/CLSAG spend authorization, Pedersen commitment integrity, or Bulletproofs+ soundness under a quantum threat model for the current mainnet.
The absence of a quantum-scope audit does not independently reduce the QRI Score (per Section 8.2), but the lack of any PQ implementation to audit means this subfactor cannot earn points.
Algorithm & Implementation Assurance
Open-source, reproducible implementation
Claim: Monero's codebase is fully open-source (GitHub, 11K+ stars) under a permissive license. The classical cryptographic implementation is publicly auditable. However, there is no PQ implementation in production to evaluate.
Coverage basis: Full source code is publicly available; no PQ production code exists
Implementation score: 0 · Evidence confidence: High
Issue classification: none · Score treatment: not applicable
Assurance: The classical codebase is exemplary in openness and reproducibility. This subfactor would score highly once a PQ implementation exists.
Score is 0.00 because there is no PQ implementation to be open-source. The classical codebase's openness is noted but does not earn points for quantum-critical implementation assurance.
Algorithm & Implementation Assurance
Parameter agility and future upgrade path
Claim: Monero's hard fork mechanism provides a proven governance path for protocol upgrades (16 successful hard forks since 2016). However, no specific PQ parameter agility framework or documented PQ upgrade path exists.
Coverage basis: Hard fork governance mechanism exists; no PQ-specific parameter agility framework
Implementation score: 0 · Evidence confidence: Medium
Issue classification: assurance-only caveat · Score treatment: note-only
Assurance: Monero's hard fork track record (v1 through v16, 2016–2022) demonstrates reliable network upgrade coordination. The FCMP++ stressnet process shows continued governance maturity. However, no PQ-specific parameter negotiation, hybrid transition, or algorithm replacement framework has been documented.
Score is 0.00 because no PQ-specific parameter agility framework exists. The general hard fork capability is noted but does not earn points for PQ parameter agility.
Algorithm & Implementation Assurance
Stateful-signature safety, side-channel, fault-injection, and custody implementation risks
Claim: No PQ signatures are used in production, so stateful-signature safety and PQ-specific implementation risks are not applicable to the current production scope.
Coverage basis: No PQ signature scheme deployed in production
Implementation score: 0 · Evidence confidence: Medium
Issue classification: none · Score treatment: not applicable
Assurance: Monero's classical implementation includes some constant-time operations and memory-zeroing (noted in the Veridise FCMP++ audit), but these address classical side-channel concerns, not PQ-specific risks.
Score is 0.00 because no PQ implementation exists for these considerations to apply to.
Algorithm & Implementation Assurance
Performance and resource-impact analysis for PQ deployment
Claim: No formal performance or resource-impact analysis exists for PQ signature/verification costs in Monero's production environment.
Coverage basis: No PQ-specific performance analysis for production
Implementation score: 0 · Evidence confidence: Medium
Issue classification: operational/product caveat · Score treatment: note-only
Assurance: The FCMP++ stressnet provides some performance data (~2–3 KB proof size, block validation latency), but this addresses FCMP++ membership proofs, not PQ signature schemes. The absence of PQ performance analysis is an operational caveat, not a QRI Score deduction by itself.
The CCS-funded 2020 PQ research noted that lattice-based alternatives 'have similar orders of magnitude in size and time requirements as current protocols,' but this is a research observation, not a production performance analysis.
Report metadata