Hardy Index Quantum readiness, rated and tracked

Chain profile

Kaspa

KAS Debating

Signs with Schnorr over secp256k1 behind addresses that are the public key itself, with a core developer's October 2026 draft KIP to hide keys and an experimental XMSS covenant run on testnet, but no post-quantum scheme agreed.

Is Kaspa quantum-safe?

No. Kaspa's default addresses hold a 32-byte Schnorr public key over secp256k1, with ECDSA available as an alternative address type, and a sufficiently large quantum computer would break both. Because a standard Kaspa address is the public key rather than a hash of it, every such address exposes its key from the moment it exists. The post-quantum record is early. On 19 October 2026 Ori Newman, a core rusty-kaspa developer, filed KIP-22 as a draft: a wallet convention that wraps the key in a pay-to-script-hash so it stays hidden until spending, written explicitly against quantum key recovery and as groundwork for a later migration it does not yet specify. Maxim Biryukov, another core developer, has published an XMSS^MT experiment that runs as a Kaspa covenant and has been exercised on testnet-10, and labels it unaudited and not for real funds. Neither names a post-quantum signature for Kaspa, and no date has been published.

Where we are making a judgement call Two judgement calls. The Debating placement rests on KIP-22, a draft filed three days before this review by a core developer, in an open pull request that has not been merged or numbered by the editors, and which hides keys rather than introducing a post-quantum signature. The number is self-assigned: a separate community pull request, number 37, opened by ezrasisk in March 2026, is also titled KIP22. A reader who requires a merged proposal, or one that names a post-quantum scheme, would place Kaspa in Tier 5, with a deployment score of 1 and a Hardy Score of 18.0 instead of 20.5. The other: a third-party developer reports spending hash-based covenant locks on Kaspa mainnet, and we confirmed two of the reported transactions were accepted. We have not recorded them as a post-quantum signature live on mainnet, because our reading of the code is that the signed message is not tied to the spending transaction, so a copied witness could redirect the funds. A reader who accepted them as a usable post-quantum signature would argue for Tier 2, with a deployment score of 8 and a signature score of 4 for an opt-in, application-level primitive, which with the other scores unchanged gives a Hardy Score of 44.5; if our reading of the code is wrong, this profile is.

At a glance

On mainnet today

Schnorr over secp256k1 by default (address version 0), ECDSA over secp256k1 opt-in (address version 1)

Post-quantum scheme

None selected. A core developer's XMSS^MT covenant experiment has run on testnet-10; draft KIP-22 hides keys behind pay-to-script-hash without a post-quantum signature.

NIST standard

None adopted

Readiness tier

Tier 4: Debating. Post-quantum work on the chain’s own signatures is documented by people with authority over it, in a formal improvement proposal or a public research programme, but no scheme is agreed and no timeline is published.

Cryptography in use

A role not listed is not evidenced either way. Every scheme, and which other chains share it, is in the cryptography registry.

Score breakdown

Each dimension scored 0 to 10. The weight beside it is its share of the total score.
Signature scheme 1 30% Deployment stage 2 25% NIST alignment 3 15% Migration path 3 15% Exposure 2 10% Verification 3 5%
Show the weighted arithmetic and the sourced note for each dimension
No. Dimension Score Weight Contribution
1 Signature scheme 1 30% 3.0
2 Deployment stage 2 25% 5.0
3 NIST alignment 3 15% 4.5
4 Migration path 3 15% 4.5
5 Exposure 2 10% 2.0
6 Verification 3 5% 1.5
Hardy Score 20.5

1 Signature scheme 1/10, weighted 30%

Band 1 to 3: Classical signatures only on mainnet, with a post-quantum implementation live and usable by the public on a persistent test network.

Kaspa mainnet signs with Schnorr over secp256k1 by default and offers ECDSA as an alternative, both broken by Shor's algorithm. A core developer's XMSS^MT covenant, built on the script opcodes the Toccata hard fork added, has run against the persistent testnet-10, which puts a post-quantum implementation on a public test network. source

Placement in the band Off the 0 floor and at a 1 rather than a 2 or a 3: the testnet-10 XMSS covenant example is public and anyone can run it against a public, persistent testnet, which is what lifts it off 0, but it is one developer's worked example in a personal repository, marked by its author as unaudited and not for real funds, rather than something offered to the public to hold keys on.

2 Deployment stage 2/10, weighted 25%

Band 2: Tier 4: Debating.

Tier 4: Debating. Post-quantum exposure is addressed in a draft improvement proposal filed by a core developer, KIP-22, but it introduces no post-quantum signature, no scheme is agreed and no timeline exists. The placement is a judgement call, set out in the caveat. source

3 NIST alignment 3/10, weighted 15%

Band 3 to 5: NIST schemes are referenced as candidates without a committed selection, or the work is bespoke research.

No post-quantum scheme has been proposed for Kaspa's signatures. The one tested for them is the core developer experiment, XMSS^MT in the SP 800-208 family, which defaults to BLAKE3 as its hash rather than a function SP 800-208 approves. KIP-22 names no post-quantum scheme. source

Placement in the band At the floor of the band rather than a 4 or a 5: a NIST-family scheme has been tested, but in a personal experiment, with a non-approved default hash, and nothing in Kaspa's improvement-proposal process selects or references it.

4 Migration path 3/10, weighted 15%

Band 3 to 5: Migration is acknowledged as a problem with no agreed mechanism, or the mechanism is contested.

KIP-22 acknowledges the problem and offers a partial mechanism: new pay-to-script-hash addresses that keep the key hidden until spending, needing no consensus change. It says a migration for existing funds could be specified separately, cites BIP-361 as a model, and specifies nothing further. It is a draft in an open pull request. source

Placement in the band At the floor of the band rather than a 4: there is a concrete wallet convention, which lifts this above a 2, but it moves no coins to a post-quantum key and the migration itself is left unwritten.

5 Exposure 2/10, weighted 10%

Band 0 to 2: Public keys are exposed for effectively all accounts, or a large, measured share of total supply sits in exposed addresses.

A standard Kaspa address encodes the 32-byte Schnorr public key directly, or the 33-byte ECDSA key, with no hashing step. Every such address therefore exposes its key on-chain from creation, whether or not it has ever spent, and the key can be harvested today against a future quantum computer. source

Placement in the band At the top of the band rather than a 0 or a 1: Kaspa meets this band on its structural limb, the default address being the key itself, but no measured share of at-risk supply has been published, and pay-to-script-hash addresses, which keep the key hidden until spending, are valid today.

6 Verification 3/10, weighted 5%

Band 3 to 5: A post-quantum component exists, on mainnet, on a persistent testnet or as a merged implementation, but is unreviewed.

The post-quantum component that exists, the XMSS^MT covenant experiment, is open source and has run on the persistent testnet-10, but its author states it has not been audited or formally reviewed. It is not merged into rusty-kaspa and protects no funds. source

Placement in the band At the floor of the band rather than a 4 or a 5: the component exists on a persistent testnet, but in a personal repository outside the node, with no review and an explicit warning against securing funds with it.

The deployment dimension is not a separate judgement. It is Tier 4 expressed as a number. See the tier mapping.

How it compares

All 80 rated chains on the 0 to 100 scale. Kaspa is marked. Select any point to open that profile.
Kaspa 20.5

Nearest chains in the ranking

The 9 chains Kaspa sits among, out of 80 rated. The last column is the gap in Hardy points from Kaspa.

Rank Chain Tier Hardy vs KAS
23 Tron 4: Debating 34.5 +14.0
24 Cardano 3: Committed 34.0 +13.5
25 Sei 4: Debating 24.5 +4.0
26 Cosmos Hub 4: Debating 23.5 +3.0
27 Kaspa this chain 4: Debating 20.5
28 BNB Chain 4: Debating 20.0 -0.5
29 Monad 4: Debating 20.0 -0.5
30 XDC Network 4: Debating 20.0 -0.5
31 Bittensor 4: Debating 19.0 -1.5

Roadmap

  1. 6 March 2026 proposed

    A community contributor, ezrasisk, opens a pull request titled KIP22 for a Pay-to-Merkle-Root script type for quantum resistance. A core developer responds that the need is not pressing; it remains unmerged. source

  2. 30 June 2026 shipped

    The Toccata hard fork activates on mainnet at DAA score 474,165,565, about 30 June 2026, bringing covenant programming, including the script opcodes that let hash-based signatures be checked in script. Mainnet's DAA score has since passed the activation height. source

  3. June to July 2026 shipped

    Core developer Maxim Biryukov publishes an XMSS^MT covenant experiment and runs it against testnet-10, marked unaudited and not for real funds. source

  4. 19 October 2026 proposed

    Core developer Ori Newman files draft KIP-22, Pay-to-Public-Key-Hash via P2SH, to keep public keys hidden until spending and prepare for a later post-quantum transition. source

If holders never migrate

No stated policy

Draft KIP-22 notes that a migration mechanism for existing funds could be specified separately, citing Bitcoin's BIP-361, but no Kaspa proposal says what would happen to coins that never move.

As of 22 October 2026. source Published beside the score, not in it. Every chain's stance is compared on the commitments page.

Exposure

Exposure measures how much of the chain's value already sits behind a public key that an attacker can record today and break later. This is the part of the threat that a future upgrade cannot undo.

A standard Kaspa address is the public key, encoded with a version byte: 32 bytes for Schnorr, 33 for ECDSA. Nothing is hashed, so every address of either kind shows its key on-chain as soon as it is used or funded, and an attacker can begin collecting keys today against a future quantum computer. Never spending does not help. Pay-to-script-hash addresses do hide the key until spending, and draft KIP-22 proposes using them for ordinary wallets, but no released wallet does so yet. Separately, a third-party developer has published hash-based covenant locks and reports spending them on mainnet with real KAS in July 2026. Our reading of that code is that the signed message is supplied in the spending input rather than tied to the transaction, so we do not count it as a signature protecting funds.

What this rating means for you

If you hold Kaspa

Kaspa has acknowledged the threat without agreeing a plan, so nothing is going to change for holders in the near term. That makes address hygiene the part worth attending to.

Editorial guidance from the Hardy Index.

Embed this rating

Paste this anywhere to show Kaspa's current rating. It renders live from the index, so it updates when the rating does, and the review date is written into the image. There is nothing to sign up for and nothing to pay. 

<a href="https://hardyindex.com/chains/kaspa"><img src="https://hardyindex.com/badge/kaspa.svg" width="260" height="76" alt="Quantum readiness rated by the Hardy Index"></a>

The image is /badge/kaspa.svg. It is a plain SVG with no script and no tracking, it sets no cookie, and it records nothing about whoever loads it.

Questions

Is Kaspa quantum-safe?

No. Kaspa signs with Schnorr over secp256k1 by default and supports ECDSA, both of which a sufficiently large quantum computer would break. Its standard addresses are the public key itself, so every key is exposed on-chain from the start. No post-quantum signature scheme has been proposed for Kaspa.

What is KIP-22?

A draft Kaspa Improvement Proposal filed by core developer Ori Newman on 19 October 2026. It defines a wallet convention that puts the public key inside a pay-to-script-hash, so the key stays hidden until the coins are spent. It needs no consensus change and does not introduce a post-quantum signature, but it says hiding keys enables a cleaner future transition to one.

Can Kaspa scripts verify post-quantum signatures?

In principle, since the Toccata hard fork added opcodes that make hash-based verification possible in script. Core developer Maxim Biryukov has built an XMSS^MT covenant and run it on testnet-10, and a third-party developer reports mainnet spends of hash-based locks. Neither is offered as a way to secure real funds, and we do not count either as a post-quantum signature protecting KAS.

Why is a Kaspa address more exposed than a Bitcoin address?

Because a Bitcoin pay-to-public-key-hash address publishes a hash of the key, not the key, until it spends, while a standard Kaspa address publishes the key itself. A Kaspa holder who has never spent still has an exposed key. KIP-22 would give Kaspa wallets a hashed form, using pay-to-script-hash.

Sources

  1. rusty-kaspa address versions (crypto/addresses/src/lib.rs) Kaspa (GitHub) · primary · checked 22 October 2026
  2. KIP 22: Pay-to-Public-Key-Hash via P2SH (pull request 48) Kaspa Improvement Proposals (GitHub) · primary · checked 22 October 2026
  3. KIP 22: Pay-to-Public-Key-Hash via P2SH (discussion thread) Kaspa Research · primary · checked 22 October 2026
  4. KIP22: P2MR ScriptPublicKey for quantum resistance (pull request 37) Kaspa Improvement Proposals (GitHub) · secondary · checked 22 October 2026
  5. Mainnet Toccata Release v2.0.0 Kaspa (GitHub) · primary · checked 22 October 2026
  6. Kaspa mainnet BlockDAG info (virtual DAA score) Kaspa REST API · primary · checked 22 October 2026
  7. kaspa-xmss: stateful hash-based post-quantum signatures (XMSS^MT) for Kaspa Maxim Biryukov (GitHub) · primary · checked 22 October 2026
  8. Kaspa XMSS Covenants: mainnet proofs mrzeku2000XTTT (GitHub) · secondary · checked 22 October 2026
  9. SP 800-208: Recommendation for Stateful Hash-Based Signature Schemes NIST · primary · checked 22 October 2026
Cite this rating

A rating is only true as of the day an editor last reviewed it, so both forms below carry that date and the methodology version, with the date its cited sources were last checked. If you are quoting the score, quote those too.

Plain text

The Hardy Index (2026). Kaspa: quantum readiness assessment. Hardy Score 20.5 of 100, Tier 4: Debating. Methodology v1.8. Last reviewed 22 October 2026; sources checked 13 November 2026. https://hardyindex.com/chains/kaspa

BibTeX 
@misc{hardyindex_kaspa_2026,
  author       = {{The Hardy Index}},
  title        = {Kaspa: quantum readiness assessment},
  year         = {2026},
  howpublished = {\url{https://hardyindex.com/chains/kaspa}},
  note         = {Hardy Score 20.5 of 100, Tier 4: Debating. Methodology v1.8},
  urldate      = {2026-11-13}
}

The whole dataset is reusable under the terms on the about page. A machine-readable version of this page is at /chains/kaspa.md.

This is a security-readiness assessment, not investment advice.