PoW privacy chain
Monero XMR
Monero is a mature PoW privacy chain whose entire production cryptographic stack — spend authorization (Ed25519/CLSAG ring signatures), address derivation, Pedersen commitments, Bulletproofs+, and key images — relies exclusively on elliptic curve cryptography vulnerable to Shor's algorithm. As of 2026-05-31, no post-quantum or hybrid-PQ spend authorization, account creation path, or state-integrity mechanism exists on mainnet. The Monero Research Lab has conducted meaningful public quantum risk research since at least 2020 (CCS-funded semitechnical summary, GitHub issues #131 and #151), and active design work is underway: CSIDH-1024 has been proposed for PQ encryption in the future Jamtis addressing scheme, and a working-group discussion on PQ signature candidates (Dilithium, Falcon, SPHINCS+) was reported in late 2025. However, these remain at the research and design-proposal stage with no mainnet code, testnet, or activation criteria. FCMP++ — Monero's most significant near-term upgrade, currently in beta stressnet with a Trail of Bits audit running May 11–22, 2026 — replaces ring signatures with full-chain membership proofs and adds Carrot's symmetric forward-secrecy for transaction-graph privacy, but it does not replace ECC spend authorization with any PQC scheme and is therefore not a quantum-resistance upgrade. CSIDH itself carries contested quantum security (subexponential quantum hidden-shift attacks are known; CSIDH-1024 parameters are chosen to compensate but the scheme is not NIST-standardized). The score of 10 is driven by the raw factor score (10.08) and is consistent with Stage 1 (Quantum Risk Assessed, max 20). The most restrictive critical blocker cap (40, for ECC-only spend authorization) and the stage cap (20) both exceed the raw factor score, so the factor score is the binding constraint. Confidence is Medium: Monero's open-source codebase and public MRL discussions provide good evidence of the current state, but the absence of a formally published MRL position paper with a complete threat model and value-at-risk classification introduces some inference.
Quantum Risk AssessedPQ-Roadmapped
Category breakdown
QRI Factors
Algorithm & Implementation Assurance
1.95 / 20
Migration Mechanism, Governance & Ecosystem Coordination
0.3 / 15
Migration Status & Value-at-Risk
1.1 / 25
Production Cryptographic Protection
4.13 / 35
Security Assessment & Evidence Preparedness
2.6 / 5
Critical Quantum Blockers
- Active production spend authorization remains entirely ECC-only (Ed25519/CLSAG ring signatures on mainnet) — Critical Blocker Cap: 40
- Users can still create new quantum-vulnerable accounts by default with no PQC path available — Critical Blocker Cap: 60
- Most restrictive applicable blocker cap applied: 40
Key Risks
- All XMR spend authorization uses Ed25519-based CLSAG ring signatures; a cryptographically relevant quantum computer running Shor's algorithm could derive private keys from exposed public keys, enabling theft of any UTXO whose key has been revealed on-chain.
- Stealth addresses protect recipients until the moment of spend, but once a transaction is broadcast the one-time key is exposed; any unspent output tied to a reused or exposed key is at risk under a CRQC.
- Pedersen commitments, Bulletproofs+ range proofs, and key images all rely on the elliptic curve discrete logarithm problem; a CRQC could potentially forge commitments or break supply-binding assumptions.
- FCMP++ (in beta stressnet, not yet on mainnet) improves anonymity set and adds Carrot symmetric forward secrecy for transaction-graph privacy, but does not replace ECC spend authorization; it is not a quantum-resistance upgrade.
- CSIDH-1024, proposed for Jamtis PQ addressing, is not NIST-standardized and is subject to subexponential quantum attacks via hidden-shift algorithms; its actual post-quantum security level at CSIDH-1024 parameters is debated in the literature.
- No PQC migration roadmap with sequencing, activation criteria, or enforcement mechanism exists; the timeline to production PQC protection is indeterminate.
- No user-facing PQC migration prompts, wallet defaults, or exchange/custodian coordination for quantum risk exists.
- The Trail of Bits audit (May 2026) covers FCMP++ integration (a classical privacy upgrade), not any PQC implementation; no independent audit of a PQC design for Monero has been completed.
- Monero's privacy architecture makes value-at-risk measurement difficult; pool-level data and protocol state can be used but precise coverage attestation is not possible, introducing conservative uncertainty into any future migration coverage assessment.
- An 18-block reorganization in September 2025 highlights that PoW consensus security has independent risks beyond quantum; mining pool operational key dependencies are not assessed here but represent an additional attack surface.
Evidence record
Claims and Caveats
Transaction
Spend authorization / transaction signatures are PQC or hybrid-PQC on mainnet
Claim: Monero uses Ed25519-based CLSAG (Compact Linkable Spontaneous Anonymous Group) ring signatures for all mainnet spend authorization. No PQC or hybrid-PQC spend authorization exists on mainnet or in any deployed testnet.
Coverage basis: Classical ECC spend authorization only; no PQC usage
Implementation score: 0 · Evidence confidence: 0.9
Quantum blocker: Active production spend authorization remains entirely ECC-only — cap 40
CLSAG ring signatures are documented in mainnet source code (src/ringct/). FCMP++ (in beta stressnet as of May 2026) replaces ring signatures with full-chain membership proofs for anonymity but does not replace Ed25519/ECC spend authorization with any PQC scheme. Seraphis/Jamtis with CSIDH-based PQ encryption is a future design proposal, not deployed.
Transaction
Account, address, public-key exposure, and key-derivation design avoids quantum-vulnerable ownership paths or supports PQ/hybrid accounts
Claim: All Monero addresses and key derivation use Ed25519 (Twisted Edwards curve). Stealth addresses provide one-time address generation that delays public-key exposure until spend time, offering partial forward secrecy, but the underlying key material is ECC-only. No PQC account or address type exists.
Coverage basis: Classical ECC key derivation only; stealth addresses provide classical forward secrecy only
Implementation score: 0 · Evidence confidence: 0.9
Quantum blocker: Users can still create new quantum-vulnerable accounts by default — cap 60
MRL issue #151 (Oct 2025) discusses CSIDH-1024 for Jamtis PQ addressing as a future design option. This is a proposal, not deployed code. Stealth addresses reduce but do not eliminate ECC exposure.
Consensus
Consensus-critical authentication is PQC or hybrid-PQC where applicable, including validator signatures, VRFs, randomness beacons, threshold signatures, or block certificates
Claim: Monero uses RandomX proof-of-work consensus. There are no validator signatures, validator sets, VRFs, randomness beacons, or finality signatures in the protocol.
Coverage basis: N/A — PoW chain with no validator authentication layer
Implementation score: 0 · Evidence confidence: 0.9
Mining pool operational keys are a separate operational risk not scored here. RandomX is ASIC-resistant by design.
State Integrity
State-integrity mechanisms are quantum-safe where applicable, including commitments, nullifiers, accumulators, script authorization, supply-binding mechanisms, and bridge verification
Claim: Monero's state integrity relies on Pedersen commitments (ECC-based), Bulletproofs+ range proofs (discrete-log hardness on Curve25519), and key images (ECC-based nullifiers). All are quantum-vulnerable. FCMP++ (in beta stressnet) uses generalized Bulletproofs which remain ECC-based.
Coverage basis: Classical ECC commitments and nullifiers only; no PQC state-integrity mechanism
Implementation score: 0 · Evidence confidence: 0.9
Quantum blocker: Quantum attack can plausibly break supply integrity or state binding in a critical layer — cap 60 (subsumed by spend-auth blocker cap 40)
FCMP++ cryptographic foundation (generalized Bulletproofs, Curve Trees) is documented in the FCMP++ design paper v0.5.2 (Jan 2026). It improves anonymity set but does not replace ECC hardness assumptions for commitments or nullifiers.
Privacy / Proof Layer
Privacy and proof layers are quantum-safe where applicable, including ZK proof assumptions, note encryption, viewing keys, stealth addresses, and shielded state
Claim: RingCT, CLSAG ring signatures, stealth addresses, and Bulletproofs+ all rely on ECC. Carrot (shipping with FCMP++) introduces symmetric-key derivations for transaction-graph forward secrecy, providing partial PQ benefit for historical transaction privacy. FCMP++ is in beta stressnet (not mainnet) as of evaluation date.
Coverage basis: Partial: symmetric-key components of Carrot provide PQ forward secrecy for tx-graph privacy; spend authorization and proof system remain ECC
Implementation score: 0.25 · Evidence confidence: 0.6
MRL issue #151 states: 'Several parts of the transaction protocol use symmetric-key derivations that are PQ secure' (Carrot). This is a partial and forward-looking benefit. FCMP++ beta stressnet launched May 6, 2026; Trail of Bits audit May 11–22, 2026. Mainnet activation not yet confirmed. Implementation score 0.25 reflects prototype/stressnet stage for the partial PQ benefit only.
P2P
P2P transport, node identity, and peer authentication are PQC, hybrid-PQC or all asset-spending authorization is PQ-signed on device and network identity is not consensus, spend, bridge, or custody-critical
Claim: Monero nodes communicate via TCP/IP. Dandelion++ obfuscates transaction origin IP addresses. Node identity is not used for consensus, spend authorization, bridge verification, or custody. Asset-spending authorization is performed on-device via ECC wallet signing, not via P2P node identity.
Coverage basis: Satisfied by design: P2P node identity is not consensus, spend, bridge, or custody-critical per QRI §7.2
Implementation score: 1 · Evidence confidence: 0.9
Dandelion++ provides IP-level privacy but uses classical TCP/IP. The satisfied-by-design ruling applies strictly to the QRI P2P subfactor scope. The underlying spend authorization being ECC is captured in the spend-auth subfactor.
Wallet / Custody
Critical wallet, custody, and signing workflows support the production PQ/hybrid path or are protected by native satisfied-by-design controls
Claim: All Monero wallets (GUI, CLI, hardware wallets via Ledger/Trezor) use Ed25519-based key management. No PQC wallet path exists. Hardware wallet support is classical ECC only.
Coverage basis: Classical ECC wallet signing only; no PQC path
Implementation score: 0 · Evidence confidence: 0.9
Ledger hardware wallet bug fix was released November 2025 (view key export). No PQC signing path is available or planned for near-term wallet releases.
Assessment
Public cryptographic inventory of critical public-key mechanisms
Claim: The 2020 CCS-funded research produced a semitechnical summary identifying Ed25519, ECDH, ring signatures, Pedersen commitments, and Bulletproofs as quantum-vulnerable ECC mechanisms. MRL GitHub issues (#131, #151) extend this inventory. No single formally published MRL position paper with a complete inventory has been confirmed as released.
Coverage basis: Partial public inventory via CCS deliverables and MRL GitHub discussions
Implementation score: 0.5 · Evidence confidence: 0.6
The 2020 CCS proposal planned a user-friendly writeup and MRL position paper as deliverables. The semitechnical summary is publicly available. Evidence confidence is 0.60 (formal specification / serious technical proposal level) because the inventory exists in distributed form across GitHub issues and CCS deliverables rather than a single authoritative published document.
- https://github.com/insight-decentralized-consensus-lab/post-quantum-monero/blob/master/writeups/semitechnical_summary.MD
- https://ccs.getmonero.org/proposals/research-post-quantum-monero.html
- https://github.com/monero-project/research-lab/issues/131
- https://github.com/monero-project/research-lab/issues/151
Assessment
Public quantum threat model covering attack assumptions, affected assets, and affected layers
Claim: The 2020 CCS research and subsequent MRL GitHub discussions describe Shor's algorithm breaking Ed25519/ECDH, Grover's algorithm halving hash security, and identify affected layers (spend auth, commitments, key images, note encryption). No single comprehensive formal threat model document has been confirmed as published.
Coverage basis: Partial threat model via CCS deliverables and MRL GitHub discussions
Implementation score: 0.5 · Evidence confidence: 0.6
The semitechnical summary explicitly covers Shor and Grover impacts on Monero's ECC stack. MRL issue #131 (Dec 2024) discusses ethical considerations and urgency. Evidence confidence 0.60 reflects the distributed, informal nature of the threat model documentation.
Assessment
Public classification of exposed value, exposed accounts, dependent systems, and critical layers
Claim: No formal published classification of value-at-risk by layer exists. MRL discussions acknowledge all XMR UTXOs are at risk but do not provide a structured, quantified classification of exposed value, critical wallets, or dependent systems.
Coverage basis: Informal acknowledgment only; no structured value-at-risk classification
Implementation score: 0.25 · Evidence confidence: 0.4
Monero's privacy architecture makes precise value-at-risk classification inherently difficult. The CCS proposal acknowledged this challenge. Evidence confidence 0.40 reflects roadmap/proposal-level documentation only.
Assessment
Public evidence record supporting the assessment, such as code references, specs, audits, transaction examples, or reproducible analytics
Claim: Public evidence includes: open-source codebase on GitHub, CCS-funded semitechnical summary (2020), MRL GitHub issues with technical analysis, Zero-to-Monero documentation, and FCMP++ design paper v0.5.2 (Jan 2026). No PQC-specific audit or reproducible analytics for quantum exposure exist.
Coverage basis: Partial evidence record: code references and technical proposals exist; no PQC audit or reproducible quantum-exposure analytics
Implementation score: 0.5 · Evidence confidence: 0.6
The Trail of Bits audit (May 2026) covers FCMP++ integration (classical privacy upgrade), not PQC. It does not constitute a PQC evidence record.
Migration
Percentage of circulating supply controlled by PQC/hybrid-PQC or otherwise quantum-protected native controls
Claim: 0% of circulating XMR supply (~18.45M XMR) is controlled by PQC or hybrid-PQC native controls. All UTXOs are protected by ECC-only spend authorization.
Coverage basis: 0% PQC coverage; all supply under classical ECC control
Implementation score: 0.05 · Evidence confidence: 0.9
Quantum blocker: Major value pool remains quantum-vulnerable with no migration path — cap 70 (subsumed by spend-auth blocker cap 40)
Coverage score per QRI §9.3.1 table: <25% = score 1 (out of 20). Implementation score = 1/20 = 0.05. Circulating supply ~18.45M XMR per multiple sources. Monero's privacy architecture prevents precise UTXO-level measurement; pool-level assessment confirms 0% PQC coverage.
Migration
Critical wallets migrated, protected, or inherently PQ-native, including treasuries, exchanges, custodians, bridges, foundations, and major protocols
Claim: No critical wallets (exchanges, custodians, foundations) have migrated to or are protected by PQC controls. All use standard ECC Monero wallets.
Coverage basis: 0% critical wallet migration; all use classical ECC
Implementation score: 0 · Evidence confidence: 0.9
Major exchanges have delisted XMR (Kraken, Binance in certain jurisdictions) for regulatory reasons, not quantum reasons. Remaining exchange custody is classical ECC.
Migration
Legacy vulnerable pools/accounts/UTXOs/contracts are identified, measurable, deprecated, migrated, frozen, or proven not to exist by design
Claim: No formal identification, measurement, or deprecation of legacy vulnerable UTXOs exists. MRL discussions informally acknowledge all UTXOs are at risk. Monero's privacy architecture makes precise measurement inherently difficult.
Coverage basis: Informal acknowledgment only; no formal identification or deprecation process
Implementation score: 0.25 · Evidence confidence: 0.4
Quantum blocker: Migration coverage cannot be measured or attested where legacy vulnerable value exists — cap 85 (subsumed by spend-auth blocker cap 40)
Monero's shielded architecture means precise UTXO-level quantum exposure cannot be publicly measured without deanonymization. This is an inherent architectural constraint, not a failure of effort. Conservative confidence applied.
Governance / Migration Mechanism
Public migration or protection roadmap with sequencing, activation criteria, and dependencies
Claim: No formal PQC migration roadmap with sequencing, activation criteria, or dependencies exists. CSIDH-1024 for Jamtis is a design proposal in MRL issue #151 (Oct 2025 – May 2026). A working group was reportedly formed in late 2025 to evaluate PQC candidates.
Coverage basis: Early design proposal stage only; no formal roadmap
Implementation score: 0.25 · Evidence confidence: 0.4
The May 2026 MRL update on CSIDH-1024 for Jamtis represents active design work but lacks activation criteria, sequencing, or hard fork planning. Evidence confidence 0.40 (official roadmap/proposal level).
Governance / Migration Mechanism
User-facing warnings, incentives, deadlines, education, or migration prompts
Claim: No user-facing PQC migration warnings, incentives, deadlines, or prompts exist in any Monero wallet, documentation, or official communication.
Coverage basis: No user-facing PQC migration communication
Implementation score: 0 · Evidence confidence: 0.9
The CCS 2020 proposal planned a community-facing writeup to minimize FUD, but no evidence of a deployed user-facing PQC migration prompt or warning system was found.
Governance / Migration Mechanism
PQ/hybrid account creation, wallet defaults, transaction paths, or custody paths are default, strongly preferred, mandatory, or complete by design
Claim: No PQC account creation path, wallet default, or transaction path exists. All defaults are classical ECC.
Coverage basis: No PQC path available
Implementation score: 0 · Evidence confidence: 0.9
Governance / Migration Mechanism
Enforcement mechanism exists, such as deprecation, freeze, disabled legacy signing, restricted withdrawals, unsafe-path blocking, or mandatory migration after a deadline
Claim: No enforcement mechanism for PQC migration exists or has been proposed with activation criteria.
Coverage basis: No enforcement mechanism
Implementation score: 0 · Evidence confidence: 0.9
Governance / Migration Mechanism
Exchange, custody, bridge, wallet, and infrastructure coordination prevents unsafe fallback into vulnerable systems
Claim: No exchange, custodian, wallet, or infrastructure coordination for PQC migration exists. Most major regulated exchanges have delisted XMR for regulatory reasons, not quantum reasons.
Coverage basis: No PQC ecosystem coordination
Implementation score: 0 · Evidence confidence: 0.9
Exchange delistings (Kraken, Binance in EU/US, Bitfinex) are regulatory-driven, not quantum-driven, and do not constitute PQC coordination.
Algorithm Assurance
Uses NIST-standardized, standards-track, or broadly reviewed PQC/hybrid-PQC algorithms appropriate to the use case
Claim: No NIST-standardized or standards-track PQC algorithm is deployed or formally proposed for mainnet spend authorization or state integrity. CSIDH-1024 is proposed for Jamtis PQ addressing but is not NIST-standardized; its quantum security is contested (subexponential quantum hidden-shift attacks apply). Dilithium/Falcon/SPHINCS+ have been discussed but not formally proposed for Monero.
Coverage basis: No NIST-standardized PQC deployed; CSIDH proposal has contested quantum security
Implementation score: 0 · Evidence confidence: 0.9
Quantum blocker: PQC design relies on a non-NIST-standardized algorithm (CSIDH) with contested quantum security — cap 75 (subsumed by spend-auth blocker cap 40)
CSIDH-1024 parameters are chosen to compensate for known subexponential quantum attacks, but the scheme is not NIST-standardized and its actual post-quantum security level remains debated. The MRL issue #151 acknowledges 'the post-quantum security of CSIDH is more complicated.' This is a design-stage concern, not a deployed risk.
Algorithm Assurance
Independent cryptographic and implementation audit exists
Claim: Trail of Bits is auditing FCMP++ integration (May 11–22, 2026). This audit covers the classical privacy upgrade (full-chain membership proofs, ECC-based), not any PQC implementation. No independent audit of a PQC design for Monero has been completed.
Coverage basis: Audit of classical privacy upgrade only; no PQC audit
Implementation score: 0 · Evidence confidence: 0.9
Quantum blocker: No independent audit of a claimed quantum-ready system — cap 92 (subsumed by spend-auth blocker cap 40)
The Trail of Bits audit is a significant positive step for FCMP++ privacy assurance but does not constitute a PQC audit. The 2020 CCS-funded semitechnical summary was an academic review of quantum vulnerabilities, not an implementation audit of a PQC system.
Algorithm Assurance
Open-source, reproducible implementation
Claim: Monero is fully open-source under the BSD license. All protocol code, research, and tooling is publicly available on GitHub. The implementation is reproducible.
Coverage basis: Fully open-source and reproducible
Implementation score: 1 · Evidence confidence: 0.9
Open-source status is well-established and not in dispute. This subfactor scores full credit.
Algorithm Assurance
Parameter agility and future upgrade path are documented
Claim: No documented PQC parameter agility or future upgrade path for quantum-resistant algorithms exists. Monero's hard-fork governance model provides a general upgrade mechanism, but no PQC-specific parameter agility documentation has been published.
Coverage basis: No PQC parameter agility documentation
Implementation score: 0 · Evidence confidence: 0.4
Monero's biannual hard-fork cadence provides a general upgrade mechanism. However, no PQC-specific parameter agility or algorithm substitution plan has been documented.
Algorithm Assurance
Side-channel, fault-injection, state-management, hardware-wallet, HSM, or custody implementation risks are considered
Claim: MRL issue #151 explicitly notes that CSIDH public keys require validation to avoid attacks and discusses side-channel risks for CSIDH implementations. The 2020 CCS semitechnical summary noted side-channel considerations for PQC candidates. No deployed PQC implementation exists to audit.
Coverage basis: Side-channel risks acknowledged in design proposals; no deployed PQC implementation
Implementation score: 0.25 · Evidence confidence: 0.6
CSIDH constant-time implementation requirements are a known challenge (original CSIDH implementation was not constant-time; side-channel attacks can recover secret key material). MRL issue #151 acknowledges key validation requirements. Implementation score 0.25 reflects design-stage consideration only.
Report metadata