In the previous article we walked through how SSP actually constructs a multisig wallet on chain: BIP48 paths, two xpubs in lexicographic order, a redeem script that the chain checks against. That entire mechanism is built on top of a particular signature scheme — ECDSA on the secp256k1 curve, the same scheme Bitcoin shipped with in 2009 and that most chains inherited.
This article is about the other signature scheme — Schnorr — and what changes when you build multisig on top of it. The headline change is that Schnorr supports aggregation: under the right protocol, n signatures from n cosigners can be combined into a single signature that looks, on chain, like one regular signature from a single key. The wallet behaves like a multisig wallet, but the chain never sees the multi-ness. That has real consequences for fees, privacy, and what kinds of multisig become economically viable.
TL;DR
- ECDSA is what most current multisig (including SSP today) signs with. Each cosigner produces a separate signature; the chain checks all of them. Costs and footprint scale with
n. - Schnorr is a different signature scheme, enabled on Bitcoin via the 2021 Taproot upgrade. It has a mathematical property — linearity — that ECDSA lacks. Linearity lets multiple Schnorr signatures be added together into a single, valid signature for a combined key.
- MuSig2 is the modern, practical protocol that turns that mathematical property into a usable multisig protocol.
ncosigners run a short interactive protocol, each contributing one round of nonces and one partial signature; the result is a single Schnorr signature indistinguishable from a single-key one. - This is a strict win on the verification side — fees, blockchain bloat, and privacy all benefit. It is not a free win on the signing side: aggregation needs careful nonce handling, and a buggy implementation can leak private keys.
- SSP today uses BIP48 + ECDSA multisig across the chains it supports. The roadmap is to add Schnorr/MuSig2 paths where the chain supports them, without breaking the existing 2-of-2 model that users already have.
A quick recap on what a signature does
A digital signature proves two things to a verifier: this exact message was signed by someone holding the private key for this public key. On chain, the "message" is a transaction hash, the "public key" is the address (or what derives the address), and the "verifier" is every node on the network. If the signature checks out, the transaction is valid; if not, it's rejected.
ECDSA — the scheme Bitcoin and most EVM chains use — is well-understood, conservative, and works fine for the case of a single signer. The trouble is what happens when you want multiple signers to authorize the same transaction. ECDSA has no way to combine signatures. If you want two-of-two, the chain has to store both signatures and check both of them. Three-of-five, five signatures. The transaction grows with the cosigner count.
What is multisig describes the protocol part — m of n keys, redeem rules, the chain enforcing the threshold. What that earlier piece doesn't dwell on is the cost: under ECDSA, all those signatures live in the transaction. A 2-of-2 P2WSH transaction is genuinely larger and more expensive to broadcast than a single-sig transaction with the same effect.
What Schnorr changes
Schnorr signatures, originally proposed in the late 1980s, were avoided in Bitcoin's original design because of patent uncertainty around them at the time. They are mathematically cleaner than ECDSA in one specific way: they are linear. If s1 is a valid signature on a message under key P1, and s2 is a valid signature on the same message under key P2, then s1 + s2 is a valid signature on that message under P1 + P2. Both the keys and the signatures add.
Why this matters: it suddenly becomes possible to combine signatures before they hit the chain. Instead of storing two signatures in the transaction, you store one — the sum. The verifier checks the one signature against the sum of the two public keys, which both signers can compute in advance. From the chain's perspective, the resulting transaction looks indistinguishable from a transaction signed by a single key.
ECDSA can't do this. The math of ECDSA involves a multiplicative inverse that breaks linearity; sums of ECDSA signatures aren't valid signatures. That's why ECDSA-based multisig has to ship all the individual signatures on chain. The chain inspects each one separately.
Bitcoin shipped Schnorr signatures (via BIP340) as part of the 2021 Taproot soft fork. The signatures themselves are slightly smaller than ECDSA signatures (64 bytes versus ~71), but the much bigger deal is what that linearity enables when you combine it with multisig.
MuSig2 — multisig that looks like one signature on chain
The honest version of "you can add Schnorr signatures together" is that you have to do it carefully. The naive approach — let each cosigner pick a nonce, share their partial signature, sum everything up — leaks key material under repeated signing and is vulnerable to a class of "rogue key" attacks. A practical aggregation protocol has to defend against both.
MuSig2 is the result of about a decade of refinement on this problem. It's the de facto standard for n-of-n Schnorr multisig: at signing time, the cosigners exchange two rounds of nonces, each produces a partial signature, and one of them sums the partials into a final aggregate signature. The result is a single Schnorr signature, valid against a single aggregated public key, indistinguishable on chain from a single-key signature.
A few important points about MuSig2:
- It's currently
n-of-n. To get a truem-of-n(e.g. 2-of-3) under aggregation you need additional machinery — FROST is the leading proposal — and that's still being productionised. So in 2026, what SSP would aggregate cleanly is the 2-of-2 default. The 2-of-3 and higher configurations from the picker article still mostly use ECDSA-style on-chain visibility. - It still requires both cosigners online to sign. Aggregation doesn't reduce the number of signers needed; it just compresses the final output. The UX is the same as today — two devices sign the same transaction — but the on-chain footprint of the result is smaller.
- A buggy MuSig2 implementation can leak keys. The nonce handling is subtle. Production deployments lean on well-audited libraries (
libsecp256k1's MuSig2 module, therust-bitcoinstack, etc.) for this reason.
What this means for SSP today
SSP today, on every chain it supports, uses BIP48-derived ECDSA multisig. Two devices, two private keys, two separate signatures on chain. That is correct, it's audited (by Halborn — see the inside-ssp-2025-halborn-audits reference in the existing 2-of-2 piece), and it's interoperable with every other BIP48-compliant wallet. The downside is that you pay 2-of-2's full on-chain cost.
The roadmap from here, in plain English: add a Schnorr/MuSig2 code path for Bitcoin (where Taproot is live and stable) that signs the same 2-of-2 wallet using aggregation instead. The wallet's threshold semantics don't change — both devices still have to sign. The on-chain bytes shrink, and the resulting transaction looks like a single-sig spend.
For the user, this would mostly show up as:
- Slightly lower Bitcoin fees per transaction.
- Improved privacy — the wallet stops broadcasting "I am a multisig wallet" to chain analytics.
- Faster reconciliation for the wallet UI (slightly less data to fetch and parse per address).
It is not — and this is worth saying clearly — a security upgrade. The cryptography is comparably hard, just structured differently. The reason to adopt it is efficiency and privacy, not raw security.
What this means for cost, privacy, and UX
Three places this lands once aggregation is widely deployed on a chain:
Cost. Bitcoin charges fees roughly by transaction size in vbytes. A 2-of-2 P2WSH ECDSA transaction is meaningfully larger than the equivalent Taproot-MuSig2 transaction. For low-balance wallets sending small amounts, the relative fee savings can be 20–30%. For high-throughput businesses, the absolute savings on annual fees are real money.
Privacy. Today, when a wallet broadcasts a 2-of-2 P2WSH spend, that fact is visible to anyone running a blockchain explorer. Sophisticated chain-analytics firms cluster addresses by spending pattern, and "this address is multisig" is a strong cluster signal. A Schnorr-aggregated spend looks identical to a single-sig spend. The cluster signal disappears.
UX. The signing UX in SSP — sign on the browser, then confirm on the phone — doesn't change. Both devices still produce partial signatures; the wallet just combines them before broadcasting instead of broadcasting both. From the user's perspective the only visible change is "the wallet feels cheaper to use."
There's a deeper UX win on the horizon, too. Once m-of-n aggregation (via FROST or similar) is production-ready, you could imagine a 2-of-3 SSP wallet — like the solo recovery setup the previous article describes — that on chain looks like a normal single-sig wallet. The third "recovery" key is genuinely a third signing key, but the chain never has to know.
What this means for you
Three takeaways:
- You don't have to think about Schnorr to use SSP correctly. The 2-of-2 setup you have today is built on well-audited ECDSA multisig, and it stays that way regardless of how aggregation lands. The next article in the series (social recovery vs multisig) deliberately ignores aggregation because the question of who can spend is independent of what the signature looks like on chain.
- Aggregation is a "fees and privacy" upgrade, not a "security" upgrade. If you ever see a wallet pitching "MuSig2 = more secure," be skeptical. The cryptographic security of well-implemented MuSig2 is comparable to well-implemented ECDSA multisig; the wins are elsewhere.
- Watch the chain support, not the wallet marketing. Schnorr is live on Bitcoin and being adopted across the EVM world via account abstraction. The chains that support it well are the ones where SSP will roll out aggregated multisig first; everywhere else, BIP48 + ECDSA remains the right and safe default.
The next article in this series, Social recovery vs multisig, shifts focus from cryptography to operations: when do you reach for multisig and when does social recovery beat it? Both protect against losing keys; they answer different questions. For a quick refresher on which devices SSP uses today and why, Meet SSP Wallet remains the starting point.
