Solana Portfolio Tracking: The Token-Account and Rent Model

What makes Solana tracking distinct is that the wallet you import does not hold your tokens. A Solana wallet is a System Account; for every SPL token it holds it owns a separate token account at its own address, and each of those carries a small SOL rent deposit that survives even after the token balance hits zero. Add staked SOL sitting in separate stake accounts, and the "balance" of one Solana wallet is really a set of accounts you have to enumerate. This article covers what that token-account-plus-rent model changes for discovery and reconciliation, and why an EVM balance reader gets a Solana wallet wrong. For tracking across non-EVM chains together, see the multi-chain aggregation hub.

What is different about Solana

• A Solana wallet (System Account) holds no tokens directly. It owns one SPL token account per token type, each at its own address.
• Each token account holds a SOL rent deposit (around 0.002 SOL) to stay active, so that locked SOL is a real, reclaimable balance component.
• A token account can persist at zero token balance while still holding its rent, so empty accounts are not nothing.
• Tracking means discovering and reconciling every token account plus any stake accounts, not reading one balance mapping.
• Token-2022 extensions (transfer hooks, confidential transfers) add behaviour a tracker must recognise.
• Cost basis uses the jurisdiction method as on any chain; the hard part is completeness and 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 (around 0.002 SOL for a token account) to remain active on-chain. Two consequences for tracking:

• That locked SOL is real, reclaimable balance, so 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, which is still the jurisdiction-mandated one. What Solana changes is the data model you read it from. The real work is:

• completeness across 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 or loss.

Practical guidance

1. Discover every SPL token account the wallet owns; completeness comes 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, which 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.

Choosing a tool for the token-account model

Koinly and CoinTracker both discover SPL token accounts and surface SOL balances, but the Solana-specific things to check before you trust the figures are:

• it enumerates every token account the wallet owns, including dormant or empty ones, rather than only those with a non-zero token balance;
• it counts the rent SOL locked in those accounts as part of the wallet's SOL position, and treats closing an account as a return of SOL rather than income;
• it includes SOL held in separate stake accounts, which a wallet-balance-only read misses;
• it recognises Token-2022 extension tokens instead of assuming every SPL token behaves like a plain one;
• it does not book an internal transfer between two of your own Solana accounts as a taxable disposal.

A tracker that ignores empty token accounts will both understate your SOL and lose the acquisition history recorded in those accounts.

How Wag3s handles Solana wallets

Wag3s Folio treats a Solana wallet as the set of accounts it actually is: it discovers every SPL token account, counts the rent SOL (and stake-account SOL) as balance, tracks dormant accounts and closures correctly, recognises Token-2022 extension tokens, and applies your jurisdiction's cost-basis method with internal Solana transfers classified as non-disposals. See the Folio product page.

Step-by-step: auditing a Solana wallet for completeness

When onboarding a Solana wallet for accounting or tax purposes, the following sequence ensures no position is missed.

Step 1 — Enumerate all associated token accounts. Use the Solana JSON RPC method getTokenAccountsByOwner with the wallet's public key and the Token Program ID (TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA) as the program filter. This returns every SPL token account owned by the wallet. Repeat the call with the Token-2022 Program ID (TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb) to enumerate any Token-2022 accounts. Do not assume a wallet has only one type of token program.

Step 2 — Check each token account's state. For each token account returned, note: the mint address (which token it holds), the current token balance, the current SOL balance in the account (rent), and whether the account is initialised, frozen, or closed. A zero-token-balance account with non-zero SOL is a dormant rent account — it must be included in the SOL balance.

Step 3 — Aggregate the SOL balance correctly. The wallet's total SOL position is the sum of: SOL held in the System Account (the wallet's own balance), plus SOL held in rent deposits across all token accounts (including dormant ones), minus any outstanding SOL that has been staked (in stake accounts, which are separate accounts). A common error is to read only the System Account SOL balance and ignore all the rent deposits scattered across token accounts.

Step 4 — Identify the acquisition and transfer history. For each token with a non-trivial balance, pull the full transaction history for the associated token account. On Solana, each token account has its own history (not the wallet-level history). The transaction history includes: initial funding (the transfer-in that first populated the account), subsequent receives and sends, and any Token-2022 transfer-hook events if applicable.

Step 5 — Classify each transaction as acquisition, disposal, or internal transfer. A transfer from another wallet controlled by the same entity is an internal transfer, not a taxable event. Identify all wallet-to-wallet transfers within the controlled population and classify them as internal. A transfer to a DEX smart contract address is typically a swap — classify as a taxable disposal in jurisdictions that treat crypto-to-crypto swaps as taxable.

Step 6 — Apply cost basis per jurisdiction. With a complete acquisition-and-disposal history, apply the cost-basis method required by the jurisdiction (FIFO, LIFO, average cost, or specific identification). Solana does not dictate the method — it provides the transaction data.

Step 7 — Reconcile the final balance. After building the full history, verify that the sum of all receives minus all sends equals the current token-account balance. Any discrepancy indicates a missing transaction. Solana RPC nodes can sometimes miss transactions in long histories; cross-reference with a block explorer (Solscan, SolanaFM) for any gap periods.

Configuration checklist for Solana portfolio tracking

• Enumerated all SPL token accounts (Token Program) owned by the wallet
• Enumerated all Token-2022 accounts owned by the wallet
• Included rent deposits in the SOL balance for all token accounts, including zero-token-balance ones
• Identified dormant accounts; account closures classified as SOL returns, not taxable events
• Classified all wallet-to-wallet transfers within controlled population as internal transfers
• Applied jurisdiction cost-basis method across full transaction history
• Reconciled computed final balance to current on-chain balance per token account

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 — SPL Token Basics and the Token program: a wallet owns a separate token account per mint, and accounts must hold a rent-exempt SOL deposit to stay active.
• Solana — Associated Token Account: the derived per-owner-per-mint account whose rent persists until the account is closed.
• Solana — Token-2022: the token-extensions program (transfer hooks, confidential transfers) that adds behaviour on top of the base SPL token model.
• IRS — Digital assets for the US cost-basis and disposal framework that applies to the data, not the chain.