One bad node

Last week a single THORChain validator drained roughly $10.7M across at least nine chains. Trading and outbound signing were paused within eight minutes. The protocol’s native token, RUNE, fell 26% over the next two days.

The forensic question — how does one node, in a 100+ node network, steal the vault? — is what made this exploit different. And it also matters far beyond THORChain.

First, the basics

A digital signature is the cryptographic proof that whoever controls a private key authorized a specific transaction. ECDSA — the Elliptic Curve Digital Signature Algorithm — is the specific signature scheme Bitcoin, Ethereum, and most major blockchains use. Every time you send a transaction from a self-custody wallet, ECDSA is what proves the transaction is really yours.

Threshold ECDSA splits that single private key into shares held by multiple parties. Any agreed-upon threshold of those parties — say, 51 out of 100 — can jointly produce a valid signature without any single party ever knowing the full key. The signature that comes out the other end is mathematically identical to an ordinary ECDSA signature; the chain cannot tell the difference.

The promise is custody without a custodian: no single node can move funds alone, and compromising any one node should leak nothing about the underlying key. That supposition is what THORChain — and a meaningful slice of cross-chain DeFi — depends on.

It’s looking a little shaky.

On May 16, the researcher Banteg published a technical reproduction of the most likely attack path against tss-lib v0.1.6, the threshold ECDSA library THORChain runs.

The following day, MPC cryptographer Arik Galansky published a deprecation list naming the schemes and libraries that "should not be in production right now." Together, the two posts form the most coherent public picture of where threshold ECDSA stands today — and which protocols are insulated, which are exposed, and which need to act now.

What Banteg found

THORChain runs a variant of the GG20 protocol, originally published by Gennaro and Goldfeder (co-founder and CEO of Offchain) in 2020. It is among the most widely deployed families of threshold ECDSA schemes in production, but also one with the most published attacks against it.

Banteg examined the specific version of the threshold ECDSA library THORChain runs — an old fork of tss-lib that never received the security patches shipped upstream. His fascinating findings point to a cross-layer attack surface rather than a single bug.

The attack works in four stages:

• A malicious node sneaks a bad key into the setup. When nodes first join a vault, they each publish cryptographic material that will be reused in every future signing session. THORChain's version checks that material against an outdated standard. Banteg built a key that passes the old check but has a hidden structure only the attacker knows about.
• The signing process accepts it. From then on, every time the malicious node participates in a signing ceremony, the other nodes treat its contributions as legitimate. They have no way to tell that the key was crafted.
• Each signing ceremony leaks information. Depending on what the attacker guesses about the honest nodes' secret values, the ceremony either produces a valid signature or fails in one of two distinct ways. That pattern of successes and failures becomes a side channel that, over enough sessions, lets the attacker reconstruct the full vault key.
• The defense in front of it doesn't hold. THORChain has a separate networking layer that was supposed to make this attack much harder — by forcing the attacker to send the same forged message to every node at once, which would make the forgery easy to spot. Banteg found a workaround.

The underlying attack class was published by SafeHeron and Fireblocks (re. CVE-2023-33241), and fixes have existed for nearly three years. THORChain's library never pulled them in.

The caveats Banteg himself emphasizes are important. He explicitly states that his reproduction:

• does not prove a complete, efficient online extractor against a live committee;
• does not establish incident attribution; and
• could not produce a target-specific split-view oracle in several attempted strategies.

In other words, the mechanics he reproduced are consistent with the May 11 drain, but they do not by themselves prove this was the exploit path used. THORChain's own postmortem is still pending. 

Taylor Monahan, one of the most experienced wallet-security operators, captured the operational consequence well in commentary on May 16:

"The attacker is essentially operating silently, collecting information, and then deriving the private key. This attacker swept over many hours, after fucking up their 7702 implementation. Most attackers won't."

Her observation matters because it describes how this kind of attack actually plays out in production. The leak happens during normal signing ceremonies. There is no anomalous traffic to flag, no failed transaction to investigate, and no smoking gun until the attacker has accumulated enough information to reconstruct the key and drain the vault. THORChain pausing within eight minutes of the sweep was a credible emergency response, but it caught the attack at the only stage where it was visible. A more patient attacker who waits longer between probes, or who sweeps in a single coordinated transaction rather than over hours, gives defenders nothing to react to.

Monahan takes a hardline view — that threshold ECDSA "shouldn't be used in prod." The consensus among researchers seems a bit narrower (see below), but the key question up for debate is whether any threshold ECDSA scheme is robust enough for permissionless validator sets where anyone with enough bond can churn in.

The deprecation picture

The day after banteg's thread dropped, the MPC cryptographer Arik Galansky published a short list with a much sharper headline claim: it isn't just THORChain's specific fork that should not be running in production. A whole generation of threshold ECDSA — the protocols and the libraries that implement them — has been quietly deprecated by the people who built it.

GG18 and GG20, the schemes THORChain runs, have been broken by multiple published attacks. Their own authors have moved on and now point developers to the successor protocol, CGGMP21.

This is part of a pattern in cryptography: An older scheme called Lindell17 has a known weakness in how it handles failed signing attempts — a gap that Yehuda Lindell himself and Coinbase have published. Earlier versions of another family, DKLS, have been superseded by a 2023 version that fixes weaknesses the originals could not. And several MPC libraries built on top of these protocols — including ones from ZenGo, Unbound, and Coinbase — are no longer maintained, meaning new vulnerabilities published in the academic literature do not get patched.

As Galansky put it, "If you are using them — you are behind the attackers."

One natural objection raised is that elliptic-curve cryptography itself — the foundation underneath all of this — will be replaced by quantum-resistant alternatives by around 2030 anyway, so why panic about which threshold scheme a protocol is using today?

The reason, Galansky says, is simple: "Deprecation is a future state. Money at risk is right now."

Identifying the blast radius

Potential exposure is the product of a few factors:

• how much value the TSS keys actually custody;
• how vulnerable the underlying scheme is; and
• how much the protocol's validator trust model amplifies the risk.

I.e. A protocol with $5B in TVL on CGGMP21 with a permissioned validator set has near-zero exposure to this attack family. But one protocol with just $50M in TVL stuck on the vulnerable GG20 with a permissionless validator set has very high exposure.

The two risks are not comparable based on raw TVL.

The tiers below reflect exposure to this specific class of attack — related to GG18/GG20 key-extraction vectors. They are not a general security ranking. Numbers reflect the best public data I could find as of May 18, 2026.

Tier 1 — Safe

• Internet Computer (ICP) — DFINITY has a custom protocol, not in the GG20 family.
• NEAR Protocol — NEAR also uses a different set of threshold schemes called Cait-Sith, built on entirely separate cryptographic foundations from GG20. Not affected.
• ZetaChain — migrated to threshold BLS for performance reasons; no longer running t-ECDSA.
• Circle's open-source CGGMP21 implementation — current state-of-the-art with no known issues.
• Taurus Group — multi-party-sig with CGGMP.

These protocols may face other cryptographic risks — every scheme does — but not the family that hit THORChain.

Tier 2 — Likely Safe

• Threshold Network / tBTC v2 — TSS-custodied value: ~5,835 BTC (~$450M at $77K BTC). Threshold runs a patched fork of tss-lib explicitly hardened against TSSHOCK-class key-extraction attacks, with 51-of-100 threshold signing and bi-weekly wallet rotation. The patches are public, documented and are thought to be immune.
• Fireblocks — the firm that discovered the q⁵-mask variant. Institutional MPC custody at scale. It should be patched against the class they researched, though specific deployment versions are not public.
• Binance / BNB Chain — uses tss-lib upstream, but the current v3.0.0 includes the specific cryptographic checks at setup time that would have blocked banteg's attack. Older deployments still on pre-v2.0.0 versions inherit the original risk; current ones do not.

Tier 3 — At Risk

While THORChain gets its house in order, these teams should be on high alert:

• Maya Protocol. Forked from THORChain's TSS architecture. Documentation explicitly confirms GG20 TSS. Maya is much smaller than THORChain — TVL in the low single-digit millions — so the absolute dollar exposure is meaningfully smaller. The architectural exposure appears identical, or worse: Maya also runs a permissionless validator set with no slashing, which removes even THORChain's economic punishment for malicious nodes. I haven’t seen any public statement on patch status against banteg's findings. What’s worse, on their Immunefi bug bounty page, Maya excludes from its bounty scope “attacks that are covered by THORChain either in a future version or that are currently reviewing privately." In other words, Maya explicitly defers to THORChain on upstream attack classes. They're not separately patching. They're just tracking what THORChain ships.
• Any wallet or protocol still running ZenGo-X/multi-party-ecdsa, Unbound/blockchain-crypto-mpc, or coinbase/kryptology in production. Galansky names these as unmaintained — meaning new MPC vulnerabilities disclosed publicly are not being patched upstream.
• Earlier Axelar deployments. Axelar previously shipped its own GG20 implementation and has deprecated it in favor of newer architectures. Any residual exposure would depend on transition status.

What to watch for

THORChain's official post-mortem.

Public statements from Maya, tBTC, or other related protocols about their patch status against the specific paths banteg reproduced.

Independent confirmation of Banteg’s results — moving the framing from "consistent with" to "demonstrated."

A wave of migrations to CGGMP21 from the affected protocols, which would resolve the structural problem rather than patching around it.

The cryptography community has been signaling this transition for years. The protocols that remain on GG20 forks are now operating in a window where the public exploit literature, the original authors' own guidance, and at least one live $10M+ incident all point in the same direction.

tl;dr — It’s not that threshold ECDSA is unsafe per se, just this particular flavor, and the people who built it have been saying so for years. The May 11 drain brought the cost of ignoring that warning into sharp focus.