MPC Wallets vs Multisig
Both MPC wallets and multisig wallets promise the same headline: no single point of compromise. Both deliver on it. But they get there by different routes, and the routes have different consequences for what happens when things go wrong — which is the only time a security model actually matters.
This article is the technical head-to-head. If you want the broader survey of self-custody choices first, comparing self-custody options covers the whole field including hardware wallets and plain seed phrases.
Two different answers to the same problem
The problem is stated the same way in both cases: one secret controlling everything is unacceptable, so spread the authority.
MPC splits the key. There is conceptually one private key, but it is never assembled anywhere. Instead, shares of it live in different places, and a cryptographic protocol lets those shares cooperate to produce a signature without any party learning the whole key.
Multisig requires multiple keys. There are genuinely several independent private keys. The address encodes a rule — this many of these keys must sign — and the blockchain enforces the rule when validating the transaction.
The distinction sounds academic. It is not. One is a fact about cryptography; the other is a fact about the blockchain. What the chain knows determines what happens when a piece of the system fails.
How MPC actually works
MPC — multi-party computation, in this context usually threshold signature schemes — lets several parties jointly compute a signature over a message while each holds only a share of the signing key. NIST maintains a threshold cryptography project if you want the formal treatment.
The output is a single, ordinary signature. On-chain, an MPC wallet's transaction is indistinguishable from a transaction signed by one person with one key. That has real advantages: it works on every chain, it costs the same as a single-signature transaction, and it reveals nothing about your security arrangement to anyone watching the chain.
The consequence of that same property is where care is needed. Because the chain sees a normal signature, the chain also enforces nothing about your policy. How many shares exist, who holds them, and how many must cooperate are facts about the software and the servers, not about the ledger. Change the software and you change the policy.
The second thing to look at is share custody. Many consumer MPC wallets hold one share on the provider's infrastructure. That is often what makes the smooth recovery experience possible — and it also means the provider's continued existence and cooperation are load-bearing parts of your setup. Some designs mitigate this well, with exportable shares or independent backup paths. The question is not whether MPC can be done well; it is whether the specific product you are considering has done it in a way you can verify.
How multisig actually works
In multisig, the policy is part of the address. On Bitcoin and other UTXO chains, the address is derived from a script that names the public keys and the threshold; a spend that does not carry enough valid signatures is simply invalid, and every node on the network rejects it. On chains with smart contracts, the equivalent is an account whose code will not act without the required approvals.
Nobody has to be trusted to apply the rule, because applying the rule is what the network does. If every piece of wallet software involved vanished tomorrow, the rule would still hold, and anyone with the keys and any compatible tool could still spend.
The costs are real too. You are managing several keys instead of one, backups get more complicated, and the transaction is bigger — on Bitcoin, more signatures means more bytes and a slightly higher fee. Your policy is also visible on-chain, which is a privacy consideration: an observer can see that an address is 2-of-3 even if they cannot see who holds what.
What is multisig, and why it matters covers the model in more depth.
Where SSP sits, precisely
SSP is a 2-of-2 multisig, but honesty requires a detail here, because the implementation is not identical on every chain.
On Bitcoin and the other UTXO chains, it is native script-level multisig via BIP-48. Two keys, one script, enforced by consensus.
On Ethereum and other EVM chains, there is no equivalent native script, so SSP uses a smart account that verifies an aggregated Schnorr signature produced from both keys. Your two devices run a MuSig2-style protocol, and the chain sees one signature — mechanically, that is closer in shape to MPC than to a Bitcoin multisig script.
The distinction that matters is not "aggregated or not". It is these two facts, which hold on every chain SSP supports:
- Both keys are generated on your devices and held only by you. SSP holds no share, no key, and no partial secret. There is no share on our servers to lose, subpoena, or hold hostage.
- The requirement is on-chain. On EVM the smart account's code will not authorize a transaction without a signature that only both of your keys can produce. That code is deployed, public, and audited — it is not a policy our software chooses to apply.
On Solana it is an on-chain program with no creator and no admin key, where the vault address is itself a fingerprint of the member set and threshold. Different mechanism, same guarantee.
If the cryptography of aggregation interests you, Schnorr signatures and multisig aggregation covers how one signature can require two keys.
Failure modes side by side
Security models are best compared by asking what breaks.
One device is compromised. Both models survive. The attacker has one share or one key and cannot sign alone.
The provider disappears. Multisig survives — the keys and the on-chain rule are all that is needed. MPC survives only if you can obtain and use your shares without the provider's software, which depends entirely on the design.
The provider is compelled to act. If a provider holds a share, that share can potentially be produced under legal compulsion, and depending on the scheme that may be enough to move funds with one other share. If a provider holds nothing — as with SSP, where both keys are yours — there is nothing to compel.
You lose one key or share. This depends on the threshold, not on the technology. A 2-of-3 setup of either kind tolerates one loss; a 2-of-2 setup of either kind does not. What happens if one of your keys is compromised walks through the SSP case specifically.
The wallet software lies to you about what you are signing. Neither model helps here, and this is worth stating plainly. Splitting authority protects against a stolen key; it does not protect against approving the wrong transaction. That is why the interesting question for both models is what your devices verify independently before they sign — decoding the raw transaction rather than trusting a server's description of it.
Where each one wins
MPC wins on chains without good multisig primitives, on transaction size and fees, on privacy of the arrangement, and often on user experience — particularly recovery, where a well-designed MPC product can be dramatically friendlier than juggling multiple seed backups.
Multisig wins on verifiability. The rule is in the ledger. You do not have to trust a description of the security model; you can read the address or the contract and see the policy. It also wins on independence: a multisig setup with keys you hold does not have a company in its trust model at all.
There is no contradiction in preferring different answers for different purposes. A small everyday balance in a well-built MPC wallet and a long-term holding in a multisig with keys stored separately is a perfectly coherent arrangement.
What to ask before you commit
Whichever way you lean, these four questions separate a strong implementation from a weak one.
- Who holds each key or share, and can I obtain all of them? If the honest answer includes "the provider, and no", you have chosen a model with a counterparty.
- What happens if the provider disappears tomorrow? There should be a documented path that does not involve them. Test it before you need it.
- Where does the policy live? In a script or contract on-chain, or in software? Both can be fine, but only one of them survives the software changing.
- What does each device verify before signing? A second key adds nothing if both devices blindly sign whatever a server sends. Multisig failure modes and how SSP mitigates them goes through this and the other ways a multi-key setup can be undermined in practice.
If you want the model SSP is built on explained from the beginning, start with what is 2-of-2 multisig. And if the concern that brought you here is losing a key rather than losing control of one, social recovery vs multisig covers the other family of answers.
