2-of-2 vs 2-of-3 vs m-of-n multisig: picking the right threshold

In the previous article we covered what multisig is: a spend rule where m of n keys have to sign before money moves. SSP defaults you into a 2-of-2 — two devices, both required, no quorum to discuss. That default is right for most solo users sitting between "first thousand dollars" and "this is real money to me." It is not right for everyone.

This article is the picker. Three configurations cover the overwhelming majority of real-world multisig setups: 2-of-2, 2-of-3, and 3-of-5 (or higher). Each is genuinely better than the others under specific conditions, and each is genuinely worse under others. By the end of this article you should be able to answer: which m-of-n matches what I'm actually trying to protect?

TL;DR

• 2-of-2 is the personal-stack default. Best for one user with two devices, low coordination overhead, modest amounts. SSP's whole product is built around this.
• 2-of-3 is the move when one user wants to plan for losing a key — losing a phone, losing a backup, family inheritance scenarios. The "redundancy" version of solo multisig.
• 3-of-5 or higher is the answer when more than one person needs to sign, when geography matters, or when the funds belong to a company / DAO / family office rather than to a person.
• Bumping m higher doesn't just add security — it adds liveness risk (more keys you need to be available) and coordination cost. The right m-of-n minimizes the sum of both.
• Going higher than 2-of-3 for a single user is usually a mistake. The marginal protection is small; the operational pain is large.

The three questions that decide the m-of-n

Skip the formal threat modeling for a second. In practice, three questions decide which configuration fits:

1. Who needs to sign? One person? Two people? A team that rotates? An organization where signers come and go?
2. What's the dominant failure you're protecting against — loss or theft? Multisig handles both, but the right ratio of m to n weights one over the other. Higher n means more redundancy against loss; higher m (relative to n) means more resistance to theft.
3. What's the operational cost of losing one signer? If the answer is "I can't get to my phone for a day" the cost is mild. If the answer is "the CFO is on a flight when payroll has to clear" the cost is enormous.

These three lines map fairly cleanly onto the three configurations below.

2-of-2: the solo-with-redundancy default

Setup: Two keys exist. Both must sign. SSP's default — one key on your browser extension, one key on the SSP Key mobile app.

Best for: One person, one wallet, two devices that don't share an attack surface (a Mac laptop and an iPhone, an Android and a Windows machine, etc.). The protection comes from the device separation: malware on the laptop can't reach into the phone, and vice versa.

Strengths:

• Lowest coordination cost of any multisig. Both devices are yours, both are usually in your pocket or on your desk.
• Massively raises the bar for theft. An attacker who has fully compromised one of your two devices still cannot move money. They have to compromise the other — almost always a different OS, different attack chain — to win.
• Forces you to keep two seeds, in two places, with two distinct backups. That's a much better default posture than the typical single-seed-paper-in-a-drawer setup.

Weaknesses:

• Both keys are load-bearing. Lose either device and its seed and the wallet is dead. That's why the Self-Custody Fundamentals checklist puts so much weight on backing up both seeds separately. It's not optional in 2-of-2.
• No quorum to "outvote" a bad signer. If both signers are you, this isn't a problem; if you ever shared a key with another person in a 2-of-2, both of you would have hostage power.

This is the configuration the existing What is 2-of-2 multisig? post unpacks in detail. Read it after this for the SSP-specific mechanics; this article is just calibrating when it's the right choice.

2-of-3: when one user wants to plan for loss

Setup: Three keys exist. Any two must sign. Common holder layout for a solo user: one on a "hot" device for daily use, one on a hardware wallet kept at home, one on a recovery device kept somewhere else (a safety-deposit box, a parent's house, a bank vault — somewhere geographically separate).

Best for: One person, but one who has crossed into "if any single object burns down, I want to still be able to recover." Self-custody users between ~$10k and ~$100k often migrate here.

Strengths:

• Survives the loss (or destruction) of any one key. House fire eats your hardware wallet? You still have laptop + remote device — enough for the 2-of-3 quorum.
• Theft of any one key is still not enough — the attacker would have to compromise two of three. Geographic separation makes the third key much harder to reach.
• Provides a clean inheritance pathway. You can leave the third key with a family member or lawyer, in a way that they can't act unilaterally (they only have one of three) but can combine with one of your remaining keys to recover the wallet in a defined scenario.

Weaknesses:

• More keys to provision, back up, test. Each one needs a unique seed and a unique storage location. Seed phrase best practices is necessary reading before doing this.
• Slightly higher attack surface — three keys means three places an attacker can try to compromise, even though they need to compromise two of them.
• More complex recovery rehearsal. You should periodically test that you can actually combine two of the three keys to spend. That's an operational chore.

A useful mental shorthand: 2-of-2 protects you against attack at the cost of being brittle to loss. 2-of-3 protects you against both, at the cost of more keys to manage.

3-of-5 (and higher): when teams and treasuries enter the picture

Setup: Five keys exist, any three must sign. Used by companies, partnerships, DAOs, family offices. The five keys are usually distributed across people, roles, and geographies.

Best for: Funds that don't belong to a single human. Anywhere two or more people legitimately need to authorize spending, and where the "single signer is on vacation" scenario shouldn't be allowed to freeze operations.

Strengths:

• No single person controls the money. Two compromised or rogue signers still can't move funds.
• Operational continuity. Any one person can be unavailable (sick, traveling, fired) and the other four still have a quorum.
• Naturally supports separation of duties — a controller, a CFO, a CEO, an external auditor, and a hot signer can all be distinct roles. The threshold can be tuned to match the firm's governance.

Weaknesses:

• Coordination overhead is real. Getting three of five humans to actually sign a transaction in a defined window is genuinely harder than getting one or two devices to sign in your own pocket.
• Each new signer adds attack surface. Five keys means five separate devices, five separate backup procedures, five separate succession plans for when a signer leaves.
• Custom workflows. Most consumer wallets don't ship 3-of-5 by default; you usually move to specialist tooling (Safe, Casa, custom multisig setups) once you cross this threshold. Wave 1 SSP is built around 2-of-2 and is not the right venue for this scale.

A common variant — 2-of-3 with social signers — sits between solo 2-of-3 and corporate 3-of-5. You hold two keys; a trusted family member or lawyer holds the third. They can't spend alone (one key isn't enough), but they can help you recover if you lose one of yours.

What size does — and doesn't — fix

Going from 2-of-2 to 2-of-3 to 3-of-5 isn't a linear "more security" slider. Some properties improve; others get worse.

Going higher in n helps with:

• Resilience to loss (more keys means more redundancy).
• Inheritance planning.
• Operational availability with multiple humans.

Going higher in n hurts:

• The amount of seed-phrase hygiene work you have to keep doing forever.
• The number of places an attacker has to fail to attack, but also the number of places they have to succeed — which is sometimes worse if the keys aren't truly independent.

Going higher in m (the threshold) helps with:

• Resistance to theft (an attacker needs more keys).
• Trust minimization between signers (any subset under m can't act).

Going higher in m hurts:

• Liveness. If m keys must be available to spend, then having n - m + 1 keys go offline freezes the wallet. A 4-of-5 that requires four humans to coordinate is famously brittle.

The art is choosing m and n so the availability cost of needing m signers matches the security benefit of needing m signers. For most solo users, 2-of-2 lands at the sweet spot. For most teams, 3-of-5. The middle case — 2-of-3 for the solo user planning for loss — is the most under-used configuration in retail self-custody.

What this means for you

Three takeaways:

1. Default to 2-of-2 for solo use under five figures. It's what SSP is built for, what Meet SSP Wallet explains, and the lowest-friction setup that materially raises your security posture.
2. Move to 2-of-3 once the cost of losing one key exceeds the cost of managing three. Roughly: when you've crossed into "this is real wealth," when you have a clear inheritance question, or when you've already lived through one close-call recovery scare.
3. Don't reach for 3-of-5+ unless you're protecting funds that belong to more than one person. It's the right answer for orgs and not really for individuals — even high-net-worth ones tend to use 2-of-3 with a custodial helper rather than full 3-of-5.

The next article in this series, BIP48 explained: the derivation path behind SSP, gets into how a 2-of-2 (or 2-of-3) wallet is actually constructed on-chain — the standard that lets multiple keys cooperate and the reason most modern multisig wallets are interoperable.