Single-signer multisig: how SSP makes two devices feel like one wallet

If you've been with this series since what multisig is, you know the protocol: more than one private key must sign before money moves. You've seen the m-of-n picker, the BIP48 wiring, the Schnorr aggregation horizon, and the social-recovery comparison. All of that is the machinery. This article is about the experience.

The honest historical critique of multisig is that it has been hostile to use. Multiple wallets, manual PSBT shuffling, coordinator software, signing parties — the protocol was sound, but the UX was a punishment. Single-signer multisig is the product idea that fixes this: a wallet that uses a full multisig spending rule on chain, but feels — to the person using it — like one wallet with one button. SSP is built around this idea.

TL;DR

• "Single-signer" doesn't mean one key. It means the protocol still has m of n keys, but the signing UX is collapsed into a single flow. The user signs in one place; the wallet handles the device-to-device coordination.
• SSP's specific shape: one browser extension, one mobile app (SSP Key), one wallet identity. You click Send, you confirm on the phone, the transaction broadcasts. Two signatures happen; you experience one.
• The win is that the threshold benefit (theft resistance, no single-point-of-failure) is preserved while the coordination cost drops close to single-sig UX.
• The cost is that this only works as long as both your devices are reachable. The moment the UX has to expose the multi-ness — recovery, device replacement, restoring on a third party — the abstraction breaks, by design.
• This pattern is the closest thing to a "no compromise" answer for solo self-custody at retail scale. It's the SSP bet, and increasingly the bet of every modern multisig product (Coinbase Wallet, Phantom's evolving custody story, Safe's smart-account flow on Ethereum).

The single-signer ideal: what users actually want

If you ask a self-custody user what they want, you get answers that contradict each other:

• "I want my coins safe." — Implies multisig, hardware, redundancy.
• "I want to sign a transaction in five seconds." — Implies a single device, one tap.
• "I want to recover if I lose something." — Implies seed backups, redundancy.
• "I never want to write down a seed again." — Implies platform-managed key custody.
• "I want it to be cheap." — Implies a minimal on-chain footprint.

These goals don't all line up. The history of self-custody wallet design is the history of which goals to honour and which to politely refuse. Hardware wallets honour safety and recovery at the cost of UX. Smart-contract wallets honour UX and recovery at the cost of cross-chain reach. Pure hot wallets honour UX and cheapness at the cost of safety.

Single-signer multisig is an attempt to honour all five — partially — by separating protocol semantics from interface semantics. The wallet still does the full multisig dance on chain; the user just doesn't have to participate in that dance more than once per transaction.

How SSP delivers it

SSP's specific implementation, plain English:

1. At setup, you install the browser extension and the mobile app (SSP Key). Each generates its own seed, which you back up separately (this is the first-1000 checklist step). The two devices exchange public keys; from that point on, they share a wallet identity at the protocol level.
2. At everyday signing, you click Send in the browser extension, review the transaction, and approve. The extension constructs a partially-signed transaction and pushes a notification to your phone. The mobile app shows the transaction details, you tap approve, and the app produces the second signature. The extension combines both signatures and broadcasts. Total elapsed time: about 8 seconds when both devices are in front of you.
3. At receive time, the address shown is the BIP48-derived multisig address from both xpubs. You scan or copy it; the sender sees nothing unusual. From their side it looks like any other crypto address.
4. At settlement, the wallet shows you balances, history, fees, and so on, identically to a single-sig wallet. There's no separate "multisig screen." The protocol shape is invisible during normal use.

The key design choice is that the second signature is the only multi-ness the user ever has to think about. Setup is two devices, signing is one extra tap, and that's the entire surface area of the multisig protocol from a user perspective.

A small but important detail: the SSP browser extension and SSP Key are not co-located. They're on different OSes, different hardware, different attack surfaces. This is what makes the two-signature setup a real theft barrier and not just a UX speed bump. (We unpack this in the seven failure modes piece and in What is 2-of-2 multisig.)

What the user never sees

A lot of work goes into keeping the user from ever having to handle multisig plumbing. Specifically:

• PSBT (Partially Signed Bitcoin Transactions) are the chunky data structures that move between the cosigning devices. In a traditional multisig setup you copy and paste these manually. SSP serializes and transmits them over its own coordination channel; the user sees a notification, not a base64 string.
• Cosigner xpub exchange is a one-time setup event. In traditional multisig, you import xpubs from each cosigner explicitly. SSP wraps this in the pairing flow at setup; you confirm a QR code or six-digit code and never touch the underlying material.
• Fee estimation, change handling, and address rotation are handled by the wallet exactly the way single-sig wallets do, despite the wallet itself being multisig under the hood.
• The redeem script — the BIP48-canonical script describing the multisig rule — is constructed by the wallet automatically. Users don't see it, don't approve it line by line, don't need to know it exists. (They can see it on a block explorer if they look, which is the cleanest "show your work" property of multisig wallets.)

All of that abstraction is necessary work, but it's also the risk — every time the protocol is hidden from the user, the wallet takes on responsibility for getting the hidden part right. SSP's audit work (Halborn) is largely about exactly these invisible code paths.

When it stops feeling single-signer

The abstraction isn't perfect, and it's important to know where it breaks. Single-signer UX holds while both devices are available. The cracks show up when one is not:

• Device replacement. When you swap your phone, the new device has to be re-paired. That's a one-time multisig coordination step that genuinely is visible — the wallet walks you through showing both devices each other again.
• Seed recovery. If a device is destroyed, you recover it from its seed phrase onto a new device, then re-pair. The fact that you have two seeds (one per device) becomes visible at this moment in a way it wasn't during normal use.
• Cross-software recovery. If you ever load your two SSP seeds into a third-party multisig wallet (Sparrow, Electrum, etc.), all the multisig plumbing becomes visible — that's a feature, not a bug, because it's what proves your wallet is interoperable, but it's not the SSP UX.
• Spending when one device is offline. The wallet can't co-sign without both devices; that's the protocol. You'll see a "waiting on second signature" state until the other device comes online.

The first three are infrequent enough that they don't really degrade the average UX. The fourth is the most common friction point — and the correct friction point. If the wallet let you spend without the second device, it wouldn't be a 2-of-2 wallet anymore. That friction is the security; you can't engineer it away without removing the property you were paying for.

Designing around single-signer UX

Three design principles SSP — and other modern multisig products — follow to keep this abstraction tight:

1. The two cosigners must live in different threat surfaces. A wallet that puts both cosign keys on the same OS isn't really providing the security benefit; it just spreads a single attack surface across two locks. SSP's split between browser extension and mobile app enforces this naturally.
2. The coordination channel must be unforgeable. The PSBT a browser extension sends to the mobile app must be cryptographically tied to the right wallet and the right transaction; otherwise the abstraction becomes an attack surface of its own. SSP signs and validates this material at the protocol layer.
3. The user's contract must be honest about what's hidden. Wallets that say "totally trustless single-signer experience" without explaining what happens at recovery are setting users up for an unpleasant surprise. SSP's onboarding explicitly walks through both seeds, both backups, and both recovery scenarios — the abstraction is hidden during use but exposed during onboarding so it doesn't ambush you later.

Account-abstraction wallets on Ethereum get a fourth tool: the smart-contract layer. With ERC-4337, a wallet can absorb gas fees, batch transactions, and present an even more "single-signer-like" UX and implement multisig under the hood. SSP doesn't have that layer on Bitcoin (no smart contracts), so the abstraction relies more on UX engineering than on chain-side absorption. Both paths are valid; the Ethereum path is more flexible at the cost of being chain-specific, the SSP path is more portable at the cost of more UI work.

What this means for you

Three takeaways:

1. The "feels like one wallet" experience is the headline feature, not multisig itself. If your friend asks "is SSP a multisig wallet," the technically-true answer is yes, but the useful answer is "it's a 2-device wallet where one tap on the phone confirms a spend." That captures what people actually feel.
2. The friction you do see is doing real work. Every time SSP asks you to confirm on the phone, it's enforcing the protocol that stops a compromised laptop from emptying your funds. That friction is the main reason you're using a 2-of-2 wallet rather than a hot wallet in the first place.
3. Treat the abstraction as a contract, not magic. The final article in this series, Multisig failure modes and how SSP mitigates them, walks through what happens when each piece of the abstraction breaks — device loss, key compromise, signing-server outage. Read it once. The abstraction is well-engineered, but understanding the failure modes is what makes you the kind of self-custody user this whole series is for.