--- title: Is QoreChain quantum-safe? chain: QoreChain ticker: QOR hardy_score: 84.5 rank: 6 of 80 tier: "2: Shipping" url: "https://hardyindex.com/chains/qorechain" updated: 2026-11-04 reviewed: 2026-11-13 methodology_version: 1.8 --- # Is QoreChain quantum-safe? **Hardy Score 84.5 / 100. Rank 6 of 80. Tier 2: Shipping. Last editorial review 4 November 2026; sources checked 13 November 2026.** Mostly, and further than a hybrid label suggests, with two gaps. QoreChain is a Cosmos SDK layer 1 whose mainnet, qorechain-vladi, has run since 7 June 2026. Since release 3.1.71 of 25 June 2026 its rules require every transaction on the Cosmos lane to carry an ML-DSA-87 signature, from the final FIPS 204 standard, alongside the classical secp256k1 one, and the EVM lane admits a transaction only from an account that holds a registered post-quantum key and has opened a spending window with a hybrid-signed message. A quantum computer that breaks secp256k1 therefore cannot move funds from an account that has registered a key, because it would also have to forge ML-DSA-87. We read this on the chain: a transfer of 23 October 2026 carries a 4,627-byte signature that verifies, under an independent FIPS 204 implementation, against the account's registered 2,592-byte key. The first gap is the registration itself. An account with no post-quantum key may register one with its secp256k1 signature alone, so until it does, its coins answer to the classical key, and on 23 October accounts without a key held about half of all QOR. The second is that validators sign blocks with Ed25519, which Shor's algorithm breaks, and no post-quantum plan for them is published. > This is a security-readiness assessment, not investment advice. ## Summary QoreChain requires an ML-DSA-87 signature beside secp256k1 on every transfer from an account with a registered post-quantum key, but an account's key is registered with a classical signature, and about half of QOR sat in accounts with no post-quantum key on 23 October 2026. ## Where we are making a judgement call QoreChain qualifies on the deployment test, a post-quantum signature running on its mainnet, and its size plays no part in the score. It also markets itself as "The quantum-safe Layer 1 for the next decade"; the claim is checked here rather than flagged, because the chain confirms a post-quantum signature protecting funds. It is overbroad all the same: it holds for registered accounts, about 47.5% of supply, while about half of QOR answers to secp256k1 alone until its holder registers a key, and validators sign with Ed25519. Three readings are ours. The first is the tier. A reader who takes the required hybrid signature as post-quantum signatures mandatory for all, built in from genesis, would place QoreChain in Tier 1 with a signature score of 10, giving 92.5 rather than 84.5. We do not, for three reasons: the mainnet launched in optional mode and enforcement arrived with release 3.1.71 of 25 June 2026; an account's post-quantum key is registered under its classical signature, so about half of QOR answered to secp256k1 alone on 23 October 2026; and validators sign with Ed25519. The second is verification: a reader who counts our independent check of on-chain signatures as enough without readable enforcement code would score 5 and add 0.5 points, and one who scores the closed code alone would score 3 and lose 0.5. The third is exposure at 7: a reader who applies the account-model rule of 2 to every published secp256k1 key would lower the score by 5.0 points. On scope: validator admission is permissioned. create-validator needs a validator_operator licence, issued through a Validator Program with selection and a $1,000 programme fee, and granted by a licence authority account that governance can replace since v3.2.3; eight validators were bonded on 23 October 2026. We rate it, as we rate other chains with permissioned validators, because it runs its own consensus and anyone can hold and send QOR; a reader who excludes permissioned validator sets would leave QoreChain out of the index rather than score it differently. Facts no score turns on: the hybrid enforcement level is a governance parameter that a proposal could set back to optional or disabled, and running a node on mainnet needs the official pre-compiled release, since a binary built from the public source refuses live networks and cannot make a Dilithium signature. ## Score breakdown | # | Dimension | Score | Weight | Contribution | |---:|---|---:|---:|---:| | 1 | Signature scheme | 9/10 | 30% | 27.0 | | 2 | Deployment stage | 8/10 | 25% | 20.0 | | 3 | NIST alignment | 10/10 | 15% | 15.0 | | 4 | Migration path | 9/10 | 15% | 13.5 | | 5 | Exposure | 7/10 | 10% | 7.0 | | 6 | Verification | 4/10 | 5% | 2.0 | | | **Hardy Score** | | | **84.5** | ### 1. Signature scheme: 9/10 Anchor band 7 to 9: A post-quantum signature is available on mainnet at the protocol level as a first-class account type. ML-DSA-87 is required on mainnet: the module parameters are hybrid_signature_mode = required and allow_classical_fallback = false, so a Cosmos-lane transaction without the Dilithium-5 extension is rejected, and since v3.2.0 an EVM transaction is refused unless its sender has a registered post-quantum key and a live authorisation window opened by a hybrid-signed message. The documented exemptions are genesis transactions, an unjail from a keyless operator, and a key registration from an account that has no key, which is signed with secp256k1 alone. Placement in the band: The top of the band rather than a 7 or an 8, because the protocol requires the post-quantum signature for every spend and offers no classical fallback. Not a 10, which needs post-quantum protection for every account: the registration exemption means an account's post-quantum key is bound by a classical signature, so the half of QOR in accounts with no key on 23 October 2026 answers to secp256k1 alone, and inside an open EVM window a transaction carries only a secp256k1 signature. Source: https://docs.qorechain.io/architecture/post-quantum-security/ ### 2. Deployment stage: 8/10 Anchor band 8: Tier 2: Shipping. Tier 2: Shipping. ML-DSA-87 protects QOR on mainnet today, and any holder can use it with released software: the QoreX wallet, published for Chrome, Firefox, iOS and Android, registers the key and signs every Native-lane transfer with the hybrid signature, and the official qorechaind release does the same from the command line. See the caveat for why this is not Tier 1. Source: https://docs.qorechain.io/qorex/overview/ ### 3. NIST alignment: 10/10 Anchor band 9 to 10: The scheme in use is covered by a final NIST standard (FIPS 204, FIPS 205, or SP 800-208). The scheme is ML-DSA-87 from FIPS 204, final since August 2024, and it is in use on mainnet. The sizes on the chain fit the final standard rather than round-three Dilithium5: the registered public key is 2,592 bytes and the signature 4,627 bytes, where the round-three scheme's signature was 4,595 bytes. A mainnet signature we checked verifies under @noble/post-quantum's FIPS 204 ML-DSA-87. Placement in the band: A 10 rather than a 9: the standard is final, the named parameter set is the one deployed, and a signature read from the chain verifies under an independent implementation of that standard, so conformance is shown rather than only claimed. Source: https://csrc.nist.gov/pubs/fips/204/final ### 4. Migration path: 9/10 Anchor band 9 to 10: Holders can migrate today, or the published plan is dated, specific, and executable under the chain’s existing governance. Holders migrate in place. An account registers an ML-DSA-87 key once, keeping its address and balance, and QoreX and the QoreChain SDK make the registration for the holder. The chain also has in-place key rotation (MsgRotatePQCKey) and a governance-run algorithm migration in which old and new keys co-sign, and it has carried coordinated upgrades by governance, most recently v3.2.5, applied by governance proposal 14 at height 3,906,833 on 29 October 2026 after v3.2.4 at height 3,742,566 on 23 October, both leaving transaction signing unchanged. Placement in the band: A 9 rather than a 10: the route is open and in-place, but nothing obliges a holder to take it before a quantum attacker could, and the 70 accounts holding about half of QOR without a key on 23 October 2026 stay bound to their classical key until their owners act, with no deadline published. Source: https://docs.qorechain.io/getting-started/first-transaction/ ### 5. Exposure: 7/10 Anchor band 6 to 8: Addresses are key hashes and exposure is limited to spent outputs, keeping a meaningful share of supply unexposed. Addresses are hashes of secp256k1 keys, as on other Cosmos chains, but a published classical key does not by itself spend from an account with a registered post-quantum key. Read through the node on 23 October 2026, 183 accounts held QOR: 107 with a registered ML-DSA-87 key held about 47.5% of supply, 70 without one held about 50.0%, and module accounts held the rest. None of the 70 had a public key on the chain. Placement in the band: Not an 8: validator Ed25519 keys are public by design, an open EVM window lets a secp256k1 key alone move tokens other than native QOR unless the window was scoped, and an unregistered account falls to its classical key if that key is visible anywhere, for example on another Cosmos chain sharing coin type 118. Not a 6, because no exposed account key authorises a Cosmos-lane spend alone and the unregistered half has published no key on QoreChain. Source: https://api.qore.host/cosmos/bank/v1beta1/denom_owners/uqor?pagination.limit=1000 ### 6. Verification: 4/10 Anchor band 3 to 5: A post-quantum component exists, on mainnet, on a persistent testnet or as a merged implementation, but is unreviewed. The post-quantum component is live on mainnet and its use is checkable there: we verified a transfer's ML-DSA-87 signature against the registered key ourselves. The code that enforces it is not public. In the open-source qorechain-core tree the hybrid verification ante handler is a "pass-through stub for public builds", the README says the post-quantum libraries are "distributed as pre-compiled binaries under separate licensing terms", and we found no named audit of the component. The open-source qorechain-pqc client library wraps outside implementations, whose review does not count here. Placement in the band: A 4 rather than a 3: anyone can confirm from the chain that the signatures are standard ML-DSA-87 and verify them with an independent library. Not a 5, because the rule that rejects a transaction without one runs in closed binaries that no outsider can read, so the enforcement itself is unreviewable. Source: https://github.com/qorechain/qorechain-core/blob/main/x/pqc/ante_hybrid_stub.go ## Nearest chains in the ranking The chains QoreChain sits among, out of 80 rated. The last column is the gap in Hardy points from QoreChain. | Rank | Chain | Tier | Hardy | vs QOR | |---:|---|---|---:|---:| | 2 | [Dilithion](https://hardyindex.com/chains/dilithion) | 1: Native | 93.5 | +9.0 | | 3 | [Quantum Resistant Ledger](https://hardyindex.com/chains/qrl) | 1: Native | 92.5 | +8.0 | | 4 | [Mochimo](https://hardyindex.com/chains/mochimo) | 1: Native | 89.0 | +4.5 | | 5 | [Tidecoin](https://hardyindex.com/chains/tidecoin) | 1: Native | 89.0 | +4.5 | | 6 | **QoreChain** | 2: Shipping | 84.5 | this chain | | 7 | [Abelian](https://hardyindex.com/chains/abelian) | 1: Native | 84.0 | -0.5 | | 8 | [NEAR Protocol](https://hardyindex.com/chains/near) | 2: Shipping | 80.0 | -4.5 | | 9 | [Algorand](https://hardyindex.com/chains/algorand) | 2: Shipping | 77.0 | -7.5 | | 10 | [Nervos CKB](https://hardyindex.com/chains/nervos-ckb) | 2: Shipping | 76.0 | -8.5 | ## Signature scheme - **On mainnet today:** Hybrid: secp256k1 plus ML-DSA-87, both required on every Cosmos-lane transaction from an account with a registered post-quantum key; EVM-lane transactions are secp256k1-signed inside a window opened by a hybrid-signed message; Ed25519 for validator consensus - **Post-quantum scheme:** ML-DSA-87 (Dilithium-5) for account signatures, required since release 3.1.71; ML-KEM-1024 specified for bridge relayer channels, with no bridge route live - **NIST standard:** FIPS 204 (ML-DSA), final since August 2024 - **Readiness tier:** Tier 2: Shipping. A post-quantum signature is live on mainnet and usable by ordinary holders. ## Cryptography in use - **Account signatures:** [ML-DSA](https://hardyindex.com/algorithms/ml-dsa.md) (ML-DSA-87). Mainnet, mandatory. Read on 23 October 2026: a bank transfer at height 3,725,984 carries a 4,627-byte PQCHybridSignature extension that verifies against the sender's registered 2,592-byte key. Required on the Cosmos lane since release 3.1.71; a key registration from an account with no key is exempt. Source (read on-chain): https://api.qore.host/cosmos/tx/v1beta1/txs/7DC4729A41FEF6061B5F3F329034B06E0F7FEB3B62F06748AA6FF84446FA5876 - **Account signatures:** [ECDSA on secp256k1](https://hardyindex.com/algorithms/ecdsa-secp256k1.md). Mainnet, mandatory. The classical half of every hybrid signature, the sole signature on a first key registration, and the sole signature on an EVM transaction inside an open authorisation window. Source (read on-chain): https://api.qore.host/cosmos/tx/v1beta1/txs/7DC4729A41FEF6061B5F3F329034B06E0F7FEB3B62F06748AA6FF84446FA5876 - **Validator consensus:** [Ed25519](https://hardyindex.com/algorithms/ed25519.md). Mainnet, mandatory. Read on 23 October 2026: all eight bonded validators carry Ed25519 consensus keys. Source (read on-chain): https://api.qore.host/cosmos/staking/v1beta1/validators?status=BOND_STATUS_BONDED A role not listed here is not evidenced either way. See https://hardyindex.com/algorithms.md. ## Roadmap - **7 June 2026** (shipped): QoreChain mainnet, qorechain-vladi, launches with the x/pqc module and ML-DSA-87 key registration, with hybrid signatures in optional mode, which the documentation records as the genesis setting. Source: https://docs.qorechain.io/architecture/post-quantum-security/ - **25 June 2026** (shipped): Release 3.1.71 makes hybrid signatures required by default on the Cosmos lane, each transaction carrying an ML-DSA-87 signature beside the secp256k1 one, with the classical-only fallback closed. Source: https://github.com/qorechain/qorechain-core/releases/tag/v3.1.71 - **25 September 2026** (shipped): Release 3.2.0, applied by governance at mainnet height 2,981,742, admits an EVM transaction only from an account with a registered post-quantum key and an open authorisation window, and binds the ML-DSA signature to a domain tag and the chain ID. Source: https://docs.qorechain.io/getting-started/first-transaction/ - **20 October 2026** (shipped): Release 3.2.3, applied at mainnet height 3,662,051, refuses weak, empty and reused post-quantum keys, requires the hybrid signature on registrations from accounts that already hold a key, and adds an optional proof of possession. Source: https://docs.qorechain.io/architecture/post-quantum-security/ - **No date published** (proposed): No post-quantum scheme for validator consensus keys has been published. Validators sign with Ed25519, and QoreChain's post-quantum validator material covers bridge attestations, which are not live. Source: https://docs.qorechain.io/developer-guide/running-a-validator/ ## If holders never migrate **No stated policy.** An account with no post-quantum key cannot transfer on either lane until it registers one, and the registration may be signed with its secp256k1 key alone, so coins that never migrate stay claimable by the classical key. The documentation states no deadline and no other treatment for them. As of 23 October 2026. Source: https://docs.qorechain.io/architecture/post-quantum-security/ ## Exposure QoreChain addresses are hashes of secp256k1 keys, so an account that has never signed keeps its key private, and the same key controls the qor1 address, the 0x address and the base58 address. What changes the usual picture is the hybrid rule. Once an account registers an ML-DSA-87 key, its published secp256k1 key no longer spends on its own: a quantum attacker who recovers it still needs the ML-DSA-87 key for any Cosmos-lane transaction, and an EVM transaction needs a window that only a hybrid-signed message opens. Two exposures remain. Inside an open window, an EVM transaction is signed with secp256k1 alone: native QOR is capped by the window, but token transfers and other calls carry no value and are not bounded unless the holder scoped the window, which lasts at most 17,280 blocks. And an account that has not registered a key can be claimed by whoever holds its classical key, through a registration signed with that key alone. On 23 October 2026, 70 such accounts held about 50.0% of the 4,493,785,582 QOR supply, read from the node; none had published a key on QoreChain, but a holder whose key is visible elsewhere, for instance on another Cosmos chain that shares coin type 118, is exposed through it. Validator Ed25519 keys are public by design. ## Frequently asked questions ### Is QoreChain quantum-safe? Mostly, and further than a hybrid label suggests, with two gaps. QoreChain is a Cosmos SDK layer 1 whose mainnet, qorechain-vladi, has run since 7 June 2026. Since release 3.1.71 of 25 June 2026 its rules require every transaction on the Cosmos lane to carry an ML-DSA-87 signature, from the final FIPS 204 standard, alongside the classical secp256k1 one, and the EVM lane admits a transaction only from an account that holds a registered post-quantum key and has opened a spending window with a hybrid-signed message. A quantum computer that breaks secp256k1 therefore cannot move funds from an account that has registered a key, because it would also have to forge ML-DSA-87. We read this on the chain: a transfer of 23 October 2026 carries a 4,627-byte signature that verifies, under an independent FIPS 204 implementation, against the account's registered 2,592-byte key. The first gap is the registration itself. An account with no post-quantum key may register one with its secp256k1 signature alone, so until it does, its coins answer to the classical key, and on 23 October accounts without a key held about half of all QOR. The second is that validators sign blocks with Ed25519, which Shor's algorithm breaks, and no post-quantum plan for them is published. ### Is QoreChain quantum-safe? For an account that has registered its post-quantum key, largely yes: every Cosmos-lane spend needs an ML-DSA-87 signature beside the secp256k1 one, and EVM spends need a window opened by such a signature. An account that has not registered a key is protected only by its classical key until it does, and on 23 October 2026 such accounts held about half of QOR. Validators sign with Ed25519. ### Why does a hybrid signature protect funds from a quantum computer? Because the chain requires both halves. A quantum computer running Shor's algorithm could recover the secp256k1 key, but a Cosmos-lane transaction without a valid ML-DSA-87 signature from the account's registered key is rejected, and ML-DSA-87 is not broken by Shor's algorithm. The secp256k1 half adds protection against a flaw in the newer scheme rather than removing any. ### How does a QOR holder get post-quantum protection? By registering an ML-DSA-87 key on the account once, which keeps the address and balance. The QoreX wallet and the QoreChain SDK do this for the holder, and the qorechaind command-line tool can do it by hand. Any later transfer then needs the post-quantum signature. This is a security-readiness assessment and not advice on how to manage your own keys. ### Is the ML-DSA used on QoreChain the NIST standard? Yes, on the evidence of the chain itself. QoreChain calls the scheme Dilithium-5 and ML-DSA-87; the signatures it carries are 4,627 bytes, the FIPS 204 ML-DSA-87 size rather than the 4,595 bytes of the earlier round-three Dilithium5, and a mainnet signature we checked verifies under an independent FIPS 204 implementation. ### Can QoreChain's post-quantum code be audited? Only in part. The client library is open source, and anyone can verify the signatures on the chain. The node code that verifies them and rejects transactions without them is not public: the open repository carries stubs in its place, and QoreChain says its post-quantum libraries ship as pre-compiled binaries under separate licensing terms. We found no named audit of that component. ## What this rating means if you hold QoreChain 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. [Post-Quantum Security](https://docs.qorechain.io/architecture/post-quantum-security/): QoreChain documentation (primary, checked 23 October 2026) 2. [Networks](https://docs.qorechain.io/appendix/networks/): QoreChain documentation (primary, checked 23 October 2026) 3. [Version History](https://docs.qorechain.io/appendix/version-history/): QoreChain documentation (primary, checked 23 October 2026) 4. [First Transaction](https://docs.qorechain.io/getting-started/first-transaction/): QoreChain documentation (primary, checked 23 October 2026) 5. [Post-Quantum Signing](https://docs.qorechain.io/developer-guide/post-quantum-signing/): QoreChain documentation (primary, checked 23 October 2026) 6. [Running a Validator](https://docs.qorechain.io/developer-guide/running-a-validator/): QoreChain documentation (primary, checked 23 October 2026) 7. [Chain Licensing](https://docs.qorechain.io/architecture/chain-licensing/): QoreChain documentation (primary, checked 23 October 2026) 8. [QoreX overview](https://docs.qorechain.io/qorex/overview/): QoreChain documentation (primary, checked 23 October 2026) 9. [QoreX browser extension](https://docs.qorechain.io/qorex/browser-extension/): QoreChain documentation (primary, checked 23 October 2026) 10. [QoreX (Firefox add-on)](https://addons.mozilla.org/firefox/addon/qorex/): Mozilla Add-ons (primary, checked 23 October 2026) 11. [qorechain-core repository](https://github.com/qorechain/qorechain-core): QoreChain (GitHub) (primary, checked 23 October 2026) 12. [Hybrid verification ante handler, public build (x/pqc/ante_hybrid_stub.go)](https://github.com/qorechain/qorechain-core/blob/main/x/pqc/ante_hybrid_stub.go): QoreChain (GitHub) (primary, checked 23 October 2026) 13. [qorechain-core README](https://github.com/qorechain/qorechain-core/blob/main/README.md): QoreChain (GitHub) (primary, checked 23 October 2026) 14. [Release v3.1.71](https://github.com/qorechain/qorechain-core/releases/tag/v3.1.71): QoreChain (GitHub) (primary, checked 23 October 2026) 15. [qorechain-pqc library](https://github.com/qorechain/qorechain-pqc): QoreChain (GitHub) (primary, checked 23 October 2026) 16. [Mainnet transaction 7DC4729A (REST)](https://api.qore.host/cosmos/tx/v1beta1/txs/7DC4729A41FEF6061B5F3F329034B06E0F7FEB3B62F06748AA6FF84446FA5876): QoreChain mainnet node (primary, checked 23 October 2026) 17. [Registered post-quantum key of qor1lqat006shcee85kyx028qnpdfgmu8glavsd607](https://api.qore.host/qorechain/pqc/v1/account/qor1lqat006shcee85kyx028qnpdfgmu8glavsd607): QoreChain mainnet node (primary, checked 23 October 2026) 18. [Latest block](https://api.qore.host/cosmos/base/tendermint/v1beta1/blocks/latest): QoreChain mainnet node (primary, checked 23 October 2026) 19. [QOR holders (denom owners)](https://api.qore.host/cosmos/bank/v1beta1/denom_owners/uqor?pagination.limit=1000): QoreChain mainnet node (primary, checked 23 October 2026) 20. [Bonded validators](https://api.qore.host/cosmos/staking/v1beta1/validators?status=BOND_STATUS_BONDED): QoreChain mainnet node (primary, checked 23 October 2026) 21. [Governance proposals](https://api.qore.host/cosmos/gov/v1/proposals): QoreChain mainnet node (primary, checked 23 October 2026) 22. [Transaction 7DC4729A on the QoreChain explorer](https://explore.qore.network/tx/7DC4729A41FEF6061B5F3F329034B06E0F7FEB3B62F06748AA6FF84446FA5876): QoreChain explorer (primary, checked 23 October 2026) 23. [FIPS 204: Module-Lattice-Based Digital Signature Standard (ML-DSA)](https://csrc.nist.gov/pubs/fips/204/final): NIST (primary, checked 23 October 2026) 24. [QoreChain documentation home](https://docs.qorechain.io/): QoreChain (primary, checked 23 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). QoreChain: quantum readiness assessment. Hardy Score 84.5 of 100, Tier 2: Shipping. Methodology v1.8. Last reviewed 4 November 2026; sources checked 13 November 2026. https://hardyindex.com/chains/qorechain ```bibtex @misc{hardyindex_qorechain_2026, author = {{The Hardy Index}}, title = {QoreChain: quantum readiness assessment}, year = {2026}, howpublished = {\url{https://hardyindex.com/chains/qorechain}}, note = {Hardy Score 84.5 of 100, Tier 2: Shipping. Methodology v1.8}, urldate = {2026-11-13} } ``` --- Methodology: https://hardyindex.com/methodology (v1.8). Cite as: The Hardy Index, "QoreChain", https://hardyindex.com/chains/qorechain, as of 13 November 2026.