Threshold Signatures (TSS) in THORChain

Threshold Signature Schemes are the cryptographic foundation that allows THORChain to custody assets across many chains without ever exposing a single private key.

The Problem with Traditional Multisig

Traditional multisignature schemes (like Bitcoin's 2-of-3) have significant limitations when used for cross-chain protocols:

• Each chain has different multisig capabilities
• Keys must be generated per chain
• No unified security model across assets

How TSS Solves This

THORChain has used GG20 threshold signature schemes, with later cryptographic migration work discussed in official incident reporting. Details should stay tied to dated sources because the implementation and recovery path can change.

• Distributed key generation: No single node ever holds the full private key
• Threshold signing: A configurable threshold (typically 2/3) of nodes must cooperate to produce a valid signature
• Chain-agnostic: The same TSS keys can be used to generate addresses on many different blockchains

Security Properties

• No intended single point of failure: Correctly implemented threshold signing avoids one node holding a complete private key, but safety depends on the current cryptographic implementation and active incident status.
• Proactive security: Keys are regularly rotated during churn events.
• Accountability: Misbehaving nodes can be identified and penalized through reward slash points or bond slashing, depending on the fault.

Real-World Impact

The May 15, 2026 official exploit reports say one vault was drained through a cryptographic attack against THORChain's GG20/TSS signing path. Report #2 adds important root-cause detail: the attacker joined as a validator, planted malformed Paillier key material during setup, then deliberately failed the MTA signing round 864 times over roughly two and a half days. Those failures looked like ordinary node flakiness in isolation, but they leaked enough key-share fragments for the attacker to reproduce the vault key and sign alone.

The same report says this was not a smart-contract, bridge, oracle, multisig-operator, or Solana/EdDSA exposure. It was specific to the GG20/ECDSA path and its Paillier cryptography assumptions. It also explains why solvency checks did not halt the loss in time: by the time funds moved, the upstream key compromise had already happened and the outbound transaction looked like a valid signature.

Post-incident changes should be described in dated terms. THORChain's v3.19.0 upgrade post identifies restart recovery work such as TSS patches, compromised-vault exclusion, temporary KeyVerify checks, and pause-safety rules. The later official exploit report says validators upgraded to v3.19.1 and completed coordinated vault verification before normal signing and fund movements resumed. It also says THORChain plans to move away from GG20 toward alternatives such as DKLS and/or Schnorr-style approaches, and that validator-level key-sign failure monitoring is being strengthened. Proposals such as minimum validator age, gradual exposure for new validators, dual-scheme vault architecture, and bug-bounty redesign should be presented as under consideration unless a later source verifies implementation.

TSS is what makes true native cross-chain liquidity possible without bridges or wrapped tokens.

Dated Recovery State

The source-backed July 2026 boundary is narrower than either "nothing changed" or "the cryptography has been replaced":

• v3.19.0 shipped the restart-oriented TSS patches, compromised-vault exclusion, temporary KeyVerify flow, and pause-safety changes.
• Exploit Report #2 says every validator upgraded to v3.19.1 and that coordinated vault verification happened before normal signing and fund movements resumed.
• The June 25 post-restart update says trading had resumed.
• That same post-restart update still describes DKLS/FROST evaluation and chain-by-chain migration as future security work. It does not say current ECDSA vault signing has completed that migration.
• The official documentation root still described THORChain with GG20 at the July 14 review. That is architecture context, not proof that every running signing path, validator, or vault is safe now.

Therefore, the safe statement is: the v3.19.x recovery restored normal network operation with patched GG20-era signing, while migration away from GG20 remained planned. Current signing and vault-safety claims still need live diagnostics and newer release evidence.

For present-tense claims, separate historical GG20/exploit/restart wording from the running release; check Network diagnostics and exact validator rollout evidence before calling any mitigation network-wide. Planned DKLS/Schnorr/dual-scheme work is live only when a newer source proves it. Generic TSS context cannot prove every validator's safety, eliminate GG20/Paillier risk, establish route availability, or assign a transaction failure to TSS without transaction-level evidence.

Common Misreadings

• "TSS means THORChain controls your keys." TSS distributes key shares across nodes using threshold signing. No single party — not the protocol, not any operator, not THORChain — holds the full private key.
• "The GG20 exploit compromised all vaults." The May 15, 2026 exploit reports say one vault was drained through a specific cryptographic attack against the GG20/TSS signing path. The attacker targeted one vault by joining as a validator and exploiting Paillier key generation, not all vaults simultaneously.