Locked lamports and spent lamports
The Solana rent exempt minimum is the balance an account must hold to remain on chain: (128 + data_bytes) * 3,480 * 2. A wallet with no data needs 890,880 lamports, an SPL token account needs 2,039,280, and both figures are held rather than consumed. They return to a destination you choose when the account is closed. Fees are the opposite: once paid, they are gone.
That distinction is the spine of this page. A run that opens two hundred accounts has not lost the reserves those accounts hold, but it also cannot use them for anything else while the accounts exist. Treating locked capital as an expense makes a fleet look far more costly than it is; treating it as free makes funding fall short at exactly the wrong moment, because the reserve has to be present before the account can be created at all.
Fees behave differently in every respect. They are small individually, they are charged whether a transaction succeeds or fails, and no part of them comes back. If you want the wider picture of what a swap actually costs beyond the account layer, there is a separate breakdown of how the rest of the swap cost stack is broken down. This page stays on the account side of that split, where the money is recoverable if you close things properly.
Both numbers belong in your funding plan, but in different columns. Locked capital sizes the float you need before a run can begin. Spent capital sizes the burn rate while it runs. Mixing them produces a plan that either strands value in accounts nobody remembers or runs out of lamports halfway through a fan-out. The procedures under runbooks assume you have separated the two before you start.
How the rent-exempt minimum is calculated
The formula is short and worth memorising: (128 + data_bytes) * 3,480 * 2. The 128 is fixed account overhead in bytes, added to whatever data the account itself stores. The 3,480 is lamports per byte-year, and the multiplication by two covers two years, which is the threshold at which an account is considered exempt. Nothing in it depends on network conditions, so the answer for a given size is stable.
Because the overhead term dominates at small sizes, an account holding no data at all is not free. Zero data bytes still gives (128 + 0) * 3,480 * 2, which is 890,880 lamports, or 0.00089088 SOL. That is the floor under every keypair you generate, before a single transaction is signed. It is also why an address with a balance of a few thousand lamports behaves as though it barely exists.
Data sizes are set by the program that owns the account, not by you. An SPL token account is 165 bytes because the token program defines that layout, and a mint is 82 bytes for the same reason. You cannot negotiate the size down, which means the only variable under your control is how many accounts you open. That is the lever the rest of this page is about. The account model itself is documented in the Solana developer documentation.
The reserve is a deposit, not a fee
Lamports held as a rent-exempt reserve remain the property of the account. They are not paid to anyone and they do not decay while the account sits idle. When the account is closed, the reserve is transferred to the destination named in the closing instruction. Plan for it the way you would plan for a deposit on equipment: it affects how much capital you need on day one, and it comes back only if you remember to ask for it.
Account costs at the sizes you will meet
Three account types cover almost everything an automation run touches. The table gives the exact reserve for each, expressed in lamports and in SOL, along with whether the reserve can be recovered. The final row is the general case, so you can price any account size a program hands you without looking anything up.
| Account type | Data bytes | Rent-exempt minimum (lamports) | In SOL | Recoverable on close |
|---|---|---|---|---|
| System account (a plain wallet) | 0 | 890,880 | 0.00089088 | Yes. Sweeping the balance to zero leaves nothing behind to reclaim later. |
| SPL token account | 165 | 2,039,280 | 0.00203928 | Yes, but only once the token balance is zero. The reserve goes to the destination named in the close instruction. |
| Mint account | 82 | 1,461,600 | 0.0014616 | Only where a close authority is available for that mint. Assume the reserve stays locked for the life of the token. |
| Any account of D data bytes | D | (128 + D) * 3,480 * 2 | Divide the lamport result by 1,000,000,000 | Depends on whether the owning program exposes a close instruction at all. |
Worked example: pricing an account size that is not in the table
Illustrative arithmetic for a program account of 200 data bytes; substitute the real size for the program you are dealing with. Add the fixed overhead: 128 + 200 = 328. Multiply by the byte-year rate: 328 * 3,480 = 1,141,440 lamports per year. Multiply by two years: 1,141,440 * 2 = 2,282,880 lamports.
Expressed in SOL that is 2,282,880 divided by 1,000,000,000, or 0.00228288 SOL. The same three steps produce every figure in the table above, which is a useful check: if your calculation of the 165 byte case does not land on 2,039,280, you have the wrong size or the wrong rate.
Why every token adds an account to every wallet
Token balances on Solana do not live in the wallet. Each wallet holds a separate token account per mint, and that account is what carries the balance, the owner and any delegate. A wallet trading one token therefore needs at least two accounts: the wallet itself and one token account. Trading a second token adds a third account, and the reserve for each of them is charged separately.
Multiplication is what makes this interesting operationally. One wallet with one token is 890,880 plus 2,039,280 lamports, which barely registers. Fifty wallets each holding two token accounts is a different conversation, and the growth is linear in both directions: more wallets multiply it, and more tokens per wallet multiply it again. Deciding how many wallets a strategy genuinely needs is therefore a capital decision as much as a design decision.
Wrapped SOL deserves a specific note because it catches people out. Wrapping produces a token account like any other, holds a reserve like any other, and is closed to unwrap. If a run creates wrapping accounts and never closes them, the reserves stay locked in accounts whose whole purpose was temporary. Include them in the audit rather than assuming they cleaned themselves up.
What a fleet of wallets ties up
Numbers make the point better than description. The example below uses a stated wallet count and a single traded token, and every figure comes from the constants above. Change the count to match your own plan; the structure of the calculation does not change.
Worked example: forty wallets, one traded token
Illustrative arithmetic, not a recommendation on fleet size. Assume forty wallets, each holding one SPL token account.
Wallet reserves: 40 * 890,880 = 35,635,200 lamports, which is 0.0356352 SOL. Token account reserves: 40 * 2,039,280 = 81,571,200 lamports, which is 0.0815712 SOL. Total locked: 35,635,200 + 81,571,200 = 117,206,400 lamports, or 0.1172064 SOL. Every lamport of that is recoverable if the accounts are later closed and swept correctly.
Now the spent side. Funding the fleet takes forty transfers, one signature each, at 5,000 lamports per signature: 40 * 5,000 = 200,000 lamports, or 0.0002 SOL. Closing forty token accounts at the end takes another forty signatures, a further 200,000 lamports. Total genuinely spent on this account overhead: 400,000 lamports, or 0.0004 SOL, against 0.1172064 SOL merely locked.
The ratio is the lesson. Locked capital here is roughly two orders of magnitude larger than the fees that create and destroy it, which means the funding question is about float and the fee question is about run duration. Add a second traded token per wallet and the locked figure rises by another 81,571,200 lamports while the fee side barely moves.
Two consequences follow. First, a fleet is cheap to run and expensive to stand up, so the temptation to open more wallets than the strategy needs costs you float rather than fees. Second, the recoverable portion only comes back if somebody closes the accounts, which makes the shutdown step a financial step and not just tidiness. That is covered in detail in shutting a run down cleanly.
What to verify before you fund anything
Funding wallets on Solana is a fan-out, and a fan-out with a wrong assumption in it is tedious to unwind. Run through the following before the first transfer leaves the source wallet. None of it takes long, and each item corresponds to a way that operators end up short or end up with lamports stranded across accounts they never look at again.
- The wallet count is final, and each wallet has a written purpose rather than existing because the script defaulted to it.
- The token list is final, so you know how many token accounts each wallet will open.
- Locked capital is calculated as wallets multiplied by 890,880 plus token accounts multiplied by 2,039,280.
- Each wallet is funded above the reserve by enough lamports to cover signature fees and any priority fees the strategy sets.
- The source wallet holds the full total plus a margin, so the fan-out does not stop partway through.
- The destination for reserves at closing time is chosen now and is an address you can sign for.
- Public keys for every wallet are recorded in the run log before funding, not reconstructed afterwards.
The fan-out mechanics themselves, including ordering and reconciliation, are set out in funding a wallet fleet. Treat this checklist as the gate in front of that procedure rather than a replacement for it.
Closing accounts and where the reserve goes
Recovering locked lamports means closing accounts, and closing has rules. An SPL token account can only be closed when its token balance is zero, so any dust left in the account blocks the instruction until it is transferred or otherwise removed. Wallets are simpler: a system account holds no data, so sweeping its lamport balance to zero leaves nothing to reclaim later.
Destination is the part that deserves attention. The close instruction sends the reserve to an address you specify, and that address does not have to be the account owner. Getting it wrong does not produce an error, it produces a successful transfer to somewhere you did not intend. Check the destination the same way you would check any transfer, and prefer a single collection wallet whose address you can verify at a glance.
Closing is a transfer, and transfers are final
A token account will refuse to close while it still holds a token balance, so clear the balance first rather than forcing the step. Once the close succeeds, the rent-exempt reserve moves to the destination address in that instruction and the account no longer exists. If the destination is mistyped, belongs to nobody, or belongs to somebody else, the lamports are gone: there is no reversal, no support queue and no chain level recovery. Verify the destination on an explorer before you close the first account, and close one account as a test before you batch the rest.
Auditing and reclaiming reserves at the end of a run
The reclaim pass is a short procedure that recovers everything the run locked. Do it as part of shutdown while the wallet list is still accurate, because an audit six weeks later starts with the harder problem of remembering which addresses were yours.
- Freeze the fleet. Confirm the signer is stopped and that no scheduled job will recreate token accounts while you are closing them.
- Rebuild the account list. For every wallet in the run log, list the token accounts it owns. Compare that against the accounts you expected to exist and investigate anything extra.
- Price what is outstanding. Multiply the counts by the reserves for each account type so you know the figure you are trying to recover before you start recovering it.
- Sweep token balances. Move every token balance, including dust, to a collection wallet. Accounts with a non-zero balance cannot be closed, and dust is the usual reason a batch stops early.
- Choose and verify the destination. Pick the wallet that will receive the reserves and confirm the address on an explorer. Use one destination for the whole pass so reconciliation is a single figure.
- Close one account as a test. Close a single token account and confirm the reserve arrived at the destination before you continue.
- Close the rest. Work through the remaining token accounts, keeping a record of which addresses have been closed so a retry does not become a guess.
- Sweep the wallets. Transfer the remaining lamports out of each wallet, leaving enough for the transfer fee itself, then confirm the balances read zero.
- Reconcile against the estimate. Compare what arrived at the destination with the figure from step three. A shortfall is a stranded account, not a rounding error, and it is worth finding while the list is fresh.
- Archive the run. Store the wallet list, the closed account list and the reconciliation in the run archive so the next audit starts from a known position.
The command line covers the whole pass. Below are the calls for querying a minimum by byte count, listing what a wallet owns, checking a token balance before closing, closing an account to a named recipient, and confirming the destination afterwards. Replace the angle bracket placeholders with your own values.
solana rent 0
solana rent 165
solana rent 82
spl-token accounts --owner <PUBKEY>
spl-token balance <MINT> --owner <PUBKEY>
spl-token close --address <TOKEN_ACCOUNT> --recipient <DESTINATION>
solana balance <DESTINATION>Account overhead as a budget line
Once the arithmetic is settled, account overhead belongs in the run budget as two separate lines rather than one. The locked line is wallets and token accounts multiplied by their reserves, and it is recoverable. The spent line is signature fees for creating, funding and closing those accounts, and it is not. Reporting them together produces a number that is wrong in both directions depending on when you look at it.
This holds regardless of who operates the software. Account overhead scales with wallet count and token count, so a fleet run through a hosted Solana volume bot platform locks the same reserves per account as the same fleet run from your own machine, and the reserves are recoverable on the same terms. What differs between the two is who has to reconstruct the figure and from where, not what the figure is.
Reviewing the budget before the run rather than after it also changes decisions. When the locked line is visible, the question of whether a strategy needs sixty wallets or twenty becomes concrete, and so does the question of whether a second traded token is worth the accounts it opens. Preflight is the natural place to check that, and the checks belong alongside the rest of the gate described in preflight before a live run.
Where reserves quietly go missing
Nothing on this page is difficult. What makes reserves disappear is administrative rather than technical, and the same handful of causes account for most of it. Dust is the leading one: a token account holding a fraction of a unit blocks the close instruction, the operator moves on to the next account, and the reserve stays locked in an account that will never be revisited.
Lost wallet lists are the second cause. A fleet generated by a script that was later edited leaves addresses nobody recorded, and the reserves in them are not recoverable in any practical sense once the keys are gone. Recording public keys at generation time, before funding, costs one line in the run log and removes the problem entirely.
Partial shutdowns come third. A run that is stopped rather than closed leaves every account it opened intact, and because the amounts per account are small, nobody notices until the same thing has happened across several runs. Close as part of shutdown, reconcile against an expected figure, and treat a shortfall as a task rather than as noise. The reserves are yours either way; the only question is whether you go and get them.
Questions the desk gets asked
Is rent a recurring charge on Solana?
An account that holds the rent-exempt minimum for its size keeps that balance as a reserve rather than paying it away. The lamports sit in the account. They are returned to a destination you name when the account is closed, so the correct way to think about the reserve is as locked capital rather than as a subscription.
How do I work out the minimum for an account size I do not have a figure for?
Apply the formula. Add 128 to the data size in bytes, multiply by 3,480 lamports per byte-year, then multiply by two years. The result is the rent-exempt minimum in lamports. Divide by 1,000,000,000 to express it in SOL. The command line tool will also report it if you pass the byte count.
Why does an empty wallet still need a balance?
A system account carries zero data bytes but still pays the 128 byte account overhead in the formula, which comes to 890,880 lamports. Below that balance the account is not rent exempt. In practice a wallet also needs lamports for signature fees on top of the reserve, so the reserve alone is not a working balance.
Can I close a token account that still holds tokens?
No. The close instruction requires a zero token balance, so you have to transfer or burn the remaining amount first. Dust is the usual reason a close fails at the end of a run, which is why sweeping token balances to a collection wallet belongs before the closing step rather than after it.
Where does the reserve go when I close an account?
To the destination you specify in the close instruction, which is not automatically the wallet that owns the account. Confirm the destination address before you submit, because the transfer is final and there is no recovery route if you send reserves to an address nobody controls.
Do reserves change with the price of SOL?
The minimum is defined in lamports and is derived from the account size, so it does not move with price. What changes is what that quantity of SOL is worth to you. Budget the reserve in lamports for accuracy and convert to a currency figure only when you report it.