Raydium fees and the quote details that shape swap cost

Cost entries in the current quote

Four cost entries can affect the completed swap, although they do not use the same unit or reach the same recipient. Record the live value beside its route or transaction context. Pool and mint charges affect token amounts, while Solana charges come from the fee payer's SOL balance. That distinction prevents a low pool rate from obscuring the swap's other costs.

Price impact belongs in the comparison even though it is not a fee. It describes how the requested size interacts with available liquidity and changes the exchange rate. Slippage tolerance is also separate: it sets an execution boundary rather than charging another percentage. Compare final output and SOL spent instead of adding every displayed percentage as though each one were a fee.

Slippage boundaries before execution

For an exact-input quote, the minimum received amount is a rejection boundary, not an extra charge. It defines how far execution may move from the quoted output before the transaction must fail.

Expected output

Expected output comes from the chosen input, pool state, route, and applicable fee settings. A fresh quote can change when another transaction alters liquidity or price before approval. The estimate is specific to that proposal and timestamp. It does not reserve liquidity or guarantee that the same route will remain preferable when the wallet signs.

Minimum received amount

The minimum received amount applies the selected slippage tolerance to the quote's output boundary. If execution would cross that floor, the swap should revert instead of settling at the worse amount. A wider tolerance does not lower the pool fee or improve the quoted rate. It permits a larger adverse movement and changes the execution limit before signing, while you can still reject the proposal.

View full-size image

How does route shape change the quoted output?

Route shape changes output because each selected pool applies its own curve, liquidity state, and configured fee. A direct route uses one pool calculation. A multi-hop route passes the first pool's output into the next pool, so the later calculation begins with an amount that already reflects the earlier hop's fee and price movement.

Raydium's router does not add a separate routing fee. Each child pool handles its own charge, and the quote incorporates those deductions into the expected final amount. A route with more hops is not automatically worse; it can still produce more output if access to different liquidity outweighs the added pool charges. The useful comparison is the same input against final output, not the hop count alone.

Priority fees and transaction landing

The priority setting affects the Solana network fee without changing the pool's exchange rate. The network fee contains a signature-based base component and may contain a priority component. Paying more for priority can improve the likelihood of earlier scheduling during congestion, but it does not increase pool liquidity, reduce price impact, or raise the quoted token output.

For legacy and v0 transactions, the priority fee uses the requested compute-unit limit rather than the units actually consumed.

The fee payer can therefore pay for unused compute units when the requested limit is unnecessarily high and the unit price is positive. The transaction record provides the authoritative paid fee after submission. Solana can collect that network fee even if execution fails, because validators still processed the signed transaction. A higher priority setting improves scheduling odds rather than guaranteeing confirmation or successful swap execution.

When do token and account costs appear?

Token rules and account state can add costs beyond the selected pool's trading fee. A compatible Token-2022 mint may carry a transfer-fee extension that deducts an amount when tokens move. The mint configuration sets its rate and maximum charge, not the pool fee tier. If either side uses that feature, read the quote's send amount, receive amount, and transfer-fee line together.

The fee payer may also need SOL when the transaction creates a token account for the output mint. That SOL funds the account's rent-exempt balance; it is not a Raydium trading fee. The balance may be recoverable if the account is later eligible for closure, while the transaction fee itself is not recovered. Existing account state determines whether this extra funding appears.

Evidence in the transaction record

The transaction signature connects the accepted proposal with the settled state. Use its status, network fee, account changes, and token balance deltas before attributing a difference to one fee.

Successful execution

A successful record confirms that the instructions committed on Solana. Compare the input-token decrease and output-token increase with the quote, allowing for any displayed mint transfer fee and account creation. Then compare the SOL decrease with the recorded transaction fee and any rent-exempt account funding. This separates exchange deductions from network spending without converting unlike units into one percentage.

Failed execution

A failed record does not commit the pool swap or its token balance changes. The fee payer can still lose the Solana network fee because the transaction was processed. Read the error and transaction fee together before retrying. A new attempt needs a current quote, since the original pool state, route, or fee configuration may no longer describe an executable proposal.

Stale wallet display

A successful transaction can reach the ledger before a wallet refreshes its displayed balances. The on-chain status and pre-transaction and post-transaction token balances distinguish a delayed interface from missing output. Refreshing the view does not alter settlement. If a new token account was created, confirm that the wallet is displaying the correct mint and account rather than treating the output as absent.

Quote-to-output reconciliation

Reconciliation begins with the accepted input amount and the route attached to it. Preserve the quoted expected output, minimum received amount, per-hop fee details, any mint transfer charge, and the proposed network setting. After confirmation, record the actual token deltas and paid SOL fee. These values answer different questions, so keep their denominations intact rather than converting everything into a single headline rate.

Subtracting the actual output from the quoted output isolates the execution difference, but it does not identify the cause by itself. Check whether the quote already included pool and transfer fees, whether the route changed before approval, and whether account funding explains part of the SOL movement. Price impact belongs to the quoted exchange rate, while priority and base fees belong to transaction processing.

Like-for-like quote comparison

A useful comparison keeps the proposed exchange constant and changes only the factor under review. This preserves the evidence needed to explain why one quote delivers a different net outcome.

Fixed comparison inputs

Hold the input mint, output mint, input amount, and slippage setting constant when comparing two routes. Record each route's expected output, minimum received amount, pool hops, fee tiers, and network estimate at the same stage of review. If token-account creation appears in only one proposal, identify it separately because that funding reflects account state rather than a better or worse pool price.

Final evidence match

After execution, match the accepted route to the transaction signature, then reconcile token and SOL balance changes. The lower-cost proposal is the one that meets the intended output boundary with the better net outcome under identical inputs, not simply the one showing the smallest fee percentage. A later quote belongs to another pool state and should be treated as a separate offer.