How to Claim SOL From Empty Solana Token Accounts

Claiming SOL is not an airdrop and not a reward. It is closing the empty token accounts your wallet left behind — each one still holding the refundable rent deposit, about 0.002 SOL, that was paid the day it was opened.

Every token you have ever received on Solana got its own on-chain account, and every one of those accounts had to be funded with a small SOL deposit before it could exist. Sell the token, send it away, watch it go to zero — the account stays open and the deposit stays inside it. Nothing on the network cleans this up. A wallet that traded through one memecoin season is usually sitting on dozens or hundreds of these, and the total is money you already own.

This article covers the whole mechanism: where the deposit comes from, why it is refundable, how Solana's rent rules changed on the way to the 90% rent cut rolling out right now, how much a wallet can realistically expect, and exactly how the close-and-refund works — with a wallet, on the command line, or with the reclaim tool I built. If you only came for the SOL, the box below is the short version.

What "Claiming SOL" Actually Means

Search for claim SOL and you will find two very different things under one phrase: the mechanism this article is about, and a pattern of pages that use the phrase to get at your seed phrase. So it is worth being exact.

On Solana, every account must hold a minimum SOL balance in proportion to its size to stay on the chain. That balance is called rent, but for years it has behaved as a refundable storage deposit: it is not spent, it is not charged per epoch, and it comes back in full when the account is closed. "Claiming SOL" is closing an account you own and receiving its deposit. The accurate verb is reclaim — the SOL was always yours; the runtime was holding it as a bond for the bytes the account occupied.

Three different kinds of account get bundled under the phrase, and they are separate operations with separate amounts:

• Empty token accounts. The common case and the subject here. Each returns about 0.002 SOL. You reclaim it by closing the account.
• Wrapped SOL (wSOL) accounts. Left over from swaps. The account holds SOL as a token plus its own deposit, and closing it returns both. You unwrap it.
• Program buffer accounts. A developer-side leftover from failed deploys, holding rent for an entire program binary — often several SOL each. You recover it.

What it is not: staking rewards, an airdrop, or "free SOL". Nobody gives you anything. And nobody can do it for you either — closing an account requires a signature from the account's owner, which is exactly why any page that offers to claim SOL on your behalf in exchange for a seed phrase, a "wallet sync" or a deposit is a drainer. The section on what can go wrong comes back to this.

Why There Is SOL to Claim: One Account per Token, One Deposit per Account

Solana does not keep your token balances inside your wallet account. Your SOL lives in a system account; every SPL token you hold lives in a separate token account — usually the associated token account, an address derived from your wallet and the token's mint. This is the design that lets the runtime process unrelated transactions in parallel, and it is also why a busy wallet quietly owns hundreds of accounts.

Each of those accounts stores 165 bytes of data, and each must be rent-exempt: it has to hold at least two years' worth of rent at the network's rate, computed over its data plus 128 bytes of runtime overhead. At the rate Solana used from launch until September 2026, the arithmetic for a token account is:

Whoever creates the account pays that deposit. When you buy a token on a DEX for the first time, the swap transaction creates your token account and the deposit comes out of your wallet — which is why the first purchase of any token costs about 0.002 SOL more than the second. When a project airdrops a token to you, the sender pays. Either way, the deposit belongs to the account, and the account belongs to you: when it is closed, the lamports go wherever its owner directs them.

Here is the stacking. Sell the token to zero, and the account is now empty — zero tokens, 2,039,280 lamports — and still open. Buy another token, and a new account is created with a new deposit. Nothing ever closes the old one: not the DEX, not the wallet, not the runtime. Fifty tokens over a season means about 0.1 SOL parked in empty accounts; three hundred means about 0.6 SOL; a bot cycling through a thousand tokens is holding about 2 SOL. Token-2022 accounts carry extensions and are slightly larger, so their deposits run slightly higher.

How Solana Rent Got Here: From a Per-Epoch Charge to a Refundable Deposit

Rent has changed meaning three times, and each change is part of why the deposit is still sitting there. The steps, in order:

• Rent as rent. At launch, an account below the exemption threshold was charged rent every epoch, and an account that ran out of lamports was deleted. Accounts holding two years' worth — the rent-exempt minimum — paid nothing. The rate was set at 3,480 lamports per byte-year, and it stayed there for years while the SOL price did not.
• Exemption becomes mandatory. Solana then required every new account to be rent-exempt from the moment it is created, and no new rent-paying account could be made. From that point the deposit was the entire mechanism: pay it once, hold it for the life of the account, get it back on close.
• Collection switched off — SIMD-0084. With no rent-paying accounts being created, the collection code was removed from the validator entirely: no account is charged rent, and none of it flows to validators. The word survived; the charge did not.
• The deposit itself gets cheaper — SIMD-0437. In 2026 the network began cutting the rate behind the deposit by 90%, in five feature-gated steps. The next section is about this.

Notice the pattern. Every step either made the deposit cheaper or made the charge disappear. None of them ever took a lamport out of an existing account, and none of them puts one back. The deposit you paid at the rate of the day is exactly what your account still holds — and exactly what comes back when you close it.

The 2026 Rent Cut: Five Steps, and Why Old Accounts Keep the Old Deposit

SIMD-0437 lowers the rate from 6,960 to 696 lamports per byte, but not in one move. Each of the five reductions is its own feature gate, switched on by the network when the validators are ready, so the rate steps down over months. Here is the schedule with the deposit a standard token account needs at each step:

Statuses move; the upgrades tracker reads the feature-gate accounts from the chain every minute and shows which step is live on which cluster. The Solana Foundation's own framing of the end state: a standard token account deposit goes from about $0.159 to about $0.016 at their reference price, which is what turns funding accounts for a million new users from a budget line into a rounding error.

Now the detail that matters for claiming. The cut is strictly a relaxation of the minimum. An account is allowed to hold less than before; nothing forces it down, and the chain moves no lamports on activation. And the close instruction returns the account's actual balance, not the current minimum. So:

For an account you still use, the same asymmetry shows up as a surplus: after step 1 a token account holds about 0.00018 SOL more than the network now requires; once all five steps land, the surplus is about 0.00184 SOL. Both token programs have a standard instruction that withdraws the excess down to today's minimum without closing the account or touching its tokens; the owner signs, and the difference lands in the wallet. It is tiny per account and only worth a signature in bulk — the rent surplus tool does it for every held account in one run. One warning for people who created tokens: a mint's surplus can only be withdrawn by its mint authority, and revoking that authority locks it away for good.

The economics of the cut — what it does to airdrop costs, ZK compression and mint pricing — are in the companion piece, Solana's 90% Rent Cut: The Economics of SIMD-0437. This article stays on the claiming side.

How Much SOL Can You Actually Claim?

Per account the answer is fixed: 0.00203928 SOL for a standard token account created before September 3, 2026, and the step's minimum for anything created after. The total is a count, so the honest answer is it depends on how many tokens you have held. Some reference points, each just count × 0.00204:

• 50 empty accounts — a light season of trading — about 0.1 SOL.
• 300 empty accounts — an active memecoin wallet — about 0.6 SOL.
• 2,000 empty accounts — a sniper or a bot — about 4 SOL.
• The largest I have scanned: 72,592 empty token accounts holding 148.9 SOL, with 8,210 accounts still holding tokens and left alone — read on September 6, 2026. The scan is public, so the current figure is one click away.

Do not expect the network to tell you. Wallets show a SOL balance, not a deposit inventory; the only way to know is to read the token accounts the wallet owns and add up the lamports in the empty ones — which is what a scan does. And keep the other places in mind: wrapped SOL you never unwrapped, an emptied liquidity position that was never closed, a lookup table a bot stopped using, a failed program deploy. Those are separate operations at separate scales, and the eleven-check scan reads all of them from one address.

How to Claim Your SOL, Step by Step

Under every method is the same instruction. The token program's CloseAccount requires the account's token balance to be zero (wrapped SOL is the one exception), requires a signature from the account's owner or close authority, sends every lamport in the account to a destination you name, and the runtime deletes the account at the end of the transaction. Your wallet signs it; no one else can. That single fact is both the security model and the reason no service can "claim" for you.

With the reclaim tool

• 1. Open the tool and connect. The scan starts as soon as a wallet is connected: it reads every token account the wallet owns and lists the empty ones — token name, and the exact lamports each holds. Accounts still holding tokens are counted and left alone. Accounts that cannot be closed right now are listed as skipped, with the reason: frozen by the issuer while holding a balance, a close authority held by someone else, or a confidential balance that has to be settled first.
• 2. Read the breakdown. The panel shows the gross total, the service fee (a percentage of what comes back — 5% at the time of writing), the estimated network fee, and the line that matters: You receive. Everything is pre-selected up to what one operation can carry — 220 accounts at the time of writing — and you can untick anything. A wallet with thousands of empty accounts runs the operation in rounds.
• 3. Sign. The selected accounts are packed into a batch of transactions, and your wallet asks you to approve each one in turn. A wallet flags a chained batch as suspicious when it cannot simulate the second transaction against the state the first one leaves behind, so the tool asks for one approval per transaction instead. The service fee is paid out of the SOL coming back, inside the same transaction, so the wallet only needs enough SOL for the network fees. If a hardware wallet takes longer than the network's transaction window (about 45 seconds at today's slot times), the tool rebuilds the batch and asks once more.
• 4. Watch it land. The SOL arrives as each transaction confirms. The tool follows the batch and reports what went through; a transaction that did not land changes nothing, so a rescan simply shows those accounts again.

Want to see the number before connecting anything? Paste any address into the read-only check: it reads public chain data and shows the same breakdown, with nothing to sign. Only the owner can act on what it finds.

On the command line

If you keep a keypair on disk, the SPL Token CLI has a garbage-collect command that closes every empty token account the keypair owns and pays nothing but network fees:

# close every empty associated token account the keypair owns
spl-token gc --close-empty-associated-accounts

# or one account at a time
spl-token close --address <TOKEN_ACCOUNT_ADDRESS>

It is the right tool for a developer wallet. It is not the right tool for a wallet whose key lives in a browser extension or a phone, because it needs the key file.

From the wallet itself

Some wallets can close a single empty token account from that token's own menu. That is fine for two or three; for two hundred it is an afternoon, and it will not surface accounts the wallet has already hidden from the token list. Whichever route you use, the instruction is the same and so is the refund.

What Can Go Wrong, and What to Never Do

• The seed phrase test. Scanning needs a public address; closing needs a signature you can read in your own wallet. Anything that asks for a seed phrase, a private key, a "wallet sync", a validation step, or a small deposit to "unlock" a larger claim is theft with a landing page. Close the tab.
• Accounts holding tokens are never closed. The instruction fails on any non-zero balance, so nothing you still hold is at risk. The flip side: an account with a dust balance of a dead coin is a held account until you sell or burn the dust yourself. The reclaim tool closes empty accounts only; it does not burn anything.
• Token-2022 has extra states. An account still holding withheld transfer tax hands that tax back to the token's mint first and then closes — the deposit comes back in full. An account with a confidential balance has to be settled before it can close. An account frozen by the issuer while holding a balance stays where it is; that is the issuer's call, not the tool's.
• Wrapped SOL is the one account you close with a balance. Closing a wSOL account returns the wrapped SOL and the deposit together. It is listed separately in the scan and handled by the unwrap tool, because it is not an empty account.
• Network fees are real, and yours. Every transaction costs the base fee per signature (5,000 lamports) plus whatever priority fee is attached — a rounding error against the deposits, but a wallet holding literally zero SOL cannot sign the first one. The tool checks the balance before it asks.
• A partial batch is not a partial loss. A transaction that fails to land changes nothing in the accounts it carried; they simply show up again on the next scan.

Is There Any Reason to Wait?

The deposit does not expire, the accounts are not going anywhere, and the network will never close them for you or against you. In that sense there is no deadline. But the rent cut has changed what waiting means: the accounts you already own are funded at ten times the rate of anything created after the final step, so the old inventory is the valuable one, and it is fixed. If you plan to keep trading, the sensible order is to close the old accounts now and let the new, cheaper ones accumulate on their own schedule. The only real cost of waiting is the same one that put the SOL there in the first place: forgetting.

Claim SOL: Questions People Actually Ask

The SOL Is Already Yours

Everything above reduces to one sentence: Solana asked your wallet for a deposit every time it opened an account, never took it, and never gave it back on its own. The empty accounts are still there, the deposits are still in them, and a signature you can read is all that separates the two. The rent cut has made those old deposits the most valuable ones the network will ever hold — and it has not started a clock. Close them when you are ready.

Sources: the SIMD-0437 proposal, Solana's reduced-rent upgrade page, the Solana Foundation's rent-reduction analysis, the SIMD-0084 proposal, and the Solana account docs for the deposit formula. Rent-step statuses are as read on September 6, 2026.