SSP vs Squads V4: Two Solana Multisig Designs
A multisig wallet is a wallet that needs more than one approval before money can move. On Solana, several teams have built multisig systems, and they do not all work the same way under the hood. This article compares two of them — Squads V4 and SSP's own multisig program — not to crown a winner, but to show two honest, well-reasoned design philosophies and who each one suits.
If this is your first stop in the series, the companion article the self-initiating Solana multisig explains how SSP's design works in full. Here we set it side by side with the most established option on the network.
Crediting Squads V4 first
Squads V4 is the dominant multisig on Solana. It is mature, it secures billions of dollars in value, and it has been examined by an unusually long list of security firms — OtterSec, Neodyme, Trail of Bits, and Certora, the last of which also applied formal verification (mathematical proof that the code behaves as specified). Wallets such as Fuse are built on top of it. Any honest comparison has to start there: Squads is a serious, battle-tested platform, and nothing below is a criticism of it.
SSP's Solana multisig program takes a different shape because it was built for a different goal. The two are not competing for the same job, and the rest of this article is about what differs and why.
A maturity caveat, stated plainly
One difference matters more than any design choice, so it goes first. Squads V4 runs on Solana mainnet — the live network where real funds move — and has been through the audits listed above. SSP's Solana multisig program is, at the time of writing, devnet-only (Solana's test network, where tokens have no monetary value) and is pending an external security audit. It is not yet something you should trust with mainnet funds. The comparison below is about design trade-offs; it is not a recommendation to use unaudited software on mainnet.
How the wallet gets created
The clearest difference is in how a multisig comes into existence.
Squads V4 creates a multisig with an on-chain instruction called multisig_create_v2. That instruction needs two things: the person creating the wallet (the creator), and a fresh, random, single-use key called a create_key. The wallet's on-chain address is derived from that random create_key — so the address simply does not exist, and cannot be known or funded, until the creation transaction runs. There is also a creator present at that moment: a single party who sets the wallet up.
SSP's program does not have a creation step in that sense. Its multisig address is derived directly from the member set itself — specifically from a fingerprint of the sorted list of members together with the approval threshold. Because the inputs are just "who the members are" and "how many must approve", anyone who knows those facts can compute the address offline, before anything happens on-chain. Registering the wallet is permissionless: the program simply checks that the members you present really do hash to the claimed address, so the canonical address can only ever hold the canonical member set. There is no creator, and no random key.
Can you fund it before it exists?
This follows directly from the previous point.
With Squads V4, the address depends on a random key chosen during creation, so you cannot pre-fund it — you create the wallet first, then send funds. With SSP's design, because the address is a pure function of the members and threshold, you can compute the deposit address and send money to it before the wallet is ever registered on-chain. This mirrors how Bitcoin works: a Bitcoin P2WSH address is a hash of the spending rules, and anyone can fund it offline with no "creation" transaction at all. Unlike the dominant Solana multisigs such as Squads, SSP's program brings that "the address is the rules" property to Solana.
Privileged roles and admin powers
Squads V4 is a governance platform, and it offers governance features to match. Each member can be assigned a permission bitmask — a combination of three rights: Initiate (propose a transaction), Vote (approve one), and Execute (carry out an approved one). On top of that, a Squads multisig can optionally have a config_authority: a key that can change the member list or threshold on its own. A "controlled" multisig keeps that authority; an "autonomous" one sets it to an empty value so that every configuration change must instead go through a member vote. These are real, useful features for organizations that want a designated administrator.
SSP's program deliberately has none of that. Every member is equal — there are no per-member permission tiers. There is no admin key and no config_authority. The member set and threshold are fixed at registration and are immutable afterward; "rotating a key" means moving funds to a new multisig with a new member set. The threshold is checked only when funds are spent, never at registration. The trade-off is plain: Squads gives you administrative flexibility; SSP gives you a smaller surface, because a privileged role that does not exist cannot be phished, stolen, or misused.
What it costs to create
Creating a Squads V4 multisig carries a documented protocol fee of roughly 0.1 SOL paid to the Squads treasury, in addition to the small Solana rent (the refundable deposit every account must hold to stay alive). SSP's program charges no protocol fee — registering a multisig costs only the underlying Solana rent. This is not a value judgment: a protocol fee funds ongoing development of a large platform. It is simply another axis on which the two designs differ.
Two philosophies, two audiences
Step back and the pattern is clear. Squads V4 is a feature-rich governance platform: per-member roles, optional administrators, a mature audited codebase, and the tooling an organization needs to manage a treasury with many stakeholders. SSP's program is a minimal deterministic primitive: the address is the member set, registration is permissionless, there are no privileged roles, and there is as little machinery as possible between you and your funds.
Each suits a different need. A DAO or company that wants designated admins, granular permissions, and a proven mainnet track record is well served by Squads. SSP's design targets a different model — a 2-of-2 consumer wallet, and an M-of-N setup for enterprises — where the priority is that the wallet address is predictable, fundable in advance, and free of any role that could become a single point of failure. SSP omits Squads' governance features on purpose: for SSP's use case, there is simply less to compromise.
To see how SSP's choices play out against real attacker scenarios, the academy article on multisig failure modes and how SSP mitigates them walks through the threat models directly. And if you want the technical detail on SSP's derivation, the self-initiating Solana multisig article is the canonical reference. For the other side, the Squads V4 source and documentation are openly available.
The honest summary
There is no "better" multisig here, only better fits. Squads V4 is the mature, heavily audited, feature-rich choice for organizations that want governance built in. SSP's program is a smaller, address-first design — currently devnet-only and awaiting its audit — built so that a multisig wallet feels as predictable as a Bitcoin address. Two honest philosophies, each solving the problem its builders set out to solve.
