So far in this series we've covered what multisig is and which threshold to pick. Both articles described the behaviour of a multisig wallet — m of n keys sign, the chain checks the threshold, money moves. Neither said much about how the wallet is actually put together underneath. That's this article.
The short version: when SSP creates a wallet for you, it doesn't just generate two random keys and call it done. It generates them in a way that follows a documented standard called BIP48, so that the resulting wallet is interoperable, recoverable in software other than SSP, and predictable to inspect on chain. This is the article that explains what BIP48 is, why it exists, and why "this wallet uses BIP48" is one of the most boring-and-important sentences in multisig.
TL;DR
- A derivation path is the road from a single seed phrase to a specific key (and address) in a wallet. Standardised paths like BIP44 / BIP48 let different wallet software arrive at the same keys from the same seed.
- BIP48 is the spec specifically for multisig wallets. It says: here is the canonical derivation path for the
mkeys that make up a 2-of-3, 3-of-5, etc. wallet across the major output script types. - SSP uses BIP48. That means the two seeds your SSP wallet generated are usable from any other BIP48-compatible wallet (Sparrow, Electrum, Bitcoin Core's descriptors) — not just from SSP itself.
- BIP48 fixes a problem the earlier multisig spec (BIP45) had: it cleanly separates the keys for different script types (legacy, P2SH-wrapped SegWit, native SegWit, Taproot) so that one seed phrase can hold all of them without collision.
- You don't need to manually deal with derivation paths to use SSP. You should know they exist so that "wallet recovery" doesn't feel like magic — and so that you understand what your seed actually maps to.
A 30-second tour of derivation paths
Before BIP48 had any meaning, the underlying machinery had to exist. That machinery is BIP32: hierarchical deterministic (HD) wallets. The core idea is that one master key — derived from a seed phrase — can produce an infinite tree of child keys, deterministically. Walk a specific path through the tree and you always end up at the same child key. Walk a different path and you end up at a different one.
Paths look like this:
m / purpose' / coin_type' / account' / change / index
For example, the BIP44 path m / 44' / 0' / 0' / 0 / 0 reaches the first receive address of the first account of Bitcoin under BIP44 rules. Change the coin_type to 60' and you're in Ethereum's space; change the purpose to 84' and you're in BIP84 (native SegWit) space; and so on. The single-quote (') is hardened derivation — the child can't be inverted back to the parent. Each segment after the master is a 32-bit number, partitioned by convention.
This is the part that gets glossed over: the path is metadata, not a secret. Anyone who knows your path and your private key (or extended key) can derive the same addresses. The path tells the wallet where to look. The seed tells it what's there.
For a friendly refresher on what the seed itself is, the seed phrase best practices post is the prerequisite.
What BIP48 specifies
BIP48 lives at m / 48' / coin_type' / account' / script_type' / change / index. The interesting addition is script_type' — the second-to-last segment.
That segment encodes which kind of multisig output the path is for:
0'→ P2SH (legacy multisig)1'→ P2SH-wrapped SegWit (P2WSH-in-P2SH)2'→ native SegWit (P2WSH)3'→ Taproot-equivalent multisig (per BIP48 amendments)
This matters because in practice the same m-of-n cosigner set produces different on-chain addresses depending on which output script is used. Without BIP48, a wallet might silently use one type, the recovery software might assume another, and the result is two wallets that look like they should derive the same coins — but don't, because they're computing different addresses.
BIP48 also fixes the purpose' segment at 48', so multisig paths can't collide with single-sig BIP44/BIP49/BIP84 paths. One seed can hold a single-sig wallet at BIP84 and a 2-of-2 multisig wallet at BIP48, with no interference. Each lives in its own subtree.
Beyond the path itself, BIP48 specifies how the cosigner public keys ("xpubs") should be ordered when constructing the multisig output. The canonical rule is lexicographic ordering of the public keys before they go into the redeem script. That removes ambiguity — every BIP48-compliant wallet building from the same xpubs computes the same address. Without that rule, two wallets could combine the same keys in different orders and end up at different addresses with the same redeem rule.
If you want to read the spec verbatim, it lives in the Bitcoin BIPs repo (bips/bip-0048.mediawiki).
How SSP uses BIP48 in practice
When you set up an SSP wallet, two seed phrases are generated — one on the browser extension, one on the SSP Key mobile app. Each seed phrase corresponds to a master private key. From each master, SSP derives the BIP48 path for the relevant chain (Bitcoin, Ethereum, Flux, and the rest of the SSP-supported set) at script_type' = 2' (native SegWit on Bitcoin; equivalent canonical forms on the other chains where applicable).
The xpubs from both signers are then exchanged. Each side now has the same set of two xpubs, lexicographically ordered per BIP48. From that pair, each side independently computes the same address. The two halves never share a private key — only public keys move between devices.
When you receive money, the address you're shown is the BIP48-derived address computed from both xpubs. When you spend, each device signs the same transaction under its own private key. The redeem script on chain references both public keys; the network checks both signatures. That's the whole protocol.
The reason this matters in a recovery scenario: if SSP, as a product, vanished tomorrow, you would still hold two BIP48-compliant seed phrases. Loading both into Sparrow (or any other multisig-capable wallet that supports the BIP48 paths SSP uses) reconstructs the same wallet, at the same addresses, with full spending ability. The wallet doesn't live inside SSP — it lives on chain, and the seeds plus the BIP48 spec are enough to reach it from anywhere.
That property is a big part of why the self-custody-without-cold-storage piece treats a 2-of-2 SSP wallet as a serious wallet rather than a custodial-flavoured curiosity. It is recoverable from open standards.
Why BIP48 over BIP45 (and not BIP44)
The earlier multisig spec was BIP45. It was an honest first try: m / 45' / cosigner_index' / change / index, with cosigner_index' encoding which co-signer you are in the wallet. In hindsight it had two problems.
First, cosigner_index' baked an ordering into the path itself. That meant the order in which signers were added affected the derivation, which made joint setup brittle — get the order wrong and you derive different addresses than your co-signer. BIP48 solves this by removing cosigner index from the path entirely and letting lexicographic ordering of public keys handle it.
Second, BIP45 didn't separate by script type. The same path would be reused whether the wallet used legacy P2SH multisig or SegWit-wrapped multisig. That created the same address-collision-not-actually-the-same-coins problem described above.
BIP44, the more general HD spec, never claimed to cover multisig. Trying to overload BIP44 with multisig paths created its own conflicts. BIP48 was the explicit fix: a dedicated purpose number, an explicit script-type slot, and a deterministic key ordering. Today most modern multisig wallets converge on it; it's the de-facto standard.
For the deeper history on how this connects to the next chapter of multisig — Schnorr aggregation, where multiple signatures compress to one — the next article in this series, Schnorr signatures and multisig aggregation, picks up the thread.
What this means for interoperability
The cleanest test of "is this multisig wallet actually self-custodial?" is: can I recover it without the wallet's software? If the answer is yes — using documented seeds, a documented derivation path, and standard tools — the wallet is genuinely yours. If the answer is no, the wallet has hidden custodial elements.
SSP's BIP48 conformance is what lets us answer yes. The seed phrases are BIP39 (standard mnemonic), the derivation is BIP48, the address construction is BIP48-canonical. Any wallet that speaks the same standards can reconstruct the wallet.
That's why the Meet SSP Wallet introduction frames SSP as "self-custody with 2-of-2 multisig" rather than as a managed service. The standards underneath are the reason that framing is honest.
What this means for you
Three takeaways:
- You don't have to memorise paths to use SSP. The number
m/48'/0'/0'/2'/0/0is not something a normal user should ever type. But knowing it exists is what makes "I can recover this wallet without SSP" a real claim instead of a marketing one. - Your two seeds are interoperable. If you ever need to recover into a third-party multisig wallet, BIP48 plus your two BIP39 seeds plus the chain's
coin_typeis the recipe. The self-custody checklist names this as the rehearsal step for a reason. - A multisig wallet that doesn't use BIP48 (or similar) is worth questioning. If a product can't tell you exactly how addresses are derived from your keys, that's not self-custody — it's custody with extra steps. Standards conformance is what makes the "your keys, your coins" claim verifiable.
