Solana arrives in SSP Wallet
SSP Wallet v1.39.0 brings Solana into the wallet. The integration goes live on Solana Devnet with the test token TEST-SOL, so you can try the full flow today before mainnet support follows.
On Solana you get the same things you already expect from every chain in SSP:
- Send and receive TEST-SOL, with live balance sync.
- Cross-chain swap, so Solana plugs straight into SSP's existing swap routing.
- Transaction memo support, for exchanges and services that require a memo on deposit.
- SSP Enterprise support, so business vaults reach Solana too.
And, like every other chain in SSP, every Solana transaction is signed through SSP's standard 2-of-2 multisig flow — one approval on your browser-extension Wallet, one on your mobile SSP Key. No single device can move funds on its own. Adding a new chain never means relaxing that rule.
Built on SSP's own Solana multisig program
Most of the chains SSP already supports lean on multisig primitives that exist at the protocol level. Solana is different. To bring true 2-of-2 multisig to Solana the way SSP does it everywhere else, the SSP team designed and built its own on-chain program: RunOnFlux/Solana-Multisig.
It is a self-initiating, permissionless M-of-N vault — a small, deliberate primitive rather than a sprawling framework. Three properties make it stand out:
- Self-initiating. The vault address is derived deterministically from its members and threshold. That means the address is knowable — and can receive funds — before anything is created on-chain. There is no setup transaction standing between you and a funded vault.
- Permissionless. There is no creator, no admin, no privileged setup step. Anyone can register a vault, and no one holds special powers over it afterwards.
- No privileged roles. Fund safety rests entirely on the cryptographic threshold check performed when a transaction is spent. There is no config authority that can quietly change the members or the threshold behind your back.
For developers, the program ships with a TypeScript SDK — @runonflux/solana-multisig — with helpers for address derivation, proposals, approvals, and execution. The program is live on devnet now, with mainnet pending.
If you want the deeper story on how a deterministic, address-is-the-member-set vault compares to other Solana multisig designs, a dedicated SSP Academy series will cover the technical details. This announcement keeps things short: Solana works in SSP, and it works the SSP way.
Why this matters
SSP's whole model is that no single key — and no single device — should ever be able to move your money. That principle does not bend for new chains. Rather than ship a watered-down Solana experience, the team built the missing piece itself, as an open, auditable program with no creator and no back doors.
The result is a Solana integration that behaves exactly like the rest of SSP. The same two-device approval. The same self-custody guarantees. The same predictability — the vault's address is a pure function of who controls it, nothing more.
This continues a long pattern of bringing new networks into SSP without compromising its security core — the same approach behind Ethereum's arrival with Schnorr multisig on ERC-4337 and the EVM expansion to Polygon, BSC, and Avalanche.
Also in v1.39.0
Alongside Solana, v1.39.0 ships a round of reliability work:
- Swap reliability fixes, including a balance refetch when a chain syncs, so swap quotes reflect what you actually hold.
- Faster wallet sync — the address discovery cap was reduced to 20 per chain, which trims the time SSP spends scanning for used addresses.
- Updated build tooling — a dependency bump, a refreshed lockfile, and upgraded Node polyfills.
- Various smaller bug fixes.
Get started
Update to SSP Wallet v1.39.0, switch to Solana Devnet, and request some TEST-SOL from a devnet faucet to try sending, receiving, and swapping. Mainnet Solana support is on the way.
For the complete list of changes, see the full v1.39.0 changelog on GitHub.
