Multisig: What It Actually Protects You From
How multisig works on Bitcoin and Ethereum, why MPC isn't the same thing, and why the largest multisig theft in history didn't break a single signature.
The pitch for multisig is that one key is a single point of failure. Lose it, and your funds are gone. Leak it, and someone else's funds are your funds no longer. Requiring several keys to authorize a spend fixes that.
It does. But the fix is narrower than most people assume, and the cost is larger. Multisig doesn't reduce risk so much as trade one risk for a different one — it converts key-theft risk into coordination risk, and coordination risk kills more wallets than people expect.
The best evidence for this is that the largest crypto theft ever recorded happened to a multisig wallet, and the attacker never broke a single signature. More on that below.
The basic idea
An m-of-n scheme requires m signatures from a set of n keys. A 2-of-3 wallet has three keys; any two can spend.
Start with the arithmetic:
- Theft resistance goes up. An attacker needs m keys, not one.
- Loss resistance goes up. You can lose n − m keys and still spend.
- Complexity goes up. You now have n things to generate, store, back up, and eventually find again.
2-of-3 is the default recommendation for individuals because it's the smallest configuration that improves both theft and loss resistance simultaneously. 1-of-2 improves loss resistance and makes theft easier. 3-of-3 improves theft resistance and makes loss catastrophic. 2-of-3 is the only small configuration that moves both dials the right way1.
For organizations the calculus differs. A DAO treasury running 5-of-9 isn't optimizing for lost keys; it's optimizing for the possibility that some of its signers are adversarial.
Bitcoin: multisig as script
Bitcoin implements multisig at the script level, and its history is a decent tour of the last decade of Bitcoin engineering.
Bare multisig (2010) put all the public keys directly in the output script2. It worked, and it was terrible: everyone could see your whole signer set, and you paid for those bytes.
P2SH (BIP 16, 2012) fixed the visibility problem by committing to a hash of the redeem script. The chain sees a hash. You reveal the script only when spending. This is where the 3... addresses came from.
P2WSH (SegWit, 2017) moved the script witness out of the transaction body, cutting fees for multisig spends significantly.
Taproot (2021) changed the shape of the problem. With Schnorr signatures, keys and signatures are linearly aggregatable3 — a property ECDSA lacks. Several parties can combine their public keys into one aggregate key, and their signatures into one aggregate signature. The result is indistinguishable on-chain from a single-signer payment.
That last property matters more than the fee saving. A 2-of-3 P2WSH spend announces to the entire world, permanently, that it was a 2-of-3. A taproot key-path spend announces nothing.
MuSig2 and FROST
Two schemes implement this in practice, and the difference between them is the thing to remember:
MuSig2 (BIP 327) is an n-of-n protocol. Everyone signs, and the signatures aggregate into one. BitGo reports roughly 47 vBytes saved per input against native SegWit multisig, around 30% lower fees. The catch is in the name: n-of-n. One unresponsive signer and nobody can spend.4 There is no threshold.
FROST (Flexible Round-Optimized Schnorr Threshold) is a threshold scheme — a subset of m signers can produce a valid aggregate signature. It also supports distributed key generation, meaning the full private key never exists anywhere, at any point, including at setup5. No script-based multisig offers that property.
FROST is the more interesting technology and the less deployed one. In Bitcoin it remains largely experimental, with production use concentrated in specialized systems rather than general wallets. MuSig2 shipped first because n-of-n is a much easier problem.
Worth being clear about the tradeoff taproot introduces: script-path multisig is recoverable with just the script and the keys. Aggregated signing requires the signers to run an interactive protocol, which means a live coordination step and more state to lose. Privacy costs operational simplicity.
Ethereum: multisig as a contract
Ethereum has no native multisig.6 An externally owned account is one key, full stop. So multisig is implemented as a smart contract that holds the funds and enforces its own rules about who may move them.
Safe is the dominant implementation. The contract stores an owner list and a threshold, collects EIP-712 signatures off-chain, and executes once the threshold is met.
The consequences of doing it this way are significant and cut both directions.
In favor: the rules are arbitrary code. You get spending limits, time delays, role separation, module systems, and social recovery — none of which Bitcoin script can express. Changing your signer set is a transaction, not a migration to a new address. That last point is a bigger operational advantage than it sounds.
Against: your funds now sit behind a program, and programs have bugs. You've added the contract's correctness — and its upgrade mechanism — to your threat model. A Bitcoin multisig can't be drained by a logic error, because there's no logic beyond signature checking.
MPC is not multisig
These get conflated constantly, including by people selling them. The distinction is simple and it matters:
| Multisig | MPC / TSS | |
|---|---|---|
| Keys | n genuinely separate keys | One key, split into n shares |
| Enforced by | The blockchain | Cryptography, off-chain |
| On-chain footprint | Visible (unless taproot-aggregated) | A single ordinary signature |
| Chain support needed | Yes — script or contracts | None |
| Change the quorum | On-chain transaction, or new address | Refresh shares, address unchanged |
| Auditable after the fact | Yes, the chain records it | No |
The critical difference is where the rule lives7. Multisig's threshold is enforced by consensus — the network itself will reject an under-signed transaction. MPC's threshold is enforced by the signing protocol. If that protocol is implemented incorrectly, or the machines running it are compromised together, nothing at the chain layer catches it.
MPC's advantages are real: it works on chains with no multisig support, it's cheaper, it leaks nothing, and you can rotate shares without moving funds. It's the right answer for exchanges and custodians managing thousands of wallets across dozens of chains.
But an MPC wallet does not leave an on-chain record that a policy was followed. A Safe does. For a DAO treasury where the point is public verifiability, that's disqualifying.
What Bybit actually taught us
In February 2025, roughly $1.44 billion left Bybit's Ethereum cold wallet. It was the largest theft in the history of the industry. The wallet was a Safe multisig, properly configured, with signers on hardware wallets.
Every signature was valid. Every key stayed secret. The cryptography worked perfectly.8
The attackers compromised a Safe developer's machine, reached Safe's cloud infrastructure, and modified the multisig frontend's JavaScript so that when Bybit's signers reviewed a transaction, the interface showed them a benign transfer while the payload they actually signed replaced the wallet's implementation contract with the attacker's.
The signers approved what they were shown. They were shown a lie.
Three things follow from this, and they generalize well beyond Safe:
1. Multisig protects the signature layer. The attack came through the display layer. Requiring more signers does nothing when every signer is looking at the same compromised screen. In fact it can actively hurt: the more signers a transaction has, the more each individual assumes someone else checked it properly.
2. Blind signing is the actual vulnerability. Hardware wallets showed the signers a hash. A hash is not information.9 The defense is independent verification — a second device, on separate infrastructure, decoding the calldata and telling you in words what the transaction does. Bybit's signers had no such channel.
3. Attack surface is a security property. Bybit's Safe supported delegatecall, a general mechanism they did not need for cold storage. A purpose-built contract exposing only what they used would have made this specific attack impossible. General-purpose wallet contracts are convenient and each unused feature is a door.
There's a real irony in the aftermath. EIP-7702 gets criticized for letting EOAs delegate to arbitrary contracts, which sounds like exactly this attack made easy. But 7702 requires a distinct, dedicated signature type to authorize a delegation — it can't be smuggled inside something that looks like a transfer. The Bybit attack works precisely because the generic EIP-712 signing flow can't distinguish "send money" from "replace the wallet."
The operational reality
Most multisig failures are boring. They're not attacks.
Quorum loss. In a 2-of-3, losing two keys loses everything. People underestimate this because they picture three independent events, but the events are correlated — keys stored in one house share a fire, keys in one password manager share a breach, keys held by three co-founders share a falling-out.
Backup complexity scales badly. Bitcoin multisig recovery needs the keys and the wallet descriptor10 — the output descriptor or the xpubs and script type. Back up three seed phrases and lose the descriptor and you may be unable to reconstruct the addresses at all. This has happened to real people with real money.
Inheritance gets harder, not easier. Explaining a 2-of-3 to someone who will need to use it while grieving, possibly years from now, on software that has since changed, is a hard design problem. Miniscript and policy languages like Liana's time-locked recovery paths address this directly and belong in any inheritance threat model.
Signer coordination has a cost. A 3-of-5 across timezones means some transactions take days. Organizations respond by keeping a hot wallet for operations — which is fine, as long as everyone stays honest about how much sits in it.
Choosing
Start from what you're actually defending against. The threat model determines the answer, and the answers differ:
One person, meaningful savings, single chain. 2-of-3, keys in three physically separate locations, at least one of them not your home. Back up the descriptor alongside the seeds. Test recovery before funding it, with a trivial amount, and test it again yearly.
One person worried about a backdoored hardware RNG. Multisig helps here in a way that's easy to miss — an attacker who has predicted one device's entropy still needs the others. Combined with dice-generated entropy, this closes a real gap.
A team or DAO treasury. Safe, threshold matched to your actual governance rather than to a number that sounds serious, and a hard requirement that at least one signer verifies calldata on independent infrastructure. Bybit is the argument for that last part.
An institution across many chains. MPC, with the understanding that you've moved the trust boundary into your provider's implementation and lost the on-chain audit trail.
Anything where the public needs to verify the rules were followed. On-chain multisig. This is the one case where MPC is simply the wrong tool.
The uncomfortable summary
Multisig is a good primitive, and it defends a narrower perimeter than its reputation suggests.11 It answers "what if one key is stolen or lost." It has essentially nothing to say about a compromised interface, a malicious signer, a coerced signer, or a set of signers who all trust the same screen.
The industry's largest loss was a multisig wallet where the cryptography performed flawlessly. That should be the starting point for anyone designing a setup, not a footnote.
Add signers only where the extra key reduces a risk you're actually afraid of. Then spend the remaining effort on the part that failed at Bybit: knowing what you're signing.
Further reading
- BIP 327 (MuSig2) — the two-round multisignature spec for Schnorr
- MuSig2 and FROST explained — the clearest side-by-side of the two taproot schemes
- NCC Group: technical analysis of the Bybit hack — the full incident breakdown
- Certora on multisig wallet security — the attack-surface argument, and why cold storage shouldn't support delegatecall
- Safe documentation — modules, guards, and the contract architecture
- Safe's own MPC vs multisig comparison — partisan, but technically accurate on the distinction
- Where Randomness Actually Comes From — multisig assumes your keys were generated unpredictably; that assumption deserves its own scrutiny
Notes
- 1Note
The full small-n table is worth internalizing. 1-of-2: loss resistance up, theft resistance down (either key drains it). 2-of-2: theft resistance up, loss resistance down. 2-of-3: both up. 3-of-5: both up further, at real coordination cost. Everything above 3-of-5 for an individual is usually someone enjoying the setup more than the security.
- 2Context
Bare multisig is still valid Bitcoin script and still occasionally used — mostly for data embedding rather than actual custody, since the public keys are arbitrary 33-byte fields nobody checks. It's also the origin of a persistent piece of chain trivia: a nontrivial amount of non-financial data lives in the UTXO set as fake pubkeys inside bare multisig outputs.
- 3Context
This is the one concrete thing Schnorr gives Bitcoin that ECDSA couldn't. In Schnorr, the sum of the signatures under the sum of the keys is a valid signature — the math is linear. ECDSA's verification equation has an inversion in it that breaks this. Satoshi's choice of ECDSA in 2008 wasn't a technical judgment so much as a licensing one: Schnorr was under patent until 2008 and simply wasn't in OpenSSL.
- 4Counter
Taproot softens this in practice, because the same output can commit to both a MuSig2 key path and a script path with a conventional threshold fallback. Happy path: everyone signs, one aggregate signature, maximum privacy, minimum fee. Someone's unreachable: fall back to the script path, pay more, reveal more. You only expose the fallback if you actually use it — which is arguably the single best piece of design in taproot.
- 5Source
Distributed key generation is the property that separates FROST from both script multisig and naive key-splitting schemes like Shamir's Secret Sharing. With SSS, someone has to hold the whole key to split it, and someone has to reassemble it to sign — two moments of total exposure. FROST's participants generate their shares interactively and the complete key is never materialized on any machine.
source → - 6Note
This is a design consequence, not an oversight. Ethereum deliberately kept the base account model minimal on the theory that anything expressible in contract code shouldn't be consensus logic. It's the same reasoning that gave Ethereum a rich contract layer and Bitcoin a rich script layer — and it's why the Bybit attack was even possible, since a contract with an upgrade path is a contract that can be pointed somewhere else.
- 7Counter
Vendors selling MPC often present it as strictly better than multisig — cheaper, chain-agnostic, more private, all true. The unstated cost is that consensus stops being your backstop. With on-chain multisig, a bug in your signing software still can't move funds without the threshold, because the network refuses the transaction. With MPC, the signing protocol is the enforcement, and a sufficiently broken implementation produces a perfectly valid signature over whatever it was tricked into signing.
- 8Note
$1.44 billion, February 21, 2025 — the largest theft in the history of the industry, and it required breaking exactly zero cryptography. The attackers compromised a developer laptop, reached Safe's cloud infrastructure, and changed what a webpage displayed. Every layer people spend their security budget on held. The layer nobody was watching was the one rendering the transaction.
source → - 9Quote
"Blind signing" is the industry's term for approving a transaction your device can only show you as a hash. It has been a known problem for years and remains largely unsolved for complex contract calls — the hardware wallet often lacks the screen, the parser, or the ABI to render what it's signing. The mitigation isn't better hardware, it's independent verification: decode the calldata on a second machine, on separate infrastructure, and compare.
— a16z crypto, on the Bybit post-mortem
source → - 10Note
Output descriptors are the standardized fix for what used to be a genuine footgun. A descriptor is a single string encoding the script type, the participating xpubs, the threshold, and the derivation paths — everything needed to reconstruct addresses. Before descriptors, recovering a multisig from seeds alone meant guessing script types and derivation paths until addresses matched. Back up the descriptor with the seeds; it contains no secrets and losing it can still lose the wallet.
source → - 11Counter
The strongest counter-argument to this whole article: Bybit is a single data point, and a survivorship-biased one. Multisig quietly prevents an unknowable number of single-key compromises every year, and those never make headlines because nothing happens. That's fair. The narrower claim still holds — multisig defends the signature layer specifically, and reasoning about it as general-purpose "more security" is how organizations end up with nine signers all looking at one compromised screen.