Litecoin LTC

Claim: LIP-0003 acknowledges quantum risk for MWEB Pedersen commitment binding and proposes switch commitments to Elgamal; no comprehensive cryptographic inventory or quantum threat model exists.

Coverage basis: Protocol specification (LIP-0003), public source code, third-party quantum analysis (Google iacr 2026/625, BMIC 2026)

Implementation score: 0.25 · Evidence confidence: High

Issue classification: quantum-critical uncertainty · Score treatment: score-reducing

Quantum blocker: No public cryptographic inventory or quantum threat assessment has been published by the Litecoin project; LIP-0003 addresses only one narrow vulnerability

Assurance: Third-party quantum analysis (Google, BMIC, PostQuantum.com) provides an external assessment but does not substitute for a project-published inventory and threat model

LIP-0003 section 'Switch Commitment to Elgamal' explicitly states: 'We will implement switch commitments to elgamal as a safety measure against the threat of quantum computers.' This is a specification-level acknowledgment (2019-2022) of one specific quantum vulnerability, not a comprehensive assessment. The switch commitment has never been implemented or activated on mainnet.

• https://github.com/litecoin-project/lips/blob/master/lip-0003.mediawiki
• https://eprint.iacr.org/2026/625
• https://bmic.ai/gb/quantum-audit/litecoin/
• https://github.com/litecoin-project/litecoin

Claim: Source code, protocol specifications (LIPs), MWEB audit (Quarkslab 2022), block explorers, and third-party quantum analyses collectively document Litecoin's cryptographic primitives and quantum vulnerabilities.

Coverage basis: Public code repositories, LIP specifications, Quarkslab audit report, block explorers (blockchair.com, mwebexplorer.com), Google Quantum AI paper

Implementation score: 0.5 · Evidence confidence: High

Issue classification: none · Score treatment: not applicable

Assurance: Evidence exists from multiple independent sources but has not been assembled by the project into a coherent quantum risk assessment. MWEB audit is stale (2022) and explicitly excludes quantum considerations.

The evidence is sufficient for third-party quantum risk evaluation but does not represent project-organized assessment preparedness.

• https://github.com/litecoin-project/litecoin
• https://github.com/litecoin-project/lips/blob/master/lip-0003.mediawiki
• https://blog.quarkslab.com/audit-of-the-mimblewimble-integration-inside-litecoin.html
• https://blockchair.com/litecoin
• https://www.mwebexplorer.com/
• https://eprint.iacr.org/2026/625

Claim: All transaction signatures use ECDSA on secp256k1 (base layer) or classical Schnorr signatures on secp256k1-zkp (MWEB). No PQC or hybrid-PQC signatures exist.

Coverage basis: ECDSA/secp256k1 for base-layer P2PKH, P2SH, P2WPKH, P2TR; Schnorr/secp256k1-zkp for MWEB

Implementation score: 0 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: cap-applying

Quantum blocker: Active production spend authorization remains entirely ECC/Schnorr-only with no PQC or hybrid path

Assurance: Confirmed by source code review, Quarkslab audit, and multiple independent analyses

Triggered 'Active production spend authorization remains entirely ECC/BLS/Schnorr/EdDSA-only' Readiness & Risk Cap (max QRI 40). LIP-0003 switch commitment does not address transaction signing.

• https://github.com/litecoin-project/litecoin
• https://github.com/litecoin-project/libmw
• https://blog.quarkslab.com/audit-of-the-mimblewimble-integration-inside-litecoin.html
• https://litecoin.com/learning-center/addresses-prefixes

Claim: All Litecoin address formats (L, M, ltc1q, ltc1p) derive from ECDSA public keys. P2PK outputs directly expose public keys. P2PKH/P2WPKH addresses expose public keys on spend. No PQ address formats exist.

Coverage basis: Standard Bitcoin-fork address model: P2PK, P2PKH, P2SH, P2WPKH, P2TR all ECDSA-based; MWEB uses secp256k1-zkp stealth addresses

Implementation score: 0 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Quantum blocker: All address formats expose or derive from ECDSA public keys; long-exposure quantum-vulnerable ownership paths exist by default

Litecoin's official documentation misleadingly states addresses provide 'Quantum resistant' protection because SHA256 and RIPEMD are quantum-resistant. This ignores that spend authorization still requires ECDSA private key—hash functions protect address derivation, not transaction authorization.

• https://litecoin.com/learning-center/addresses-prefixes
• https://blockchair.com/litecoin
• https://litecoin.watch/articles/litecoin-address-formats-explained-legacy-segwit-bech32-and-mweb

Claim: Litecoin is a PoW chain with no validator signatures, BLS threshold signatures, VRFs, or finality signatures. Consensus-critical authentication is not applicable.

Coverage basis: PoW consensus via Scrypt; no validator set or BFT finality

Implementation score: 1 · Evidence confidence: High

Issue classification: none · Score treatment: not applicable

PoW consensus authentication (hash-based) is not directly quantum-vulnerable in the way BLS validator signatures would be. Scrypt PoW itself provides no additional quantum resistance vs SHA-256.

• https://github.com/litecoin-project/litecoin
• https://litecoin.org/

Claim: Base-layer UTXO state integrity relies on ECDSA script verification. MWEB uses Pedersen commitments and Bulletproofs on secp256k1-zkp—all classical ECC, quantum-vulnerable.

Coverage basis: ECDSA for base-layer script authorization; Pedersen commitments + Bulletproofs for MWEB confidential transactions and supply binding

Implementation score: 0 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Quantum blocker: MWEB Pedersen commitments have fixed public parameters; a single ECDLP solution enables permanent classical inflation exploits (Google iacr 2026/625)

Assurance: Quarkslab audit (2022) confirms implementation correctness for classical security but does not assess quantum vulnerabilities. Google paper (2026) provides independent quantum vulnerability analysis.

LIP-0003's proposed switch-commitment-to-Elgamal would sacrifice hiding (privacy) to preserve binding (supply integrity) post-quantum, but this has never been implemented. The Google paper notes the Litecoin community 'chose to sacrifice privacy protection rather than monetary integrity' in this design.

• https://blog.quarkslab.com/audit-of-the-mimblewimble-integration-inside-litecoin.html
• https://eprint.iacr.org/2026/625
• https://github.com/litecoin-project/libmw

Claim: MWEB uses MimbleWimble with classical ECC: Pedersen commitments, Bulletproof range proofs, ECDH key exchange for stealth addresses, and Schnorr signatures. All are quantum-vulnerable.

Coverage basis: MWEB extension block: confidential transactions via Pedersen commitments, range proofs via Bulletproofs, stealth addresses via ECDH

Implementation score: 0 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Quantum blocker: MWEB privacy guarantees are retroactively breakable by a future CRQC; historical confidential transactions can be deanonymized irreversibly

Assurance: PostQuantum.com categorizes Litecoin MWEB as Category 4: 'Privacy-preserving with retroactive deanonymization risk.' This damage cannot be undone through migration.

MWEB does not use pairing-based proof systems (ZK-SNARKs); it uses Bulletproofs which rely on discrete log assumptions. The zkSTARK alternative was evaluated by the Litecoin community but rejected due to cost.

• https://blog.quarkslab.com/audit-of-the-mimblewimble-integration-inside-litecoin.html
• https://eprint.iacr.org/2026/625
• https://postquantum.com/quantum-threat-crypto/blockchain-ecosystem-quantum-vulnerabilities/
• https://academy.binance.com/en/articles/what-is-mimblewimble

Claim: Litecoin uses standard Bitcoin-style P2P networking with no PQC or hybrid-PQC protection for node identity or peer authentication.

Coverage basis: Standard Bitcoin-fork P2P networking; no special quantum protection

Implementation score: 0 · Evidence confidence: Medium

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

Assurance: P2P node identity is not spend-authorization, consensus, bridge, or custody-critical. Per QRI spec Section 7, this could be satisfied-by-design if asset-spending authorization were PQ-signed—but it is not. Currently score-reducing but not a primary quantum blocker.

P2P transport quantum vulnerability is a secondary concern relative to ECDSA spend authorization and long-exposure public key risk.

• https://github.com/litecoin-project/litecoin

Claim: No PQC or hybrid-PQC wallet, custody, or HSM workflows exist for Litecoin. All wallet software uses classical ECDSA key management.

Coverage basis: Litecoin Core, Electrum-LTC, Cake Wallet, hardware wallets—all ECDSA-only

Implementation score: 0 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

No wallet supports PQ or hybrid-PQC signing paths because no such protocol capability exists on Litecoin mainnet.

• https://litecoin.org/
• https://electrum-ltc.org/
• https://docs.cakewallet.com/cryptos/litecoin

Claim: 0% of Litecoin value-at-risk is protected from quantum key-recovery attacks. ~0.45% of supply (~378,000 LTC) is in MWEB which is also quantum-vulnerable. >99.5% remains on the transparent ECC-only ledger.

Coverage basis: ~84M LTC total supply; ~378,000 LTC in MWEB (~$20M); all addresses ECC-based; significant long-exposure P2PK and reused-address value

Implementation score: 0.05 · Evidence confidence: Medium

Issue classification: quantum-critical vulnerability · Score treatment: cap-applying

Quantum blocker: Material long-exposure quantum-vulnerable value exists with no migration, freeze, deprecation, burn, recovery, or policy path

Assurance: Value-at-risk figures are approximate. Exact percentage of LTC supply in addresses with exposed public keys (P2PK, reused P2PKH/P2WPKH, P2TR key-path) is not independently verified for Litecoin specifically. Bitcoin estimates suggest >34% of BTC supply has exposed public keys; Litecoin likely has comparable or higher exposure due to similar UTXO architecture and longer history of address reuse.

Coverage <25% → score 1 of 20 per QRI Section 9.3.1. MWEB's ~0.45% of supply does not meaningfully change coverage. MWEB is itself quantum-vulnerable. Triggered 'Material long-exposure quantum-vulnerable value exists with no migration path' cap (max QRI 55).

• https://www.mwebexplorer.com/
• https://blockchair.com/litecoin
• https://bmic.ai/gb/quantum-audit/litecoin/
• https://postquantum.com/quantum-threat-crypto/blockchain-ecosystem-quantum-vulnerabilities/

Claim: No critical wallets (treasuries, exchanges, custodians, bridges, foundations) have migrated to PQC or hybrid-PQC protection, as no such capability exists on Litecoin.

Coverage basis: No PQ wallet infrastructure exists

Implementation score: 0 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Exchange and custody migration is not possible when the protocol itself provides no PQC migration path.

• https://litecoin.org/
• https://github.com/litecoin-project/litecoin

Claim: No formal identification, measurement, deprecation, freeze, or migration mechanism exists for quantum-vulnerable UTXOs or accounts.

Coverage basis: No policy or mechanism exists

Implementation score: 0 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Early P2PK mining outputs (analogous to Bitcoin's ~1.7M BTC P2PK exposure) are permanently vulnerable with no policy path. Charlie Lee (Litecoin founder) publicly warned about this risk for Bitcoin in March 2026 but no Litecoin-specific policy has been proposed.

• https://github.com/litecoin-project/litecoin
• https://litecoin.org/

Claim: LIP-0003 proposes a switch-commitment-to-Elgamal for MWEB as a quantum safety measure, but this is a narrow specification-level proposal (unimplemented) addressing only MWEB commitment binding, not base-layer ECDSA migration.

Coverage basis: LIP-0003 (2019-2022), section 'Switch Commitment to Elgamal'

Implementation score: 0.25 · Evidence confidence: High

Issue classification: quantum-critical uncertainty · Score treatment: score-reducing

Quantum blocker: No roadmap exists for base-layer ECDSA-to-PQC migration; LIP-0003 switch commitment addresses only MWEB and has no implementation

Assurance: LIP-0003 explicitly states: 'We will implement switch commitments to elgamal as a safety measure against the threat of quantum computers. More discussion must be had around its specific implementation and activation.' No progress beyond this specification text since 2022.

This is the only quantum-related proposal in any Litecoin Improvement Proposal. It was specified alongside MWEB activation (2022) but never prioritized for implementation. Charlie Lee's March 2026 public comments about quantum risk have not translated into a formal roadmap.

• https://github.com/litecoin-project/lips/blob/master/lip-0003.mediawiki

Claim: No PQC or hybrid-PQC account creation, wallet tooling, transaction paths, custody paths, user-facing warnings, education, or migration prompts exist.

Coverage basis: No PQ infrastructure exists

Implementation score: 0 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

No wallet warns users about quantum-vulnerable address formats or recommends migration strategies.

• https://litecoin.org/
• https://github.com/litecoin-project/litecoin

Claim: No enforcement mechanisms exist (deprecation, freeze, disabled legacy signing, restricted withdrawals, unsafe-path blocking, mandatory migration deadlines). No exchange, custody, bridge, wallet, or infrastructure coordination for quantum migration.

Coverage basis: No enforcement or coordination exists

Implementation score: 0 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

The MWEB March 2026 incident demonstrated Litecoin's ability to coordinate emergency miner upgrades, but this was for classical security, not quantum migration.

• https://github.com/litecoin-project/litecoin
• https://litecoin.org/

Claim: No quantum-specific vulnerability disclosure process, incident-response plan, or governance process has been published.

Coverage basis: No quantum-specific process exists

Implementation score: 0 · Evidence confidence: High

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

Assurance: Per QRI spec Section 8.2, lack of a formal quantum-specific IR playbook does not by itself create a Readiness & Risk Cap when no PQC production system exists. This is recorded as an assurance note.

Litecoin demonstrated classical incident response capability during the MWEB March-April 2026 security incident, but no quantum-specific processes are formalized.

• https://litecoin.org/

Claim: No NIST-standardized, standards-track, or broadly reviewed PQC or hybrid-PQC algorithms are used in any Litecoin production layer.

Coverage basis: No PQC algorithms deployed

Implementation score: 0 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Litecoin uses only classical algorithms: ECDSA (secp256k1), Schnorr (secp256k1-zkp), SHA-256, RIPEMD-160, Scrypt. None are post-quantum for their cryptographic purpose.

• https://github.com/litecoin-project/litecoin
• https://github.com/litecoin-project/libmw

Claim: MWEB audit (Quarkslab 2021-2022) covers classical cryptography implementation correctness but explicitly excludes quantum considerations. No PQC audit exists because no PQC implementation exists.

Coverage basis: Quarkslab audit of MWEB integration; audit scope excluded low-level cryptographic primitives and quantum analysis

Implementation score: 0.25 · Evidence confidence: High

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

Assurance: Audit is stale (2022) and scope-mismatched for quantum assessment—it explicitly states 'Very low-level cryptographic primitives are left out of scope (secp256k1, bulletproof) and considered secure.' No quantum threat model was applied. The audit is still relevant for classical implementation correctness of current MWEB design.

Partial credit (0.25) for having an independent audit of the production cryptographic implementation, even though quantum considerations are absent.

• https://blog.quarkslab.com/audit-of-the-mimblewimble-integration-inside-litecoin.html
• https://blog.quarkslab.com/resources/2021-12-08_litecoin/21-08-872-REP.pdf

Claim: Litecoin Core and libmw are fully open source under permissive licenses. However, no PQC implementation exists to be open source.

Coverage basis: MIT-licensed code on GitHub; no PQC code exists

Implementation score: 0 · Evidence confidence: High

Issue classification: none · Score treatment: not applicable

Assurance: Classical code is fully open source and reproducible. This subfactor measures PQC implementation openness; since no PQC implementation exists, score is 0.

The classical implementation's open-source nature is a positive indicator for future PQC development transparency.

• https://github.com/litecoin-project/litecoin
• https://github.com/litecoin-project/libmw

Claim: No documented parameter agility or PQC upgrade path exists. LIP-0003's switch commitment mentions activation via miner signaling but provides no concrete parameters or timeline.

Coverage basis: No PQC agility documentation exists

Implementation score: 0 · Evidence confidence: High

Issue classification: quantum-critical uncertainty · Score treatment: score-reducing

Assurance: LIP-0003 mentions BIP8 activation with 75% miner signaling threshold for the switch commitment, but this is only a high-level mechanism description with no concrete parameters.

Litecoin's Bitcoin-fork architecture may allow it to adopt Bitcoin PQC upgrades (e.g., BIP-360 P2QRH) relatively quickly if they materialize, but this is speculative and not a documented upgrade path.

• https://github.com/litecoin-project/lips/blob/master/lip-0003.mediawiki

Claim: Litecoin does not use stateful hash-based signatures (XMSS/LMS). Not applicable.

Coverage basis: No stateful signatures in use

Implementation score: 1 · Evidence confidence: High

Issue classification: none · Score treatment: not applicable

• https://github.com/litecoin-project/litecoin

Claim: No performance or resource-impact analysis for PQC signature/verification costs has been published.

Coverage basis: No analysis exists

Implementation score: 0 · Evidence confidence: High

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

Assurance: Per QRI spec, lack of a formal performance benchmark does not by itself reduce the QRI Score when no PQC implementation exists. Recorded as an assurance note for future PQC consideration.

Litecoin's 2.5-minute block time and 1 MB block size would need analysis for PQC signature size impact (ML-DSA signatures ~2.4KB, SLH-DSA ~7-8KB vs ECDSA ~70 bytes).