Hardy Index Quantum readiness, rated and tracked

Chain profile

THORChain

RUNE Exposed

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.

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.

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.

At a glance

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 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 code or release
  • Validator consensus Ed25519 Mainnet, mandatory Mainnet consensus parameters list ed25519 as the one validator public key type. Read on-chain
  • Threshold signing ECDSA on secp256k1 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. Read on-chain
  • Threshold signing Ed25519 Mainnet, mandatory Threshold EdDSA for vaults on Ed25519 chains; the mainnet inbound address for Solana carries an Ed25519 vault key. Read on-chain

A role not listed is not evidenced either way. Every scheme, and which other chains share it, is in the cryptography registry.

Score breakdown

Each dimension scored 0 to 10. The weight beside it is its share of the total score.
Signature scheme 0 30% Deployment stage 1 25% NIST alignment 0 15% Migration path 2 15% Exposure 2 10% Verification 2 5%
Show the weighted arithmetic and the sourced note for each dimension
No. Dimension Score Weight Contribution
1 Signature scheme 0 30% 0.0
2 Deployment stage 1 25% 2.5
3 NIST alignment 0 15% 0.0
4 Migration path 2 15% 3.0
5 Exposure 2 10% 2.0
6 Verification 2 5% 1.0
Hardy Score 8.5

1 Signature scheme 0/10, weighted 30%

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

2 Deployment stage 1/10, weighted 25%

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

3 NIST alignment 0/10, weighted 15%

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. source

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.

4 Migration path 2/10, weighted 15%

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. source

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.

5 Exposure 2/10, weighted 10%

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. source

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.

6 Verification 2/10, weighted 5%

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. source

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.

The deployment dimension is not a separate judgement. It is Tier 5 expressed as a number. See the tier mapping.

How it compares

All 80 rated chains on the 0 to 100 scale. THORChain is marked. Select any point to open that profile.
THORChain 8.5

Nearest chains in the ranking

The 9 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 5: Exposed 8.5 level
69 Polygon PoS 5: Exposed 8.5 level
70 Provenance Blockchain 5: Exposed 8.5 level
71 Theta Network 5: Exposed 8.5 level
72 THORChain this chain 5: Exposed 8.5
73 VeChain 5: Exposed 8.5 level
74 WEMIX 5: Exposed 8.5 level
75 Whitechain 5: Exposed 8.5 level
76 Beldex 5: Exposed 7.5 -1.0

Roadmap

  1. 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

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. Published beside the score, not in it. Every chain's stance is compared on the commitments page.

Exposure

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.

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.

What this rating means for you

If you hold THORChain

THORChain 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.

Embed this rating

Paste this anywhere to show THORChain's current rating. It renders live from the index, so it updates when the rating does, and the review date is written into the image. There is nothing to sign up for and nothing to pay. 

<a href="https://hardyindex.com/chains/thorchain"><img src="https://hardyindex.com/badge/thorchain.svg" width="260" height="76" alt="Quantum readiness rated by the Hardy Index"></a>

The image is /badge/thorchain.svg. It is a plain SVG with no script and no tracking, it sets no cookie, and it records nothing about whoever loads it.

Questions

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.

Sources

  1. Technical FAQ THORChain developer documentation · primary · checked 22 October 2026
  2. Architecture decision records THORChain developer documentation · primary · checked 22 October 2026
  3. TSS implementation THORChain developer documentation · primary · checked 22 October 2026
  4. Vault behaviours THORChain developer documentation · primary · checked 22 October 2026
  5. Bifrost, TSS and vaults THORChain documentation · primary · checked 22 October 2026
  6. Versioning and release process THORChain developer documentation · primary · checked 22 October 2026
  7. ADR 028: Exploit Conciliation THORChain developer documentation · primary · checked 22 October 2026
  8. THORNode THORChain (GitLab) · primary · checked 22 October 2026
  9. THORNode go.mod THORChain (GitLab) · primary · checked 22 October 2026
  10. THORNode ante handler (x/thorchain/ante.go) THORChain (GitLab) · primary · checked 22 October 2026
  11. THORNode chain signing algorithms (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) THORChain (GitLab) · primary · checked 22 October 2026
  13. Mainnet consensus parameters THORChain mainnet API (Liquify gateway) · primary · checked 22 October 2026
  14. Mainnet inbound addresses THORChain mainnet API (Liquify gateway) · primary · checked 22 October 2026
  15. Mainnet THORNode version THORChain mainnet API (Liquify gateway) · primary · checked 22 October 2026
  16. FIPS 204: Module-Lattice-Based Digital Signature Standard (ML-DSA) NIST · primary · checked 22 October 2026
Cite this rating

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.

Plain text

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}
}

The whole dataset is reusable under the terms on the about page. A machine-readable version of this page is at /chains/thorchain.md.

This is a security-readiness assessment, not investment advice.