• What THORChain got wrong
• Why Bitcoin-native means Schnorr, not ECDSA
• MPC-TSS is a layer, not a system
• Per-node hardening as precondition
• The conversation worth having
  • References

On May 15, THORChain lost roughly $10.8M across Bitcoin, Ethereum, BSC, and Base. The public forensics read it as a TSSHOCK-class attack against GG20, a 2020-era threshold ECDSA protocol running on a stale fork of Binance’s tss-lib. The protocol family has documented CVEs going back to 2021. The cryptographers who designed GG18 and GG20 have been steering implementers elsewhere for years.

The incident has reopened a question that’s been simmering in Bitcoin: does MPC-TSS belong in Bitcoin infrastructure at all? The skeptical case has gotten louder, and not without reason. Adaptive cryptography attacks, implementation bugs, a tiny pool of qualified reviewers, online software shards as the entire security model, every part of the critique has a CVE behind it.

We use MPC-TSS at Surge. We’ve used it from the beginning and we’ll continue to. This is the long version of why and where we think the failure modes actually live.

§What THORChain got wrong

Four distinct failures, each with documented alternatives that have existed for years.

Protocol choice. GG20 is a Paillier-based threshold ECDSA protocol. The Paillier family : GG18, GG20, Lindell17, CMP, CGGMP21 has been the source of every named critical vulnerability against threshold ECDSA in recent years. The structural reason is the Multiplicative-to-Additive (MtA) subprotocol, which uses Paillier homomorphic encryption and zero-knowledge range proofs to let parties compute the product of their shares without revealing them. Each component has been an attack vector. The OT-based family : DKLS, Haitner-Lindell-Nof-Ranellucci, replaces MtA with Oblivious Transfer, which has a much smaller cryptographic surface. The DKLS authors have been recommending DKLS23 for new deployments since 2023.

Library hygiene. A correct protocol in an unmaintained library is at least as dangerous as an obsolete protocol. THORChain’s TSS implementation was a fork of Binance’s tss-lib that didn’t track upstream. By the time the attack landed, the gap between what the fork did and what current security practice required had been growing for years.

Threat model on quorum entry. Any participant who bonded enough RUNE could churn into the active validator set and join the keygen ceremony. Bond-gated entry is acceptable when the validator’s misbehavior is bounded by their stake. It is not acceptable when the validator’s misbehavior can extract the full threshold key. THORChain conflated economic security with cryptographic security. The two have different threat models.

Architectural single-point-of-failure. This is the deepest failure and the one that’s gotten the least attention. One threshold key controlled vaults across every chain. Key recovery through whatever vector — meant simultaneous drains on BTC, ETH, BSC, and Base. The cryptography was the security model. When the cryptography failed, the funds left.

None of these failures are inherent to MPC-TSS. Each is a specific design choice.

§Why Bitcoin-native means Schnorr, not ECDSA

This is the part most of the post-THORChain commentary has skipped.

ECDSA is what Bitcoin used pre-Taproot. Threshold ECDSA exists because of that legacy and inherits the structural pain. ECDSA signatures involve multiplicative coupling between the nonce and the private key:

s = k⁻¹ · (m + r · x) mod n

When k and x are split across parties as additive shares, computing k⁻¹ · x requires the parties to multiply their shares together without revealing them. That’s the MtA step. It’s where every named threshold-ECDSA CVE in the last five years has landed.

BIP340 changed this. Schnorr signatures are linear:

s = k + e · x

No multiplicative coupling. No inverse. The signature is the sum of two scalars. Threshold Schnorr is structurally simpler — parties hold additive shares of k and x, each computes their contribution to s, the contributions add to the final signature. No MtA. No Paillier. No range proof on the multiplicative coupling because there is no multiplicative coupling.

Entire classes of attacks that hit GG18 and GG20 have no analog in Schnorr. TSSHOCK doesn’t translate. CVE-2023-33241 doesn’t translate. The Alpha-Rays finding doesn’t translate. The protocols that produced these CVEs depend on cryptographic constructions that Schnorr-based threshold signing does not require.

Taproot made Schnorr the native Bitcoin signature scheme. Activated November 2021, deployed across the ecosystem, supported by every serious Bitcoin wallet and infrastructure project. Threshold Schnorr schemes : FROST, MuSig2, and the variants Surge uses have been the subject of active cryptographic research and have shipped audited implementations from credible teams.

There is no longer a technical reason to build Bitcoin custody on threshold ECDSA. There are legacy reasons (existing deployments, vendor relationships, codebases that predate Taproot). There are not new-deployment reasons. A team starting in 2026 with a clean sheet and Bitcoin as the target chain should use threshold Schnorr.

Surge uses Schnorr-based threshold signing on BIP340. Not because it’s trendy. Because Bitcoin gave us a better primitive and there’s no excuse for ignoring it.

§MPC-TSS is a layer, not a system

This is the architectural argument, and it’s the one that matters most.

The failure mode at THORChain wasn’t just GG20. It was that the threshold key was the security model. If the key was compromised, the vault was drained. The cryptography sat alone at the top of the trust hierarchy with nothing structural below it to catch the fall.

Bitcoin is one of the few platforms where this isn’t necessary. Taproot lets a vault encode multiple spending conditions, each with different signers, different timelocks, and different cryptographic assumptions. A well-designed Bitcoin-native vault doesn’t put the entire weight of user funds on any single component.

Surge’s vaults are Taproot scripts with multiple spending paths:

• Cooperative path. The Distributed Custody Network (DCN) co-signs with the user via threshold Schnorr. Fast, ergonomic, the default for normal operation. This is where MPC-TSS lives.

• Unilateral exit path. A timelocked script path that lets the user recover their Bitcoin without any DCN participation. Enforced by Bitcoin Script, not by signer behavior. If the DCN is compromised, offline, censoring, or fully colluding, the user waits out the timelock and spends through this path.

The critical property: the threshold signature is one spending condition among several. If the entire DCN colludes, gets compromised, or every shard leaks simultaneously, the user still recovers their funds through the script. The vault does not trust the signers more than the script permits.

This is the answer to the strongest version of the skeptical case. The critics are right that online software shards alone are an insufficient security model. The Surge architecture is built on the same premise, which is why we don’t ask the threshold signature to be the only thing standing between the user and their Bitcoin.

§Per-node hardening as precondition

Even with a script-enforced fallback, per-node security matters. A degraded DCN is a worse UX, a worse liveness story, and a worse trust story. Unilateral exit is the safety net, not the operating mode.

Surge’s DCN nodes run inside TEE-attested environments. Fischlin ZKPs during keygen and signing close the malformed-message attack family at the protocol layer the same family that produced TSSHOCK against GG20. Hardware-isolated enclaves close shard extraction at the platform layer. Node onboarding requires attested identity rather than economic stake.

Hardening co-signers isn’t an addition to MPC-TSS. It’s a precondition for it. The protocol is sound. The operational posture around it is where most real-world failures live. THORChain’s nodes weren’t operationally distinguishable from any other Go service running on standard infrastructure. They didn’t need to be malicious; they needed to be reachable.

§The conversation worth having

The question after THORChain isn’t “is MPC-TSS broken.” Threshold signing is a useful and well-studied primitive that has shipped in production custody for years without losing funds when correctly deployed. The question is what an MPC-TSS deployment should actually be responsible for in a system where Bitcoin’s own primitives : Taproot, Schnorr, scriptable spending conditions give builders better tools than threshold cryptography alone.

We’re not claiming MPC-TSS is risk-free. We’re not claiming Schnorr-based threshold signing eliminates all classes of cryptographic bugs. We’re not claiming TEE attestation is a substitute for cryptographic security proofs. What we are claiming is narrower: that on Bitcoin specifically, builders should choose protocols matched to the chain’s native primitives, treat per-node security as critical infrastructure, and design architectures where no single layer is asked to be infallible.

Bitcoin-native systems don’t need TSS to be the only line of defense. They shouldn’t ask it to be.

Don’t trust, verify. That phrase carries more weight when there are multiple things to verify, and when the verification doesn’t depend on any single party being honest.

§References

• Punith. After THORChain — A Builder’s Guide to Threshold ECDSA. Surge, 2026. https://x.com/punithbtc/status/2056327478956966208

• Doerner, Kondi, Lee, Shelat. Threshold ECDSA from ECDSA Assumptions. IEEE S&P 2018, current revision DKLS23.

• Lindell. Simple Three-Round Multiparty Schnorr Signing with Full Simulatability. IACR Communications in Cryptology, 2024 (“Lindell22”).

• Canetti et al. UC Non-Interactive, Proactive, Threshold ECDSA with Identifiable Aborts. CCS 2021 (“CGGMP21”).

• Gennaro, Goldfeder. GG18 / GG20 series. eprint 2020/540.