Why two rent scanners give you different numbers for the same wallet

Paste the same wallet into two rent tools and you get two totals. One says 0.73 SOL, the other says 0.71. People read that as proof that one of them is lying, and occasionally that is true, but the ordinary explanation is duller: the two are answering slightly different questions.

Reclaimable is an estimate, not a balance

The rent in your token accounts is not in dispute. It is on-chain, anyone can read it, and a standard SPL token account holds 0.00203928 SOL. What varies is the judgement call on top of it: which of your accounts will actually close, today, in a transaction you could sign right now.

That is a prediction, and every tool draws the line somewhere slightly different. Here is where.

1. Dust accounts

The biggest single cause. An account holding 0.0000001 of some dead token still holds its full rent deposit, but the close instruction requires a zero balance, so it will not close until that fraction is burned or swapped away.

A scanner that counts those accounts is right about the rent and wrong about what lands in your wallet today. A scanner that excludes them is right about today and quietly hides SOL you could get with one extra step. Both are defensible. Burn or swap covers which extra step is worth taking.

2. Frozen accounts

Widely stated wrongly, including by us. A frozen account can be closed, as long as its token balance is zero. Freezing blocks transfers and burns, not the close instruction.

So frozen and empty is reclaimable. Frozen with a balance is genuinely stuck, because you cannot clear the balance to reach zero. A tool that excludes every frozen account reports a lower number than one that checks the balance first. SolanaSweeper currently skips all frozen accounts, which is the conservative side of that line and means our estimate can come in under a competitor's without either being wrong.

3. Token program coverage

There are two token programs on Solana, the original SPL Token program and Token-2022. A wallet that has been active since 2021 usually has accounts under both, and a scanner that queries only the first silently misses the rest.

Token-2022 adds a second trap. A mint can carry a transfer fee extension, and when you sell out of such a token the balance reads zero while a withheld fee stays inside the account. Closing it fails with custom program error: 0x23 until the withheld amount is harvested to the mint. A tool that does not harvest first will list the account as reclaimable and then fail on it.

4. Metadata accounts

An NFT is two accounts: the token account and a separate metadata account, each with its own rent. They are closed by different instructions in different programs.

A tool that only closes token accounts recovers the smaller half and leaves the metadata rent behind. A tool that does both reports a higher number for the same wallet. Again, both are counting honestly, they are just counting different things.

5. Compressed NFTs

This one has a right answer. Compressed NFTs do not live in individual accounts; they are leaves in a Merkle tree, with one on-chain account covering thousands of items. There is no per-item rent deposit, so there is nothing to reclaim.

Any tool advertising meaningful SOL recovery from compressed NFTs is either confused or counting on you not checking. The arithmetic does not exist.

6. Gross versus net

The most boring reason and probably the most common. One tool shows the rent that comes out of the accounts, the other shows what reaches your wallet after its fee. Comparing those two is comparing a price before tax with a price after it.

A worked example: a 0.0186 SOL gap between two tools is about nine accounts at 0.00204, which points at scope. A gap that is a clean percentage of the total, on the other hand, is a fee, not a disagreement about your wallet.

7. New in 2026: not every account holds the same rent

Rent is being cut in steps. The rent-exempt minimum has already dropped from 6,960 to 6,333 lamports per byte, which takes a new token account from about 0.00204 SOL to about 0.00185 SOL, with further steps to come.

Accounts opened before the change still hold the old amount, and closing one still returns the full 0.00204. So a scanner that multiplies your account count by a hardcoded constant will drift from one that reads the actual lamports per account, and that drift grows with every step. The rent cut has the details.

How to settle it in ten seconds

Ignore both headline numbers and read the transaction preview. Your wallet shows the instruction list before you sign: count the closes, multiply by the rent, subtract the stated fee. That number is not an opinion, and it is the only one that has to be right.

If a tool will not show you what it is about to sign, that is the finding, not the total. How to read the transaction walks through the four instructions worth recognising.

The short version

• Dust accounts hold rent but will not close until emptied.
• Frozen and empty closes fine. Frozen with a balance does not.
• Missing Token-2022 accounts means missing rent.
• NFT metadata rent is a separate account and a separate instruction.
• Compressed NFTs hold no reclaimable rent at all.
• Check whether you are comparing before-fee with after-fee.
• Old accounts hold more rent than new ones, and that gap is widening.

Two tools disagreeing is normal. A tool that cannot explain why it disagrees is the one to be careful with.