What Is Multisig?

In brief

An M-of-N threshold names the minimum approvals M accepted from N authorized keys. A 2-of-3 policy tolerates one unavailable key and resists one isolated key compromise. A 3-of-3 policy requires everyone but has no missing-key tolerance. A 1-of-3 configuration has multiple authorized keys but does not provide multi-party approval for an ordinary spend.

“Multisig” is an umbrella term, not one cross-chain standard:

• Bitcoin can place multiple-signature conditions in Script, hide them behind P2SH/P2WSH, or use Taproot script paths. Coordinated Schnorr schemes such as MuSig2 can produce one aggregate public key and signature, so the on-chain spend may look like a single-signature Taproot key-path spend.
• Ethereum commonly uses a contract account whose code stores owners, verifies a threshold of approvals, and executes calls. Safe is a prominent implementation, named here as an example rather than a recommendation.
• Other programmable chains can enforce thresholds in programs or native account features, with different transaction and recovery rules.

What problem a threshold can solve

A single-signature wallet has one decisive credential. If that key is lost and no recovery authority exists, funds may be inaccessible. If it is copied, an attacker may be able to spend alone.

A well-operated 2-of-3 changes both outcomes:

• one lost key leaves two that can spend;
• one stolen key is insufficient;
• two participants can authorize when the third is unavailable;
• keys can be separated across people, devices, software stacks, and locations.

The word separated matters. Three seed copies imported into three apps on one laptop are three keys but largely one failure domain. Three hardware devices initialized from the same seed are not independent signers. Two officers who always approve from the same compromised computer can be deceived together.

Threshold selection is a trade-off. Raising M can improve resistance to isolated compromise or unilateral action, while making operational delay and permanent lockout more likely. Increasing N can add redundancy but also expands the number of keys, people, backups, and processes that must be secured.

Bitcoin multisig: authorization lives with outputs

Bitcoin spends unspent transaction outputs (UTXOs). Each output is locked by a script or script commitment, and a later input must satisfy that condition. BIP-11 documented the early standard OP_CHECKMULTISIG M-of-N form. BIP-16’s P2SH moved the full redeem condition to spending time behind a script hash. SegWit later supports script commitments through P2WSH.

Taproot adds other choices. A threshold script can exist in a Taproot script tree and be revealed only when used. Alternatively, participants can cooperate under a protocol such as MuSig2 to create an aggregate key and signature for a key-path spend. MuSig2 is interactive cryptography with nonce-handling and coordination requirements; it is not simply “replace OP_CHECKMULTISIG with one opcode.”

Operationally, a Bitcoin multisig wallet needs more than seeds:

• the threshold and complete public-key or descriptor policy;
• the derivation paths and script type;
• enough private keys or hardware signers;
• transaction data for the UTXOs being spent;
• coordinator software that constructs a transaction each signer can independently inspect.

Backing up keys without the wallet policy can make recovery difficult. Address verification during setup matters because deposits sent to a mistakenly constructed policy may not be recoverable as intended.

Ethereum multisig: authorization lives in contract code

An Ethereum contract account has no single protocol-level private key. Its code decides which calls are authorized. In Safe’s basic model, the account stores a list of owners and a threshold. Owners sign the Safe transaction data; the contract verifies the required signatures before executing the requested call. A nonce helps distinguish and order Safe transactions and prevent replay within that account’s rules.

The contract can own ETH, tokens, NFTs, and administrative rights over other contracts. A valid threshold can therefore authorize much more than a transfer: an upgrade, token approval, role change, bridge action, or arbitrary contract call.

Extensions change the security boundary. Safe documents that enabled modules can execute transactions through a separate module path and may bypass the normal owner-signature check according to the module’s logic. A malicious module can take over a Safe. A guard can inspect and reject transactions, but a broken or malicious guard can block execution and create denial of service. Owners, thresholds, modules, guards, fallback handlers, and upgrade or deployment assumptions all belong in an audit of the actual account.

The visible label “3-of-5 Safe” is therefore not a complete security description.

Multisig does not eliminate compromise

Important failure modes include:

• Threshold compromise: an attacker obtains at least M independent keys.
• Common-mode compromise: signers share one seed, host, vendor, location, cloud account, or setup ceremony.
• Signer deception: enough honest people approve malicious or unreadable transaction data.
• Collusion or coercion: authorized participants cooperate against the intended owner or organization.
• Liveness failure: fewer than M signers remain available, capable, or willing.
• Policy loss: keys survive but descriptors, derivation paths, owner lists, or recovery instructions do not.
• Contract or extension failure: an Ethereum account, module, guard, fallback handler, or integration has a bug or unsafe privilege.
• Coordinator manipulation: software constructs a different recipient, fee, input set, contract call, or change output; signers fail to catch it.
• Governance mismatch: an off-chain vote says one thing while threshold signers execute another.

Multisig limits what one key can do only if the threshold path is truly required. A vendor-held mandatory cosigner may add theft resistance while also creating a service availability or censorship dependency. A recovery module may improve liveness while introducing another authorization path.

Defensive operating practices

There is no universal template, but a sound process usually includes:

• independently generated keys with no shared seed;
• separation across devices, operators, locations, and—where appropriate—implementations;
• a documented and tested recovery procedure;
• verified wallet descriptors, owner lists, threshold, network, and receive addresses before funding;
• human-readable review of every output or contract action by each signer;
• a defined process for replacing a key or owner before an emergency;
• monitoring of owner, threshold, module, guard, and role changes;
• limited test funds during setup, with independent confirmation rather than blind reliance on history.

A test transaction can catch some setup errors but is not proof that future destinations or contract calls are safe. Likewise, hardware wallets protect key material but cannot make a signer’s judgment correct.

Multisig is not automatically a DAO or self-custody

A DAO may use token voting, off-chain signaling, delegates, a multisig, timelocks, or several of these. A multisig by itself is only an authorization mechanism. It does not supply membership rules, transparent deliberation, legal status, or assurance that signers follow a vote.

It is self-custodial only to the extent that the user or intended group controls enough authorization and recovery paths without an outside party’s unilateral power. A service can be one cosigner; whether that design is custodial or partly custodial depends on what the service can block, recover, or authorize.