Threshold Signatures vs Multisig: Which Is Safer?

If you hold or move real size, your signing model is not a side quest. It is the thing. The control plane. The gate between intent and loss.

Two models dominate serious crypto ops: classic multisig and threshold signatures. They look similar from the outside. They are not the same inside. The right choice depends on how you weigh cryptography risks, human process, on-chain costs, and the blast radius if something breaks.

I will keep this practical. What each model actually secures, how it fails in the wild, and where the fees and paper trail land. Then a decision matrix you can actually use.

What each model actually secures

Both approaches stop a single compromised signer from moving funds. They just anchor trust in different places.

Multisig in practice

Multisig encodes the policy into the chain itself. On Bitcoin, that is P2WSH or Taproot script paths. On Ethereum and other EVM chains, that is a smart contract wallet. The quorum check lives on-chain. If you do not meet the threshold, the network will not accept the spend. Pretty direct.

Upside: it is obvious to auditors and recoverable with basic tooling. Downside: larger on-chain size for higher thresholds on Bitcoin if you are not using Taproot in key-path form, and higher gas on EVM contracts vs a simple EOA. Also, your policy may be partially visible to chain analysts unless you’re careful with Taproot paths.

Threshold signatures in practice

Threshold signatures split a private key into shares and coordinate an off-chain signing protocol so that t-of-n participants produce one aggregated signature. The chain only sees one signature from what looks like a single key. In ECDSA land, that might be GG18 or GG20 style MPC. In Schnorr land, you will hear FROST or MuSig2.

Upside: smaller, cleaner on-chain footprint and a familiar EOA interface for dapps. Downside: your security lives in a distributed protocol and whatever coordinates it, plus all the off-chain monitoring and logging you run.

On-chain footprint, fees, and privacy

Fees and fingerprinting matter when you sign hundreds or thousands of times a day or you rotate cold storage infrequently but with large inputs.

On Bitcoin, the fee math has changed with Taproot and modern Schnorr-based schemes. Spark’s July 2026 custody comparison measured a FROST or MuSig2 input at about 57.5 virtual bytes, while a classic 2-of-3 P2SH input sits near 296 vB and a 3-of-5 P2WSH can be around 350 vB. That is roughly an 80 percent reduction for higher-threshold examples (Spark).

On Ethereum, TSS lets you appear as a single EOA, which avoids contract execution overhead entirely. That is a material gas difference in busy routes. The flip side is you give up the contract-level guardrails and visibility you might want for treasuries.

Privacy is cleaner with TSS because everything looks like a single key. With multisig, unless you use Taproot carefully, some aspects of your policy can leak when you spend.

Pro tip: If you lean Bitcoin-first and care about fees, a Taproot key-path spend using FROST or MuSig2 gives you both cost savings and policy privacy. Just do not skip the operational hardening that makes TSS safe in practice.

Failure modes that keep me up at night

Most headline losses do not happen because elliptic curves broke. They happen because keys, permissions, or signing flows were compromised.

CertiK’s H1 2026 review counted $1,315,676,432 lost across 344 incidents, with wallet compromise the costliest vector at $444,531,691 across 33 cases (CertiK). That is the backdrop for any TSS vs multisig talk: your ops discipline often decides the outcome more than the math.

How TSS can fail

TSS is powerful, but the protocols have sharp edges. On July 3, 2026, THORChain published an exploit report describing a May 15 incident where an attacker abused its GG20-based TSS. By deliberately failing signing rounds 864 times over about two and a half days, they leaked enough key material from other validators to drain around $10 million (THORChain (blog)).

That is not a condemnation of TSS in general, but it is a loud reminder: round-based protocols need strict abort rules, liveness protections, and detection of repeated manipulation. You also need rapid rotation and share refresh procedures that actually get used, not just written in a wiki.

How multisig can fail

Multisig’s biggest enemies are key loss and policy misconfigurations. Lose two keys in a 2-of-3 with no time-delayed recovery path, and funds are frozen. On EVM, contract multisigs can be upgraded into a broken state if governance or admin keys are not nailed down. People still forget to set sane daily limits, or they bypass them “for speed” and never turn them back on.

Most losses start off-chain

To underline that point, CoinDesk reported in late July 2026 that multiple cross-chain protocols were drained within hours for more than $35 million combined. Those were not cryptographic failures. They came from compromised keys or permission logic flaws (CoinDesk).

So the question is not just “which math is safer,” but which setup gives your team fewer ways to shoot itself in the foot.

Operational reality: who runs what, and where

What will your team actually run every day? This part drives both safety and cost.

TSS operations

• Infrastructure: You need a coordinator, network reachability between signers, and monitoring to spot failed or suspicious rounds. Cloud is common, but do not ignore HSMs or enclaves for share custody.
• Availability: A quorum must be online to sign. That raises questions about geographic redundancy, DDoS resilience, and emergency fallbacks.
• Rotation and refresh: Good TSS stacks support key refresh without moving funds. Run it regularly. Practice it. Assume at least one share device will be lost or compromised at some point.
• Vendor risk: If you use a provider, you inherit their process guarantees. Demand export paths, independent share custody, and attestations you can audit.

Multisig operations

• Devices: Hardware wallets plus a PSBT flow on Bitcoin, or a contract multisig UI on EVM. Keep one key air-gapped for cold paths.
• Recovery: You can swap a signer by moving funds to a new address with a fresh policy, or by using contract upgrade hooks. It is slower and more visible, but straightforward.
• Liveness: You can sign with any subset that meets the threshold. No coordinator needed. That removes one moving part but does not remove human error.
• Human factors: Clear procedures for who can propose, who can approve, and time-delayed lanes for large moves are where most teams win or lose.

Auditability and compliance expectations

Auditors and regulators like controls they can see. Multisig gives you that almost for free. The address or contract encodes a policy that can be verified on-chain. On Bitcoin, you can also hold backup spending paths behind time locks. On EVM, you can prove role assignments and limits with contract state.

TSS looks like a single-sig on-chain, which is great for privacy and fees but pushes the proof burden off-chain. That is fine if you have robust logs, signer attestations, SIEM hooks, and periodic external attestations. If you do not, an auditor is going to ask whether this is just a hot wallet with extra steps.

For many treasuries, the path of least resistance is a mix: TSS for high-frequency execution where fees hurt, and a visible, boring multisig with time locks for cold or warm storage.

Cover image of CertiK’s “Hack3D: H1 2026” report — the authoritative mid‑year analysis documenting USD 1.315B lost in H1 2026 and highlighting wallet compromise as the largest loss vector (relevant to multisig/TSS operational risk). — Source: CertiK

Decision matrix: picking for your stack

If you lean TSS, sanity-check these

• Which protocol variant are you actually using? Request a plain-English paper and an external review summary.
• What are the abort rules? Do repeated aborts trigger alarms and remediation, or can someone grind rounds quietly?
• How often do you refresh shares, and how is that scheduled and attested?
• Do you have a provable separation of duties between coordinator ops and share custodians?

If you lean multisig, sanity-check these

• Can you survive the loss of any single device? Two? Test it without moving real funds first.
• Are time locks and spend limits actually enabled for big moves, or just written in a policy doc?
• Who can upgrade or rotate the contract on EVM, and how is that governed?
• Is your address type fee-efficient enough for your volume, or should you migrate to Taproot paths?

Common mistakes and safer defaults

• Confusing redundancy with backups. TSS’s shares are not a classic seed you can write on steel and forget. Plan for share refresh and incident rotation. Document it like an airline checklist.
• Skipping liveness and anomaly monitoring. If multiple TSS rounds fail in a row, that is a pager event, not a log line.
• Running N-of-N multisig “just for a week.” It becomes permanent. One lost device later, and the funds are stuck.
• Trusting admin keys on EVM multisigs. Put upgrades behind the same or stricter quorum than spending. Add a delay.
• Ignoring supply chain risk. Keep spare hardware wallets and secure firmware paths. Vet any MPC vendor’s export and recovery story before onboarding.

Pro tip: Whichever route you take, practice a full rotation drill quarterly. Rotate one signer out, attest the process, and confirm downstream systems keep working. It is the fastest way to surface silent assumptions.

If you want a quick mental model: TSS optimizes for execution performance and privacy, but demands excellent operational hygiene. Multisig optimizes for simple, provable controls, but charges more on-chain and sometimes in UX. The safer option is the one your team can run cleanly at 3 a.m. on a holiday when something trips an alarm.

For ongoing coverage and deeper dives, I often break down real incident reports and compare how teams responded. If you want that in your feed, you will find it at Crypto Daily.

Frequently Asked Questions

Is threshold signatures or multisig safer on Bitcoin right now?

It depends on your ops. With Taproot, TSS using FROST or MuSig2 is very fee-efficient and private. Multisig with Taproot scripts gives on-chain policy and simple audits. Pick the one you can monitor and recover without heroics.

Does TSS make sense for a DAO treasury?

Often, a contract multisig still fits better for treasuries because it exposes policy on-chain, lets communities verify actions, and supports delays and limits. TSS can complement this for execution wallets or market-making arms.

What about the THORChain TSS incident — should I avoid MPC?

It is a cautionary tale, not a ban. The exploit involved round manipulation in a GG20-based setup. If you use TSS, demand strict abort handling, monitoring, and regular share refresh. Design so one noisy participant cannot grind rounds unnoticed.

Are losses usually due to broken crypto?

Rarely. Recent bridge drains and many major losses were traced to compromised keys or permission logic, not broken signature algorithms. Process, permissions, and monitoring tend to decide outcomes.

Can I mix TSS and multisig?

Yes. Many desks run a TSS hot or warm layer for execution and a multisig with delays for cold storage. The split lets you keep fees low where it matters and preserve strong, visible controls where it matters more.

Does Taproot remove the need for multisig?

No. Taproot improves privacy and cost, especially for Schnorr-based schemes, but it does not replace the governance, time locks, and audit trail many teams want from multisig policies.

What is the biggest mistake teams make when switching?

Migrating in a rush without rehearsing rotation and recovery. Whatever you choose, run tabletop exercises and a dry-run with small funds. Confirm alarms fire when you expect, and people know exactly who does what.

Disclaimer: This article is provided for informational purposes only. It is not offered or intended to be used as legal, tax, investment, financial, or other advice.