
Solana Fees and Rent, Explained
Solana has a reputation for being almost free to use, and for ordinary transfers that reputation is earned. But "almost free" hides a structure worth understanding, because the costs you meet in a self-custody wallet are not all fees, and the largest number you will ever see on Solana is money you get to keep.
This article breaks down exactly what you pay when you send SOL or an SPL token from SSP, with the real figures rather than round numbers. If you have not yet read how SSP holds SOL at all, Solana in SSP is the foundation.
The three things you actually pay for
Every Solana transaction can involve three distinct costs, and conflating them is where confusion starts.
The base fee is what the network charges to process your transaction. The priority fee is optional and buys your transaction better treatment when the network is busy. Rent is not a fee at all — it is a refundable deposit that keeps an account alive on-chain.
Only the first two are spent. Rent is parked. Understanding that distinction is most of the battle.
Base fees: cheap and predictable
Solana charges 5,000 lamports per signature — 0.000005 SOL. That is the whole base fee model. It does not vary with the size of the amount you are sending, the complexity of the program you are calling, or the time of day.
A simple SOL transfer has one signature and costs 5,000 lamports. A transaction with three signatures costs 15,000. At any plausible SOL price this is a rounding error, which is precisely why Solana is used for the kind of small, frequent payments that would be uneconomic elsewhere. Solana's fee documentation is the primary source.
If you have come from Ethereum, the contrast is stark: there the fee scales with computation and with congestion, sometimes by orders of magnitude. Gas fees on Ethereum, explained for self-custody users covers that model.
Priority fees: buying a place in line
When Solana is busy, validators have more transactions than they can fit. The priority fee is how you signal that yours should go first. It is priced per compute unit — a measure of how much work your transaction does — in micro-lamports.
SSP sets a priority fee of 50,000 micro-lamports per compute unit on mainnet. A send consumes roughly 10,000 compute units, so the priority fee comes to about 500 lamports, or 0.0000005 SOL.
That is a deliberately small number with a deliberately large purpose. It is negligible next to everything else in the transaction, and it is the difference between a send landing during a busy period and being quietly dropped. Paying half a thousandth of a cent to not have to wonder whether your transaction made it is a good trade.
Rent is a deposit, not a fee
Here is the part that surprises people migrating from other chains. On Solana, an account must hold a minimum SOL balance proportional to its size in order to exist. Skip the deposit and the account is purged.
The figures for the accounts SSP creates:
- Multisig account (86 bytes) — about 0.00149 SOL
- Durable nonce account (80 bytes) — about 0.00145 SOL
- Associated token account (165 bytes) — about 0.00204 SOL
None of that is spent. It sits inside those accounts and comes back if the account is ever closed. The multisig and nonce accounts are permanent for as long as your vault exists — the nonce deposit is recoverable only when a vault is retired. A token account's deposit is recoverable by its owner at any time by closing it.
This is why your first Solana send in SSP is the expensive one and why it never repeats. You are not paying a setup fee; you are funding the accounts that make everything afterwards work.
What SSP charges, line by line
Every number here comes from SSP's published fee schedule rather than an estimate.
| What happened | Cost | What it is |
|---|---|---|
| First send from a new vault | 3,200,000 lamports (~0.0032 SOL) | Multisig rent + nonce rent + network fee |
| Every send after that | 100,000 lamports (~0.0001 SOL) | Network fee plus a small margin |
| Sending an SPL token to a new recipient | + 2,500,000 lamports (~0.0025 SOL) | Rent for the recipient's token account |
There is one more piece of accounting worth knowing about. The multisig proposal your two devices approve is itself an on-chain account, and it needs rent too. SSP closes it in the same transaction that executes it, so that rent is returned immediately and nets to zero. You will never see it as a cost because it never becomes one.

The exact fee is shown on the review screen before you sign, decoded from the transaction bytes rather than reported by a server. Your devices also enforce an independent ceiling on it: a reimbursement above the maximum SSP considers plausible is treated as an attack and blocks signing, regardless of what any server claims.
Why the vault reimburses a paymaster
On Solana, the account that pays a transaction's fee — the fee payer — has to sign the transaction. For a fresh multisig vault this is a genuine bootstrapping problem: the vault needs SOL to pay for the very transaction that would create its accounts, and those accounts do not exist yet.
SSP's relay operates a paymaster that signs as fee payer, fronts the network fee and any rent, and is reimbursed by your vault inside the same transaction. The reimbursement instruction is part of the proposal your two devices approve, so it cannot execute without both signatures, and it cannot be substituted for something else without the decoding check catching it.
The practical consequence is that you never maintain a separate gas balance. Receive SOL, send SOL. If paymasters as a general pattern are new to you, gas sponsorship and paymasters, explained covers the idea, and durable nonces and two-device signing explains the other half of what makes two-device signing work on Solana.

Getting SOL back
Rent deposits are recoverable, but the mechanism differs by account.
Token accounts can be closed by their owner once the balance is zero, returning roughly 0.002 SOL each. If you have accumulated token accounts for tokens you no longer hold — including ones people sent you unsolicited — closing them reclaims real SOL. SPL tokens and token accounts in SSP explains what those accounts are.
The multisig and nonce accounts stay funded for the life of the vault. Their deposits are only recoverable when the vault is retired entirely, which is not something you do casually — those accounts are what make your address spendable.
The practical takeaway is a small one: treat the roughly 0.003 SOL behind your vault as part of the vault rather than as spendable balance, and do not be surprised when a wallet's "available" figure sits slightly below the raw on-chain number.
For the step-by-step mechanics of a send, including where each of these numbers appears on screen, see sending Solana with SSP.


