--- title: Is THORChain quantum-safe? chain: THORChain ticker: RUNE hardy_score: 8.5 rank: 72 of 80 tier: "5: Exposed" url: "https://hardyindex.com/chains/thorchain" updated: 2026-11-04 reviewed: 2026-11-13 methodology_version: 1.8 --- # Is THORChain quantum-safe? **Hardy Score 8.5 / 100. Rank 72 of 80. Tier 5: Exposed. Last editorial review 4 November 2026; sources checked 13 November 2026.** No. RUNE accounts on THORChain sign with ECDSA on secp256k1, as on other Cosmos SDK chains, and the CometBFT validator set signs consensus votes with Ed25519, which the live network's consensus parameters list as the one validator key type. THORChain also holds native assets on other chains, among them Bitcoin, Ethereum, Litecoin and Dogecoin, in Asgard vaults controlled by threshold signatures: according to THORChain's documentation, the node operators run GG20 threshold ECDSA on secp256k1 for most connected chains and threshold EdDSA on Ed25519 for chains such as Solana, and a two-thirds supermajority of a vault's members must cooperate to spend from it. A sufficiently large quantum computer running Shor's algorithm would break every one of these schemes. We found no post-quantum position from THORChain: none of its architecture decision records mentions post-quantum signatures, and the node repository, developer documentation and user documentation do not address them. THORNode pins Cosmos SDK v0.53.0, which has no post-quantum key type. > This is a security-readiness assessment, not investment advice. ## Summary RUNE accounts sign with ECDSA on secp256k1, validators with Ed25519, and the vaults holding swapped assets on other chains with threshold ECDSA and EdDSA keys, and no post-quantum plan, proposal or research programme for any of them could be found. ## Where we are making a judgement call Three judgement calls carry this profile. The first is what the row scores. It scores RUNE and THORChain's own ledger: the accounts that hold RUNE, the validators that finalise blocks, and the protocol's control of its vaults. The assets in those vaults sit on Bitcoin, Ethereum and the other connected chains under THORChain's threshold ECDSA and EdDSA keys. Those keys are published by design and the threshold schemes are as vulnerable to Shor's algorithm as single-key signatures, so the vault assets are exposed twice over: through THORChain's vault keys and through the host chain's own signature scheme, which that chain's profile scores. We describe the vault exposure here and keep it out of the exposure score, because a measurement of it would belong to assets the index already scores on their own chains. A reader who folds the vault keys in would score exposure 1, on the grounds that the keys guarding every pooled asset are public, giving a Hardy Score of 7.5 rather than 8.5. A score of 0 is not open on that reading, because never-signed RUNE addresses still keep their keys hidden. The second is the Cosmos SDK. Cosmos SDK v0.55 now offers ML-DSA-65 keys, and the Cosmos Hub's profile credits that work because Cosmos Labs maintains the Hub's software. Cosmos Labs has no such role at THORChain, which runs its own release process, pins SDK v0.53.0 and has published nothing about adopting the newer release, so the framework option earns THORChain nothing here. A reader who credits it as available upstream work would still find no THORChain proposal or research programme on its signatures, so no reading of the record lifts THORChain to Tier 4. The third is migration. Vault keys already rotate at every churn, when the node operators generate new threshold keys and move the vault funds to them, which a reader might treat, as the Toncoin profile treats its wallet contracts, as a structural route that a post-quantum vault scheme could use without disturbing holders. On that reading migration would score 3, giving a Hardy Score of 10.0 rather than 8.5. We keep it at 2, because churn rotates keys within the same classical schemes, RUNE accounts have no equivalent route, and THORChain has not acknowledged the quantum problem in public. ## 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 | 2/10 | 10% | 2.0 | | 6 | Verification | 2/10 | 5% | 1.0 | | | **Hardy Score** | | | **8.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. THORChain's developer documentation gives the signing algorithm as "secp256k1 (same as Cosmos)", the mainnet consensus parameters accept Ed25519 validator keys and nothing else, and the vault keys are threshold ECDSA and EdDSA. Nothing post-quantum protects RUNE or the assets THORChain holds. Source: https://dev.thorchain.org/technical-faq.html ### 2. Deployment stage: 1/10 Anchor band 1: Tier 5: Exposed. Tier 5: Exposed. The signatures protecting RUNE and finalising THORChain's blocks are quantum-vulnerable, and no architecture decision record, developer documentation, release or other publication from THORChain addresses post-quantum signatures. Source: https://dev.thorchain.org/architecture/ ### 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 THORChain's account, validator or vault 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: nobody with authority over THORChain has named a scheme, even as an example. The ML-DSA keys in Cosmos SDK v0.55 are not counted, because THORNode pins v0.53.0 and no THORChain publication points to them. Source: https://dev.thorchain.org/architecture/ ### 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 or published position exists. THORChain does have a working upgrade route: each consensus-breaking release is proposed on chain by an active validator with a target height, approved by the validators' on-chain vote and activated at that height, and mainnet runs THORNode 3.21.0 after a series of such releases, with 3.21.1 named as the next version on 3 November 2026. Nothing has been proposed to carry a post-quantum scheme through it. Placement in the band: The top of the band rather than a 0 or a 1: the release process has delivered consensus changes to mainnet many times, and vault funds already move to newly generated keys at every churn, which a future vault migration could build on. Not a 3, because THORChain has not acknowledged the quantum problem in public. Source: https://dev.thorchain.org/release.html ### 5. Exposure: 2/10 Anchor band 0 to 2: Public keys are exposed for effectively all accounts, or a large, measured share of total supply sits in exposed addresses. A THORChain address is a Bech32 encoding of a hash of the secp256k1 public key, so an account that has never signed keeps its key hidden. Any send, swap, bond or deposit reveals it, which covers almost all RUNE in use. Validator consensus keys are public by design, and the vault public keys are published through the network's inbound-address endpoint. Placement in the band: The top of the band rather than a 1: never-signed addresses keep their keys hidden, as on other Cosmos SDK chains. Not a 3, because almost all active RUNE sits behind a revealed key and no measurement of the unexposed share has been published. See the caveat on the vault keys. Source: https://dev.thorchain.org/technical-faq.html ### 6. Verification: 2/10 Anchor band 0 to 2: No post-quantum component exists, or the claims rest on marketing. No post-quantum component exists for THORChain: no code, specification or testnet implementation was found in THORNode or the architecture decision records. THORNode imports its threshold-signature library from a private repository, gitlab.com/thorchain/tss/tss-lib-private.git/v3, so the library in use cannot be inspected, and the statement that the vaults run GG20 rests on THORChain's documentation. THORNode is open source, but under v1.8 the openness of classical code earns nothing on this dimension. Placement in the band: The top of the band rather than a 0 or a 1: there is nothing post-quantum to verify, but THORChain does not market RUNE or its vaults as quantum-safe, so its position does not rest on marketing. Source: https://gitlab.com/thorchain/thornode/-/blob/develop/go.mod ## Nearest chains in the ranking The chains THORChain sits among, out of 80 rated. The last column is the gap in Hardy points from THORChain. | Rank | Chain | Tier | Hardy | vs RUNE | |---:|---|---|---:|---:| | 68 | [MultiversX](https://hardyindex.com/chains/multiversx) | 5: Exposed | 8.5 | level | | 69 | [Polygon PoS](https://hardyindex.com/chains/polygon-pos) | 5: Exposed | 8.5 | level | | 70 | [Provenance Blockchain](https://hardyindex.com/chains/provenance) | 5: Exposed | 8.5 | level | | 71 | [Theta Network](https://hardyindex.com/chains/theta) | 5: Exposed | 8.5 | level | | 72 | **THORChain** | 5: Exposed | 8.5 | this chain | | 73 | [VeChain](https://hardyindex.com/chains/vechain) | 5: Exposed | 8.5 | level | | 74 | [WEMIX](https://hardyindex.com/chains/wemix) | 5: Exposed | 8.5 | level | | 75 | [Whitechain](https://hardyindex.com/chains/whitechain) | 5: Exposed | 8.5 | level | | 76 | [Beldex](https://hardyindex.com/chains/beldex) | 5: Exposed | 7.5 | -1.0 | ## Signature scheme - **On mainnet today:** ECDSA on secp256k1 for RUNE accounts; Ed25519 for CometBFT validator consensus; GG20 threshold ECDSA (secp256k1) and threshold EdDSA (Ed25519) for the Asgard vaults that hold assets on other chains - **Post-quantum scheme:** None. No post-quantum scheme has been proposed, selected or tested for THORChain. - **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. THORChain's developer documentation gives the signing algorithm as secp256k1, and THORNode's ante handler rejects transactions signed with secp256r1 keys, which the Cosmos SDK would otherwise accept. Source (source code or release): https://gitlab.com/thorchain/thornode/-/blob/develop/x/thorchain/ante.go - **Validator consensus:** [Ed25519](https://hardyindex.com/algorithms/ed25519.md). Mainnet, mandatory. Mainnet consensus parameters list ed25519 as the one validator public key type. Source (read on-chain): https://gateway.liquify.com/chain/thorchain_api/cosmos/consensus/v1/params - **Threshold signing:** [ECDSA on secp256k1](https://hardyindex.com/algorithms/ecdsa-secp256k1.md). Mainnet, mandatory. GG20 threshold ECDSA for the Asgard vaults on Bitcoin, Ethereum and the other secp256k1 chains THORChain connects. A two-thirds supermajority of vault members must sign. Source (read on-chain): https://gateway.liquify.com/chain/thorchain_api/thorchain/inbound_addresses - **Threshold signing:** [Ed25519](https://hardyindex.com/algorithms/ed25519.md). Mainnet, mandatory. Threshold EdDSA for vaults on Ed25519 chains; the mainnet inbound address for Solana carries an Ed25519 vault key. Source (read on-chain): https://gateway.liquify.com/chain/thorchain_api/thorchain/inbound_addresses A role not listed here is not evidenced either way. See https://hardyindex.com/algorithms.md. ## Roadmap - **No published position** (proposed): No post-quantum architecture decision record, roadmap, research programme or testnet implementation for THORChain's account, validator or vault signatures was found at the time of writing. Source: https://dev.thorchain.org/architecture/ ## If holders never migrate **No stated policy.** THORChain has said nothing about post-quantum migration, so nothing has been said about RUNE in accounts that never move to post-quantum keys, or about the assets in its vaults. As of 22 October 2026. ## Exposure A THORChain address is a Bech32 encoding of a hash of its secp256k1 public key, so an account that has received RUNE but never signed has not published its key. The first send, swap, bond or liquidity deposit publishes it permanently, and almost every account of consequence has done one of those. Validator consensus keys are Ed25519 keys published by design. The vaults are a separate and larger exposure. THORChain publishes each Asgard vault's public key, and the vault addresses on Bitcoin, Ethereum and the other connected chains are derived from those keys, so the keys guarding every pooled asset are public by design and can be recorded today. Those assets sit on the other chains under THORChain's threshold signatures, and a quantum attacker who recovered a vault key could spend from the vault without the node operators. THORChain's own record shows that vault keys are a real point of failure: ADR 028, accepted by the node operators, conciliates the protocol's accounting after an exploit drained assets from one Asgard vault, an exploit with a classical cause. This row scores RUNE and THORChain's own ledger, and the caveat sets out how the vault exposure bears on that. ## Frequently asked questions ### Is THORChain quantum-safe? No. RUNE accounts on THORChain sign with ECDSA on secp256k1, as on other Cosmos SDK chains, and the CometBFT validator set signs consensus votes with Ed25519, which the live network's consensus parameters list as the one validator key type. THORChain also holds native assets on other chains, among them Bitcoin, Ethereum, Litecoin and Dogecoin, in Asgard vaults controlled by threshold signatures: according to THORChain's documentation, the node operators run GG20 threshold ECDSA on secp256k1 for most connected chains and threshold EdDSA on Ed25519 for chains such as Solana, and a two-thirds supermajority of a vault's members must cooperate to spend from it. A sufficiently large quantum computer running Shor's algorithm would break every one of these schemes. We found no post-quantum position from THORChain: none of its architecture decision records mentions post-quantum signatures, and the node repository, developer documentation and user documentation do not address them. THORNode pins Cosmos SDK v0.53.0, which has no post-quantum key type. ### Is THORChain quantum-safe? No. RUNE accounts sign with ECDSA on secp256k1, validators sign consensus votes with Ed25519, and the vaults holding swapped assets on other chains are controlled by threshold ECDSA and EdDSA keys. A sufficiently large quantum computer would break all of them, and THORChain has published no post-quantum plan. ### Does threshold signing protect THORChain's vaults against a quantum computer? No. Threshold signing spreads a vault key across the node operators so that no single operator can spend, and a two-thirds supermajority must cooperate. The vault's public key is still an ordinary secp256k1 or Ed25519 key, and it is published. Shor's algorithm recovers the private key from the public key without involving any operator, so the threshold offers no defence against it. ### Are RUNE holders' public keys already exposed? For almost all RUNE in use, yes. A THORChain address is a hash of the key and hides it until the account signs, but sending, swapping, bonding and depositing liquidity all sign, so active holders have revealed their keys. Those keys can be recorded now and attacked later. ### Why does the score not include the Bitcoin and Ethereum in THORChain's vaults? Because those coins live on Bitcoin and Ethereum, whose own signatures the index scores on their own profiles, and this row scores RUNE and THORChain's ledger. The vault keys are described in the exposure note and the caveat, which gives the score a reader would reach by folding them in. ### What would move THORChain up the index? An architecture decision record or a public research programme on post-quantum signatures for RUNE accounts, validators or vaults would meet the Tier 4 floor. A plan from THORChain's developers or an adopted decision record naming the scheme to be used would meet Tier 3. ## What this rating means if you hold THORChain 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. [Technical FAQ](https://dev.thorchain.org/technical-faq.html): THORChain developer documentation (primary, checked 22 October 2026) 2. [Architecture decision records](https://dev.thorchain.org/architecture/): THORChain developer documentation (primary, checked 22 October 2026) 3. [TSS implementation](https://dev.thorchain.org/bifrost/tss.html): THORChain developer documentation (primary, checked 22 October 2026) 4. [Vault behaviours](https://dev.thorchain.org/bifrost/vault-behaviors.html): THORChain developer documentation (primary, checked 22 October 2026) 5. [Bifrost, TSS and vaults](https://docs.thorchain.org/technical-documentation/technology/bifrost-tss-and-vaults): THORChain documentation (primary, checked 22 October 2026) 6. [Versioning and release process](https://dev.thorchain.org/release.html): THORChain developer documentation (primary, checked 22 October 2026) 7. [ADR 028: Exploit Conciliation](https://dev.thorchain.org/architecture/adr-028-exploit-conciliation.html): THORChain developer documentation (primary, checked 22 October 2026) 8. [THORNode](https://gitlab.com/thorchain/thornode): THORChain (GitLab) (primary, checked 22 October 2026) 9. [THORNode go.mod](https://gitlab.com/thorchain/thornode/-/blob/develop/go.mod): THORChain (GitLab) (primary, checked 22 October 2026) 10. [THORNode ante handler (x/thorchain/ante.go)](https://gitlab.com/thorchain/thornode/-/blob/develop/x/thorchain/ante.go): THORChain (GitLab) (primary, checked 22 October 2026) 11. [THORNode chain signing algorithms (common/chain.go)](https://gitlab.com/thorchain/thornode/-/blob/develop/common/chain.go): THORChain (GitLab) (primary, checked 22 October 2026) 12. [THORChain threshold signature library, public tss-lib (THORNode imports the private tss-lib-private instead)](https://gitlab.com/thorchain/tss/tss-lib): THORChain (GitLab) (primary, checked 22 October 2026) 13. [Mainnet consensus parameters](https://gateway.liquify.com/chain/thorchain_api/cosmos/consensus/v1/params): THORChain mainnet API (Liquify gateway) (primary, checked 22 October 2026) 14. [Mainnet inbound addresses](https://gateway.liquify.com/chain/thorchain_api/thorchain/inbound_addresses): THORChain mainnet API (Liquify gateway) (primary, checked 22 October 2026) 15. [Mainnet THORNode version](https://gateway.liquify.com/chain/thorchain_api/thorchain/version): THORChain mainnet API (Liquify gateway) (primary, checked 22 October 2026) 16. [FIPS 204: Module-Lattice-Based Digital Signature Standard (ML-DSA)](https://csrc.nist.gov/pubs/fips/204/final): NIST (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). THORChain: quantum readiness assessment. Hardy Score 8.5 of 100, Tier 5: Exposed. Methodology v1.8. Last reviewed 4 November 2026; sources checked 13 November 2026. https://hardyindex.com/chains/thorchain ```bibtex @misc{hardyindex_thorchain_2026, author = {{The Hardy Index}}, title = {THORChain: quantum readiness assessment}, year = {2026}, howpublished = {\url{https://hardyindex.com/chains/thorchain}}, note = {Hardy Score 8.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, "THORChain", https://hardyindex.com/chains/thorchain, as of 13 November 2026.