--- title: Is Dash quantum-safe? chain: Dash ticker: DASH hardy_score: 16.5 rank: 34 of 80 tier: "5: Exposed" url: "https://hardyindex.com/chains/dash" updated: 2026-10-22 reviewed: 2026-11-13 methodology_version: 1.8 --- # Is Dash quantum-safe? **Hardy Score 16.5 / 100. Rank 34 of 80. Tier 5: Exposed. Last editorial review 22 October 2026; sources checked 13 November 2026.** 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. > This is a security-readiness assessment, not investment advice. ## Summary 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. ## 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. ## 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 | 3/10 | 15% | 4.5 | | 4 | Migration path | 3/10 | 15% | 4.5 | | 5 | Exposure | 4/10 | 10% | 4.0 | | 6 | Verification | 2/10 | 5% | 1.0 | | | **Hardy Score** | | | **16.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. 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: https://docs.dash.org/projects/core/en/stable/docs/guide/transactions.html ### 2. Deployment stage: 1/10 Anchor 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: https://github.com/dashpay/dips ### 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. 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. 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. Source: https://github.com/dashpay/grovedb/blob/develop/docs/book/src/quantum-cryptography.md ### 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. 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. 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. Source: https://github.com/dashpay/grovedb/blob/develop/docs/book/src/quantum-cryptography.md ### 5. Exposure: 4/10 Anchor 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. 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. Source: https://insight.dash.org/insight-api/tx/f770f05d2b1c63b71b2650227252da06ef226661982c4ee9b136b64f77bbbd0c ### 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 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. 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. Source: https://github.com/dashpay/orchard/pull/3 ## Nearest chains in the ranking The 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](https://hardyindex.com/chains/xdc-network) | 4: Debating | 20.0 | +3.5 | | 31 | [Bittensor](https://hardyindex.com/chains/bittensor) | 4: Debating | 19.0 | +2.5 | | 32 | [Monero](https://hardyindex.com/chains/monero) | 4: Debating | 17.5 | +1.0 | | 33 | [Neo](https://hardyindex.com/chains/neo) | 4: Debating | 17.0 | +0.5 | | 34 | **Dash** | 5: Exposed | 16.5 | this chain | | 35 | [Bitcoin](https://hardyindex.com/chains/bitcoin) | 4: Debating | 14.5 | -2.0 | | 36 | [Sonic](https://hardyindex.com/chains/sonic) | 5: Exposed | 14.5 | -2.0 | | 37 | [Terra Classic](https://hardyindex.com/chains/terra-classic) | 5: Exposed | 14.5 | -2.0 | | 38 | [Ethereum Classic](https://hardyindex.com/chains/ethereum-classic) | 5: Exposed | 13.0 | -3.5 | ## Signature scheme - **On mainnet today:** 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 - **Post-quantum scheme:** 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. - **NIST standard:** None adopted. ML-DSA (FIPS 204) and SLH-DSA (FIPS 205) are named as candidates for Platform's shielded pool only. - **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. Spends of DASH on Dash Core. Source (specification or proposal): https://docs.dash.org/projects/core/en/stable/docs/guide/transactions.html - **Validator consensus:** [BLS signatures on BLS12-381](https://hardyindex.com/algorithms/bls12-381.md). Mainnet, mandatory. Masternode operator keys and long-living masternode quorum threshold signatures, which sign ChainLocks and InstantSend locks. They finalise blocks and lock inputs; they do not authorise spends. Source (specification or proposal): https://github.com/dashpay/dips/blob/master/dip-0006/bls_signature_scheme.md - **Account signatures:** [RedDSA](https://hardyindex.com/algorithms/reddsa.md) (RedPallas). Mainnet, opt-in. Spend authorisation in Dash Platform's shielded pool, which credits enter by choice. Platform 4.0 introduced the pool; its mainnet activation in July 2026 is reported in secondary sources and was not read from the chain. Source (source code or release): https://github.com/dashpay/platform/releases/tag/v4.0.0 A role not listed here is not evidenced either way. See https://hardyindex.com/algorithms.md. ## Roadmap - **November 2018** (shipped): 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: https://github.com/dashpay/dips/blob/master/dip-0008.md - **July 2021** (shipped): 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: https://github.com/dashpay/dips/blob/master/dip-0023.md - **March 2026** (shipped): 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: https://github.com/dashpay/grovedb/pull/447 - **No published position** (proposed): 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: https://github.com/dashpay/dips ## If holders never migrate **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. ## Exposure 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. ## Frequently asked questions ### Is Dash quantum-safe? 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. ### Is Dash quantum-safe? 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. ### Do ChainLocks or InstantSend help against a quantum attacker? 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. ### Has Dash said anything about post-quantum cryptography? 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. ### Does Dash inherit Bitcoin's exposed coins? 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. ## What this rating means if you hold Dash 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. [Dash Core developer guide: Transactions](https://docs.dash.org/projects/core/en/stable/docs/guide/transactions.html): Dash documentation (primary, checked 22 October 2026) 2. [Dash Improvement Proposals](https://github.com/dashpay/dips): Dash (GitHub) (primary, checked 22 October 2026) 3. [DIP-0032: Confidential Transactions (dips pull request 161)](https://github.com/dashpay/dips/pull/161): Dash (GitHub) (primary, checked 22 October 2026) 4. [DIP-0006 supporting document: BLS Signature Scheme](https://github.com/dashpay/dips/blob/master/dip-0006/bls_signature_scheme.md): Dash (GitHub) (primary, checked 22 October 2026) 5. [DIP-0008: ChainLocks](https://github.com/dashpay/dips/blob/master/dip-0008.md): Dash (GitHub) (primary, checked 22 October 2026) 6. [DIP-0023: Enhanced Hard Fork Mechanism](https://github.com/dashpay/dips/blob/master/dip-0023.md): Dash (GitHub) (primary, checked 22 October 2026) 7. [DIP-0003: Deterministic Masternode Lists](https://github.com/dashpay/dips/blob/master/dip-0003.md): Dash (GitHub) (primary, checked 22 October 2026) 8. [GroveDB book: Quantum Cryptography, Post-Quantum Threat Analysis](https://github.com/dashpay/grovedb/blob/develop/docs/book/src/quantum-cryptography.md): Dash (GitHub) (primary, checked 22 October 2026) 9. [docs: add quantum cryptography chapter (GroveDB pull request 447)](https://github.com/dashpay/grovedb/pull/447): Dash (GitHub) (primary, checked 22 October 2026) 10. [feat: hybrid KEM (ML-KEM-768 + ECDH) for quantum-resistant note encryption (Orchard pull request 3)](https://github.com/dashpay/orchard/pull/3): Dash (GitHub) (primary, checked 22 October 2026) 11. [Dash Platform v4.0.0 release notes](https://github.com/dashpay/platform/releases/tag/v4.0.0): Dash (GitHub) (primary, checked 22 October 2026) 12. [Features](https://docs.dash.org/en/stable/docs/user/introduction/features.html): Dash documentation (primary, checked 22 October 2026) 13. [Block 1000 coinbase transaction](https://insight.dash.org/insight-api/tx/f770f05d2b1c63b71b2650227252da06ef226661982c4ee9b136b64f77bbbd0c): Dash Insight explorer (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). 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 ```bibtex @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} } ``` --- Methodology: https://hardyindex.com/methodology (v1.8). Cite as: The Hardy Index, "Dash", https://hardyindex.com/chains/dash, as of 13 November 2026.