--- title: Is Qtum quantum-safe? chain: Qtum ticker: QTUM hardy_score: 10.5 rank: 46 of 80 tier: "5: Exposed" url: "https://hardyindex.com/chains/qtum" updated: 2026-10-22 reviewed: 2026-11-13 methodology_version: 1.8 --- # Is Qtum quantum-safe? **Hardy Score 10.5 / 100. Rank 46 of 80. Tier 5: Exposed. Last editorial review 22 October 2026; sources checked 13 November 2026.** No. Qtum protects QTUM with ECDSA on the secp256k1 curve, inherited from the Bitcoin Core code it is built on, and since its 2022 hard fork also accepts Taproot outputs spent with Schnorr signatures on the same curve. A sufficiently large quantum computer running Shor's algorithm would break both. Qtum is proof of stake, and each block is signed by the staker's own key with an ECDSA signature, so the signatures that produce and finalise blocks are quantum-vulnerable too. We found no Qtum Improvement Proposal, roadmap item or research programme on post-quantum signatures. Despite the name, nothing we found in Qtum's own material markets it as quantum-safe. What Qtum does have is a record of shipping coordinated hard forks, most recently the January 2026 upgrade at block 5,483,000, which is the capability a migration would one day need. Qtum began its own ledger in September 2017, so it took Bitcoin's code but none of Bitcoin's coins. > This is a security-readiness assessment, not investment advice. ## Summary A proof-of-stake UTXO chain built from Bitcoin Core's code whose coins and staked blocks are signed with ECDSA on secp256k1, with Schnorr for Taproot outputs, and no post-quantum proposal for either. ## Where we are making a judgement call Two judgement calls, and one fact a reader should have. First, exposure scores 4 on the key-hash address model, as Litecoin and Dogecoin do, although staking reveals keys on a scale those chains do not have: every block signature exposes the staker's key, and qtum.info reports a stake weight of about 20.5 million QTUM against a supply of about 106.1 million. Not all of that has produced a block, and nobody has measured how much has. A reader who takes staking to mean that most active coins have revealed a key would score 3, lowering the Hardy Score from 10.5 to 9.5. Second, migration scores 2 on Qtum's record of hard forks, one of which added a new signature type. A reader who weighs that record at nothing without a quantum plan would score 1, taking 1.5 points off. Qtum's Account Abstraction Layer earns nothing here: it connects UTXOs to the EVM's account model and does not let a holder rotate to a new kind of key. Third, the fact: Qtum's Decentralised Governance Protocol lets admin and governor keys, voting in an on-chain contract, change the minimum gas price, block gas limit, block size and gas schedule without a fork. The DGP contract template sets its first admin key to whoever calls it first, and we found no published list of who holds those keys. They govern fees and block parameters, not minting or signatures, and change no score here. Whatever its name suggests, nothing we found in Qtum's own material markets the chain as quantum-safe, so the claims-unverified flag does not apply. ## 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 | 4/10 | 10% | 4.0 | | 6 | Verification | 2/10 | 5% | 1.0 | | | **Hardy Score** | | | **10.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. Qtum spends are authorised by ECDSA on secp256k1, and since the v22.0 hard fork Taproot outputs by Schnorr signatures on the same curve. Proof-of-stake blocks carry an ECDSA signature by the staker's key, which the node checks against the block key published in the coinstake output. Nothing post-quantum protects QTUM on mainnet. Source: https://github.com/qtumproject/qtum/blob/master/src/pos.cpp ### 2. Deployment stage: 1/10 Anchor band 1: Tier 5: Exposed. Tier 5: Exposed. The signatures securing QTUM and signing its blocks are quantum-vulnerable, and the Qtum Improvement Proposals, which are filed as issues in the qips repository, include none on post-quantum signatures. No roadmap or research programme addressing them was found on qtum.org or in the node repository. Source: https://github.com/qtumproject/qips/issues ### 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 Qtum's spend signatures or its block signatures, so there is nothing to assess against a NIST standard. Placement in the band: The floor of the band rather than a 1 or a 2: no scheme of any kind has been named for Qtum's fund-protecting signatures, standardised or otherwise, so there is nothing for the band's upper values to credit. Source: https://github.com/qtumproject/qips/issues ### 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. Qtum has shipped a run of mandatory hard forks: v22.0 activated Taproot and Schnorr signatures at block 2,080,512, v27.1 forked at block 4,590,000 in February 2025, and v29.1 at block 5,483,000 in January 2026. None changed the signature scheme away from secp256k1. Its Decentralised Governance Protocol adjusts fee and block parameters, not keys. Placement in the band: The top of the band rather than a 0 or a 1: repeated coordinated hard forks, including one that added a signature type, are direct evidence that Qtum can ship the kind of change a migration needs. Not a 3, because nobody with authority over the chain has acknowledged quantum migration as a problem to solve. Source: https://github.com/qtumproject/qtum/releases/tag/v29.1 ### 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. Qtum has its own ledger, begun with a genesis block of 6 September 2017, and follows Bitcoin's UTXO model, where a standard address is a key hash and the key is revealed when an output is spent. Staking adds exposure: every block's signature reveals the staker's public key, and a coinstake output that changes form must be a pay-to-public-key output. 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, spending and staking reveal keys. Not a 3, because no measurement of the share of supply behind revealed keys exists, and staking coins that have not yet produced a block have revealed nothing. Source: https://github.com/qtumproject/qtum/blob/master/src/pos.cpp ### 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 Qtum, so there is nothing post-quantum to review or audit. Under v1.8 the openness of the Qtum node, which tracks Bitcoin Core, earns nothing here, because it is classical code that a quantum computer would break. 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 Qtum is marketed as quantum-safe, so its position does not rest on marketing. Source: https://github.com/qtumproject/qtum ## Nearest chains in the ranking The chains Qtum sits among, out of 80 rated. The last column is the gap in Hardy points from Qtum. | Rank | Chain | Tier | Hardy | vs QTUM | |---:|---|---|---:|---:| | 42 | [Decred](https://hardyindex.com/chains/decred) | 5: Exposed | 10.5 | level | | 43 | [IOTA](https://hardyindex.com/chains/iota) | 5: Exposed | 10.5 | level | | 44 | [Litecoin](https://hardyindex.com/chains/litecoin) | 5: Exposed | 10.5 | level | | 45 | [Midnight](https://hardyindex.com/chains/midnight) | 5: Exposed | 10.5 | level | | 46 | **Qtum** | 5: Exposed | 10.5 | this chain | | 47 | [Kaia](https://hardyindex.com/chains/kaia) | 5: Exposed | 10.0 | -0.5 | | 48 | [Vaulta](https://hardyindex.com/chains/vaulta) | 5: Exposed | 10.0 | -0.5 | | 49 | [Dogecoin](https://hardyindex.com/chains/dogecoin) | 5: Exposed | 9.0 | -1.5 | | 50 | [0G](https://hardyindex.com/chains/0g) | 5: Exposed | 8.5 | -2.0 | ## Signature scheme - **On mainnet today:** ECDSA on secp256k1 for spends and for proof-of-stake block signatures; Schnorr on secp256k1 for Taproot outputs since the 2022 hard fork - **Post-quantum scheme:** None deployed or proposed. - **NIST standard:** None adopted - **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 pay-to-public-key-hash and pay-to-public-key outputs, inherited from Bitcoin Core. Source (source code or release): https://github.com/qtumproject/qtum/blob/master/src/pos.cpp - **Account signatures:** [Schnorr signatures on secp256k1](https://hardyindex.com/algorithms/schnorr-secp256k1.md). Mainnet, opt-in. BIP-340 Schnorr for Taproot outputs, which the node verifies on every block; added in the v22.0 hard fork. Source (source code or release): https://github.com/qtumproject/qtum/blob/master/src/validation.cpp - **Validator consensus:** [ECDSA on secp256k1](https://hardyindex.com/algorithms/ecdsa-secp256k1.md). Mainnet, mandatory. Each proof-of-stake block carries an ECDSA signature by the block key, which the node accepts either in compact (recoverable) form or as a standard DER signature. The block key is also published in the coinstake transaction's second output, as a pay-to-public-key output or a non-spendable OP_RETURN push, and under offline staking the block is signed by the staker's key with a delegator's signed proof of delegation. Source (source code or release): https://github.com/qtumproject/qtum/blob/master/src/validation.cpp A role not listed here is not evidenced either way. See https://hardyindex.com/algorithms.md. ## Roadmap - **6 September 2017** (shipped): Qtum's genesis block is mined, starting a ledger of its own. Qtum took Bitcoin Core's code, not Bitcoin's transaction history, so no Bitcoin output exists on Qtum. Source: https://github.com/qtumproject/qtum/blob/master/src/kernel/chainparams.cpp - **31 July 2022** (shipped): The v22.0 hard fork activates at block 2,080,512, adding Taproot, Schnorr signatures and Tapscript. A new signature type on secp256k1, not post-quantum work, but evidence that Qtum can change how coins are signed. Source: https://github.com/qtumproject/qtum/releases/tag/v22.0 - **15 February 2025** (shipped): The v27.1 hard fork activates at block 4,590,000, moving Qtum to Bitcoin Core 27.1 and the Cancun EVM. Source: https://github.com/qtumproject/qtum/releases/tag/v27.1 - **12 January 2026** (shipped): The v29.1 hard fork activates at block 5,483,000, moving Qtum to Bitcoin Core 29.1 and the Pectra EVM. It does not change the signature scheme. Source: https://github.com/qtumproject/qtum/releases/tag/v29.1 - **No published position** (proposed): No Qtum Improvement Proposal, roadmap item or research programme on post-quantum signatures was found in the qips repository, the node repository or on qtum.org at the time of writing. Source: https://github.com/qtumproject/qips/issues ## If holders never migrate **No stated policy.** Qtum has published no policy on coins that stay behind ECDSA or Schnorr keys, including staking coins whose keys block signatures have already revealed. As of 22 October 2026. ## Exposure Qtum began its own ledger with a genesis block dated 6 September 2017, so it shares no transaction history with Bitcoin and the exposure inheritance rule does not apply. Within that ledger it follows Bitcoin's UTXO model: a standard address is a key hash, and the key is revealed when an output is spent, so address reuse and ordinary spending erode the protection. Proof of stake adds a Qtum-specific exposure. Every block carries an ECDSA signature by the staker's key, and the key itself is published in the coinstake transaction's second output. A coinstake transaction must either return the stake to the same script or pay it to a pay-to-public-key output, so a coin that has staked a block has its key on-chain while it goes on staking. Under offline staking, the delegator's signed proof of delegation is checked against the delegator's address in the same way. The explorer qtum.info reports a network stake weight of about 20.5 million QTUM against a supply of about 106.1 million, but how much of that has produced a block, and so revealed its key, has not been measured. The score therefore reflects the address model rather than a measured figure. ## Frequently asked questions ### Is Qtum quantum-safe? No. Qtum protects QTUM with ECDSA on the secp256k1 curve, inherited from the Bitcoin Core code it is built on, and since its 2022 hard fork also accepts Taproot outputs spent with Schnorr signatures on the same curve. A sufficiently large quantum computer running Shor's algorithm would break both. Qtum is proof of stake, and each block is signed by the staker's own key with an ECDSA signature, so the signatures that produce and finalise blocks are quantum-vulnerable too. We found no Qtum Improvement Proposal, roadmap item or research programme on post-quantum signatures. Despite the name, nothing we found in Qtum's own material markets it as quantum-safe. What Qtum does have is a record of shipping coordinated hard forks, most recently the January 2026 upgrade at block 5,483,000, which is the capability a migration would one day need. Qtum began its own ledger in September 2017, so it took Bitcoin's code but none of Bitcoin's coins. ### Is Qtum quantum-safe? No. Qtum signs spends with ECDSA on the secp256k1 curve, and Taproot spends with Schnorr on the same curve. Its proof-of-stake blocks are signed with ECDSA too. A sufficiently large quantum computer would break all of them, and no post-quantum proposal, plan or research programme for Qtum was found. ### Does the name Qtum mean it is quantum-resistant? No. Nothing we found in Qtum's code or published material claims quantum resistance, and its signatures are the same elliptic-curve schemes Bitcoin uses. The index rates the cryptography the chain runs, which here is entirely quantum-vulnerable. ### Does staking QTUM expose my public key? Once your coins stake a block, yes. Each Qtum block carries the staker's ECDSA signature, the block key is published in the coinstake transaction, and the staked coins return either to the same script or to a pay-to-public-key output. A key revealed this way stays on-chain for good, which is what a harvest-now attacker needs. ### Does Qtum inherit Bitcoin's exposed coins? No. Qtum is built from Bitcoin Core's code, but its ledger began with its own genesis block in September 2017, so no Bitcoin output exists on Qtum. Its exposure comes from its own history: address reuse, ordinary spending and staking. ## What this rating means if you hold Qtum 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. [Qtum Core node software](https://github.com/qtumproject/qtum): Qtum (GitHub) (primary, checked 22 October 2026) 2. [Qtum proof-of-stake checks (src/pos.cpp)](https://github.com/qtumproject/qtum/blob/master/src/pos.cpp): Qtum (GitHub) (primary, checked 22 October 2026) 3. [Qtum block validation (src/validation.cpp)](https://github.com/qtumproject/qtum/blob/master/src/validation.cpp): Qtum (GitHub) (primary, checked 22 October 2026) 4. [Qtum chain parameters (src/kernel/chainparams.cpp)](https://github.com/qtumproject/qtum/blob/master/src/kernel/chainparams.cpp): Qtum (GitHub) (primary, checked 22 October 2026) 5. [Qtum Core v22.0 release notes](https://github.com/qtumproject/qtum/releases/tag/v22.0): Qtum (GitHub) (primary, checked 22 October 2026) 6. [Qtum Core v27.1 release notes](https://github.com/qtumproject/qtum/releases/tag/v27.1): Qtum (GitHub) (primary, checked 22 October 2026) 7. [Qtum Core v29.1 release notes](https://github.com/qtumproject/qtum/releases/tag/v29.1): Qtum (GitHub) (primary, checked 22 October 2026) 8. [Qtum Improvement Proposals (issues)](https://github.com/qtumproject/qips/issues): Qtum (GitHub) (primary, checked 22 October 2026) 9. [Decentralised Governance Protocol contract template (dgp-template.sol.js)](https://github.com/qtumproject/qtum-dgp/blob/master/dgp-template.sol.js): Qtum (GitHub) (primary, checked 22 October 2026) 10. [Qtum Technology](https://qtum.org/tech): Qtum Foundation (primary, checked 22 October 2026) 11. [qtum.info network information API](https://qtum.info/api/info): qtum.info explorer (secondary, 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). Qtum: quantum readiness assessment. Hardy Score 10.5 of 100, Tier 5: Exposed. Methodology v1.8. Last reviewed 22 October 2026; sources checked 13 November 2026. https://hardyindex.com/chains/qtum ```bibtex @misc{hardyindex_qtum_2026, author = {{The Hardy Index}}, title = {Qtum: quantum readiness assessment}, year = {2026}, howpublished = {\url{https://hardyindex.com/chains/qtum}}, note = {Hardy Score 10.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, "Qtum", https://hardyindex.com/chains/qtum, as of 13 November 2026.