When One Key Is Not Enough: Multisig, MPC and Collaborative Custody, Honestly Compared

The problem a single key cannot solve

Before comparing schemes, it is worth stating the problem precisely, because the schemes are answers to it and the answers only make sense against the question.

A single-seed wallet asks you to hold one secret satisfying two requirements that pull in opposite directions. It must never be lost, which argues for copies, in more places, known to more people. And it must never be found, which argues for one copy, hidden, known to nobody. Every backup decision is a trade along that line, and no position on it is safe in both directions at once.

Requiring more than one key changes the shape of that problem rather than solving it. If no single secret can move funds, a copy being found is no longer fatal; if more keys exist than are required, a copy being lost is no longer fatal either. Both failure modes become survivable at once, which no arrangement of a single seed can achieve.

That is the genuine argument, and it is a strong one. What follows is what it costs, because the cost is where the losses happen.

What M-of-N actually changes

The Bitcoin Wiki's definition is the cleanest available: multi-signature refers to requiring multiple keys to authorise a Bitcoin transaction, rather than a single signature from one key. The scheme is described as M-of-N, where any M private keys out of a possible N are required to move the money.

Work through a 2-of-3, the configuration most individuals and small groups end up at. Three keys exist; any two can spend. A stolen key achieves nothing, because the thief needs a second. A key destroyed in a fire achieves nothing either, because two remain. You are protected against a theft and a loss simultaneously, which is the whole point.

The Wiki lists the applications directly: dividing up responsibility for possession of bitcoins among multiple people, avoiding a single point of failure so that it is substantially more difficult for the wallet to be compromised, and M-of-N backup where loss of a single seed does not lead to loss of the wallet. It also gives the arrangement people actually use — one key held at home, a second in a bank safe deposit box, and copies of a third distributed to a close friend, a relative and an office.

Two things follow that are easy to miss. First, geography is doing as much work as cryptography: keys in the same drawer are a 2-of-3 on paper and a single point of failure in reality, because one fire or one burglary reaches all of them. Second, the threshold encodes a judgement about which risk you fear more. A 2-of-3 tolerates one loss and resists one theft. A 3-of-5 tolerates two losses and resists two thefts, at the cost of more things to manage. Raising the threshold buys theft resistance and spends loss tolerance, and the Wiki notes the plain consequence of going further: the more signatures required, the more cumbersome actually using that wallet becomes.

Collaborative custody is this same structure with one key held by a service, which can help you recover when you lose one, at the cost of reintroducing a company into an arrangement you may have adopted to avoid one. Ask which quorum the service can reach alone: a setup where your own keys always meet the threshold without them is a different proposition from one where they are load-bearing.

The XPUB trap: how a multisig becomes a new single point of failure

This is the section that justifies the guide, because it is the part the casual recommendation leaves out and the part that loses coins while every key is intact.

A single-seed wallet can be reconstructed from the seed alone. That is what a seed phrase is for, and BIP-39's whole purpose is to turn a master secret into words you can write down and later restore from. A multisig wallet cannot be reconstructed that way. To recreate the wallet, software needs to know the full arrangement: which keys participate, the threshold, and the derivation involved. That information lives in the wallet's extended public keys and configuration, and Trezor's guidance is unambiguous about what happens without it — if you do not have the XPUB for every single key used to set up the wallet, you will not be able to send your transaction or access your wallet.

The consequence stated more sharply, in the same source: if you do not save your XPUBs, losing one key will cause you to lose your funds, even if you have enough private keys to theoretically unlock the multisig wallet.

Sit with that sentence, because it describes a genuinely perverse outcome. You adopted a 2-of-3 to survive losing a key. You then lose a key, exactly as planned. You still hold two, which is the threshold. And the funds are unreachable, because the surviving keys cannot be assembled into the wallet they belong to without the configuration you did not think to save.

The trap is effective because the missing item is public information. Extended public keys reveal addresses, not spending power, so they attract none of the protective instinct a seed phrase does — nobody hides them in a safe, or thinks of them as a backup at all. Yet a multisig with perfect key custody and no saved configuration has a single point of failure, and it is the one you were not watching.

The fix is procedural and cheap. Back up the configuration — the descriptor or the collected XPUBs — alongside every seed, in every location, so any place holding a key also holds the map. Then verify by restoring, before the arrangement holds anything you care about. A multisig you have never restored is an assumption, not a backup.

MPC, smart accounts and Shamir are three different things

These get discussed together as multi-key security, and conflating them leads to bad choices, so it is worth separating them by what is actually being divided.

Multisig divides authorisation. Several distinct keys exist, the chain enforces the threshold, and the rule is visible in the transaction. Its strength is that nobody has to trust an implementation for the threshold to hold — it is the ledger's rule, not a vendor's.

MPC divides one signature. NIST's Multi-Party Threshold Cryptography project describes the underlying idea as threshold schemes that apply the principles of secure multiparty computation to achieve a secure distribution of trust in the operation of cryptographic primitives. In a wallet, that means key shares held separately and combined cryptographically to produce a single ordinary signature, so the chain sees a normal transaction and never knows a threshold existed. The practical benefits are real: no larger transaction, no multisig support needed from the network, and a simpler experience. The trade-off follows from the same fact — because the protection is implemented rather than enforced on-chain, you rely on the correctness of the protocol and the vendor who built it, and your recovery path is generally theirs rather than a standard you could reconstruct elsewhere.

Smart-account recovery divides authority over an account. Ethereum's roadmap documentation describes what these enable: recovering your account if you lose the keys, adding backup keys to replace a compromised primary, sharing account security across trusted devices or individuals, and requiring multiple signatures for high-value transactions. Vitalik Buterin's case for social recovery wallets is the human argument — that ordinary people should not be one lost piece of paper from ruin. The trade-off is that the rules live in contract code, so its correctness is part of your security, and nominated guardians are a dependency you must keep current.

SLIP-39 Shamir divides the backup, not the signing. The specification applies Shamir's secret sharing to mnemonic codes, splitting a secret into shares of which any threshold reconstructs it, and its stated motivation is that Shamir's secret-sharing provides a better mechanism for backing up secrets by distributing custodianship among trusted parties. The distinction that matters: this protects the backup while spending remains single-key, and the secret does get reassembled in one place at recovery time. So Shamir addresses the loss problem elegantly and does not give you multisig's theft resistance during normal use.

Which explains Trezor's own recommendation, and it is not the one most guides imply. Multisig, they say, may not be ideal for everyone, especially beginners, and is most appropriate for groups of people who need to control a wallet collectively, such as a business or corporate treasury. For individuals they recommend a SLIP-39 Shamir backup instead, as offering similar protection against single points of failure while being easier to set up and manage.

Choosing without over-engineering

The failure people expect from these systems is a break-in. The failure that actually happens is complexity — an arrangement nobody can operate under stress, or one whose owner is the only person who ever understood it. So start from the honest costs rather than the appeal. Multisig transactions must carry multiple public keys, multiple signatures and the script describing the threshold, which as Trezor notes significantly increases transaction size and therefore the fee — a transaction needing three signatures may cost significantly more than a single-signature one. Key rotation is worse than most people assume: if a key is lost or suspected compromised you should rotate it, and that typically requires creating an entirely new multisig wallet and transferring the funds, because most wallet software does not support in-place key replacement. That is not a settings change; it is a migration with fees and a fresh chance to make a mistake.

Three questions do most of the choosing. What are you defending against — losing a backup, or someone taking one? Loss-dominant risk points toward redundancy, which SLIP-39 delivers with much less machinery; theft-dominant risk points toward a genuine quorum. Who else needs to move these funds, now or after you? Shared control is the case multisig was designed for, and the honest answer to inheritance, because a quorum your heir can reach with help beats instructions they must follow perfectly and alone. And who operates it if you are unavailable tomorrow? An arrangement only you understand has a single point of failure wearing a disguise.

Then match the structure to the amount, and do not skip the smaller step because the larger one exists. For most individuals a well-backed-up single-key hardware wallet, with a tested restore and a Shamir or geographically separated backup, is an enormous improvement on what they have now and achievable this month. A genuine multisig is the right answer for shared control, for a treasury, and for amounts where the overhead is clearly justified.

Whatever you choose, the drill is the same and it is non-negotiable. Restore the wallet from your backups alone, on different software, on a different machine, and confirm it produces the same addresses — and for a multisig, assemble the quorum and actually sign a small transaction. Untested backups are the most common cause of loss in self-custody, and adding keys multiplies assumptions rather than removing them.

Authority sources used

Outbound links are included for verification and entity authority, not decoration.

• Multi-signatureBitcoin Wiki
• Multisig Wallets: How Multi-Key Security Protects Your BitcoinTrezor Learn
• SLIP-0039: Shamir's Secret-Sharing for Mnemonic CodesSatoshiLabs Improvement Proposals
• Multi-Party Threshold Cryptography (MPTC)NIST Computer Security Resource Center
• Account abstractionEthereum.org
• Why we need wide adoption of social recovery walletsVitalik Buterin
• BIP-39: Mnemonic code for generating deterministic keysBitcoin Improvement Proposals

FAQ