Rent and token accounts, explained

Why accounts cost anything at all

Solana keeps its account state in memory across the validator network. Every account that exists imposes an ongoing cost on every validator, forever, whether or not anyone ever touches it again.

Charging nothing would mean anyone could create unlimited accounts and permanently burden the network at no cost. The mechanism that prevents this is rent: an account must hold a minimum balance proportional to how much space it occupies. Hold that balance and the account is rent exempt, meaning it persists indefinitely.

The important property is that the balance is not consumed. It is not a subscription being drawn down. It sits there as a deposit, and when the account is closed and its space returned to the network, the deposit is returned to whoever closes it.

The associated token account

A wallet address cannot hold an SPL token directly. Holding a token requires a separate account that belongs to that wallet and is dedicated to that specific mint.

The convention is an associated token account, whose address is derived deterministically from the wallet and the mint. That determinism is why any wallet can show your balance without being told where to look, and why sending a token to someone can create their account automatically.

The consequence that matters here is arithmetic. One wallet holding five different tokens has five token accounts, each with its own deposit. A fleet of five hundred wallets holding one token has five hundred token accounts. The deposit is per pair of wallet and mint, not per wallet.

What it actually costs

A standard token account requires 0.00203928 SOL to be rent exempt. That figure follows from the account's fixed size and the network's rent parameters, which is why it is the same number everywhere rather than something that varies by wallet.

Set against the network fee for the same fleet, this is by far the larger number. A thousand transactions cost 0.005 SOL in base fees; a thousand token accounts tie up over two SOL. The fee breakdown puts both alongside the venue costs that dwarf them in turn.

Why fleet size has a working capital cost

This is the practical point for anyone planning a campaign, and it is independent of how much volume you intend to route.

Doubling a fleet from five hundred wallets to a thousand does not merely double the transaction count. It doubles the capital that must be present before anything happens, because every one of those new wallets needs its own account for your mint. That capital is not spent, but it has to exist, and for a team funding a campaign out of a limited treasury the distinction between spent and tied up is smaller in practice than it is in principle.

It also means fleet size is a decision with two separate costs. There is the recoverable float described here, and there is the effect on how the campaign reads, which the fleet sizing guide covers. Both point in the same direction for most campaigns, but only one of them shows up in a budget.

There is a second and less obvious consequence of the deposit being per mint. A wallet fleet reused across several tokens accumulates accounts, one per token it has ever held, and each of those keeps its deposit locked until closed. Operators who reuse fleets without cleaning up therefore find their available capital declining over time for no visible reason, with the missing SOL sitting in dozens of small accounts nobody thought about. Closing accounts at the end of each campaign avoids the whole situation, and it is a single instruction rather than a process.

Getting it back

Closing a token account returns its rent to a destination you specify. The requirement is that the account holds no tokens, which means the position has to be fully exited first.

Two things are worth knowing about the timing. First, the recovery is complete rather than partial: the full deposit comes back, not a depreciated amount. Second, it is a per-account transaction, so recovering a large fleet's deposits costs a number of base fees, which is trivial against the amount recovered but non-zero.

The trade-off worth thinking about is whether to close at all. Leaving accounts open keeps the capital locked and means a future campaign with the same fleet pays nothing to trade the same token again. Closing recovers the money now and means recreating the accounts later if the fleet returns. For a one-off campaign, closing is clearly right. For a programme running monthly against the same token, leaving them open can be the cheaper choice overall.

Practical consequences

• Fund wallets with headroom. A wallet needs the swap amount, fees for both legs, priority fee room, and the rent deposit if it has never held the token. Underfunding produces failures that look like market problems and are not, which the failure guide covers.
• Budget rent as capital, not expense. It is a float requirement, and describing it as a cost overstates what a campaign actually consumes.
• Close accounts at the end. Beyond recovering the money, it removes several hundred standing rows from any future holder query on your token.
• Remember it is per mint. A fleet used across several tokens pays the deposit separately for each one.
• Do not confuse it with the account minimum for SOL. A wallet also needs a small balance to exist at all, separate from the token account deposit.

The reason this deserves its own page is that rent is the item most consistently missed in campaign budgeting, and missing it produces a specific failure: a fleet funded exactly for swaps and fees, where every first trade fails because the wallets cannot afford to create the account they need. The error message points at funding, the operator adds a little more, and the same thing happens again because the shortfall was never in the swap.