Multisig failure modes and how SSP mitigates them

This is the closing article of Multisig Deep Dive. Over six prior pieces we built the picture: what multisig is, which threshold to pick, the BIP48 wiring, Schnorr aggregation, the social-recovery comparison, and the single-signer UX that ties them all together for actual humans. The abstraction works well in normal conditions. This article is about the abnormal conditions.

Every multisig wallet has predictable failure modes — places where the comfortable single-signer abstraction breaks and the underlying protocol becomes visible. Knowing which failures map to which recoveries is the difference between a stressful incident and a routine one. We'll walk five of them, in the order they're most likely to happen, with what SSP actually does (and what you have to do) in each case.

TL;DR

• Mode 1: One device lost, that device's seed intact. Trivial recovery — install SSP on a replacement device, restore from the seed, re-pair. No funds at risk.
• Mode 2: One device lost and its seed lost. Wallet is impaired but not lost: spend from your remaining device using your second seed as the sole recovery key, then move funds to a freshly-paired wallet.
• Mode 3: One device is compromised by malware/phishing. Funds are safe because the attacker has only one of two signatures. You contain the breach by re-pairing with a clean device; SSP can't be drained from one compromised device alone.
• Mode 4: SSP's coordination layer is unavailable. Inconvenient, not catastrophic. Coordination is metadata transport; the underlying multisig wallet is recoverable by any BIP48-compliant software using only the two seeds.
• Mode 5: Both devices and both seed papers are destroyed at the same time. This is the only catastrophic failure mode, and it's also the one your self-custody checklist is designed to make geographically implausible.

Reading this article once is enough. You don't need to memorise it. The point is that for every failure your future self might worry about, there's a specific, executable response.

Mode 1: Single device lost, seed intact

This is the most common failure: you replace your phone, or drop your laptop, or do a clean OS reinstall. The device that ran one half of your SSP wallet is gone, but the seed phrase for that half is still in its place (because you followed the first-1000 checklist and stored it physically separated).

The recovery is:

1. Install SSP on a replacement device (new phone, new laptop, etc.).
2. Restore that half from its seed phrase.
3. Re-pair with your surviving device. SSP walks you through showing each device to the other again — the multisig coordination layer detects the same xpub on the new device and accepts it.
4. Continue using the wallet normally. The on-chain wallet identity is unchanged — same address, same balance, same history.

At no point are funds at risk during this flow. The seed phrase is meant to do exactly this: reconstitute one signing half from scratch. The reason SSP's onboarding is so insistent about backing up both seeds separately is that this is the recovery you're paying for.

Time cost: ~20 minutes if you have your seed paper in hand.

Mode 2: Single device and its seed lost

The harder version of mode 1: you lost a device and its seed paper at the same time. House fire, flood, theft of a single physical location, etc. Now you can't reconstitute that signing half from its own seed.

This is precisely the case where the 2-of-2 vs 2-of-3 decision shows its consequences. Under 2-of-2 — the SSP default — you have exactly one signing half left (the surviving device, with its own seed). Under 2-of-3 you'd have two of three keys and could spend without urgency; under 2-of-2 you cannot spend at all from this wallet, because the chain still requires both original signatures.

The recovery is:

1. Don't panic. The funds are safe — no attacker can spend them either, because they're under a 2-of-2 rule.
2. Verify your surviving device's seed is still backed up and accessible. This is suddenly your only fallback.
3. Set up a new SSP wallet on a fresh device pair (both your remaining device and a new device, each with new seeds).
4. Send the funds from the old wallet — wait, you can't. The 2-of-2 is broken.

Hmm. Step 4 reveals the honest truth about 2-of-2: in this specific failure mode, the funds are frozen. Not stolen. Not lost in the cryptographic sense. They're still at the on-chain address. But you can't move them, because the wallet enforces the 2-of-2 spending rule and you only have one half.

What you can do is re-create the wallet. Specifically: the surviving device still has its seed, you set up a brand-new device with a brand-new seed, you pair them as a new 2-of-2 wallet, and you spend from the old wallet to the new one by — and this is the key — combining the surviving original seed with the lost one recovered from somewhere else. If you have no other copy of the lost seed, the funds genuinely are stranded.

This is why the checklist's "two seeds, two physically separated locations, one of which is fire-rated" instruction is not paranoia. It is the answer to mode 2. If you only ever followed one piece of self-custody advice, follow seed phrase best practices for both of your SSP seeds. The rest of the wallet is well-engineered around the assumption that you did.

Mode 3: One device compromised

Imagine the more sinister scenario: your laptop is compromised by malware. The browser extension is still installed; the attacker has potentially observed your usage, may have full access to that device's signing key. What do they get?

Under a single-sig hot wallet — they get everything. The wallet is drained as soon as you next try to spend (or sooner, if the malware can initiate spends silently).

Under a 2-of-2 SSP wallet, they get nothing yet. They have one signature; the chain requires two. They cannot spend by themselves. The most they can do is fabricate a transaction proposal, push it to your phone via SSP's coordination layer, and hope you approve it on the phone without noticing.

This is where the single-signer UX discussion intersects security. The phone confirmation step is not a UX nicety; it is the only thing standing between a compromised laptop and a drained wallet. Read the transaction details on the phone. Match the recipient address. Match the amount. If anything looks wrong, don't approve it, regardless of how the prompt got there.

The containment response when you discover a compromise:

1. From your uncompromised device, send your funds to a brand-new SSP wallet (set up on two fresh devices, two fresh seeds). This is a single multisig transaction — both old devices must sign once, but immediately afterward you stop using the compromised one.
2. Wipe the compromised device. Factory reset; don't just uninstall the extension.
3. Treat the compromised seed as burned. Never re-import that specific seed; consider it leaked.

This containment is much faster and lower-stakes than the equivalent for a single-sig wallet, where you have to outrun the attacker. With multisig, you have time to act calmly because the attacker is locked out without the second signature. The seven failure modes piece from the previous series put this in dollar terms: most retail self-custody losses are single-key compromises, and 2-of-2 is the answer for the most common scenario.

Mode 4: SSP's coordination layer is unavailable

What happens if SSP, the company, has an outage? Or the coordination service that ferries PSBTs between your browser extension and your phone is down? Or you've decided you don't want to use SSP anymore at all?

The honest answer is that the coordination layer is metadata transport — convenient but not load-bearing. The actual wallet lives on chain, derived from your two BIP48 seeds. If SSP's signing server is down for an hour, you can wait an hour. If it's down for a week, that's annoying. If it's down forever, you can still recover the wallet by loading both seeds into any other BIP48-compatible wallet — Sparrow on Bitcoin, Electrum, the Bitcoin Core descriptor wallets, equivalent multisig clients on EVM chains, etc.

The recovery path here is:

1. Confirm the issue is on SSP's side (vs. your local devices) — the SSP status page or its community channels will say.
2. If you need to spend urgently, install a third-party wallet that supports the BIP48 multisig path. Sparrow is the most user-friendly Bitcoin choice; for EVM, you'd use Safe or a similar multisig client.
3. Load both seeds into that third-party wallet. The same address appears, the same balance, the same spending capability.
4. Sign and broadcast normally from there.

The reason you can do this — the reason this isn't a marketing claim but a verifiable property — is that SSP uses standards. The BIP48 article and What is 2-of-2 multisig walk through this. SSP is the convenient front-end on top of a wallet that exists independently of SSP.

In practice, SSP's signing infrastructure is built to high availability — but the guarantee that the wallet is recoverable without SSP is what makes the convenience matter rather than scare you.

Mode 5: Both devices and both seeds destroyed simultaneously

This is the catastrophic failure mode and it deserves to be stated plainly: if you lose both signing halves and both seed backups in the same event, the wallet is permanently inaccessible. The funds are still on chain, at the multisig address, but no one — including SSP — can move them. This is the cost of true self-custody; the same property that means SSP can't freeze your funds means it can't unfreeze them either.

The defense is geographical and structural:

• The two seeds live in physically separated locations. The first-1000 checklist names "different room, different building if practical."
• At least one of the seeds lives in a fire-rated container.
• If your stack is large enough to warrant it, you eventually migrate to 2-of-3 — adding a third key (often kept with a lawyer, family member, or in a bank safety-deposit box) reduces the catastrophic-failure surface from "both physical locations destroyed" to "any two of three locations destroyed."

The honest framing is that this failure mode trades probability for severity. Single-key wallets fail far more often (mode 1 and mode 3 dominate the data) but with lower severity per incident. Multisig with geographical seed separation reduces failure frequency by an order of magnitude but raises severity-per-incident slightly. Most users come out ahead.

The Meet SSP Wallet introduction frames the product as a tool for sophisticated retail self-custody. The seriousness of mode 5 is part of why that framing is honest — the product is built for people who are willing to treat seed papers as load-bearing infrastructure, not as something you write down once and forget.

What this means for you

Closing takeaways:

1. Most failure modes have routine recoveries. Modes 1, 3, and 4 — by far the most common — have well-defined, low-stress recovery paths. The 2-of-2 model genuinely does what it promises: it absorbs single-point compromises and gives you time to respond.
2. The catastrophic case is geographical, not cryptographic. Mode 5 is what your seed phrase best practices are about. The wallet's cryptography is well-audited; the failure surface that remains is whether you stored the two seeds in physically distinct, durable places.
3. You now have the full picture. This series (article 1, article 2, article 3, article 4, article 5, article 6, this one) has covered what multisig is, when to choose which threshold, how it's wired together, what aggregation changes, how recovery models differ, why the UX feels the way it does, and what each failure mode looks like operationally. The Self-Custody Fundamentals series that precedes it gave you the why; this series gave you the how. From here, the work is operational discipline: backup hygiene, periodic recovery rehearsals, and the patience to do mode 1 / 2 / 3 / 4 recoveries calmly when they happen.

The wallet is well-engineered. The remaining variable is you.