Multisig
Also: m-of-n, multi-signature
wallets · intermediate
A spending condition requiring signatures from m of n possible keys. The canonical way to share custody without a custodian.
Multisig outputs encode "any m signatures from this list of n public keys are sufficient to spend." A 2-of-3 multisig spends with any 2 signatures from any 2 of the 3 keys; the third key can be lost or compromised without losing the funds.
The classical script form, using OP_CHECKMULTISIG:
``
m <pubKey1> <pubKey2> ... <pubKeyN> n OP_CHECKMULTISIG
The spender provides m signatures in order matching the public keys. A historical quirk: OP_CHECKMULTISIG pops one extra item off the stack — the canonical fix is to push OP_0 first, which is why you'll see real spends begin <OP_0> <sig1> <sig2>....
Real-world use cases include:
- Shared custody. Multi-stakeholder treasuries (DAOs, businesses) where no single person can move funds alone.
- Personal redundancy. A 2-of-3 with keys in three locations means losing any one location doesn't lose the coins.
- Custodian arrangements. Services like Casa, Unchained, and Liana issue 2-of-3 or 3-of-5 keys where the customer holds some and the service holds the rest, allowing recovery without giving the service unilateral control.
[Taproot](/glossary/bip86) makes single-sig and multisig indistinguishable on-chain via key aggregation (MuSig2 / FROST). The output looks like one Schnorr key; only the wallets involved know it's actually a federation.