Solana rent, token accounts, and hidden cash flows

The short answer

SPL tokens do not sit directly in the wallet's system account. They sit in token accounts, each tied to a mint and an owner authority. Creating one requires enough lamports to keep the account rent-exempt. Those lamports leave the funder's spendable SOL balance, but they are an account deposit—not automatically a permanent trading expense.

If an eligible token account is later closed, its remaining lamports are sent to a chosen destination. Wrapped SOL adds another layer: SOL is held as lamports inside a token account and exposed to Token Program instructions as WSOL. Opening, syncing, and closing that account can make a swap's native balance changes look larger or smaller than the economic trade.

Wallet address, token account, and ATA are different

Because the token program address participates in ATA derivation, the legacy Token Program and Token-2022 can derive different associated accounts for what otherwise looks like the same wallet and mint input. Verify mint, owner, token program, and account address together.

Account creation changes native SOL before the trade is measured

Creating a token account allocates account data and funds its rent-exempt minimum. The transaction may create the output ATA immediately before the swap, or another wallet may have created it earlier. The funding account—not necessarily the token account's owner—absorbs that SOL outflow.

A quote can include account-creation instructions without presenting the deposit as an AMM fee. Inspect the instruction list and pre/post lamport balances. If the output account already exists, a later quote for the same swap can appear cheaper even when the pool and route are unchanged.

Use the current rent minimum, not a memorized constant

Solana's rent-exempt minimum depends on account data length. Token extensions can change account size, so one copied “ATA cost” is not a safe universal value. The official getMinimumBalanceForRentExemption RPC method returns the required lamports for a given data length.

For accounting, tag that outflow as locked account capital while the account remains open. If it is later returned through a close instruction, recognize the rent refund against the same account lifecycle rather than treating it as trading revenue.

Closing determines whether the deposit comes back

The Token Program's CloseAccount instruction transfers the account's lamports to a destination and removes the token account. A standard token account generally must have a zero token balance before it can close, and the proper close authority must sign. Empty does not mean closed; verify the close instruction and destination balance.

Wrapped SOL token accounts are the important exception: they can be closed while carrying a token amount, returning the underlying lamports to the destination. A terminal may create and close a temporary WSOL account inside one atomic swap, or it may leave a persistent WSOL account behind. Those produce different-looking native balance deltas for the same economic input.

WSOL is SOL represented through a token account

A WSOL account holds native SOL in its lamport balance while its token amount tracks the spendable wrapped portion above the rent-exempt reserve. After SOL is transferred into that account, SyncNative updates the token amount to match the lamports available above the reserve.

This is why “SOL left the wallet” is not enough to identify a purchase. The SOL may have moved into the wallet's own WSOL token account, from that account into a pool, back from a pool, and then out again during close. Follow instruction-level flows and token balance changes, not just the top-level system-account delta.

Reconcile native SOL with an explicit equation

Compute token deltas separately for every mint and token account. Then pair actual swap input and output using program instructions and balance changes. The residual SOL should reconcile to fees, tips, accounts, WSOL, and transfers—not be forced into realized P&L.

Solana fees are charged even when a transaction fails, while the atomic instruction set leaves no partial swap state. A failed transaction can therefore create a negative SOL delta with zero token fill and no surviving account creation from that same reverted transaction.

Common reconstruction mistakes

What the journal should preserve

1. Every created token account: address, mint, owner, token program, payer, and lamports funded.
2. Every closed account: authority, destination, lamports returned, and remaining token state.
3. WSOL transfer, SyncNative, swap, and close instructions in their actual order.
4. Base fee, priority fee, Jito or other tip, and transaction success status.
5. Per-account token deltas and the reconciled native-balance equation.

Primary sources