A wallet address looks like a simple thing: a string you copy, paste, and send money to. On Bitcoin, it almost is that simple. On Solana, putting a shared wallet — a multisig — behind an address is surprisingly hard. This article explains why, and it sets up the question the rest of this series answers.
What a multisig address has to promise
A multisig wallet is one controlled by several keys, where a fixed number of them must agree before money moves. A "2-of-3" multisig, for example, has three keys and needs any two to approve a payment. The point is to remove single points of failure: lose one key, or have one key stolen, and your funds are still safe.
For that to be useful, the address has to keep two promises. First, it must be knowable in advance — you want to hand someone a deposit address before you have finished setting anything up. Second, it must be honest: whoever sends money to that address should be able to trust that only the agreed group of keys, under the agreed rule, can ever spend from it. Hold onto those two promises. They are the thread through everything below.
On Bitcoin, the address is the rule
Bitcoin makes this look easy. A Bitcoin multisig is described by a small script: the list of public keys plus the "M-of-N" rule. To get the address, you take that script and hash it. The address (a P2WSH address) literally is the hash of the spending rules.
That has a quietly powerful consequence. Anyone can compute the address offline, on a laptop with no internet, before a single transaction is broadcast. There is no "create the wallet" step — the wallet does not need to exist on the network to receive money. The script is revealed only later, when funds are spent, and the network checks that the revealed script matches the address and that enough valid signatures are present. Address knowable in advance: yes. Honest: yes — because the address is derived from the rule itself, a different set of keys produces a different address.
On Solana, an address is an account that must be created
Solana works differently. On Solana, everything is an account — a slot of on-chain storage with an owner. Your funds live in accounts, programs live in accounts, and a multisig's configuration lives in an account too. Crucially, accounts do not spring into existence for free. An account has to be explicitly created and paid for: someone funds it with a small amount of SOL called "rent" so the network will store its data.
A multisig on Solana is therefore not just an address — it is a program-controlled account holding the member list and the threshold. And that account has to be created by a transaction before the multisig can do anything. This is the root of the difficulty: a shared wallet on Solana has a setup step that Bitcoin simply does not have.
PDAs: addresses with no private key
Solana does have an elegant tool for this, called a Program Derived Address, or PDA. A normal Solana address has a matching private key — whoever holds the key controls the address. A PDA is deliberately built to be off the curve: it is a valid-looking address for which no private key exists and no private key can exist. Nobody can sign for it personally.
Instead, a PDA is derived deterministically. You take some input values — called "seeds" — plus the ID of a program, run them through a one-way function, and out comes the address. The same seeds and program always produce the same PDA, so it is reproducible by anyone. And because there is no private key, only the owning program can authorize actions for that address, which it does through a mechanism called a cross-program invocation with invoke_signed: the program presents the seeds to the Solana runtime, and the runtime grants it signing authority for the PDA. No cryptographic signature is ever produced — the right to act comes from knowing the seeds, not from holding a key.
A PDA is exactly the right home for a multisig: an address controlled by program logic rather than by any one person. So far, so good. The hard part is what gets chosen as the seeds.
The fund-before-creation problem
Here is where the dominant Solana multisigs run into trouble. Unlike the deterministic Bitcoin model, the widely used Solana multisigs — Squads V4 is the leading example, mature and heavily audited — derive the multisig's address from a freshly generated random value chosen at creation time, not from the member set. In Squads V4 that value is called a create_key, an ephemeral key produced when a creator runs the creation transaction.
Deriving the address from a random create_key is a deliberate, reasonable design choice — it sidesteps an awkward edge case where two different groups want the exact same membership. But it has two consequences worth understanding clearly:
- You cannot know the address in advance. The seed does not exist until someone runs the creation transaction, so neither does the address. There is no way to print a deposit address and fund it before setup — the fund-before-creation problem. The first promise breaks.
- The creator is a single point of trust at setup. One specific account must run that creation transaction and choose that random value. For the brief window of setup, you are trusting that one party to do it correctly.
None of this makes Squads V4 unsafe — it is the most battle-tested multisig on Solana and secures very large sums. It is simply a different shape of trust than Bitcoin's. The address is no longer "the hash of the rule"; it is "whatever the creation transaction happened to produce."
Ethereum found a middle path
Ethereum faced a similar issue and answered it with a feature called CREATE2. It lets you compute a smart contract's address before the contract is deployed, from fixed inputs. Wallets like Safe use this to give you a so-called counterfactual address: a real, fundable address that you can share and receive money at, while the actual contract is deployed lazily — only when funds first need to move. The newer account-abstraction standard, ERC-4337, formalizes the same idea. Ethereum thus recovers the "knowable in advance" promise even though, like Solana, it needs an on-chain object to exist eventually.
The question this series answers
Lay the three models side by side. Bitcoin: the address is the hash of the rule — knowable offline, honest by construction, no creation step. Ethereum: a counterfactual address — knowable in advance, with deployment deferred. Solana's mainstream multisigs: the address comes from creation-time randomness — not knowable in advance, with a creator trusted at setup.
So here is the question. Solana needs accounts, and accounts need creating — that is not going away. But does a Solana multisig have to give up the Bitcoin property? Could the address instead be derived purely from the member set and the threshold — the rule itself — so that it is knowable offline, fundable before setup, and honest because a different group of keys yields a different address?
That is exactly the property the SSP team built into its own Solana multisig program. The next article shows how: an address that is the member set, a vault you can fund before anything is registered on-chain, and a registration step that needs no creator at all. The design was shipped alongside Solana support in SSP Wallet — see the release announcement — and, in keeping with how SSP treats security, the program is currently devnet-only and awaiting an external audit before mainnet. If you are still new to multisig itself, start with what a multisig is and why it matters; otherwise, read on.
