Solana support in SSP moves from devnet to mainnet. The same 2-of-2 self-custody you use on Bitcoin and Ethereum now covers real SOL and SPL tokens, signed through SSP's own multisig program running on Solana mainnet at SSPWVu7dtTDkZYmDx73StqV46PioSmdiNE7igpjHK1r.
We shipped Solana on devnet first, deliberately, in SSP Wallet v1.39.0. Everything since then has gone into the part that is hard to undo once real money is involved: the on-chain program, the way your device checks it, and the guarantee that the code running on mainnet is the code we published.
No creator, no coordinator
Solana multisig usually begins with someone creating it. Squads V4 — the mature, widely used option, and the one worth comparing against — creates a wallet with an on-chain instruction that takes two things: a creator, and a fresh random single-use create_key. The vault's address derives from that random key, which means the address does not exist and cannot be funded until someone runs the creation transaction, and one party is present at that moment as the creator.
SSP's program has no creation step of that shape. Your vault address is a fingerprint of the sorted member set together with the approval threshold — nothing else. Anyone who knows who the members are and how many must approve can compute the address offline, before anything touches the chain. Registration is permissionless: the program simply checks that the members you present really do hash to the claimed address, so registering changes nothing about who can spend.
The result is that there is no creator to trust, no privileged registrar, and no admin key. Spending is gated solely by the threshold check inside execute_transaction — the address is the rule, rather than a record of whoever set it up.
That property is what lets your two devices behave the same way on Solana as everywhere else in SSP. If the model is new to you, what 2-of-2 multisig actually is is the place to start; the SSP implementation on Solana goes into the program itself, and SSP vs Squads V4 is the full side-by-side.
Your device does not trust our relay
Solana transactions are opaque in a way Bitcoin transactions are not: what a transaction does lives in instruction data that a wallet has to decode before it can tell you anything truthful.
So SSP decodes it on your device, byte by byte, using the open-source @runonflux/solana-multisig library. Recipients, amounts and token mints are verified against the raw transaction bytes rather than believed from what the relay sends. If the two disagree, signing is hard-blocked — a mismatch there indicates an active attack, not a display bug.
That work shipped ahead of mainnet in v1.40.0, along with an independent ceiling on paymaster fee reimbursement and an instruction allowlist on approvals. Mainnet is switching on a decoder that has already been in production on devnet for weeks.
Builds you can verify
The mainnet program is built with a pinned toolchain and verifiable builds, so the bytecode deployed at that address can be reproduced from the published source. You do not have to take our word for what is running — you can rebuild it and compare.
This is the same posture as the wallet's deterministic builds: the security claim is only worth as much as your ability to check it yourself.
Getting started
Update to the latest SSP Wallet and SSP Key, then activate Solana from the chain selector. With v2's batch sync you can enable it alongside any other chains in a single approval on your Key.
From there Solana behaves like every other chain in SSP: it appears in your Portfolio total, sends go through the same compose → review → approve flow with the full recipient address shown, and every transaction is co-signed by your two devices.
