--- title: Is Bitcoin SV quantum-safe? chain: Bitcoin SV ticker: BSV hardy_score: 8.5 rank: 55 of 80 tier: "5: Exposed" url: "https://hardyindex.com/chains/bitcoin-sv" updated: 2026-10-22 reviewed: 2026-11-13 methodology_version: 1.8 --- # Is Bitcoin SV quantum-safe? **Hardy Score 8.5 / 100. Rank 55 of 80. Tier 5: Exposed. Last editorial review 22 October 2026; sources checked 13 November 2026.** No. Bitcoin SV signs transactions with ECDSA on the secp256k1 curve, as its node software does, and a sufficiently large quantum computer running Shor's algorithm would break it. We found no post-quantum roadmap, improvement proposal or research programme from the BSV Association or the node team for the signatures that protect BSV. The post-quantum mentions that do exist sit at the application layer: BRC-220, a notarisation standard in the Association's Bitcoin Request for Comments repository written by an outside author, lets a document signer choose ML-DSA or SLH-DSA, but it signs document hashes, not spends. Bitcoin SV's restored script language can also verify a hash-based one-time signature, and the sCrypt boilerplate repository carries a sample Lamport contract, but no released wallet puts coins behind one. Bitcoin SV split from Bitcoin Cash on 15 November 2018, which had split from Bitcoin on 1 August 2017, so it shares Bitcoin's history to that date, including the early pay-to-public-key outputs, around 2 million coins by Deloitte's count, whose public keys are already on-chain. > This is a security-readiness assessment, not investment advice. ## Summary Signs with ECDSA on secp256k1 and has no post-quantum proposal for its own signatures, and as a fork of Bitcoin Cash it inherits the early pay-to-public-key coins whose keys have been on-chain since 2009. ## Where we are making a judgement call Four judgement calls. First, the signature score. Since Genesis, BSV script can verify a hash-based one-time signature, and the sCrypt boilerplate repository holds a sample Lamport contract that does so. We score that 0 rather than as an opt-in application-level primitive, because no released wallet or package lets a holder put coins behind it, which is the difference from Bitcoin Cash, where wallets shipped Quantumroot. A reader who credits what the script language can express would score signature 4, adding 12.0 points to a Hardy Score of 8.5. Second, BRC-220. It sits in the BSV Association's Bitcoin Request for Comments repository, its author lists himself as CTO of SmartLedger, and it names ML-DSA and SLH-DSA, but for notarising document hashes, which v1.8 places outside the NIST dimension. A reader who counts it for NIST alignment would score 3, adding 4.5 points, and one who also treats it as documented post-quantum work for the Tier 4 floor would add a further 2.5. We do neither: the BRC process describes itself as a platform for sharing ideas without bureaucratic overhead, not a route for changing the chain's signatures, and the standard leaves spends untouched. Third, migration scores 2 on the Genesis and Chronicle hard forks. The node repository's stated aim is to keep the original protocol stable, and a reader who weighs that against any change of signature scheme would score 1, taking 1.5 points off. Fourth, exposure inherits the measured pre-fork pay-to-public-key outputs Bitcoin SV shares with Bitcoin and Bitcoin Cash. A measurement of Bitcoin SV itself would replace that and could move the score either way. ## Score breakdown | # | Dimension | Score | Weight | Contribution | |---:|---|---:|---:|---:| | 1 | Signature scheme | 0/10 | 30% | 0.0 | | 2 | Deployment stage | 1/10 | 25% | 2.5 | | 3 | NIST alignment | 0/10 | 15% | 0.0 | | 4 | Migration path | 2/10 | 15% | 3.0 | | 5 | Exposure | 2/10 | 10% | 2.0 | | 6 | Verification | 2/10 | 5% | 1.0 | | | **Hardy Score** | | | **8.5** | ### 1. Signature scheme: 0/10 Anchor band 0: Classical signatures only on mainnet, with nothing post-quantum protecting live funds. Short-lived devnets and one-off benchmarks sit here: they demonstrate research rather than something a user can hold keys on. The Bitcoin SV node verifies spends with libsecp256k1's ECDSA, and the BSV Academy documentation states that BSV transactions use ECDSA on secp256k1. Mining is proof of work, so there are no validator signatures. Nothing post-quantum protects BSV on mainnet: a Lamport contract can be written in script, but no released wallet uses one. Source: https://github.com/bitcoin-sv/bitcoin-sv/blob/master/src/pubkey.cpp ### 2. Deployment stage: 1/10 Anchor band 1: Tier 5: Exposed. Tier 5: Exposed. The signatures securing BSV are quantum-vulnerable, and neither the node repository nor the BSV Association's published material holds a post-quantum proposal, plan or research programme for them. BRC-220 names post-quantum schemes for notarising document hashes, which is not the chain's own signatures. See the caveat below on why this is a judgement call. Source: https://github.com/bitcoin-sv/bitcoin-sv ### 3. NIST alignment: 0/10 Anchor band 0 to 2: No post-quantum scheme named for the chain’s fund-protecting signatures, or a proprietary scheme with no public cryptanalysis. No post-quantum scheme has been named for the signatures that authorise BSV spends. BRC-220 lists ML-DSA under FIPS 204 and SLH-DSA under FIPS 205 as signature options for notarisation certificates anchored on BSV, a use that v1.8 places outside this dimension because it protects no funds. Placement in the band: The floor of the band rather than a 1 or a 2: nothing has been named for the fund-protecting signatures at all, and the one standard that names NIST schemes, BRC-220, applies them to document hashes rather than to spends. Source: https://github.com/bsv-blockchain/BRCs/blob/master/apps/0220.md ### 4. Migration path: 2/10 Anchor band 0 to 2: No agreed migration path, or the proposals on the table would strand or freeze holder funds. No migration plan exists. Bitcoin SV has shown it can coordinate consensus changes: the Genesis upgrade activated at block 620,538 in February 2020, and the Chronicle hard fork, which restored further original opcodes, at block 943,816 on 7 April 2026. Neither touched the signature scheme, and the node repository describes its aim as restoring the original protocol and keeping it stable. Placement in the band: The top of the band rather than a 0 or a 1: two coordinated hard forks in six years, Chronicle among them in 2026, are direct evidence that the chain can ship protocol changes. Not a 3, because nobody with authority over the chain has acknowledged quantum migration as a problem to solve. Source: https://github.com/bitcoin-sv/bitcoin-sv/releases/tag/v1.2.0 ### 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. Under v1.8's inheritance rule, published measurements of the history Bitcoin SV shares with Bitcoin apply to it until one specific to Bitcoin SV exists. Its chain carries Bitcoin's blocks to August 2017 and Bitcoin Cash's to November 2018, including the original pay-to-public-key outputs that Deloitte puts at about 2 million coins, roughly a tenth of supply, with keys already on-chain. Placement in the band: The top of the band rather than a 1: the pre-fork pay-to-public-key share is the part inherited with certainty, while Deloitte's figure of 2.5 million coins in reused addresses was measured on Bitcoin's later history and does not transfer. Not a 3, because a measured tenth of supply with keys on-chain is a large share. Source: https://www.deloitte.com/nl/en/services/risk-advisory/perspectives/quantum-computers-and-the-bitcoin-blockchain.html ### 6. Verification: 2/10 Anchor band 0 to 2: No post-quantum component exists, or the claims rest on marketing. No post-quantum component protects BSV. The sCrypt Lamport contract is sample code in a boilerplate repository, not a released wallet or a deployed component, and BRC-220's post-quantum options sign documents rather than spends. Under v1.8 the openness of the classical node earns nothing here. Placement in the band: The top of the band rather than a 0 or a 1: there is no post-quantum component to verify, but nothing about Bitcoin SV is marketed as quantum-safe, so its position does not rest on marketing. Source: https://github.com/sCrypt-Inc/boilerplate/blob/master/src/contracts/lamportSig.ts ## Nearest chains in the ranking The chains Bitcoin SV sits among, out of 80 rated. The last column is the gap in Hardy points from Bitcoin SV. | Rank | Chain | Tier | Hardy | vs BSV | |---:|---|---|---:|---:| | 51 | [AIOZ Network](https://hardyindex.com/chains/aioz) | 5: Exposed | 8.5 | level | | 52 | [Akash Network](https://hardyindex.com/chains/akash) | 5: Exposed | 8.5 | level | | 53 | [Arweave](https://hardyindex.com/chains/arweave) | 5: Exposed | 8.5 | level | | 54 | [Avalanche](https://hardyindex.com/chains/avalanche) | 5: Exposed | 8.5 | level | | 55 | **Bitcoin SV** | 5: Exposed | 8.5 | this chain | | 56 | [Celestia](https://hardyindex.com/chains/celestia) | 5: Exposed | 8.5 | level | | 57 | [Chiliz Chain](https://hardyindex.com/chains/chiliz) | 5: Exposed | 8.5 | level | | 58 | [Conflux](https://hardyindex.com/chains/conflux) | 5: Exposed | 8.5 | level | | 59 | [dYdX Chain](https://hardyindex.com/chains/dydx) | 5: Exposed | 8.5 | level | ## Signature scheme - **On mainnet today:** ECDSA on secp256k1 for transactions; proof of work for block production - **Post-quantum scheme:** None deployed or proposed for the chain's signatures. A sample Lamport one-time signature contract exists for BSV script, and BRC-220 offers ML-DSA and SLH-DSA for notarising document hashes. - **NIST standard:** None adopted. BRC-220 names ML-DSA (FIPS 204) and SLH-DSA (FIPS 205) for notarisation certificates, not for spends. - **Readiness tier:** Tier 5: Exposed. The signatures securing funds on mainnet today are quantum-vulnerable, and no public post-quantum plan, proposal or research programme addressing them could be found. ## Cryptography in use - **Account signatures:** [ECDSA on secp256k1](https://hardyindex.com/algorithms/ecdsa-secp256k1.md). Mainnet, default. Spend signatures, verified through libsecp256k1. Source (source code or release): https://github.com/bitcoin-sv/bitcoin-sv/blob/master/src/pubkey.cpp A role not listed here is not evidenced either way. See https://hardyindex.com/algorithms.md. ## Roadmap - **1 August 2017** (shipped): Bitcoin Cash splits from Bitcoin in the 1 August 2017 hard fork, which Bitcoin SV's node software still records as its fork height, block 478,558. Bitcoin SV's chain descends from that split, so it shares Bitcoin's history, and every public key revealed in it, up to this point. Source: https://github.com/bitcoin-sv/bitcoin-sv/blob/master/src/chainparams.cpp - **15 November 2018** (shipped): Bitcoin SV splits from Bitcoin Cash at block 556,767 with its November 2018 upgrade, which re-enabled several original opcodes and removed automatic replay protection. Source: https://github.com/bitcoin-sv/bitcoin-sv/blob/master/doc/release-notes-v0.1.0.md - **4 February 2020** (shipped): The Genesis upgrade activates at block 620,538, removing script limits and rejecting new pay-to-script-hash outputs. Not post-quantum work, but evidence that the chain can coordinate a hard fork. Source: https://github.com/bitcoin-sv/bitcoin-sv/blob/master/src/chainparams.cpp - **7 April 2026** (shipped): The Chronicle hard fork activates at block 943,816, restoring further original opcodes and the original transaction digest algorithm. It does not change the signature scheme. Source: https://github.com/bitcoin-sv/bitcoin-sv/releases/tag/v1.2.0 - **No published position** (proposed): No post-quantum roadmap, improvement proposal or research programme for Bitcoin SV's own signatures was found in the node repository or the BSV Association's published material at the time of writing. Source: https://github.com/bitcoin-sv/bitcoin-sv ## If holders never migrate **No stated policy.** Neither the node team nor the BSV Association has published a policy on coins that stay behind ECDSA keys, including the inherited early pay-to-public-key outputs. As of 22 October 2026. ## Exposure Bitcoin SV inherits two histories. Its chain carries every Bitcoin block to the Bitcoin Cash split of 1 August 2017, and every Bitcoin Cash block to its own split on 15 November 2018, so each original pay-to-public-key output mined in Bitcoin's early years exists here too, with its public key on-chain, and every address reused before November 2018 has revealed its key on this chain as well. Under the v1.8 inheritance rule, the measured pre-fork share applies here until a measurement of Bitcoin SV exists: Deloitte found that the pay-to-public-key supply has stayed practically constant at about 2 million coins, which places it in the early history that predates both splits. This follows the treatment of Bitcoin Cash. No measurement specific to Bitcoin SV has been published, so coins that moved on this chain after the splits, and address reuse since, are unmeasured. Since the Genesis upgrade a locking script can be a bare public key or a key hash, and new pay-to-script-hash outputs are rejected. ## Frequently asked questions ### Is Bitcoin SV quantum-safe? No. Bitcoin SV signs transactions with ECDSA on the secp256k1 curve, as its node software does, and a sufficiently large quantum computer running Shor's algorithm would break it. We found no post-quantum roadmap, improvement proposal or research programme from the BSV Association or the node team for the signatures that protect BSV. The post-quantum mentions that do exist sit at the application layer: BRC-220, a notarisation standard in the Association's Bitcoin Request for Comments repository written by an outside author, lets a document signer choose ML-DSA or SLH-DSA, but it signs document hashes, not spends. Bitcoin SV's restored script language can also verify a hash-based one-time signature, and the sCrypt boilerplate repository carries a sample Lamport contract, but no released wallet puts coins behind one. Bitcoin SV split from Bitcoin Cash on 15 November 2018, which had split from Bitcoin on 1 August 2017, so it shares Bitcoin's history to that date, including the early pay-to-public-key outputs, around 2 million coins by Deloitte's count, whose public keys are already on-chain. ### Is Bitcoin SV quantum-safe? No. Bitcoin SV signs transactions with ECDSA on the secp256k1 curve, which a sufficiently large quantum computer would break. We found no post-quantum proposal, plan or research programme from the BSV Association or the node team for the signatures that protect BSV. ### Can BSV script already do post-quantum signatures? In principle. BSV's restored script language can check a hash-based one-time signature, and the sCrypt boilerplate repository includes a sample Lamport contract. Sample code is not something a holder can install and use, though: no released wallet puts coins behind such a contract, so the index scores nothing post-quantum as protecting BSV today. ### Does Bitcoin SV inherit Bitcoin's exposed coins? Yes, for the history it shares. Bitcoin SV's chain contains Bitcoin's blocks up to August 2017 and Bitcoin Cash's up to November 2018, so the original pay-to-public-key outputs from Bitcoin's early years, about 2 million coins by Deloitte's count, exist on Bitcoin SV with their public keys on-chain. Under the index's inheritance rule that measured share applies here until someone measures Bitcoin SV itself. ### What is BRC-220 and does it make BSV quantum-safe? BRC-220 is a notarisation standard in the BSV Association's Bitcoin Request for Comments repository. It anchors a signed document hash on BSV and lets the signer use ML-DSA or SLH-DSA instead of ECDSA, so the proof stays verifiable as classical schemes weaken. It does not change how BSV itself is spent, so it protects no coins. ### What would move Bitcoin SV up the index? A formal proposal or public research programme from the node team or the BSV Association on Bitcoin SV's own signatures would meet the Tier 4 floor. A released wallet that lets holders lock coins behind a hash-based signature in script would raise the signature, NIST alignment and verification scores, as it has for Bitcoin Cash. ## What this rating means if you hold Bitcoin SV 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. [Bitcoin SV node software](https://github.com/bitcoin-sv/bitcoin-sv): Bitcoin SV (GitHub) (primary, checked 22 October 2026) 2. [Bitcoin SV public key and signature verification (src/pubkey.cpp)](https://github.com/bitcoin-sv/bitcoin-sv/blob/master/src/pubkey.cpp): Bitcoin SV (GitHub) (primary, checked 22 October 2026) 3. [Bitcoin SV chain parameters (src/chainparams.cpp)](https://github.com/bitcoin-sv/bitcoin-sv/blob/master/src/chainparams.cpp): Bitcoin SV (GitHub) (primary, checked 22 October 2026) 4. [Bitcoin SV version 0.1.0 release notes](https://github.com/bitcoin-sv/bitcoin-sv/blob/master/doc/release-notes-v0.1.0.md): Bitcoin SV (GitHub) (primary, checked 22 October 2026) 5. [Bitcoin SV version 1.0.0 release notes](https://github.com/bitcoin-sv/bitcoin-sv/blob/master/doc/release-notes-v1.0.0.md): Bitcoin SV (GitHub) (primary, checked 22 October 2026) 6. [Bitcoin SV version 1.2.0 release notes (Chronicle)](https://github.com/bitcoin-sv/bitcoin-sv/releases/tag/v1.2.0): Bitcoin SV (GitHub) (primary, checked 22 October 2026) 7. [ECDSA (secp256k1) for Bitcoin Transaction](https://hub.bsvblockchain.org/higher-learning/bsv-academy/digital-signatures/bsv-and-digital-signatures/ecdsa-secp256k1-for-bitcoin-transaction): BSV Blockchain (BSV Academy) (primary, checked 22 October 2026) 8. [BRC-220: NotaryHash, Privacy-Preserving Signed-Hash Notarization with SPV-Verifiable Certificates](https://github.com/bsv-blockchain/BRCs/blob/master/apps/0220.md): BSV Blockchain BRCs (GitHub) (primary, checked 22 October 2026) 9. [BRC: Bitcoin Request for Comments](https://github.com/bsv-blockchain/BRCs): BSV Blockchain (GitHub) (primary, checked 22 October 2026) 10. [sCrypt boilerplate: Lamport signature contract (src/contracts/lamportSig.ts)](https://github.com/sCrypt-Inc/boilerplate/blob/master/src/contracts/lamportSig.ts): sCrypt (GitHub) (secondary, checked 22 October 2026) 11. [Quantum computers and the Bitcoin blockchain](https://www.deloitte.com/nl/en/services/risk-advisory/perspectives/quantum-computers-and-the-bitcoin-blockchain.html): Deloitte (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). Bitcoin SV: quantum readiness assessment. Hardy Score 8.5 of 100, Tier 5: Exposed. Methodology v1.8. Last reviewed 22 October 2026; sources checked 13 November 2026. https://hardyindex.com/chains/bitcoin-sv ```bibtex @misc{hardyindex_bitcoin_sv_2026, author = {{The Hardy Index}}, title = {Bitcoin SV: quantum readiness assessment}, year = {2026}, howpublished = {\url{https://hardyindex.com/chains/bitcoin-sv}}, note = {Hardy Score 8.5 of 100, Tier 5: Exposed. Methodology v1.8}, urldate = {2026-11-13} } ``` --- Methodology: https://hardyindex.com/methodology (v1.8). Cite as: The Hardy Index, "Bitcoin SV", https://hardyindex.com/chains/bitcoin-sv, as of 13 November 2026.