--- title: Is Kaspa quantum-safe? chain: Kaspa ticker: KAS hardy_score: 20.5 rank: 27 of 80 tier: "4: Debating" url: "https://hardyindex.com/chains/kaspa" updated: 2026-10-22 reviewed: 2026-11-13 methodology_version: 1.8 --- # Is Kaspa quantum-safe? **Hardy Score 20.5 / 100. Rank 27 of 80. Tier 4: Debating. Last editorial review 22 October 2026; sources checked 13 November 2026.** 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. > This is a security-readiness assessment, not investment advice. ## Summary 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. ## 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. ## Score breakdown | # | Dimension | Score | Weight | Contribution | |---:|---|---:|---:|---:| | 1 | Signature scheme | 1/10 | 30% | 3.0 | | 2 | Deployment stage | 2/10 | 25% | 5.0 | | 3 | NIST alignment | 3/10 | 15% | 4.5 | | 4 | Migration path | 3/10 | 15% | 4.5 | | 5 | Exposure | 2/10 | 10% | 2.0 | | 6 | Verification | 3/10 | 5% | 1.5 | | | **Hardy Score** | | | **20.5** | ### 1. Signature scheme: 1/10 Anchor 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. 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. Source: https://github.com/biryukovmaxim/kaspa-xmss ### 2. Deployment stage: 2/10 Anchor 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: https://github.com/kaspanet/kips/pull/48 ### 3. NIST alignment: 3/10 Anchor 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. 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. Source: https://github.com/biryukovmaxim/kaspa-xmss ### 4. Migration path: 3/10 Anchor 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. 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. Source: https://github.com/kaspanet/kips/pull/48 ### 5. Exposure: 2/10 Anchor 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. 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. Source: https://github.com/kaspanet/rusty-kaspa/blob/master/crypto/addresses/src/lib.rs ### 6. Verification: 3/10 Anchor 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. 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. Source: https://github.com/biryukovmaxim/kaspa-xmss ## Nearest chains in the ranking The 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](https://hardyindex.com/chains/tron) | 4: Debating | 34.5 | +14.0 | | 24 | [Cardano](https://hardyindex.com/chains/cardano) | 3: Committed | 34.0 | +13.5 | | 25 | [Sei](https://hardyindex.com/chains/sei) | 4: Debating | 24.5 | +4.0 | | 26 | [Cosmos Hub](https://hardyindex.com/chains/cosmos-hub) | 4: Debating | 23.5 | +3.0 | | 27 | **Kaspa** | 4: Debating | 20.5 | this chain | | 28 | [BNB Chain](https://hardyindex.com/chains/bnb-chain) | 4: Debating | 20.0 | -0.5 | | 29 | [Monad](https://hardyindex.com/chains/monad) | 4: Debating | 20.0 | -0.5 | | 30 | [XDC Network](https://hardyindex.com/chains/xdc-network) | 4: Debating | 20.0 | -0.5 | | 31 | [Bittensor](https://hardyindex.com/chains/bittensor) | 4: Debating | 19.0 | -1.5 | ## Signature scheme - **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 - **Account signatures:** [Schnorr signatures on secp256k1](https://hardyindex.com/algorithms/schnorr-secp256k1.md) (32-byte x-coordinate keys). Mainnet, default. Address version 0 (PubKey). Source (source code or release): https://github.com/kaspanet/rusty-kaspa/blob/master/crypto/addresses/src/lib.rs - **Account signatures:** [ECDSA on secp256k1](https://hardyindex.com/algorithms/ecdsa-secp256k1.md) (33-byte compressed keys). Mainnet, opt-in. Address version 1 (PubKeyECDSA). Source (source code or release): https://github.com/kaspanet/rusty-kaspa/blob/master/crypto/addresses/src/lib.rs - **Contract level:** [XMSS](https://hardyindex.com/algorithms/xmss.md) (XMSS^MT, two height-12 layers, 192-bit hash (BLAKE3 by default)). Testnet. A core developer's covenant experiment, run against testnet-10 and marked not for production use. Source (source code or release): https://github.com/biryukovmaxim/kaspa-xmss A role not listed here is not evidenced either way. See https://hardyindex.com/algorithms.md. ## Roadmap - **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: https://github.com/kaspanet/kips/pull/37 - **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: https://github.com/kaspanet/rusty-kaspa/releases/tag/v2.0.0 - **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: https://github.com/biryukovmaxim/kaspa-xmss - **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: https://github.com/kaspanet/kips/pull/48 ## 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: https://github.com/kaspanet/kips/pull/48 ## Exposure 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. ## Frequently asked questions ### 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. ### 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. ## What this rating means if you hold Kaspa Plain-language guidance from the same publication, with no product recommendation attached. - [Is my crypto safe from quantum computers?](https://hardyindex.com/guides/is-my-crypto-safe-from-quantum-computers.md) - [How to protect your crypto from quantum computers](https://hardyindex.com/guides/how-to-protect-crypto-from-quantum-computers.md) - [All guides](https://hardyindex.com/guides.md) ## Sources 1. [rusty-kaspa address versions (crypto/addresses/src/lib.rs)](https://github.com/kaspanet/rusty-kaspa/blob/master/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)](https://github.com/kaspanet/kips/pull/48): Kaspa Improvement Proposals (GitHub) (primary, checked 22 October 2026) 3. [KIP 22: Pay-to-Public-Key-Hash via P2SH (discussion thread)](https://research.kas.pa/t/kip-22-pay-to-public-key-hash-via-p2sh/545): Kaspa Research (primary, checked 22 October 2026) 4. [KIP22: P2MR ScriptPublicKey for quantum resistance (pull request 37)](https://github.com/kaspanet/kips/pull/37): Kaspa Improvement Proposals (GitHub) (secondary, checked 22 October 2026) 5. [Mainnet Toccata Release v2.0.0](https://github.com/kaspanet/rusty-kaspa/releases/tag/v2.0.0): Kaspa (GitHub) (primary, checked 22 October 2026) 6. [Kaspa mainnet BlockDAG info (virtual DAA score)](https://api.kaspa.org/info/blockdag): Kaspa REST API (primary, checked 22 October 2026) 7. [kaspa-xmss: stateful hash-based post-quantum signatures (XMSS^MT) for Kaspa](https://github.com/biryukovmaxim/kaspa-xmss): Maxim Biryukov (GitHub) (primary, checked 22 October 2026) 8. [Kaspa XMSS Covenants: mainnet proofs](https://github.com/mrzeku2000XTTT/kaspa-xmss-covenants): mrzeku2000XTTT (GitHub) (secondary, checked 22 October 2026) 9. [SP 800-208: Recommendation for Stateful Hash-Based Signature Schemes](https://csrc.nist.gov/pubs/sp/800/208/final): NIST (primary, checked 22 October 2026) ## How to cite this rating A rating is only true as of the day it was reviewed, so both forms carry the review date and the methodology version. If you are quoting the score, quote those too. 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} } ``` --- Methodology: https://hardyindex.com/methodology (v1.8). Cite as: The Hardy Index, "Kaspa", https://hardyindex.com/chains/kaspa, as of 13 November 2026.