Active primitives well-documented. Minor deduction: bare TCP P2P cipher posture is not pinned in foundation docs (Tor/I2P supported at network layer).

Every privacy primitive reduces to discrete-log hardness on Curve25519/Ed25519. Privacy guarantee, not only value-transfer non-forgeability, collapses retroactively because ring signatures, stealth addresses, and Pedersen commitments are all classical-only.

0 PQ families on mainnet. Entire protocol is mono-family pre-quantum DL on a single curve. No lattice, hash-based, code-based, or isogeny primitive deployed. Diversity Cap is not yet triggered (pre-cap state of zero PQ families).

No primitive in active use maps to NIST PQC categories 1-5. Curve25519/Ed25519 targets ~128-bit classical security; Keccak-256 targets 256-bit preimage / 128-bit collision classical, halved under Grover.

monero-project C++ reference continuously developed since 2014. CLSAG independently academically reviewed (IACR 2019/654) before deployment. Bulletproofs+ underwent independent review with critical pre-deployment vulnerability caught and patched. RandomX audited by Trail of Bits and others. FCMP++ underwent 2025 audit by Veridise reporting no critical/high findings. Constant-time engineering documented for ed25519; not formally machine-checked across full stack. Cryptanalytic tier 1 for ECC/Schnorr/Curve25519, tier 2 for Keccak.

Monero's stealth-address scheme means each transaction output goes to a one-time public key. The recipient's master spend-public-key is NOT directly visible on chain, only per-output one-time keys derived from it. Those one-time keys ARE elliptic-curve points published on chain at every transaction; an attacker with Shor recovers each one-time secret key from its on-chain point and can forge spends from any unspent output. Forge surface is essentially 100% of the live UTXO set.

Every dormant unspent output on Monero, including outputs going back to mainnet 2014, sits at a one-time Curve25519 point on chain. Cold/lost coins are fully Forge-vulnerable. Unlike Bitcoin P2PKH (where curve point is hashed and only revealed at spend), Monero's transaction model requires the one-time public key to be on chain at output creation so ring signatures and stealth detection can work. No hash-protected cold-storage analogue.

Every CLSAG (since 2020-10) and prior MLSAG ring signature on the chain is verifiable against a forged version post-Shor. Combined with stealth-address derivation (also DL-based), every historical authorization on Monero loses non-repudiation under Shor. Chain is permanent; signatures are permanent; forgeability is structural.

Monero P2P layer operates over plain TCP by default, with optional Tor and I2P routing at network layer. No mandated transport-layer encryption (wallet-to-daemon RPC channel typically runs over TLS at infrastructure provider level for remote nodes; daemon-to-daemon P2P broadcast is not TLS-encrypted by design, relies on Dandelion++ for sender obfuscation). Tor/I2P provide additional protection but Tor's hop-by-hop crypto is X25519/Curve25519, also Shor-vulnerable.

Dominant Decrypt-class exposure for Monero. Every transaction since the chain's 2014-04-18 genesis carries Curve25519-encrypted amount commitments (Pedersen on Ed25519, with binding factor/mask transmitted via stealth-address ECDH) plus per-output payment IDs and tx_extra encrypted blobs. An adversary who has harvested the full Monero blockchain today can, once Shor is operational, decrypt every historical amount, every historical recipient identity, and every historical ring signature's true signer. Largest retroactive de-anonymization surface in any chain LayerQu has scored. Research-lab issue #151 (opened 2025-10-24) proposes CSIDH-1024, research-stage discussion, not deployed.

Canonical 'hidden transaction graph' privacy chain, sender hidden by ring signatures (currently ring-size 16 since 2022-08 v16 hard fork), recipient hidden by one-time stealth addresses, amount hidden by Pedersen commitments + Bulletproofs+ range proofs. Structurally stronger than opt-in shielded pools because privacy is mandatory for every transaction. FCMP++, when activated, will lift anonymity set from 16 to entire UTXO set (~100M+ outputs). Minor deduction reflects EAE-class statistical attacks that reduce effective anonymity set in some adversarial scenarios.

(i) RPC concentration: Monero culture strongly favors self-hosted full nodes; public remote-node providers (MyMonero, Cake Wallet's nodes, Feather's defaults, monero.fail aggregator) represent smaller fraction than most chains. (ii) Mempool gossip: Dandelion++ (since v0.15 / 2019-11) provides stem-phase sender-identity obfuscation against passive observers. (iii) Validator metadata retention: N/A, there are no validators; PoW miners do not retain operator-tier metadata in centralized form.

Monero has minimal bridge surface by design, no production-grade trustless bridges (Wormhole, LayerZero, Axelar do not support XMR; Monero-side multi-sig and atomic swap research at limited deployment scale). Centralized exchange deposits/withdrawals are dominant on/off-ramp; meaningful share of CEXs delisted XMR following 2024 EU MiCA pressure. Atomic swaps to BTC operational at low volume. Reduced bridge attack surface is a structural privacy advantage; offsetting concern is CEX KYC creates strong correlation channel between fiat-rail identity and Monero address at the exchange perimeter.

Highest-stakes retroactive-deanonymization scenario among all chains scored. A future Shor-capable adversary with full chain history can: (1) recover per-output one-time secret key from its on-chain Curve25519 point; (2) trace stealth-address derivations back to recipient master view key; (3) un-blind every Pedersen commitment using recovered ECDH-derived mask; (4) identify true signer among each ring signature's 16 candidates. Privacy of every Monero transaction since 2014-04-18 collapses retroactively, sender, recipient, AND amount, all three layers, simultaneously. Approximately 11 years of confidential financial activity becomes publicly readable. Research-lab issue #131 (opened 2024-12-10 in response to Google Willow) explicitly frames this as an ethical responsibility.

Monero does not run a structural mix-network at the protocol layer; Dandelion++ provides stem-phase sender-IP obfuscation but is not a cryptographic shuffle. Ring signatures themselves provide cryptographic-shuffle-like indistinguishability within the ring (anonymity-set 16 today, full-chain after FCMP++). Combination of (ring sigs + Dandelion++ + optional Tor/I2P) is the strongest on-chain mixing posture among production chains, but falls short of cMix-class IT-secure mix-network.

Only PQ signal on note-encryption shelf life is research-lab issue #151 (opened 2025-10-24), which proposes CSIDH-1024 for Jamtis-address forward secrecy. Announced research-stage proposal, not testnet, not mainnet, not foundation roadmap commitment. Score 5 ('announced') reflects discussion exists. CSIDH choice is technically interesting but isogeny-based schemes carry post-SIKE-break cautionary discount. No historical re-encryption plan exists.

Three production crypto-primitive replacements executed without contested split: PoW Cryptonight → RandomX (2019-11 v12); ring-signature MLSAG → CLSAG (2020-10 v13); range-proof original Bulletproofs → Bulletproofs+ (2022-08 v16). FCMP++ (in stressnet 2025-10-03) replaces ring signatures with full-chain membership proofs entirely. Each required hard-fork coordination, executed without contested split. No formal algorithm-agility specification; operational discipline of swapping core crypto primitives every 2-4 years is concrete. Partial deduction because there is no published spec for swapping Curve25519 itself.

Monero accounts have no native account-abstraction primitive comparable to ERC-4337 or EIP-7702. Subaddresses (since 2017) provide key-derivation primitive allowing unlimited fresh addresses from a single master keypair without on-chain registration; view keys allow read-only delegation. These are useful operational primitives but do NOT enable algorithm rotation, every subaddress is still on Curve25519. Rotating to a new algorithm requires moving funds. No documented client-layer PQC migration path. FCMP++ (stressnet) is a same-curve protocol upgrade, not a key-rotation primitive.

Most aggressive coordinated hard-fork cadence in v3.1.0 pilot peer set, historically every ~6 months in early years, slowing to every ~2 years post-v16. Coordinated forks executed: v9 RingCT (2017-01), v10 Bulletproofs (2018-10), v12 RandomX (2019-11), v13 CLSAG (2020-10), v16 Bulletproofs+/ring-16/view-tags (2022-08), with FCMP++ stressnet activated 2025-10-03 ahead of mainnet. No contested fork. Minor deduction reflects 2022-08 → 2026-05 representing a ~3.7-year gap without a mainnet hard fork (FCMP++ delayed beyond original 2024 target).

No public hybrid PQ design exists for Monero. CCS-funded Insight 2020 research program explored lattice-based ring signatures (Raptor, MatRiCT-family) and hash-based ring signatures, producing a write-up at insight-decentralized-consensus-lab/post-quantum-monero. That write-up is dated and was not absorbed into the current FCMP++ design path. Architecturally, deepest constraint is that ring signatures, stealth-address derivation, AND amount-commitment binding all share the same Curve25519. Cleanest hybrid path would be a parallel PQ signature scheme co-signing the spend authorization with note encryption migrated separately to a hybrid KEM. No such design has been published.

Monero does not use stateful hash signature schemes (XMSS / LMS / leanXMSS) anywhere in the stack. CLSAG and Schnorr-on-Ed25519 are stateless. Per rubric, stateless-by-default chains score full 15.

Monero is Nakamoto-style PoW (RandomX). It does not use BFT consensus and has no BLS-aggregation surface in consensus signing. Per rubric, this sub-score is N/A for chains using non-aggregating signatures at consensus. N/A treated as full credit; renormalized to /80 for Dim 4 total → 47/80 → 47/100 on the rubric scale.

0% of CLSAG signing, stealth-address derivation, Pedersen-commitment generation, range-proof verification, or PoW hashing runs on a PQC primitive as of 2026-05-01.

monero-project/monero contains no merged PQC primitive, no ML-DSA, no SLH-DSA, no ML-KEM, no FRI proof system, no CSIDH, no lattice-based ring signature. FCMP++ stressnet code uses generalized Bulletproofs and Curve Trees, both DL-based on Curve25519.

Monero is PoW; no validator set in BFT sense. PoW miners do not hold consensus signing keys. Conservative read: 0/15, since the analogue 'node operator infrastructure key' is also classical (TLS/SSH for daemon administration).

VOIDED to 0 per v3.1 rule (5a = 0). Even ignoring void rule, no dated, enforcement-mechanism-backed PQ deployment milestone exists. CCS 2020 research proposal was a research milestone that produced a write-up but did not establish a deployment timeline. Research-lab issue #131 (2024-12-10) calls for a 5-year production target but is community discussion. Issue #151 (2025-10-24) proposes CSIDH for Jamtis but Jamtis itself does not yet have a mainnet-activation date.

Announced PQC = ~2-3 in trailing 12 months (research-lab issue #131 opened Dec 2024, issue #151 opened Oct 2025, ongoing community discussion). Shipped PQC = 0. Monero community is unusually clear-eyed publicly about chain's pre-quantum posture; no foundation-level marketing of PQ readiness because there is no foundation. Minor deduction reflects that some community-side commentary occasionally overstates resilience of FCMP++ 'forward secrecy' framing.

Undisclosed. No PQ scheme is targeted for deployment. Reference scenarios from issue #151: NTRU/lattice-based KEM addresses run >1,300 characters and increase tx sizes up to 6× for 16-output transactions; Classic McEliece addresses are ~418KB and infeasible; CSIDH-1024 is more compact but adds ~310ms decrypt time per enote. Lattice ring-signature options carry kilobyte-scale per-tx overhead.

Top wallets are official monero-wallet-cli/monero-wallet-gui (monero-project), Feather Wallet (open-source desktop, Tor-default), Cake Wallet (mobile, multi-coin), MyMonero (web/light), Edge (mobile multi-coin). None has published a PQC roadmap. All track upstream monero-project crypto primitives, meaning a PQ migration would happen at the protocol level with wallet code following automatically.

Monero has minimal bridge surface, no major trustless bridges support XMR (Wormhole, LayerZero, Axelar all do not). Atomic swap research (COMIT-style XMR↔BTC) operational at low volume. Haveno is a P2P decentralized exchange (Bisq fork). Reduced surface is a structural privacy advantage but means few bridge-adjacent vendors are unaudited for PQC. None of named services has a published PQC roadmap.

Institutional custody for XMR is structurally limited following 2024 EU MiCA implementation, Binance delisted XMR in Feb 2024, Kraken restricts XMR in EU jurisdictions, BitGo and Fireblocks have limited or selective XMR support. Coinbase Custody, Anchorage, and Komainu do not list XMR. Remaining custody footprint concentrated in smaller specialized providers and self-custody. None of named institutions has a published PQC roadmap covering XMR keys.

Full-node self-hosting is the dominant pattern (monero-project default). Public remote-node aggregator monero.fail tracks ~100s of community-operated public nodes. RPC providers in Infura/Alchemy/QuickNode/Helius mainstream do not support XMR. HSMs: no documented Ledger / Trezor / Thales / YubiHSM integration that exposes Monero spend keys to a hardware-backed PQ migration path. Ledger does support Monero (including Live integration) but the curve and signature scheme are classical Ed25519 only. TEEs not used in core consensus path.

Monero is RandomX PoW, ASIC-resistant, CPU-mineable. Mining-pool concentration is moderate (top 2-3 pools historically have approached but not crossed 50% combined hashrate; community pressure has led miners to migrate when concentration grows). No premine, no foundation control of mining capacity. Nakamoto coefficient for hashrate is healthier than most PoW chains in the peer set. Single dominant client (monero-project/monero), modest C++/Rust dual-stack via FCMP++ work.

Strongest demonstrated coordinated-fork track record among privacy chains. Bulletproofs critical vulnerability disclosure (March 2020, prior to deployment) handled with coordinated patch and on-schedule hard fork. Ring-signature heuristic vulnerabilities (EAE-class) led to coordinated minimum-ring-size increases (4→7→11→16) over multiple forks. RandomX migration (2019-11) was a coordinated transition under economic-pressure conditions. No contested fork, no chain split. Minor deduction reflects FCMP++ delays beyond original 2024 target.

There is no foundation. Coordination runs through: Monero Research Lab (MRL), pseudonymous and named contributors (koe, jeffro256, tevador, kayabaNerve historically active); Community Crowdfunding System (CCS) at ccs.getmonero.org; dev mailing list and weekly #monero-dev IRC meetings. No named PQC migration WG, no named PQ-lead role, no published mandate for PQ migration. Community-driven model has been operationally effective for crypto upgrades but lacks named-accountability structure for full credit.

Demonstrated coordinated upgrade execution under several adversarial conditions: ASIC manufacturer attacks (Bitmain Antminer X3 / Innosilicon, 2018; led to Cryptonight algorithm changes and ultimately RandomX); March 2020 Bulletproofs critical pre-deployment vulnerability disclosure; 2024 EU MiCA delisting wave. Recovery from original 2017 unintentional inflation-bug (Bytecoin-inherited) was coordinated. Track record is solid for security-pressure coordination but does not include a quantum-specific or cryptography-replacement-under-attacker-pressure event.

No community honeypot, no rate-limited spending rule, no cryptographic tripwire embedded in consensus, no automated-response mechanism for Shor / chain-deanonymization breakage published. Monero ethos, privacy-by-default, no-foundation, is structurally inhospitable to a 'freeze quantum-vulnerable addresses' rescue path.