Chain profile
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.
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.
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.
ECDSA on secp256k1 for transactions; proof of work for block production
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.
None adopted. BRC-220 names ML-DSA (FIPS 204) and SLH-DSA (FIPS 205) for notarisation certificates, not for spends.
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.
A role not listed is not evidenced either way. Every scheme, and which other chains share it, is in the cryptography registry.
| No. | Dimension | Score | Weight | Contribution |
|---|---|---|---|---|
| 1 | Signature scheme | 0 | 30% | 0.0 |
| 2 | Deployment stage | 1 | 25% | 2.5 |
| 3 | NIST alignment | 0 | 15% | 0.0 |
| 4 | Migration path | 2 | 15% | 3.0 |
| 5 | Exposure | 2 | 10% | 2.0 |
| 6 | Verification | 2 | 5% | 1.0 |
| Hardy Score | 8.5 | |||
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
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
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. source
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.
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. source
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.
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. source
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.
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. source
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.
The deployment dimension is not a separate judgement. It is Tier 5 expressed as a number. See the tier mapping.
The 9 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 | 5: Exposed | 8.5 | level |
| 52 | Akash Network | 5: Exposed | 8.5 | level |
| 53 | Arweave | 5: Exposed | 8.5 | level |
| 54 | Avalanche | 5: Exposed | 8.5 | level |
| 55 | Bitcoin SV this chain | 5: Exposed | 8.5 | |
| 56 | Celestia | 5: Exposed | 8.5 | level |
| 57 | Chiliz Chain | 5: Exposed | 8.5 | level |
| 58 | Conflux | 5: Exposed | 8.5 | level |
| 59 | dYdX Chain | 5: Exposed | 8.5 | level |
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
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
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
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
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
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. Published beside the score, not in it. Every chain's stance is compared on the commitments page.
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.
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.
What this rating means for you
Bitcoin SV runs quantum-vulnerable signatures with no published post-quantum plan that we could find. Nothing here is urgent today, and there is also nothing scheduled to change it.
Editorial guidance from the Hardy Index.
We will email you the day this rating moves, with the changelog note that explains why. Nothing else, and nothing in between.
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.
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.
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.
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.
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.
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.
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
@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}
} The whole dataset is reusable under the terms on the about page. A machine-readable version of this page is at /chains/bitcoin-sv.md.
This is a security-readiness assessment, not investment advice.