Multisig, and what several keys change

The threshold and the key count are chosen together, and the choice expresses a trade-off between convenience and resilience. A 2-of-2 scheme requires both keys for every spend, which means no single device is sufficient but also that losing either key loses the funds. It removes the single point of failure for theft without removing it for loss.

A 2-of-3 scheme is the most widely used configuration, and the reason is that it tolerates exactly one failure of either kind. Two keys are needed to spend, so one key alone cannot move the coins. Three keys exist, so one can be lost, destroyed or held offline without affecting the ability to spend. It is the smallest arrangement that provides both properties at once, which is why it appears so often in wallet defaults and in guidance for individual holders.

Higher thresholds follow the same logic with more margin. A 3-of-5 scheme tolerates two lost keys and still requires three to spend, which suits an organisation where several people hold keys and some turnover is expected. The cost is operational: every spend requires coordinating three signers, and the more keys involved the more places there are for the process to break down. A scheme that is secure in theory but too cumbersome to use correctly is not secure in practice.

The most immediate change is to theft risk. In a single-key wallet, anyone who obtains the key can spend the coins, and the owner's only defence is to keep the key secret. In a multisig wallet, obtaining one key is not enough. An attacker must compromise enough keys to reach the threshold, and if those keys are held in different places and by different people, that is a substantially harder problem.

The change to loss risk is more subtle and cuts both ways. Multisig tolerates the loss of some keys, which a single-key wallet cannot. But it also introduces new ways to fail. The keys must be generated and stored such that the threshold remains reachable, the wallet must know the full set of keys and the threshold in order to reconstruct the script, and a backup that records only one key is not a backup of the wallet. A multisig setup whose participants do not understand which keys exist and where they are is more fragile than a single key kept carefully.

Recovery therefore depends on a different kind of record. A single-key wallet is recovered from one seed phrase. A multisig wallet is recovered from the seed phrases of enough keys to meet the threshold, together with the wallet descriptor or configuration that records the full key set and the threshold. Losing the descriptor while keeping the keys is a recoverable situation for a competent technician; losing the keys is not. The seed phrases and private keys page explains what each of those backups actually contains.

Multisig is not the right answer for every holder. It adds moving parts, and each moving part is a chance to make a mistake. For a small holding, a single well-protected key is simpler and the additional resilience is not worth the operational burden. For a large holding, or one where several people need to authorise a spend, the calculus changes and the redundancy becomes the point.

The arrangement also has a collaborative use that is distinct from personal security. A 2-of-3 scheme in which one key is held by a service and two by the owner can provide recovery assistance without giving the service the ability to spend alone. The service holds one key, the owner holds two, and neither party can move the coins unilaterally. This is a genuine middle ground between full self-custody and full custodial control, and it is the basis of most collaborative custody products.

The hardware and software wallets page covers the devices that hold each key, and the self-custody and exchange custody page sets out the counterparty question that multisig is designed to reduce.