SPL Tokens and Token Accounts in SSP
If you have used ERC-20 tokens on Ethereum, Solana's token model will feel familiar for about thirty seconds and then stop making sense. On Ethereum, a token contract keeps a ledger of who owns what, and your address appears as a row in that ledger. On Solana, your address does not appear in the token's records at all. Instead, a separate account is created to hold your balance of that specific token, owned by you but distinct from your main address.
That one design decision explains almost every surprise people hit with SPL tokens: why sending a token to a new person costs more than sending it to someone who already holds it, why a wallet can show a token balance of zero for an address that has never touched the token, and why decimals matter more here than anywhere else. This article walks through the model as SSP implements it.
Why Solana needs a separate account per token
Solana's core rule is that everything is an account, and every account has an owner, a size, and a rent deposit proportional to that size. There is no such thing as a contract that quietly grows an internal mapping as more users arrive — the storage has to live in an account somewhere, and someone has to pay for it.
So the SPL Token program splits the job. The mint account holds facts about the token itself: total supply, decimals, and who may issue more. Each holder gets their own token account, a small fixed-size account that records one balance for one mint and names an owner. Your SOL balance lives at your address; your USDC balance lives in a token account that your address controls.
The upside of this design is predictability — every token balance is the same shape and costs the same to store. The trade-off is that holding a new token requires bringing a new account into existence. Solana's token documentation is the primary source if you want the specification rather than the summary.
The associated token account, and who pays for it
If every holder needs a token account, and anyone can create accounts, you would end up with several token accounts per person per mint and no way to know which one to send to. The associated token account — ATA — is the convention that fixes this: for a given owner and a given mint, there is one canonical address, derived deterministically from both. Wallets can compute it, so nobody has to publish it.
The catch is rent. A token account is roughly 165 bytes, which comes to about 0.002 SOL held as a rent deposit for as long as the account exists. That deposit is recoverable when the account is closed, but it must be paid up front, and it must be paid by somebody who has SOL — which the recipient of their first-ever token transfer, by definition, may not.
SSP handles this the way it handles every other Solana fee. When you send an SPL token to someone whose ATA does not exist, the transaction includes an idempotent instruction to create it, and SSP's paymaster pays the rent. Your vault reimburses the paymaster inside the same transaction, which is why that first transfer to a new recipient costs about 0.0025 SOL more than a repeat transfer to the same person. "Idempotent" is the important word: if the account turns out to already exist, the instruction succeeds and does nothing rather than failing the whole transfer.
Note that this creation instruction sits outside the multisig proposal. Creating someone's token account does not move your funds and needs no authorization from your vault, so it does not belong inside the part your two devices sign. The reimbursement, which does move your funds, is inside the proposal.
What SSP supports out of the box
SSP ships with native SOL, Circle's official USDC mint, and FLUX on Solana. Any other SPL token that turns up in your vault is resolved and displayed alongside them.
One deliberate limit is worth stating plainly: SSP's Solana transfers are built against the classic SPL Token program. Tokens issued under Token-2022, the newer program with transfer hooks, confidential transfers, and other extensions, are not part of the send path today. This is a scope decision rather than an oversight — Token-2022 extensions can change what a transfer does, and shipping support for them means auditing each extension against the on-device decoding guarantees described below.
How a token transfer is actually built
When you send an SPL token from SSP, the transaction that gets signed contains, in order:
- Create the recipient's ATA if needed — idempotent, paid by the paymaster, outside the proposal.
- TransferChecked — moves the balance from your vault's token account to the recipient's, authorized by the vault.
- Reimburse the paymaster — a plain SOL transfer from your vault, inside the proposal.
All of it lands as a single atomic transaction. There is no separate approval step, no pending proposal sitting on-chain, and no state where the recipient's account has been created but the transfer has not happened. Either the whole thing executes or none of it does.
The source account is your vault's own ATA — derived the same deterministic way, with the vault program address as the owner. Because the vault is a program-derived address rather than a keypair, the derivation explicitly permits an owner that is off the ed25519 curve. If you want the underlying detail on why the vault address works that way, the self-initiating Solana multisig covers it.
Decimals are part of the signature
This is the part worth slowing down for, because it is where a token can lie to you.
A mint declares how many decimal places its token uses. USDC uses six; many tokens use nine; there is no rule. If a wallet displays "100 USDC" but builds a transfer for a number of raw units that assumes the wrong decimals, you can send a thousand times too much and see nothing wrong on screen.
SSP uses TransferChecked rather than the plain transfer instruction. The difference is that TransferChecked embeds the mint address and the decimals byte directly into the signed instruction data. Three separate checks follow from that:
- Your extension decodes the bytes and compares them against what it is displaying.
- SSP Key decodes the same bytes independently on your phone and compares them against the token metadata the extension supplied.
- The on-chain SPL Token program compares the decimals in the instruction against the mint's actual decimals and rejects the transaction if they differ.
The third check is the one you cannot talk your way past. A mint that claims different decimals than it has does not produce a wrong transfer — it produces a failed transaction.
Receiving tokens
Receiving is simpler, with one wrinkle. Give the sender your wallet address — the one SSP shows on the receive screen — not a token account address. Whatever they are sending, the correct ATA is derived from your address and the mint, and the sender's wallet creates it if needed.
If your vault has never held that token, the account will not exist until the first transfer arrives, and its rent is paid by whoever sends to you. This is normal and requires nothing from you. It does mean a block explorer will show no token account for a token you have been promised but not yet received — that is the account not existing yet, not a lost transfer.
Common pitfalls
Sending to a token account address instead of a wallet address. Some explorers display the ATA prominently. Sending a token to a token account rather than its owner is a well-known way to lose funds on Solana. SSP expects the owner's wallet address and derives the rest.
Assuming an unfamiliar token is safe because it appears in your wallet. Anyone can create a mint and send it to you, and mints can carry names that mimic real tokens. A token showing up in your vault is not an endorsement. Verify the mint address against an official source before treating a balance as real value.
Expecting Ethereum-style approvals. SPL tokens have a delegate mechanism, but the standing-allowance pattern that makes ERC-20 approvals a recurring risk is not how most Solana applications are built. If you are coming from Ethereum, token approvals: the permissions you keep granting explains the habit you are unlearning, and Ethereum in SSP covers the comparison.
Forgetting the first-send surcharge. The extra ~0.0025 SOL on a first transfer to a new recipient is rent, not a fee SSP collects. It sits in the recipient's token account and is recoverable by them if they ever close it.
For the step-by-step mechanics of an actual transfer, see sending Solana with SSP. For how SSP holds the underlying vault in a 2-of-2 multisig with no creator, start with Solana in SSP.
