A multisig replaces one key with a threshold, so no single device can move funds. That is the theft half of the problem. The other half is availability: the same threshold that stops a thief stops you when a signer is lost, a colleague leaves, or a device sits in a country you no longer visit. For a small team the design question is not how many signatures, but how many failures of each kind the wallet can survive.
The threshold is a trade, not a setting
An m-of-n wallet needs m signatures from n keys. Raising m hardens the wallet against a single compromised signer. It also raises the chance that ordinary life locks you out.
The arithmetic is simple and usually ignored. A 2-of-3 wallet survives one lost key and one compromised key. A 3-of-5 survives two of either, but now five devices or five people must be maintained, and every payment needs three of them awake. A 4-of-7 looks safer on paper and behaves worse in practice, because coordination cost grows faster than security does.
For a small team, 2-of-3 is the default to start from. A treasury with a formal payment process and more than one person able to authorise a transfer belongs at 3-of-5.
Where the signers live matters more than the count
Three keys held by three people in the same room, on devices bought in the same order from the same vendor, is a 1-of-1 with extra steps. Fire, burglary, a legal seizure of one office, or a single firmware flaw takes all three at once.
Diversity is the control. Different people, different cities, different device vendors, different firmware versions, and at least one signer that is not a browser extension. A software signer on a laptop that also browses is a hot key with a multisig label on it.
Write this down as a matrix: signer, person, device, location, backup, and who can reach it on a Sunday. The matrix usually reveals that two signers share a flat.
The failure that actually happens is process
Most multisig losses in practice come from procedure, not cryptography. The initiator builds a transaction, the other signers approve it because the initiator is trusted, and the destination was wrong or the payload was not what the label said.
Four habits close most of it. Read the destination and amount on the signing device, not in the coordination app. Confirm the first and last characters of the address out of band, by voice, for anything above a set limit. Require the initiator to state the purpose in the transaction memo. And name a deputy for every signer, so a holiday does not freeze the wallet.
Test a recovery before funding
Build the wallet, then break it on purpose. Remove one signer, restore it from its backup, and confirm the wallet still spends. Better, run a full drill: rebuild the wallet from the backups alone on fresh hardware, with the original devices switched off.
Do this while the balance is small. A recovery you have never performed is a plan, and plans fail at the moment they are needed.
Availability has a clock you do not control. Staked ETH is the clearest example: the exit queue held 850,000 ETH in October 2026, about 14.8 days, per this board’s data pack, and a solo validator needs 32 ETH to exist at all. A treasury asset with a redemption window behaves the same way. If a multisig lockout lands inside that window, the delay compounds.
| Configuration | Key losses tolerated | Compromises tolerated | Typical use |
|---|---|---|---|
| 1-of-1 hardware | None | None | Personal savings |
| 2-of-2 | None | None | Partnership with no slack |
| 2-of-3 | One | One | Small team default |
| 3-of-5 | Two | Two | Treasury with a payment process |
| 4-of-7 | Three | Three | Larger organisation with dedicated ops |
What to do next
Choose 2-of-3 unless you can name the person who will run a 3-of-5 process every week. Then place the signers so no single event removes two of them, and record the placements somewhere the team can find them without the keys.
Run the recovery drill before the first real deposit, and repeat it when a signer leaves. Staff turnover is the most common way a working multisig becomes an unusable one.
Finally, decide what each wallet is for. A multisig holding trading inventory and a multisig holding reserves should not share signers, because the first needs speed and the second needs deliberation. The hot wallet sizing question sets that boundary, and how a custodian proves reserves covers the part a multisig cannot answer on its own.
0 comments
No comments yet — ask a question and we will answer it here.