Solana Portfolio Tracking: The Token-Account and Rent Model

Read a Solana wallet like an EVM address and you will get the balances wrong. Solana does not store token balances on the wallet — it scatters them across one account per token, each holding a SOL deposit. This guide is the token-account/rent model and why it changes tracking.

TL;DR

• A Solana wallet (System Account) holds no tokens directly — it owns one SPL token account per token type.
• Each token account holds a SOL rent deposit (~0.002 SOL) to stay active — a real balance component.
• A token account can persist at zero token balance while still holding rent → empty accounts are not nothing.
• Tracking = discover and reconcile every token account, not read one balance mapping.
• Token extensions (Token-2022: transfer hooks, confidential transfers) add behaviour — recognise them.
• Cost basis uses the jurisdiction method as anywhere; the hard part is completeness + internal-transfer classification.

The model: one account per token

On an EVM chain, an address has a balance mapping per token contract. On Solana, a wallet is a System Account that does not hold tokens itself. For each token (mint) it holds, it owns a separate SPL token account — an independent on-chain data structure with its own address. So a Solana "portfolio" is the set of token accounts the wallet owns, not a single balance record.

Tracking therefore starts with discovery: enumerate every associated token account. Missing one is missing a position — the Solana equivalent of an unmapped wallet.

Rent is a balance component

Every account must hold a rent deposit in SOL (~0.002 SOL for a token account) to remain active on-chain. Two consequences for tracking:

• That locked SOL is real, reclaimable balance — it must be counted in the wallet's SOL position.
• A token account can sit at zero token balance while still holding its rent — so "empty" accounts are not nothing.

A scan that ignores empty token accounts both understates SOL and misses reclaimable deposits. Rent is not noise; it is a line in the balance.

Dormant accounts after a sale

After you sell a token, its token account commonly stays open and keeps the rent deposit until explicitly closed. Reconciliation must:

• keep the rent SOL attributed to the wallet;
• treat closing an account as a return of SOL, not income;
• not drop the dormant account from the portfolio view silently.

These orphan accounts are a recurring source of "my SOL doesn't add up."

Token extensions

The Token-2022 program adds extensions — transfer hooks, confidential transfers, and more. An extension-bearing token can behave differently on transfer or expose different visibility. A tracker must recognise extension tokens rather than assume every SPL token is plain. The base model (per-token-account, rent) is unchanged; extensions layer behaviour on top, and a decomposition discipline like DeFi position reconciliation applies to hook-driven effects.

Cost basis is unchanged; completeness is the work

Solana does not change the tax cost-basis method — that is still the jurisdiction-mandated one. What Solana changes is the data model you read it from. The real work is:

• completeness — every token account, including dormant ones;
• internal transfers between your own Solana accounts classified as non-disposals (see internal transfer vs disposal);
• rent correctly attributed, not booked as gain/loss.

Practical guidance

1. Discover every SPL token account the wallet owns — completeness first.
2. Count rent SOL as a balance component; do not ignore empty accounts.
3. Track dormant accounts; treat account closure as a SOL return, not income.
4. Recognise Token-2022 extension tokens — they can behave non-trivially.
5. Apply the jurisdiction cost-basis method as on any chain; classify internal transfers.
6. Reconcile the token-account set to the chain with an audit trail.

How vendor tools handle Solana

Koinly and CoinTracker discover SPL token accounts and surface SOL balances. Confirm the tool enumerates all token accounts (including dormant/empty ones), accounts for rent, recognises Token-2022 extensions, and does not treat account closure or internal Solana transfers as taxable events.

How Wag3s helps

Wag3s Folio discovers every SPL token account a wallet owns, counts rent SOL as a balance component, tracks dormant accounts and closures correctly, recognises Token-2022 extension tokens, and applies your jurisdiction's cost-basis method with internal transfers classified as non-disposals. See the Folio product page.

Further reading

• Multi-Chain Reconciliation
• L2 Accounting: Arbitrum, Optimism, Base
• Crypto Cost Basis Methods 2026
• Internal Transfer vs Disposal in Crypto
• Crypto Bank Reconciliation: Subledger to General Ledger
• Multi-Chain Portfolio Aggregation Beyond EVM

Sources

• Solana documentation — SPL token-account model (a wallet owns a separate token account per mint) and the rent-deposit requirement to keep accounts active
• Token account persistence at zero balance until explicitly closed (rent reclaimable on closure)
• Token-2022 token extensions (transfer hooks, confidential transfers) add behaviour to SPL tokens