Chain profile
A Bitcoin-derived chain whose coins are protected by ECDSA on secp256k1 and whose masternode quorums sign with BLS12-381, with no post-quantum proposal for either and only a deferred note on its Platform layer.
No. Dash Core secures DASH with ECDSA on the secp256k1 curve, the scheme it took from Bitcoin's codebase, and a sufficiently large quantum computer would break it. Dash adds a second layer Bitcoin does not have: masternode quorums that sign ChainLocks and InstantSend locks with BLS threshold signatures on the BLS12-381 curve, which finalise blocks and are also broken by Shor's algorithm. We found no Dash Improvement Proposal, roadmap or research programme to replace either; the one draft DIP that mentions quantum computers, an open proposal for Confidential Transactions, discusses inflation rather than signatures. The nearest thing is a threat analysis merged into the documentation of GroveDB, the storage layer of Dash Platform, which names ML-DSA and SLH-DSA as eventual replacements for the spend signatures in Platform's shielded pool and says that change can wait until 2035 or later. It does not address Dash Core's ECDSA, which protects the coins.
Where we are making a judgement call Several judgement calls. First, NIST alignment scores 3 because the GroveDB threat analysis, written by a dashpay organisation member (GitHub user QuantumExplorer) and merged in Dash's own GitHub organisation, names ML-DSA and SLH-DSA for spend signatures in Dash Platform's shielded pool, which protects Dash-backed credits. A reader who treats Dash Core alone as the chain's fund-protecting layer would score it 0, which lowers the Hardy Score from 16.5 to 12.0. Second, migration scores 3 on the same chapter, which acknowledges migration: it says to design for upgradability now and to migrate signatures from 2035 if needed. A reader who gives the chapter no weight for migration would score 2, on Dash's record of activating consensus changes alone, for a Hardy Score of 15.0, and one who sets the chapter aside for both dimensions would reach 10.5. Third, the tier. That same analysis could be counted as documented post-quantum work, which would place Dash in Tier 4 with a deployment score of 2 and a Hardy Score of 19.0. We do not, because it is a book chapter rather than a Dash Improvement Proposal or a research programme, it covers only Platform's shielded pool, and on signatures it recommends waiting. Open DIP pull request 161, a draft DIP-0032 for Confidential Transactions from an outside author, does not change that: its Quantum Computer Risk section is about inflation through forged Pedersen commitments, not signatures. Fourth, exposure scores 4 on the address model, as Litecoin and Dogecoin do, but two Dash-specific exposures are unmeasured: the early pay-to-public-key coinbase outputs, and masternode registrations that sign with the key of an external 1,000 DASH collateral the registration leaves unspent. A measurement putting a large share of supply behind exposed keys would take exposure lower, and at 2 the Hardy Score would fall by 2.0 to 14.5. The inheritance rule is not applied, because Dash began its own ledger in 2014 and copied Bitcoin's code, not its history.
ECDSA on secp256k1 for coins on Dash Core; BLS12-381 threshold signatures for masternode quorums, ChainLocks and InstantSend; RedPallas for spends in Dash Platform's shielded pool
None deployed or proposed for Dash Core. A GroveDB design note names ML-DSA and SLH-DSA as eventual replacements for shielded-pool spend signatures on Dash Platform, deferred to 2035 or later.
None adopted. ML-DSA (FIPS 204) and SLH-DSA (FIPS 205) are named as candidates for Platform's shielded pool only.
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 | 3 | 15% | 4.5 |
| 4 | Migration path | 3 | 15% | 4.5 |
| 5 | Exposure | 4 | 10% | 4.0 |
| 6 | Verification | 2 | 5% | 1.0 |
| Hardy Score | 16.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.
Dash's developer documentation states that Dash uses ECDSA with the secp256k1 curve, and a standard pay-to-public-key-hash output is spent with an secp256k1 signature. The spend signatures in Dash Platform's shielded pool are RedPallas, also elliptic-curve. Nothing post-quantum protects DASH on mainnet. source
Band 1: Tier 5: Exposed.
Tier 5: Exposed. The signatures securing DASH are quantum-vulnerable, and the Dash Improvement Proposal index lists no post-quantum proposal. The one quantum mention in a DIP is in open pull request 161, a draft DIP-0032 for Confidential Transactions by an author outside Dash's organisation, whose Quantum Computer Risk section concerns inflation through forged Pedersen commitments rather than signatures. The GroveDB threat analysis covers Platform's shielded pool, not Dash Core, and defers signature replacement rather than planning it. source
Band 3 to 5: NIST schemes are referenced as candidates without a committed selection, or the work is bespoke research.
A threat analysis merged into GroveDB's documentation, in the dashpay GitHub organisation, names ML-DSA and SLH-DSA as the replacements for spend authorisation signatures in Dash Platform's shielded pool, which holds Dash-backed credits. It commits to neither and dates the change at 2035 or later, if needed. Nothing has been named for Dash Core's ECDSA. source
Placement in the band The floor of the band rather than a 4 or a 5: NIST schemes are named as candidates, but only for Platform's shielded pool, with no selection between them, no plan and nothing named for Dash Core's ECDSA keys.
Band 3 to 5: Migration is acknowledged as a problem with no agreed mechanism, or the mechanism is contested.
No migration path exists. The GroveDB threat analysis, merged in the dashpay organisation, acknowledges migration for Platform's shielded pool: it says to design for upgradability now, versioning stored formats, and to migrate signatures and the proof system from 2035 if needed. Dash has also shown it can ship consensus changes: deterministic masternode lists, long-living masternode quorums, ChainLocks and an enhanced hard fork mechanism are all Dash Improvement Proposals with Final status. Nothing addresses moving coins on Dash Core. source
Placement in the band The floor of the band rather than a 4 or a 5, on the standard applied to Sonic: the GroveDB chapter acknowledges migration and says to design for upgradability, but it agrees no mechanism, defers signature migration to 2035 or later, and covers Platform's shielded pool rather than Dash Core. Above a 2, because the acknowledgement comes from within Dash's own organisation, the same chapter the NIST score credits.
Band 3 to 5: Most active accounts have revealed a public key, or the chain has no live supply to assess.
Dash follows Bitcoin's UTXO model: a standard address is the hash of a public key, and the key is published when the output is spent. Address reuse and every spend reveal keys, and early coinbase outputs from January 2014 paid straight to public keys, such as the 500 DASH output of block 1000, which is still unspent. source
Placement in the band A 4 rather than a 5, on the same address-model reasoning as Litecoin and Dogecoin: never-spent coins at key-hash addresses have published no key, but reuse and spending reveal keys, pay-to-public-key coinbase outputs from 2014 have keys on-chain now, and a masternode registration with external collateral carries a signature by the collateral key while the 1,000 DASH stays unspent. Neither Dash-specific exposure has been measured, and a measurement could take exposure lower.
Band 0 to 2: No post-quantum component exists, or the claims rest on marketing.
No post-quantum component protects Dash. The hybrid ML-KEM note encryption proposed for Platform's shielded pool is an open, unmerged pull request, and it encrypts notes rather than signing spends. Under v1.8 the openness of the classical code 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 Dash 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 Dash sits among, out of 80 rated. The last column is the gap in Hardy points from Dash.
| Rank | Chain | Tier | Hardy | vs DASH |
|---|---|---|---|---|
| 30 | XDC Network | 4: Debating | 20.0 | +3.5 |
| 31 | Bittensor | 4: Debating | 19.0 | +2.5 |
| 32 | Monero | 4: Debating | 17.5 | +1.0 |
| 33 | Neo | 4: Debating | 17.0 | +0.5 |
| 34 | Dash this chain | 5: Exposed | 16.5 | |
| 35 | Bitcoin | 4: Debating | 14.5 | -2.0 |
| 36 | Sonic | 5: Exposed | 14.5 | -2.0 |
| 37 | Terra Classic | 5: Exposed | 14.5 | -2.0 |
| 38 | Ethereum Classic | 5: Exposed | 13.0 | -3.5 |
DIP-0008, ChainLocks, is created: long-living masternode quorums sign each block with a BLS threshold signature to finalise it. Not post-quantum work, but it adds a second quantum-vulnerable signature to the chain's finality. source
DIP-0023 defines an enhanced hard fork mechanism involving both masternodes and miners, now final. Not post-quantum work, but evidence that Dash can activate consensus changes. source
A post-quantum threat analysis is merged into GroveDB's documentation. It recommends hybrid ML-KEM note encryption for Platform's shielded pool in 2028 to 2030 and defers spend signature replacement to 2035 or later, if needed. It does not cover Dash Core. source
No Dash Improvement Proposal, roadmap or research programme to replace Dash Core's ECDSA or the masternode BLS signatures was found at the time of writing. source
No stated policy
No Dash Core or Dash Platform policy on coins that never move to post-quantum keys has been published.
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.
Dash has its own ledger, begun with a block mined on 18 January 2014, so it shares no transaction history with Bitcoin or Litecoin and the exposure inheritance rule does not apply. Within that ledger it follows Bitcoin's UTXO model, where a standard address is a key hash and the key is revealed when an output is spent. Address reuse and ordinary spending erode that protection. Two Dash-specific features add exposure: coinbase outputs from the chain's first days paid directly to public keys, and a masternode registration that references an external 1,000 DASH collateral carries an on-chain signature by the collateral key while the collateral stays unspent. Masternode BLS operator keys are public by design, but they cannot spend collateral. No measurement of the share of DASH behind revealed keys was found, so the score reflects the address model rather than a measured figure.
What this rating means for you
Dash 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. DASH is protected by ECDSA on the secp256k1 curve, and Dash's masternode quorums sign with BLS on BLS12-381. A sufficiently large quantum computer would break both. No post-quantum signature is deployed or proposed for Dash Core.
No. Both rest on BLS threshold signatures from masternode quorums, which Shor's algorithm breaks as it breaks ECDSA. They finalise blocks and lock transaction inputs, so a quantum attacker able to forge quorum signatures would undermine finality as well as being able to forge spends.
Only for Dash Platform's shielded pool. A threat analysis merged into GroveDB's documentation in March 2026 recommends adding hybrid ML-KEM encryption to shielded notes around 2028 to 2030, to stop notes being harvested now and decrypted later, and names ML-DSA and SLH-DSA as replacements for spend signatures, deferred to 2035 or later. Nothing addresses the ECDSA keys on Dash Core.
No. Dash's code descends from Bitcoin's, but its ledger began with its own block on 18 January 2014, so no Bitcoin output exists on Dash. Its exposure comes from its own history: early coinbase outputs paid straight to public keys, plus the usual address reuse and spending.
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). Dash: quantum readiness assessment. Hardy Score 16.5 of 100, Tier 5: Exposed. Methodology v1.8. Last reviewed 22 October 2026; sources checked 13 November 2026. https://hardyindex.com/chains/dash
@misc{hardyindex_dash_2026,
author = {{The Hardy Index}},
title = {Dash: quantum readiness assessment},
year = {2026},
howpublished = {\url{https://hardyindex.com/chains/dash}},
note = {Hardy Score 16.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/dash.md.
This is a security-readiness assessment, not investment advice.