Cowrie Research

thorchain-asgard-vault-gg20-threshold-signing-key-extraction-cross-chain-drain-2026-05-15

16 min read

THORChain Asgard Vault GG20 Threshold-Signing Key-Extraction Cross-Chain Drain (2026-05-15)

  • Name: THORChain Asgard vault GG20 threshold-signing key-extraction cross-chain drain
  • Date: 2026-05-15
  • Protocol: THORChain
  • Chain: THORChain + affected connected chains including Bitcoin, Ethereum, BNB Chain, Base, Avalanche, Dogecoin, Litecoin, Bitcoin Cash, XRP, and TRON
  • Category: threshold-ceremony share leakage / signer-quorum compromise / bridge verification failure / cross-chain vault compromise
  • Loss: about $10.7M-$11M drained from one Asgard vault; THORChain’s public reporting framed the loss as vault / protocol balance-sheet loss rather than user in-flight swap loss
  • Summary: On 2026-05-15, a newly churned THORChain node operator exploited a vulnerability class in THORChain’s GG20 threshold-signature stack and turned one malicious participant into effective full control over a live Asgard vault. THORChain’s official exploit report said the attacker entered the active set two days earlier, participated in normal signing ceremonies, and exploited a GG20 Threshold Signature Scheme flaw to reconstruct the full vault private key. Public technical analysis after the incident sharpened that into a more specific claim: THORChain’s deployed GG20 fork appears to have skipped MOD/FAC Paillier proof checks, letting the attacker register malformed key material and harvest honest participants’ signing-share leakage across repeated ceremonies. Once the vault key was reconstructed, the attacker no longer needed quorum or bridge contracts to misbehave; they simply signed unauthorized outbounds directly across many chains until THORChain’s solvency checker halted the network.
  • Trigger / entry point:
    • A fresh node operator churned into THORChain’s active validator set on 2026-05-13 and was assigned to one of the five Asgard vaults.
    • THORChain’s official report says the malicious node then spent roughly two days participating in ordinary GG20 signing rounds before the drain.
    • The decisive entry point was not a user-facing swap bug or a bad router memo. It was the threshold-signing ceremony that Asgard vault custody depended on for ECDSA chains.
    • THORChain publicly confirmed the broad exploit class as a vulnerability in the GG20 Threshold Signature Scheme; later technical writeups attributed the failure more specifically to omitted Paillier MOD/FAC proof verification in THORChain’s GG20 fork, which would let attacker-shaped key material leak long-term shares from honest participants over repeated rounds.
  • Root cause:
    • THORChain’s practical custody boundary collapsed from threshold of independent vault signers to one malicious participant plus enough signing rounds.
    • The core failure was cryptographic / implementation-side, not a smart-contract arithmetic bug: a hostile node could allegedly make normal GG20 ceremonies leak enough information to reconstruct the full vault key offline.
    • Once that happened, THORChain’s advertised signer threshold stopped mattering. The attacker had transformed routine participation in the quorum into unilateral signing authority.
    • The preserved invariant is no single validator should ever be able to turn ordinary signing participation into the complete vault private key. This incident shows what happens when the threshold protocol itself ceases to preserve that invariant.
  • Exploit path:
    1. The attacker funded and bonded a new THORChain node, then churned into the active validator set on 2026-05-13.
    2. That node was assigned to one live Asgard vault and joined ordinary GG20 signing ceremonies for outbound transactions.
    3. THORChain’s official report says the attacker exploited a GG20 TSS vulnerability during those ceremonies; later technical analysis argued that THORChain’s GG20 fork omitted Paillier modulus / factor proof checks, so a malicious participant could contribute malformed Paillier material with attacker-known structure.
    4. Over repeated signing rounds, honest participants’ long-term signing-share material leaked in small pieces to the malicious node.
    5. After enough ceremonies, the attacker reconstructed the complete private key for the affected Asgard vault offline.
    6. With that vault key in hand, the attacker bypassed THORChain’s normal multi-party signing flow entirely and broadcast unauthorized outbound transactions directly across the chains served by that vault.
    7. Assets were drained to attacker-controlled receiving addresses including EVM addresses 0x82fc0d5150f3548027e971ec04c065f3c93154eb and 0xd477b69551f49c0519f9b18c55030676138890bd, alongside chain-specific BTC, BCH, DOGE, LTC, and XRP recipient addresses reported by TRM.
    8. THORChain’s reactive solvency checker detected vault insolvency at THORChain block 26190429, automatically halting affected-chain trading and signing; node operators then layered manual pauses and Mimir votes to extend the halt network-wide.
  • What the attacker needed to be true:
    • A malicious node had to be able to churn into the active validator set and get assigned to a live Asgard vault.
    • The deployed GG20 implementation had to leak or otherwise expose enough key-share material during routine signing ceremonies for one hostile participant to accumulate it.
    • The vault had to custody meaningful assets across multiple chains, so one recovered key translated directly into multi-chain unauthorized outbounds.
    • There had to be no independent balance-sheet throttle between valid vault signature and release assets, because once the full vault key existed the bridge-side chains treated those outbounds as authentic.
    • Detection needed to lag long enough for the attacker to sign and broadcast the first batch of unauthorized withdrawals before solvency halts fired.
  • Technical anatomy worth remembering:
    • This was not the 2021 THORChain family of deposit event lied about locked value bugs. The 2026 incident sat at the custody-signing layer itself: the protocol’s threshold ceremony stopped protecting the vault key.
    • The especially important inversion is that the attacker did not need to compromise a majority of signers in the ordinary sense. If the public technical analysis is correct, one malicious signer could turn repeated honest ceremonies into enough leakage to collapse the threshold from the inside.
    • THORChain’s automatic solvency checker worked, but it only helped after the fact. Once the attacker held the recovered vault key, proactive do not sign an insolvent txOut logic was irrelevant because the attacker no longer needed the network to co-sign anything.
    • The incident is a useful bridge-custody counterpart to classic signer-quorum compromise notes: the chain-facing contracts may behave perfectly and still release custody if the offchain signing stack has already turned one participant into the real effective threshold.
    • It is also a useful operator-topology reminder. A threshold scheme can fail not only because too many keys were stolen, but because the cryptographic ceremony itself no longer keeps one participant from learning too much about everyone else’s shares.
  • Representative addresses and onchain markers:
    • Malicious node operator address reported by THORChain: thor16ucjv3v695mq283me7esh0wdhajjalengcn84q
    • THORChain block where the solvency checker reportedly detected insolvency and halts began: 26190429
    • Reported EVM recipient addresses: 0x82fc0d5150f3548027e971ec04c065f3c93154eb, 0xd477b69551f49c0519f9b18c55030676138890bd
    • Reported BTC recipient address: bc1ql4u94klk265lnfur2ujk9p6uh52f2a8jhf6f37
    • Reported DOGE recipient address: DBLJWFemMHbduKofBRg6TJ9XFAgWdvFCjS
    • Reported LTC recipient address: ltc1qg0h4rz5kf27fkr99gamw4heg20rfz5epd7m7wh
  • Response / mitigation:
    • THORChain’s automatic solvency checker halted signing and trading on affected chains within minutes of the unauthorized withdrawals once actual balances diverged from expected balances.
    • Node operators then stacked manual pauses and used operational Mimir votes to widen the halt while investigation continued.
    • THORChain released exploit report #1, publicly identified the broad root-cause class as a GG20 TSS vulnerability, and shipped patch v3.18.1 as an immediate safeguard for the remaining vaults.
    • Recovery planning moved into ADR-028, with public reporting indicating the attacker node would be slashed, protocol-owned liquidity would absorb losses first, and trading would resume only after patched churn / vault safety work.
    • THORChain also emphasized that fake refund or compensation claims circulating during the halt were scams and that the immediate incident handling would proceed through protocol governance rather than ad hoc social promises.
  • Key transaction hashes:
    • This incident did not reduce cleanly to one canonical exploit transaction hash. Once the attacker reconstructed the full vault key, the drain manifested as many chain-native unauthorized outbound transactions from the compromised vault across multiple chains.
    • The most reusable onchain markers are therefore the attacker receiving addresses above and THORChain halt / insolvency marker block 26190429, rather than pretending one EVM tx hash captures the exploit path.
  • Comparable exploit pattern:

Pattern tags

  • threshold-ceremony-share-leakage
  • signer-quorum-compromise
  • bridge-verification-failure
  • A newly admitted signer appears to have been able to turn ordinary GG20 participation into full-key recovery, so THORChain’s practical threshold collapsed from quorum of vault signers to one malicious participant plus enough ceremony exposure
  • The likely missing MOD/FAC Paillier proof checks mattered twice: they let attacker-shaped key material enter the ceremony and they let the resulting leakage remain invisible until the recovered vault key started signing raw outbounds
  • One recovered Asgard key still had immediate line-of-sight to multi-chain custody across Bitcoin, EVM chains, Dogecoin, Litecoin, Bitcoin Cash, XRP, and TRON, so cryptographic failure and balance-sheet failure remained too tightly coupled

Why the exploit worked

  • THORChain’s public threshold story assumed no single node ever holds the full private key, but that sentence was only true if the deployed GG20 ceremony enforced the proof set that keeps malicious participants from learning too much. Public analysis after the incident says the forked GG20 stack skipped Paillier MOD/FAC proof checks, which means a node could join as a nominally ordinary signer while still feeding attacker-shaped setup material into the ceremony.
  • That turns the decisive boundary into what exactly must a fresh signer prove before it is allowed to observe and influence a live high-value vault ceremony? THORChain appears to have let a brand-new node churn into one of its five live Asgard vaults and accumulate roughly two days of routine signing exposure before any deeper quarantine, smaller blast-radius lane, or fresh-signer cap narrowed what one participant could learn.
  • Once enough share leakage accumulated, every downstream chain simply saw authentic vault signatures. At that point there was no bridge verifier bug left to trigger and no normal co-signing policy left to intercept: the attacker had converted ceremony participation into the real vault key itself.
  • THORChain’s reactive solvency checker therefore functioned as containment, not prevention. The official report is explicit that the checker halted chains within minutes, but a recovered full key bypassed the proactive do not sign an insolvent txOut path because the attacker no longer needed the network to sign anything.
  • The blast radius stayed larger than the cryptographic failure alone. One recovered key still implied immediately spendable custody across many chains and asset families, so the difference between one vault compromised and large multi-chain protocol loss was mostly how quickly bounded-loss controls could react after real funds had already left.

Detection and audit pivots

  • Treat TSS proof completeness as production custody logic, not library detail. Ask exactly which Paillier modulus, factor-soundness, range, nonce, and transcript checks the deployed fork enforces today, and diff that answer against patched upstream GG20 guidance rather than against team memory.
  • Audit fresh-signer exposure directly. How quickly can a newly churned validator be assigned to a high-value vault, how many ceremonies can it join before stronger trust is earned, and what lower-blast-radius probation lane exists if the scheme family later proves weaker than expected?
  • Review ceremony telemetry as security telemetry. Repeated retries, signer-specific anomalies, unusual churn urgency, or other seemingly routine GG20 friction may matter less as reliability noise than as setup for transcript harvesting.
  • Model containment assuming the attacker already has the recovered vault key. If proactive signing checks, txOut policy, or signer-majority logic all disappear once the key exists, what per-vault caps, segmented reserves, staged release, or rapid chain-local brakes still keep one vault from commanding treasury-scale loss?
  • Compare public threshold claims with the real effective threshold under a ceremony bug. If one malicious signer plus enough time can defeat the scheme, then user-facing decentralized vault threshold language should be paired with clearer disclosure of scheme choice, proof completeness, signer-admission staging, and blast-radius controls.

Failure-prevention checklist

  • Treat the deployed GG20 fork, proof-verification paths, and local patches as live custody code. Review them against current upstream advisories and academic break guidance on every security cycle, not only when a library maintainer announces a crisis.
  • Inventory the exact proof families and parameter checks that production THORChain actually enforces today, then compare that list against both THORChain’s public TSS claims and patched reference GG20 implementations. Docs say verifiable is not evidence that the deployed fork still verifies the right things.
  • Stage fresh signers into lower-blast-radius exposure first. A newly churned node should not immediately accumulate repeated ceremony access to one of the system’s largest multi-chain vaults without probation, smaller limits, or stronger monitoring.
  • Keep ceremony telemetry as first-class security telemetry. Repeated aborts, retries, signer-specific friction, unusual churn urgency, and other ops noise should page humans when they cluster around one participant or one vault.
  • Bound each vault’s immediate loss budget. One recovered key should not imply broad same-window access to deep reserves across Bitcoin, EVM chains, XRP, TRON, and other connected domains before narrower caps or staged release can matter.
  • Separate valid vault signature from full uncapped outbound authority wherever possible. Per-vault quotas, route-local spend ceilings, delayed release for unusually large outbounds, and fast chain-local brakes should survive even if the threshold primitive itself fails.
  • Rehearse emergency signer eviction, churn acceleration, vault migration, and patched-library rollout under the assumption that the attacker may already possess the full key and may keep signing during the response window.
  • Keep the public trust model honest about scheme choice and blast radius. If the real boundary is GG20 fork correctness + fresh-signer exposure + bounded-loss controls, say that more explicitly than just 2/3 threshold, no full key exists.

Audit prompts

  • Which exact MOD, FAC, biprime, range, nonce, and transcript-consistency checks does the deployed THORChain GG20 stack enforce today, and where in the forked codebase do those checks live?
  • How does the current production fork differ from upstream tss-lib or later patched GG20 guidance, and who owns proving that those deltas do not re-open known malicious-participant breaks?
  • What is the maximum ceremony exposure a brand-new node can accumulate in its first churn cycle, and how much multi-asset custody sits behind that exposure before any probationary throttles expire?
  • Are there vault-assignment rules, smaller probationary vaults, per-signer observation windows, or other mechanisms that intentionally limit what one fresh participant can learn or command before trust is earned?
  • If one Asgard key is reconstructed offline, what concrete controls still bind loss size: per-vault caps, per-chain route ceilings, staged outbound release, segmented reserves, or emergency destination freezes?
  • Does THORChain’s monitoring distinguish between ceremony instability and possible extraction setup, or are retries and aborts still mostly treated as reliability issues rather than cryptographic danger signals?
  • Do public architecture docs, operator expectations, and the live code all describe the same security story, or is there still a gap between zero-knowledge proofs and verifiable contributions exist in docs and what production actually checks?
  • How quickly can the network evict a suspect signer, rotate vault membership, and move inventory after suspicion that one participant has already learned too much from ceremonies in progress?

Lessons that should already be standard

  • Threshold cryptography is a custody boundary, not a branding layer. If the ceremony implementation is wrong, the advertised signer threshold is already fiction.
  • No node ever sees the full private key is only true while the deployed protocol really preserves that property under malicious participation.
  • A brand-new signer seat is not only a governance or liveness event; it is also potential exploit pre-positioning for the largest live vaults.
  • Public TSS documentation that promises verifiable multi-party safety must stay synchronized with the exact proof checks production still enforces.
  • Reactive solvency checks are valuable, but they are containment after authenticity collapse, not prevention once the attacker has reconstructed the key.
  • One recovered multi-chain vault key is too much concentrated authority unless per-vault blast radius is already tightly budgeted.
  • Bridge and custody systems need to design for cryptographic primitive failure the same way they already design for signer theft or backend compromise.
  • The right time to discover that a threshold scheme had quietly become one malicious participant plus enough rounds is during continuous cryptographic maintenance, not after raw outbounds are already onchain.

Why this incident matters

  • It preserves a nasty bridge-custody lesson that sits between classic multisig compromise and pure cryptographic break: the threshold can fail even when no visible signer majority defected and no destination contract verifier bug exists.
  • It is also a sharp counterexample to comforting bridge narratives like the contracts are fine or the node threshold is decentralized. If the signing ceremony leaks long-term shares, the contracts only end up enforcing the attacker’s newly forged authenticity.
  • The incident also preserves the separate blast-radius lesson: one recovered vault key still controlled too much immediately spendable multi-chain custody. THORChain’s solvency checker was valuable, but it only fired after real unauthorized outbounds had already left the vault, which is exactly the containment gap bridge bounded release design tries to make explicit.
  • For the corpus, it is an important classifier boundary against THORChain’s 2021 bridge bugs. Those failures accepted fake deposit truth; this one corrupted the custody-signing truth that authorized outbound releases in the first place.

Internal linkages

Control surface

Graph View

Backlinks