The THORChain Signing Exploit Explained
Quick answer. On May 15, 2026, a malicious validator drained one THORChain vault of about $10M, per THORChain's July report. A planted flawed key and 864 failed signing rounds leaked other validators' key shares. The failure spike was the warning.
Video transcript
THORChain lost about ten million dollars on May 15, 2026, and no smart contract failed. A malicious validator broke its threshold signing.
THORChain says this was no contract, bridge or oracle bug. It calls it a cryptographic zero day, aimed at the GG20 threshold signing its validators rely on.
The attacker joined as a normal validator and planted a flawed key that looked valid. It then leaked other validators' key shares until it could sign alone.
The leak came from failing one signing step on purpose, 864 times over two and a half days. Each failure looked like routine node flakiness.
Three small flaws in a signing library inherited from Binance made it work. Key generation never checked for a two-prime modulus, range proofs were never tied together, and blinding used too small a range.
The upstream library fixed all three by 2024, but THORChain's deployed fork predated every fix. Combined, THORChain says, they turned a statistical gamble into a deterministic leak.
Automatic halts could not stop a key that was already compromised. Splitting liquidity across vaults capped the loss at one of five.
Audits look for known issues, and minor flaws combine. A spike in signing failures is a warning. Plan for one hostile member, not only outsiders.
Guardian's Offchain Automation Pentest tests threshold signers with a partly compromised set. Read the full breakdown, or talk to Guardian at guardian.security.
THORChain lost about $10M on May 15, 2026, its July report says, and no smart contract failed. "It was not a smart contract bug, a bridge vulnerability, or an oracle manipulation," THORChain wrote.
Instead, an attacker broke the threshold signing that THORChain's validators use to authorize transactions. THORChain calls it a cryptographic zero day.
This post follows THORChain's own account, from its exploit reports of May 20 and July 3, 2026.
What Happened
No single validator holds the private key to a THORChain vault. Validators sign together, using a threshold signature scheme (TSS) based on a protocol called GG20.
The validator set "is permissionless by design," THORChain says, and anyone can churn into the network.
A new node churned in on May 13, 2026, with about 635,000 RUNE bonded across two addresses, according to THORChain's first report.
On May 15, THORChain "identified unauthorised outbound transactions from one of the network's vaults." One vault of five was drained.
The attacker had rebuilt the vault's full private key. It "moved all the assets in one transaction, before any halt could have effect," THORChain says.
Chains secured by EdDSA signatures, including Solana, "were not exposed at any point."
How the Attack Worked
THORChain's July report breaks the attack into four steps:
- Join. The attacker "joined the network as a normal validator."
- Plant a flawed key. At vault setup, it built key material "that looked valid but wasn't."
- Leak. It deliberately failed one signing step "864 times across two and a half days."
- Sign alone. It then had enough material "to sign transactions unilaterally."
The flawed key
When a vault is created, every participant publishes a Paillier public key. Paillier encryption lets validators compute on each other's secret numbers.
Its modulus should be a biprime: the product of two large primes. The attacker "used several small primes" instead.
The result was the normal size, so it looked valid from outside. Local checks could confirm its size and rule out obvious small factors, but not count its primes.
THORChain ran the tests it could, "and the attacker's modulus passed every one of them."
The leak
The step it failed was round 2, or MTA, of signing. Each exchange with its malformed key leaked a fragment of another validator's key share.
"Each failure looked like routine node flakiness," THORChain says. Failures carry minor slashes, but "the attacker simply absorbed those penalties."
Three small flaws
The attack combined three weaknesses in tss-lib, the signing library THORChain inherited from Binance:
- Key generation: the library never checked that the modulus was a product of two primes.
- Range proofs: two halves of a proof were checked separately, never tied together.
- Blinding: a masking value came from too small a range, so each session leaked a sliver.
THORChain calls them "individually low-severity issues." Combined, "they convert a slow statistical gamble into a deterministic leak."
Upstream tss-lib fixed two in its v2.0.0 release of August 2023 and the third in v3.0.0 in 2024. THORChain's deployed fork, v0.1.6, "predated all three fixes."
The multi-prime weakness is the class documented in 2023 as BitForge and TSSHOCK.
Why the defenses did not stop it
The solvency checker and automatic halts "didn't stop this attack," THORChain says. The key was already compromised, and the funds left in one transaction.
Spreading liquidity across vaults capped the loss. Attacking more vaults meant running more bonded nodes, and "the working theory is the attacker didn't have the capital to do it."
Timeline and Impact
Times are UTC, per THORChain's first report.
| Date | Event | Source |
|---|---|---|
| May 13, 2026 | Malicious node churns in with about 635,000 RUNE | Report #1 |
| Before the drain | 864 deliberately failed signing rounds over 2.5 days | Report #2 |
| May 15 | One vault drained | Report #1 |
| May 15, 09:08 to 09:41 | Community raises the alarm | Report #1 |
| May 15, 11:01 | First statement estimates $7.4M lost | Report #1 |
| May 15, 19:10 | Loss revised to about $10.7M; attacker identified | Report #1 |
| May 18 | Patch v3.18.1 and a recovery roadmap | Report #1 |
| Jul 3 | Report #2 explains the root cause | Report #2 |
THORChain's July report puts the loss at "approximately $10M." Its May report had revised a first estimate of $7.4M to about $10.7M.
Within about 52 minutes of the unauthorized transactions, the solvency checker had automatically halted signing and trading on several chains, the May report says.
Node operators then voted network-wide halts on trading, signing, chain observation and churning. Pausing churn was meant to stop the malicious node from exiting.
In May, THORChain put recovery of the lost funds to community governance, through ADR-028. Options under discussion included bond slashing and absorption by protocol-owned liquidity.
The fix
Every validator upgraded to the patched release, version 3.19.1. The network then verified all vaults before normal signing resumed.
In the medium term, "THORChain is going to move away from GG20 entirely." It plans schemes such as DKLS and/or Schnorr-based approaches that do not rely on Paillier.
It is adding validator-level monitoring of key-sign failures. It is also weighing a minimum wallet age for validators and gradual access to larger vaults.
What It Shows
- Audits look for known issues. THORChain's many audits did not find this path, which was in "no advisory, no CVE."
- Minor flaws combine. Three issues fixed upstream as minor added up to a key leak.
- Failures are signals. One validator caused "a disproportionately large share of signing failures."
- Plan for a hostile member. A permissionless signing set must survive one malicious participant, not only outsiders.
- Containment works. Splitting funds across vaults kept the loss to one.
Threshold signing also underpins MPC wallets. Our MPC wallet provider comparison covers BitForge, and multisig vs MPC weighs the tradeoffs.
For the other ways cross-chain systems fail, see our guide to cross-chain bridge security.
How Guardian Tests Signing Services
Guardian's Offchain Automation Pentest covers keepers, relayers, bots and threshold signers, which "use real privileges unattended."
It tests them "with hostile inputs and a partly compromised set." For threshold signing, the page lists:
- Share storage
- Participant authentication
- What a sub-threshold subset can force
- Recovery after a node is compromised
The review starts by establishing what the automation must guarantee. Then it works through the triggers, state transitions, key handling and retries that break it. Source code access is required.
It sits alongside Guardian's other offchain pentests, from web apps and APIs to cloud and SDKs.
Frequently Asked Questions
What happened in the THORChain exploit?
On May 15, 2026, a validator that had churned in two days earlier drained one THORChain vault of about $10M, per THORChain's July report. It leaked other validators' key shares through 864 deliberately failed signing rounds, then signed transactions alone.
Was the THORChain exploit a smart contract bug?
No. THORChain says it "was not a smart contract bug, a bridge vulnerability, or an oracle manipulation." It was a cryptographic attack on GG20 threshold signing that combined three low-severity flaws in its fork of Binance's tss-lib.
How did THORChain fix it?
Every validator upgraded to version 3.19.1, and the network verified all vaults before signing resumed. THORChain plans to move from GG20 to DKLS and/or Schnorr-based schemes, and is adding validator-level monitoring of signing failures.
Were other vaults or Solana affected?
No, per THORChain. One vault of five was drained. The flaw lives in ECDSA, the scheme GG20 uses, so chains secured by EdDSA, including Solana, were not exposed.
Sources
Test your signing set with Guardian
Guardian's Offchain Automation Pentest tests threshold signers, keepers and bots with hostile inputs and part of the set compromised.