The Solana multisig wallet where the address is the member set
A multisig wallet needs two or more keys to approve any spend. On Bitcoin, the wallet's address is simply a hash of its own rules — the list of public keys and the "how many signatures are required" number. You can compute that address on a notepad, hand it out, and receive funds long before anyone touches the blockchain.
Solana traditionally cannot do this. As the first article in this series explains, the dominant Solana multisigs ask you to run a creation transaction with creator-chosen randomness before the wallet's address even exists. SSP's own Solana multisig program takes the Bitcoin approach instead. It is self-initiating: the wallet address is the member set.
One note up front: SSP's Solana multisig program is open source (RunOnFlux/Solana-Multisig) and currently runs on devnet only — Solana's test network. A mainnet deployment is gated on an external security audit.
Two addresses: the multisig and the vault
SSP's design uses two separate addresses for every multisig wallet.
The multisig address holds the rules — the sorted list of member keys, the threshold (the M in "M-of-N"), and a counter of proposed transactions. It is owned by SSP's program.
The vault address holds the money — SOL and SPL tokens. It is owned by Solana's built-in System Program and stores no data of its own. The vault is the deposit address: the one you give to anyone who wants to pay you.
Both are a Program Derived Address, or PDA — an address with no private key, deliberately placed off the cryptographic curve so no key could ever control it. Only the program that derived it can authorize moves from it. That detail matters at the end.
How the address is computed from the members
Here is the part that makes the wallet self-initiating. To derive the multisig address, in plain language: take the literal label multisig, a SHA-256 hash of the sorted member list, and the threshold — then feed those, plus SSP's program ID, into Solana's address-derivation function. Three details deserve attention.
The members are sorted and deduplicated first. A 2-of-3 wallet with members A, B, C produces the same address whether you list them as C, A, B or B, C, A. Order does not matter; only the set does.
The full 32-byte hash is used — never a shortened version. Truncating the hash would open a real attack: an attacker could search for a different member set that hashes to the same shortened value, then register their own members at your address and drain any funds you pre-loaded. The full 32-byte hash makes that search astronomically expensive, so it never happens.
The threshold is part of the address. A 2-of-3 wallet and a 3-of-3 wallet with the very same members are different wallets at different addresses. The rules are baked into the identity.
The vault address is then derived from the multisig address plus a small index number (SSP always uses index 0) — so the vault, too, is fully determined by the member set and threshold.
The practical result: anyone can compute both addresses offline, before a single transaction is sent. You can hand out the vault address and receive funds into a wallet that, on-chain, does not yet exist — the Bitcoin property, brought to Solana.
Permissionless registration: anyone can turn it on
The wallet's address exists the moment you know the members. But to spend from it, the rules eventually need to be written on-chain — the program calls this step initialize.
On most Solana multisigs, only a privileged creator can do the equivalent step. On SSP's program, initialization is permissionless: anyone at all can do it. No creator account, no member signature, no special permission. Typically SSP's relay service pays the small rent fee and flips the wallet on, but it genuinely does not matter who does it.
That sounds alarming until you see the safety check. When someone initializes the wallet, the program recomputes the SHA-256 hash of the member list they supplied and rejects the transaction unless that hash matches the one baked into the address. Solana's account framework independently binds the address to that same hash. Together, those two checks mean the canonical address can only ever hold the canonical member set. Nobody can register your address with a member list of their choosing — the hash would not match, and the transaction fails.
Why a stranger initializing your wallet cannot hurt you
Walk through what an attacker could actually try.
They initialize with a different member set. A different set hashes to a different value, which derives a different address. The attacker has simply created their own unrelated wallet elsewhere on Solana — no connection to your vault, no claim on your funds.
They initialize with your member set. The hash matches, so the transaction succeeds — but all they have done is pay your rent fee for you. The wallet is now registered with exactly the rules you expected, and the attacker is not a member, so they cannot propose, approve, or execute anything. Money never sits at the multisig address itself — it sits at the vault, which is system-owned and cannot be hijacked. Whoever initializes the wallet, and whenever, the outcome is the same canonical, correctly-ruled wallet.
The threshold is checked when you spend, not when you register
This is the same model Bitcoin's P2WSH multisig uses, and it is worth stating plainly: the M-of-N threshold is enforced only when funds move — never at registration.
Registration just records "these are the members, this is the threshold." It asks for no signatures because it cannot do any harm. The real gate is the spending flow, where the program counts approvals and refuses to act until enough members have signed off. The address is the hash of the rules; anyone may fund it; only valid signatures may spend it. For a refresher on what "M-of-N" means, see 2-of-2 vs 2-of-3 vs M-of-N multisig.
The full lifecycle, start to finish
Putting the pieces together, the life of an SSP Solana multisig wallet:
- Derive. Anyone computes the multisig and vault addresses offline from the members and threshold. No blockchain, no cost.
- Pre-fund. Anyone sends SOL or tokens to the vault address — this works even before the wallet is registered.
- Initialize. Anyone, usually SSP's relay, submits the permissionless registration transaction. The program verifies the member hash and writes the canonical rules on-chain.
- Propose. A member creates a transaction proposal, stored compactly on a dedicated proposal account.
- Approve. Each member approves the proposal, once each. Approvals accumulate on-chain.
- Execute. Once approvals reach the threshold, anyone can trigger execution. The program first marks the proposal as executed — a deliberate guard so it can never run twice — then carries out each instruction, with the vault itself acting as the signer.
That last step is where the keyless vault address pays off. Because the vault is a PDA with no private key, no human and no program can move its funds by signing in the ordinary way. The only path out is SSP's program executing an approved, threshold-met proposal — it "signs" for the vault by presenting the vault's derivation recipe to the Solana runtime, a permission it gets purely because it owns the address.
No creator, no admin, no key rotation in place
Two final properties tie the design together.
The member set and threshold are immutable. Once a wallet is initialized, no instruction in the program can change its members or its threshold — there is no code path for it. To change who controls a wallet — what other systems loosely call "rotating keys" — you create a new multisig with the new member set and move the funds across. The old address keeps its old rules forever.
There is no creator role and no admin key, ever. Many multisig designs keep a privileged account that can override the members or change the configuration. SSP's program has none — nothing to compromise, no admin key to phish, no creator to coerce. The members and the threshold are the whole story.
That minimalism is a deliberate trade-off: SSP built a small, deterministic primitive rather than a feature-rich governance platform. The next article, SSP's Solana multisig vs Squads, compares this design honestly against Squads V4 — the mature, audited, dominant Solana multisig. For product context, the release announcement for Solana support covers what landed in SSP Wallet v1.39.0.
The core idea is small enough to hold in your head: on SSP's Solana multisig, the wallet address is a fingerprint of its own rules. Know the members and the threshold, and you know the address. Nothing else is needed, and nothing else is trusted.
