The full active inventory is reconstructible, but only from client source and KIP texts. The project publishes no consolidated cryptographic specification, and the KIP texts that do name primitives precisely (KIP-16, KIP-17, KIP-21) cover only what those proposals change. Third-party descriptions of the UTXO commitment in circulation misname it as elliptic-curve-based, which the client source refutes. Toccata added the KIP-16 verifiers and BLAKE3 to the active inventory; each is named exactly in the KIP texts and present in the client's dependency manifest. The hash function inside the tag-0x21 verifier is not named in KIP-16 at all and is recoverable only from client source, which rejects every option other than Poseidon2.

The Toccata fork added one verification primitive that is not broken by Shor (the tag-0x21 STARK-receipt verifier) and one new pairing-based surface that is (tag 0x20 Groth16 over BN254). Both verify opt-in application proofs. Every primitive that protects funds or ledger state (Schnorr secp256k1, ECDSA secp256k1, MuHash) remains Shor-vulnerable. The hash functions protecting the chain itself are Grover-weakened only and retain a 128-bit preimage margin; the algebraic hash inside the tag-0x21 verifier carries a separate confidence flag rather than a Shor or Grover tag.

Zero PQ signature or KEM families deployed for chain security. No post-quantum signature or KEM crate appears anywhere in the client workspace manifest. The tag-0x21 RISC Zero Succinct STARK-receipt verifier, live since Toccata, is a hash-based proof-verification primitive in consensus code, not a fund-protecting PQ signature or KEM family, so it earns no family-diversity credit. The Cryptographic-Diversity Cap fires on the a-fortiori reading that a chain with no PQ family cannot outrank a single-family deployment.

No NIST PQC primitive is deployed. No ML-DSA (FIPS 204), SLH-DSA (FIPS 205) or ML-KEM (FIPS 203) implementation is present, and no NIST security category applies.

The GHOSTDAG/PHANTOM consensus protocol has an academic protocol paper (IACR ePrint 2018/104), which is a preprint rather than a peer-review certification of the deployed code. There is no formal verification of any cryptographic-primitive implementation. The Rust client uses the standard secp256k1 crate; no public constant-time validation of the signing path is published. All signing is stateless. The fund-protecting path is cryptanalytically mature: classical elliptic-curve cryptography plus cSHAKE256, BLAKE2b-256 and BLAKE3. The consensus script engine is not: Toccata's KIP-16 verifiers integrate pinned third-party libraries (Arkworks 0.6.0 for Groth16 over BN254, RISC Zero 3.0.4/4.0.4 crates for Succinct receipts), the deployed Succinct verifier accepts only Poseidon2 over the BabyBear field, which our framework classes as a research-grade hash family, and no independent audit or formal verification of the precompile integration is published. Deployed-verifier provenance therefore scores zero: there is no reproducible-build or audit evidence tying the shipped verifier to audited source. The KIP itself flags that a vulnerability in one of those verifier libraries could compromise transactions relying on the precompiles. A tier characterization that covers only the fund-protecting path omits these script-engine additions.

Exposure is worse than a spend-time-reveal model implies. Kaspa's two standard non-script address versions are version 0 (PubKey), a 32-byte x-only Schnorr public key, and version 1 (PubKeyECDSA), a 33-byte compressed ECDSA public key. Both encode the public key itself with a checksum rather than a hash of it, and the output script paying such an address is the bare key followed by OpCheckSig or OpCheckSigECDSA, so the key needed for a Shor attack is on chain from the moment an address is funded, whether or not it has ever been spent from. No commit-to-public-key-hash address type is deployed for keys; only version 8 (ScriptHash) withholds its preimage. Address rotation therefore does not reduce exposure.

Mainnet launched November 2021, so roughly 4.75 years of dormant balances have accumulated. The fair-launch model, with no premine or pre-sale, skews dormant balances toward early miners and adopters. Because version-0 and version-1 addresses carry the public key in the output script, dormant balances are exposed from funding and gain no protection from having never moved.

Mechanism per the client documentation. Normal Kaspa nodes are pruned and keep only recent blocks, with archival retention an opt-in flag and the default retention equal to the pruning period. So the archived-signature surface is bounded, not permanent, on default nodes. The exposure conclusion rests on a stronger route: the standard address versions publish the public key in the live UTXO set, which is retained indefinitely, so after Shor every such balance is forgeable from on-chain data alone without recourse to historical signatures. The MuHash UTXO commitment adds a separate long-term surface: its security rests on the discrete-log problem in a 3072-bit multiplicative group, so a quantum adversary able to solve it could construct a colliding multiset matching an alternative UTXO set.

Node-to-node P2P transport is not encrypted at all: it is plaintext gRPC over HTTP/2, peer endpoints are constructed with the http scheme, the P2P crate declares no TLS dependency, and the server is built without TLS configuration. There is therefore no P2P key exchange for a quantum adversary to break, and no harvest-now-decrypt-later exposure at that layer, because the traffic is already readable. The genuine harvest-now-decrypt-later surface is the client-facing RPC path, which uses TLS via rustls 0.23.18 pinned to the ring provider, whose key-exchange groups are X25519, secp256r1 and secp384r1 and include no hybrid or post-quantum option, so recorded handshakes are retrospectively recoverable. No ML-KEM or hybrid-KEM crate appears in the workspace manifest and no release note documents one.

Pseudonymous BlockDAG with full public visibility of every block, transaction and output. No native shielding. The UTXO model permits address rotation, but because the standard address versions publish the public key, rotation changes the identifier without withdrawing the key material.

No measurement of transaction-origination concentration across public RPC providers was obtained, so the concentration component is unscored rather than credited. What is verifiable: the node software is permissionlessly self-hostable so entry points are not gated; mempool gossip is permissionless and fully observable; the primary public REST endpoint responds live and reports node version 2.0.1; and no validator-metadata or query-log retention policy is published by any endpoint operator we checked, which zeroes the retention-policy component under the rubric.

No canonical bridge protocol ships in the node software; there is no native message-passing or light-client bridge in consensus. Cross-chain KAS movement is handled off-protocol by third-party wrapped-asset venues operating custodial or semi-custodial signing infrastructure, which concentrates correlation risk on those operators' key management rather than on chain-level primitives. Toccata is a base-layer consensus and scripting change and does not touch bridge infrastructure. The specific operator set is not independently verified here.

After Shor, every secp256k1 public key on chain is solvable for its private key, and because the standard address versions are the public key, that covers every ordinary address rather than only those that have spent. The MuHash commitment rests on a separate discrete-log assumption in a 3072-bit multiplicative group and constitutes an additional retroactive surface at the ledger-state level.

No on-chain mixing primitive, no shielded pool, no commit-reveal scheme. The four Toccata KIPs add proof-verification opcodes, covenants, covenant identifiers and sequencing commitments; none introduces a shielded transaction type, a confidential amount, or a mixing primitive.

Proof-of-work chain with hard-fork-only upgrades. There is no on-chain governance and no protocol-level algorithm-switch mechanism; changing a signature scheme would require a coordinated hard fork with a published DAA-score activation, the same mechanism used for Crescendo and Toccata. The full-node reimplementation from Go to Rust (KIP-1) and the two forks demonstrate the team can ship invasive changes, though the reimplementation itself changed no consensus rules.

No account abstraction. UTXO-model addresses can be rotated by spending to a new address, but because the standard address versions publish the public key, rotation does not withdraw exposed key material and so is not a mitigation against a quantum adversary. KIP-5 (Message Signing) supports off-chain signed messages, using the BLAKE2b-256 'PersonalMessageSigningHash' domain, and is not a key-rotation primitive.

Two consensus hard forks are on record, both hitting their published DAA-score activation targets without a contested chain split: Crescendo (KIP-14), 1 to 10 blocks per second with the GHOSTDAG K parameter recalibrated to 124 and finality-depth, merge-depth and block-reward maturity rescaling, activation DAA 110,165,000 reached 2025-05-05; and Toccata (KIP-16/17/20/21), activation DAA 474,165,565 reached 2026-06-30. Separately, KIP-1 delivered a complete Go-to-Rust full-node reimplementation, adopted network-wide but introducing no consensus rule change, so it is not counted as a fork; KIP-14 records Crescendo as the closure of that rewrite.

No announced hybrid PQ deployment plan and no hybrid signature composition merged in any form. KIP-17 and KIP-20 covenant and introspection opcodes and KIP-21 BLAKE3 partitioned sequencing commitments, live since Toccata, give the script engine commit-to-hash building blocks that a script-path PQ spend could in principle build on. That is an infrastructure precondition only, and it is our inference rather than a project claim: no KIP text asserts post-quantum applicability for these opcodes. KIP-22 (P2MR ScriptPublicKey for quantum resistance) remains an open, unmerged pull request opened 2026-03-06 with last activity 2026-07-13, carries no assigned KIP number in the repository index, and has unresolved reviewer objections on compatibility with KIP-5, KIP-10, KIP-14 and KIP-17. It is a Merkle-root commitment scheme that would withhold the public key until spend, not a hybrid signature composition.

Kaspa deploys no stateful hash-based signature scheme; there is no XMSS (RFC 8391) or LMS (RFC 8554) implementation and no such crate in the workspace. All signing is stateless elliptic-curve. Default full credit, since there is no signing state to lose.

N/A. Kaspa is Nakamoto-style proof-of-work with no validator set and no BLS aggregation in consensus. Weight redistributes within Dimension 4.

0% mainnet PQC traffic. No PQ primitive is present in any active mainnet signing or transport surface.

The RISC Zero Succinct STARK-receipt verifier (KIP-16 OpZkPrecompile opcode 0xa6, verifier tag 0x21) is merged in the client and live on mainnet since Toccata activation 2026-06-30; the client's risc0-zkp, risc0-core, risc0-binfmt and risc0-circuit-recursion dependencies are pinned in the script-engine crate, and the transient block-mass limit was doubled from 500,000 to 1,000,000 specifically so STARK proofs fit in a block. This is the only code in the consensus client whose security rests on hashing rather than on a Shor-breakable assumption for the asymmetric-primitive role, and it verifies external application proofs; its deployed form accepts only Poseidon2 over the BabyBear field, so the hash it rests on is not one of the mature functions used elsewhere in the client. No PQ signature or KEM code protecting Kaspa's own user keys or transport is merged. The same opcode also ships a Groth16 verifier over BN254 pairings (tag 0x20) which is Shor-vulnerable. No public data measures what share of mainnet traffic has used either verifier since activation, so this is not scored as measured usage.

N/A. Kaspa is proof-of-work with no validator set. Weight redistributes within Dimension 5.

Voided per the v3.1 Milestone-Discipline rule, which sets 5d to 0 when 5a is 0. Independently, no dated PQ migration milestone is published by the foundation or by core developers: no quantum or post-quantum content appears in the KIP repository outside KIP-16's verifier discussion, in the client repository, or on the project site. The foundation site is a client-rendered application whose body could not be retrieved server-side, so it is excluded from that absence finding rather than counted toward it.

One PQ-labeled claim in the trailing twelve months, and it shipped. KIP-16 describes its tag-0x21 RISC Zero Succinct verifier as providing quantum-resistant proof verification with post-quantum security properties, and that verifier is live on mainnet since Toccata; announced-to-shipped ratio 1.0. The same KIP states directly that its Groth16 verifier is not quantum safe under Shor, which is candor rather than overstatement. No foundation PQ-migration announcements exist to overstate. Full marks.

Undisclosed. No PQ scheme is selected and no PQ signature benchmark is published. The chain does publish verification-cost benchmarks for its new proof verifiers against an ECDSA baseline (ECDSA verification 12.311 microseconds, Groth16 1.648881 milliseconds at roughly 134 times the baseline, STARK 9.080792 milliseconds at roughly 738 times), which establishes that the project measures verification cost empirically, but no equivalent measurement exists for any PQ signature scheme. The 100ms block budget at 10 blocks per second would constrain any PQ-signature footprint choice.

The wallet tier spans a mobile wallet, a browser-extension wallet and a hardware card product. The hardware-card vendor's Kaspa page was re-fetched directly and makes only physical and certification security claims with no post-quantum or quantum-resistant content and no named signature scheme. The other two vendor sites returned client-rendered shells with no retrievable body, so no finding was made from them either way. No wallet vendor publishes a PQC roadmap for Kaspa in any source we located.

Cross-chain wrapped-KAS movement is operated by third-party custodial venues rather than by a canonical protocol bridge. No bridge operator publishes a PQC roadmap in any source we located. Operator identities are not independently verified here.

KAS custody and trading concentrate on centralized exchanges. No exchange or custodian publishes a Kaspa-specific PQC roadmap in any source we located, and none was found to publish a post-quantum key-custody migration plan covering secp256k1 holdings. The specific venue list is not independently verified here.

Public RPC is served by community and ecosystem-operated nodes; the primary public REST endpoint responds live at node version 2.0.1. The node software documents no hardware-security-module integration, no trusted-execution-environment attestation chain, and no remote-attestation path, and no such crate appears in the workspace manifest. No infrastructure operator publishes a PQC roadmap.

Proof-of-work chain with no validator set, so security distribution is a question of mining-pool hashrate concentration, which we did not measure because the available dashboards render client-side and returned no tabular data. No characterization of that concentration is currently reconstructible, so none is credited. What is verifiable: client-software diversity is low, since the Rust implementation is the project's recommended node software and the legacy Go node is not maintained as a co-equal alternative, so a consensus-critical bug has no independent implementation to fail against.

Two successful coordinated hard forks, each announced with a DAA-score activation target and each reaching it: Crescendo at DAA 110,165,000 on 2025-05-05 and Toccata at DAA 474,165,565 on 2026-06-30, both with a peer-protocol version gate taking effect 24 hours ahead of activation, and Toccata with a maintenance release issued two weeks before activation on top of that gate. Neither produced a contested chain split. The Go-to-Rust node reimplementation demonstrates additional coordination capacity without being a fork. No upgrade has been executed under adversarial pressure, so cadence under duress is untested.

The Kaspa Ecosystem Foundation is the named foundation, describing its role as supporting the Kaspa ecosystem. Its site is a client-rendered application whose body could not be retrieved server-side, so we make no finding from it about named roles. Core contributors are identifiable from KIP authorship: the GHOSTDAG/PHANTOM co-author and a second long-standing core contributor are named authors on the consensus KIPs including KIP-21, and one KIP-21 co-author uses a foundation email address, which establishes continued core involvement through the Toccata cycle. No PQ migration lead is named in the KIP repository, the client repository, the release notes or the project site, and no individual or body is identified anywhere we checked as accountable for cryptographic migration.

The fair launch, with no premine, insider allocation or pre-sale, gives the community legitimacy for coordinated action. There is no record of a coordinated cryptographic pivot under active-attacker conditions. Crescendo and Toccata were both planned capability upgrades executed on published schedules, not emergency responses.

No canary, honeypot, rate-limited spending rule, or cryptographic tripwire is embedded in consensus or documented in foundation or core-developer policy. None of the four Toccata KIPs introduces such a mechanism.