Jupiter swap: Tokens spent, tokens received, and balance reconciliation

Liquidity and token behavior shape the amounts to reconcile

Available liquidity determines the proposed exchange, while token behavior and transaction charges affect how its amounts appear in your accounts. Price impact and slippage concern execution pricing. They do not explain every difference between a displayed quote and a balance change.

A token with an enabled transfer-fee extension can withhold part of a transfer from the recipient's spendable amount. That mechanism differs from a swap fee or a network charge. Apply this distinction only when the selected token and supported transaction actually use it. Naming every unexplained difference "slippage" obscures the movement you need to identify.

The starting record needs accounts and token identities

Before authorization, record the selected input mint, output mint, intended amount, and destination alongside the balances you expect the transaction to affect. The mint address identifies the token. A symbol alone cannot establish which asset a balance represents.

Keep the proposed exchange separate from the starting balances. Include the available input, existing output holdings, and any SOL the transaction requires from your wallet. An absent output token account also matters because creating it may require funding. A wallet snapshot provides context, but other transactions can change it before execution. The transaction's own before-and-after balances provide the tighter comparison.

Route amounts and wallet totals answer different questions

Jupiter's managed execution response separates the amount passing through the swap route from the amount debited or credited to the wallet.

The inputAmountResult field describes the input entering the route after any fee collected in the input token. By comparison, totalInputAmount includes that fee in the wallet's input debit. These fields answer different accounting questions even when their values happen to match.

On the output side, outputAmountResult describes what the route produces before any output-token fee. The totalOutputAmount field reports the final output amount after any fee collected in the output mint. Use the wallet totals when recording tokens spent and received.

The order's feeMint identifies the fee token. An input-token fee equals total input minus route input; an output-token fee equals route output minus total output. Compare each pair in that token's units. These field names describe the managed execution response, so other interfaces may present the same information differently.

Network charges belong beside the exchange amounts

The network charge pays for transaction processing and needs its own entry, even when SOL also forms part of the exchange.

A Solana transaction fee consists of a base fee and any prioritization fee. Transaction metadata reports the charged fee in lamports. Do not add a displayed priority component again if your recorded network fee already includes it. Jupiter's displayed prioritization amount can also include validator tips; account for those separately from the network fee. Attribute the charge to the transaction's actual fee payer before treating it as your wallet's expenditure.

Open full-size image

Separate token-denominated charges also need their own explanation. A fee already included in the recorded input debit must not become a second token outflow when importing the transaction. Preserve its breakdown without counting the same expenditure twice.

Account funding and wrapped SOL explain additional movements

SOL movements can include token-account funding or wrapping, so a wallet's SOL decrease does not always equal the amount exchanged.

Wrapped SOL holds SOL inside a token account and tracks a corresponding token amount above its rent-exempt reserve. A transaction may fund such an account, use it during the exchange, and close it afterward. The exact instructions determine which movements occurred. Counting the native funding and the wrapped token movement as separate spending would count the same principal twice.

Closing a token account transfers its lamports to the specified destination. That return can include account funding rather than proceeds from selling tokens. Keep the destination and closure instruction with the reconciliation. An account remaining open retains its funding, which differs from a network fee already charged for processing.

Exact balance changes require matching units

For a token account, the net change is its post-transaction balance minus its pre-transaction balance, expressed using that mint's decimal precision.

To express a net decrease as a positive amount, reverse the subtraction. With raw balance values, the readable token difference equals the raw difference divided by 10 raised to the mint's decimals. Perform subtraction on the integer amounts before formatting the result. A rounded wallet display can hide a small movement or make a precise comparison appear inconsistent.

Match entries in preTokenBalances and postTokenBalances through the transaction account index and mint. Include ownership when deciding which movements belong to the wallet. Several accounts can hold the same mint, so summing by token name alone is insufficient. Missing balance data also differs from a recorded zero. Account creation or closure requires instruction context before assigning an absent side a zero balance.

Open full-size image

Instruction detail explains the limits of a net balance

A transaction balance change combines every movement affecting that account during the transaction, which can complicate an exchange embedded in another operation.

Transfers between accounts with the same owner can disappear from a wallet-wide total while remaining visible as individual debits and credits. Additional transfers can also make an account's net change differ from the swap amount. Instruction detail helps attribute those movements. Keep the exchange's input and output separate from unrelated actions sharing its transaction.

A positive recorded token balance establishes a holding. Transfer restrictions can still affect whether that holding is available for another operation.

Open full-size image

Keep the amounts reproducible after the wallet display changes

A useful saved record preserves enough detail to reconstruct the exchange without relying on a later wallet screen or a refreshed quote.

Retain the transaction signature, execution outcome, relevant account identities, raw amounts, and decimal precision. Keep the quote separately if you want to compare expectations with execution. A current balance can include later activity, while a current fiat valuation answers a different question from how many tokens the exchange delivered.

Store any unexplained difference alongside the amounts it affects. A complete-looking total should not conceal missing transaction data. For a managed execution record, give each amount an explicit name, such as net output received: totalOutputAmount.