Kaspa KAS

Claim: A community-authored KIP identifies Kaspa's quantum-vulnerable cryptography (P2PK addresses, Schnorr/ECDSA on secp256k1, ECDLP dependence). The Kaspa wiki FAQ acknowledges 'Not yet' quantum resistant and links to community resources including Shai Wyborski's analysis.

Coverage basis: Community proposal and public researcher analysis; no official project-authored inventory exists.

Implementation score: 0.25 · Evidence confidence: Medium

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

Quantum blocker: No official project-authored cryptographic inventory exists; community proposal is not adopted by core team.

Assurance: The community KIP provides a reasonable inventory of vulnerable primitives but is not an official project deliverable. Shai Wyborski's public analysis of MuHash vulnerability adds credible independent identification.

Kaspa wiki FAQ directly answers 'Is Kaspa quantum resistant?' with 'Not yet' and links to Shai's explanation and the community KIP. This is public acknowledgment, not a formal inventory.

• https://github.com/bitcoinsSG/Kaspa-Post-Quantum-Improvement-Proposal
• https://wiki.kaspa.org/en/faq
• https://github.com/bitcoinsSG/Kaspas-Phase-I-Towards-Quantum-Resiliency

Claim: Public evidence includes the community KIP, Shai Wyborski's MuHash analysis thread, Kaspa wiki FAQ, and open-source code demonstrating classical cryptography.

Coverage basis: Public code, community proposal, researcher analysis; no formal audit or official spec-level assessment.

Implementation score: 0.25 · Evidence confidence: Medium

Issue classification: assurance-only caveat · Score treatment: score-reducing

Assurance: No independent cryptographic audit exists for Kaspa's core protocol. Evidence quality is sufficient to verify the vulnerable classical cryptography but lacks formal independent review of quantum-critical scope.

The open-source codebase (rusty-kaspa) provides reproducible evidence of classical-only cryptography. Explorer confirms P2PK address exposure in production.

• https://github.com/kaspanet/rusty-kaspa
• https://kaspa.org/
• https://explorer.kaspa.org/
• https://github.com/bitcoinsSG/Kaspa-Post-Quantum-Improvement-Proposal

Claim: Kaspa uses Schnorr signatures (default) with ECDSA also supported, both on secp256k1 curve. No post-quantum or hybrid signature scheme is available on mainnet.

Coverage basis: ECC-only; no PQ or hybrid path exists.

Implementation score: 0 · Evidence confidence: High

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

Quantum blocker: All production spend authorization is ECC-only (Schnorr/ECDSA on secp256k1), fully vulnerable to Shor's algorithm.

Assurance: Evidence is high confidence: Cube Exchange documentation, open-source code in rusty-kaspa, and protocol documentation all confirm Schnorr/ECDSA-only signatures. No contradictory evidence exists.

Schnorr signatures are the default; ECDSA is also supported. Both are on secp256k1 and fully breakable by Shor's algorithm. There is no hybrid-PQC or PQC signature option on mainnet.

• https://www.cube.exchange/what-is/kaspa
• https://github.com/kaspanet/rusty-kaspa
• https://kaspa-mdbook.aspectron.com/transactions/sighashes.html

Claim: Kaspa's default address format is P2PK (Pay-to-Public-Key), which exposes the full 32-byte Schnorr public key immediately upon funding. No hash-based address protection is default or mandatory.

Coverage basis: Long-exposure quantum-vulnerable public keys exist for all funded P2PK addresses.

Implementation score: 0 · Evidence confidence: High

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

Quantum blocker: P2PK address format exposes public keys at funding time, creating long-exposure attack surface. No production hash-based or PQ address protection exists.

Assurance: High confidence: mainnet explorer confirms P2PK outputs with visible public keys. Community KIP explicitly documents this exposure.

Community KIP proposes P2PKH-Blake2b-256-via-P2SH addresses to hide public keys until spend time, but this is a draft proposal with no production deployment or wallet adoption.

• https://explorer.kaspa.org/
• https://github.com/bitcoinsSG/Kaspa-Post-Quantum-Improvement-Proposal
• https://www.cube.exchange/what-is/kaspa

Claim: Kaspa is a proof-of-work blockchain with no validator set, no validator signatures, no BLS threshold signatures, no VRFs, and no finality signatures. Consensus is achieved through GHOSTDAG block ordering on accumulated PoW.

Coverage basis: N/A: PoW chain with no validator authentication layer.

Implementation score: 1 · Evidence confidence: High

Issue classification: none · Score treatment: not applicable

While consensus authentication via validators is N/A, the MuHash UTXO commitment mechanism (evaluated under state-integrity) is consensus-critical and quantum-vulnerable.

• https://kaspa.org/
• https://kaspa.org/lore

Claim: Kaspa uses MuHash for incremental UTXO set commitments. MuHash relies on the Elliptic Curve Discrete Logarithm Problem (ECDLP), making it breakable by Shor's algorithm. Kaspa prunes historical block data, so nodes depend on these commitments for state verification.

Coverage basis: Quantum-vulnerable state-integrity mechanism structurally embedded in protocol design.

Implementation score: 0 · Evidence confidence: High

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

Quantum blocker: MuHash UTXO commitment scheme is ECDLP-dependent. Quantum adversary can forge commitments, enabling state manipulation and chain-history rewriting after pruning.

Assurance: High confidence: the MuHash vulnerability was publicly analyzed by Kaspa researcher Shai Wyborski (April 2026). Multiple secondary sources corroborate the analysis. The ECDLP dependence of MuHash is a mathematical property, not implementation-specific.

Mitigation options (archival nodes, post-quantum hash like LtHash) introduce trust assumptions or significant performance overhead. No official migration plan for MuHash exists.

• https://captainaltcoin.com/kaspas-quantum-achilles-heel-why-utxo-commitments-will-break-first/
• https://bitcoinist.com/kaspas-quantum-achilles-heel-utxo-commitments-can-be-broken-the-only-crypto-that-protects-you-is-bmic/
• https://www.ainvest.com/news/kaspa-unveils-evm-layer-2-roadmap-quantum-security-concerns-2604/

Claim: KIP-16 (merged into rusty-kaspa) adds OpZkPrecompile for on-chain verification of RISC0-Groth16 and RISC0-Succinct (STARKs) proofs. STARKs are hash-based and quantum-resistant.

Coverage basis: Partial: STARK verification infrastructure exists on mainnet for off-chain ZK computation, but does not protect native spend authorization or state integrity.

Implementation score: 0.25 · Evidence confidence: Medium

Issue classification: none · Score treatment: confidence-only

Assurance: Medium confidence: KIP-16 merge is confirmed via community reports and GitHub activity but the exact mainnet activation status for STARK verification should be verified against a block explorer or protocol documentation.

STARK verification is quantum-resistant but limited to off-chain computation proofs. It does not protect native L1 spend authorization, address exposure, or UTXO commitment integrity. Groth16 verification (also included) is pairing-based and quantum-vulnerable.

• https://www.reddit.com/r/kaspa/comments/1hk56t9/kaspa_vs_quantum_computing/

Claim: No post-quantum or hybrid P2P transport protection is documented. P2P node identity is not consensus-critical, spend-critical, bridge-critical, or custody-critical for Kaspa's PoW architecture.

Coverage basis: Classical P2P; not independently verified as quantum-safe.

Implementation score: 0.25 · Evidence confidence: Low

Issue classification: operational/product caveat · Score treatment: score-reducing

Assurance: Low confidence: no specific P2P cryptography documentation was identified. The practical quantum risk from P2P compromise in a PoW system is low (cannot forge signatures), but the formal QRI precondition for satisfied-by-design is not met because spend authorization is not PQ-signed.

P2P node identity compromise in Kaspa's PoW architecture would not directly enable asset theft. However, eclipse attacks could theoretically delay transaction confirmation. This is a minor risk relative to the dominant spend-authorization and state-integrity vulnerabilities.

• https://github.com/kaspanet/rusty-kaspa

Claim: No Kaspa wallet, custody solution, HSM, or hardware wallet supports post-quantum or hybrid-PQC signing. All wallet workflows use classical Schnorr/ECDSA signatures.

Coverage basis: No PQ wallet support exists in production.

Implementation score: 0 · Evidence confidence: High

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

Quantum blocker: No production wallet, custody, or HSM workflow supports PQ or hybrid-PQC signing.

Assurance: High confidence: all Kaspa wallet options (Kaspium, KDX, web wallet, CLI, Ledger integration) use classical cryptography. Community KIP Phase I proposes P2PKH address generation but has not been adopted by any major wallet.

Ledger hardware wallet integration exists for Kaspa but uses classical Schnorr signatures only. No PQ hardware signing path is available.

• https://github.com/kaspanet/rusty-kaspa
• https://wiki.kaspa.org/en/updates-and-projects

Claim: Approximately 100% of Kaspa's circulating supply is held in quantum-vulnerable P2PK addresses with ECC-only spend authorization and long-exposure public keys. No migration has occurred.

Coverage basis: <25% protected; effectively 0%.

Implementation score: 0.05 · Evidence confidence: High

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

Quantum blocker: ~100% of value-at-risk remains quantum-vulnerable with no migration path in production. All UTXOs use P2PK or similarly exposed formats.

Assurance: High confidence: mainnet explorer confirms P2PK outputs for all funded addresses. No P2PKH or other hash-protected address format is used in production. Market data from Gate.io (May 2026) confirms ~$922M market cap.

Coverage score of 0.05 (1/20) reflects <25% threshold with negligible protection. Even the 1-point floor may be generous since 0% of value has any quantum protection.

• https://explorer.kaspa.org/
• https://www.gate.com/blog/kaspa-toccata-hard-fork-pow-blockchain-programmable-era-upgrade-analysis

Claim: No critical wallets (treasuries, exchanges, custodians, bridges, foundations, major protocols) have been migrated to quantum-resistant controls. No PQ wallet infrastructure exists.

Coverage basis: No critical wallets migrated.

Implementation score: 0 · Evidence confidence: High

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

Quantum blocker: No critical wallets have been migrated to quantum-resistant controls.

Assurance: High confidence: no evidence of any exchange, custodian, or protocol migrating Kaspa holdings to quantum-resistant addresses. Kaspa wiki FAQ confirms 'Not yet' quantum resistant.

Even if individual users wanted to self-custody with quantum-safe practices, no production wallet supports PQ address generation or signing for Kaspa.

• https://explorer.kaspa.org/
• https://wiki.kaspa.org/en/faq

Claim: Community KIP identifies the P2PK vulnerability and proposes P2PKH-Blake2b-256-via-P2SH as mitigation. No deprecation, freeze, burn, or migration policy exists in production.

Coverage basis: Identified in community proposal only; no production deprecation or measurement.

Implementation score: 0.25 · Evidence confidence: Medium

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

Quantum blocker: Legacy vulnerable pools are identified only in a community draft proposal. No official deprecation, freeze, or migration policy exists.

Assurance: Medium confidence: the community KIP identifies the vulnerability correctly and proposes a technically sound Phase I mitigation, but the proposal is not officially adopted and has no implementation timeline.

The P2PKH-Blake2b-256-via-P2SH proposal defers public key exposure to spend time (short-exposure), which is a meaningful improvement over the current P2PK (long-exposure) design. However, spend-time signatures remain ECC-based and quantum-vulnerable.

• https://github.com/bitcoinsSG/Kaspa-Post-Quantum-Improvement-Proposal
• https://github.com/bitcoinsSG/Kaspas-Phase-I-Towards-Quantum-Resiliency

Claim: Community-authored KIP proposes a 4-phase quantum resiliency strategy: Phase I (P2PKH-Blake2b-via-P2SH wallet upgrade), Phase II (Grover's algorithm protections), Phase III (network-wide transition mechanisms), Phase IV (full PQC implementation). Phases II-IV are 'to be published after Phase I.'

Coverage basis: Community proposal only; not an official project roadmap.

Implementation score: 0.25 · Evidence confidence: Low

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

Quantum blocker: No official project roadmap for quantum migration exists. Community proposal has no adoption by core team.

Assurance: Low confidence: the proposal is authored by a single community member (bitcoinsSG), has not been assigned a KIP number, remains in draft status since May 2025, and has no indication of core team review or adoption. Only Phase I has technical specifications; Phases II-IV are placeholder outlines.

The proposal acknowledges Kaspa core team members in acknowledgments (Ori Newman, Michael Sutton, Shai Wyborski, Yonatan Sompolinsky) but this does not constitute official endorsement or commitment.

• https://github.com/bitcoinsSG/Kaspa-Post-Quantum-Improvement-Proposal
• https://github.com/bitcoinsSG/Kaspas-Phase-I-Towards-Quantum-Resiliency

Claim: No PQ account creation, wallet tooling, transaction paths, custody paths, user-facing warnings, education, or migration prompts exist in any production Kaspa wallet or tool.

Coverage basis: No migration accessibility in production.

Implementation score: 0 · Evidence confidence: High

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

Quantum blocker: No migration tooling, PQ account creation, or user-facing quantum warnings exist in any production wallet.

Assurance: High confidence: all production Kaspa wallets (Kaspium, KDX, web wallet, CLI) generate P2PK addresses with no PQ option. No wallet displays quantum risk warnings.

Community KIP Phase I proposes Rust library (kaspa-p2pkh-blake2b) and CLI tools for P2PKH address generation but these have not been integrated into any production wallet.

• https://wiki.kaspa.org/en/updates-and-projects
• https://github.com/kaspanet/rusty-kaspa

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

Coverage basis: No enforcement or coordination in production.

Implementation score: 0 · Evidence confidence: High

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

Quantum blocker: No enforcement mechanisms or ecosystem coordination for quantum migration exists.

Assurance: High confidence: absence of evidence is meaningful here — no exchange has announced Kaspa quantum migration support, no wallet has deprecated P2PK, no core team coordination initiative exists.

The community KIP Phase I is designed as voluntary wallet-level adoption, which inherently lacks enforcement. Without core team or major wallet adoption, coordination cannot begin.

Claim: No quantum-specific vulnerability disclosure process, incident response plan, or emergency governance mechanism was identified for Kaspa.

Coverage basis: No quantum-specific incident response process.

Implementation score: 0 · Evidence confidence: Medium

Issue classification: operational/product caveat · Score treatment: note-only

Assurance: Medium confidence: no quantum-specific incident response process was found in public documentation. Kaspa likely has general security disclosure channels but nothing quantum-specific. This is treated as note-only per QRI spec: 'lack of a formal quantum-specific incident-response playbook' does not create a Readiness & Risk Cap by itself.

While quantum-specific IR is desirable, the absence does not independently create a quantum-enabled attack path. The dominant vulnerabilities (ECC spend auth, P2PK exposure, MuHash) are structural, not incident-response-dependent.

Claim: Kaspa does not use any NIST-standardized PQC algorithms for spend authorization or state integrity. KIP-16 introduces STARK verification (hash-based, quantum-resistant, broadly reviewed) for off-chain ZK computation proofs.

Coverage basis: No PQC algorithms for critical layers; STARKs for ZK proof verification only.

Implementation score: 0.1 · Evidence confidence: Medium

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

Quantum blocker: No NIST-standardized or broadly reviewed PQC algorithms are used for spend authorization, address protection, or state integrity.

Assurance: Medium confidence: STARKs are well-reviewed and quantum-resistant, but their application in Kaspa (KIP-16) is limited to ZK proof verification and does not protect the layers where quantum attack would cause theft or state corruption.

Community KIP Phase IV proposes eventual full PQC implementation but provides no algorithm selection, specification, or timeline.

• https://github.com/kaspanet/rusty-kaspa
• https://www.reddit.com/r/kaspa/comments/1hk56t9/kaspa_vs_quantum_computing/

Claim: No independent cryptographic audit of Kaspa's core protocol or quantum-critical implementation was identified.

Coverage basis: No audit exists.

Implementation score: 0 · Evidence confidence: Medium

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

Assurance: Medium confidence: no audit was found through web search and evidence dossier. The classical cryptography (Schnorr/ECDSA on secp256k1) is well-understood and verifiable from public code. Per QRI spec, 'No independent audit and the quantum-security property cannot be verified from other public evidence' would lower score or apply cap, but here the vulnerability (ECC-only) is fully verifiable from public code and documentation. This is treated as an assurance-only caveat.

An audit would be valuable for verifying the correctness of the cryptographic implementation and identifying non-quantum vulnerabilities, but the quantum-critical properties (ECC dependence, MuHash ECDLP binding) are mathematically inherent and do not require an audit to verify.

Claim: Kaspa's primary implementation (rusty-kaspa) is open-source (Rust, MIT/Apache-style license) and publicly available on GitHub. The codebase is actively maintained and independently buildable.

Coverage basis: Open-source classical implementation; no PQC code exists.

Implementation score: 1 · Evidence confidence: High

Issue classification: none · Score treatment: note-only

Assurance: High confidence: rusty-kaspa is a well-maintained open-source repository with broad contributor base. However, the codebase implements only classical cryptography. The community P2PKH-Blake2b library (separate repo) is open-source but not integrated.

Open-source reproducibility is a strength for verifying the current classical implementation. It does not compensate for the absence of PQC code.

• https://github.com/kaspanet/rusty-kaspa
• https://github.com/kaspanet/kaspad

Claim: The community KIP outlines a phased migration strategy. DAGKnight (KIP-2) is a planned consensus upgrade. Toccata hard fork (June 2026) introduces covenant-based programmability that could theoretically support future migration mechanisms. No formal parameter agility documentation for PQC exists.

Coverage basis: Community proposal for future path; no formal PQC agility documentation.

Implementation score: 0.25 · Evidence confidence: Low

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

Assurance: Low confidence: the community KIP is a draft with no official adoption. DAGKnight and Toccata are real protocol upgrades but do not address quantum cryptographic migration. No formal parameter agility specification exists.

Kaspa's hard-fork-based upgrade mechanism (Crescendo, Toccata, planned DAGKnight) demonstrates the network can execute protocol upgrades. However, quantum migration would require fundamentally new cryptographic primitives, not just parameter changes.

• https://github.com/bitcoinsSG/Kaspa-Post-Quantum-Improvement-Proposal
• https://github.com/kaspanet/kips/blob/master/kip-0002.md
• https://kaspa.org/lore

Claim: Kaspa does not use stateful hash-based signatures (XMSS/LMS) and has no PQC implementation. This subfactor is not applicable to the current production scope.

Coverage basis: N/A: no PQC implementation exists to assess.

Implementation score: 1 · Evidence confidence: High

Issue classification: none · Score treatment: not applicable

When Kaspa does adopt PQC, stateful signature schemes (e.g., XMSS/LMS for validator or infrastructure keys) would require careful state management, anti-reuse controls, and hardware wallet integration planning.

Claim: Community KIP acknowledges that 'immediate migration to post-quantum cryptography would impose significant performance penalties' and claims Phase I has 'negligible' overhead. No formal performance analysis or benchmarking exists.

Coverage basis: Acknowledged in community proposal; no formal analysis.

Implementation score: 0.1 · Evidence confidence: Low

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

Assurance: Low confidence: the community KIP makes qualitative claims about performance impact but provides no benchmarks, measurements, or formal analysis. Per QRI spec, 'lack of a formal performance benchmark' does not create a Readiness & Risk Cap by itself. Treated as note-only because it does not independently create a quantum-enabled attack path.

Performance analysis will be critical when PQC algorithms are selected. Kaspa's 10 BPS block rate and blockDAG architecture impose unique constraints on signature verification time and block size that must be carefully evaluated for any PQC migration.

• https://github.com/bitcoinsSG/Kaspa-Post-Quantum-Improvement-Proposal