Raydium fees vary by pool, while total swap costs include separate Solana charges.

Pool charges and separate SOL spending

A swap’s total cost includes pool charges, network fees and account funding that its path requires. The fee payer supplies SOL for network processing, while supported tokens can impose separate transfer fees.

A usable quote identifies the input mint, output mint, swap amount and relevant amount bound. A mint address identifies the token itself; matching ticker symbols do not establish that two quotes concern the same asset. Pool charges reduce the value exchanged through the pool; additional costs can reach other recipients and use different assets, so they need a common valuation before addition. Keep expected output separate from extra SOL debits. Deducting a pool fee that the quote already includes counts it twice. Account deposits need their own line because they can remain recoverable.

Swap configurations and the charges they apply

Raydium’s swap paths use different pool programs and fee configurations on Solana. AMM means automated market maker; CPMM is a constant-product market maker and CLMM is a concentrated liquidity market maker. The applicable charge follows the actual pool, including its enabled fee features.

Availability depends on the selected token pair and its usable liquidity. A multi-pool route can combine several configurations, so its quote must reflect the complete path. The same pool design can also appear in different routes.

Creator fees and changing pool parameters

A CPMM creator charge requires an enabled creator-fee feature and a nonzero configured rate. The pool’s shared configuration supplies that rate. Its deduction can affect input or output, depending on the pool’s fee mode and swap direction. An enabled flag alone therefore does not establish an additional charge.

Protocol and fund allocations within the trade fee divide that collected charge among recipients. They do not apply their allocation percentages to the entire swap amount.

CLMM pools can charge fees from the swap input or consistently from one designated pool token. In the latter modes, reversing the swap direction can move the deduction to the output side.

A CLMM pool with dynamic fees enabled adds a volatility-based component to its configured base rate. A static tier label alone does not show the dynamic component. Shared fee parameters may also change, so the applicable pool configuration and fresh quote determine the charge for a proposed swap.

Pool depth and the quoted return

Pool depth affects the exchange rate available for a particular amount, alongside the fee that the pool charges. Constant-product pools price swaps against their usable reserves. Concentrated liquidity supports trading within selected price ranges, and available liquidity can change as a swap crosses their boundaries. A pool’s total deposited value therefore does not describe every trade’s available depth.

Price impact describes the effect of the trade itself on pool pricing. It can reduce expected output even before any movement between quoting and execution. Equal fee rates can therefore produce different returns for the same input amount. A small quote and a larger quote also face different liquidity conditions within the same pool. Comparing the intended amount preserves that relationship; extrapolating a tiny swap’s quoted rate can conceal the larger trade’s cost.

Matching quote inputs and execution limits

Fixed-input quotes estimate the output for a specified spending amount; fixed-output quotes estimate the input needed for a specified output target. Comparing them requires a common basis. Keep the same mints, direction and amount definition. The pool program, route and interface determine which swap form is available, so a supported protocol instruction does not establish an interface control.

Execution limits also belong in that comparison. A minimum-output bound limits an input-specified swap, while a maximum-input bound limits an output-specified swap. If execution violates the applicable amount bound, the swap instruction fails. Slippage tolerance allows movement around the quote; it does not set the pool’s trading rate. A wider tolerance can admit a worse execution price. Quotes taken under different market conditions or different bounds cannot demonstrate a fee advantage by themselves.

Does a lower pool fee always mean a cheaper swap?

A lower pool fee does not necessarily make the same swap cheaper. Weaker liquidity or additional route charges can offset the difference. For equal inputs, compare expected output after modeled pool charges alongside extra SOL spending. For equal output targets, compare required input and the permitted input ceiling. Valuing token output against SOL costs requires a consistent reference price. A route’s better quoted return must also satisfy the same amount bounds, including the treatment of any token-level deductions.

Network fees and priority settings

Solana transaction fees pay for network processing, separately from the trading fees that pools collect. Base fees depend on the transaction’s required signatures, while an optional priority fee influences scheduling. The estimate belongs to the prepared transaction. Several swap instructions can share one transaction, and Raydium’s routing program can execute multiple pool hops within that boundary.

For legacy and v0 transactions, the priority fee uses the requested compute-unit limit, not actual compute consumption. A compute unit measures execution work. At a positive per-unit price, a larger requested limit can raise the priority charge. Different transaction budgets can therefore produce different fees even at the same per-unit price. Compare total estimated SOL fees, rather than treating a priority setting’s name as a cost amount.

Account funding and recoverable balances

A new receiving or intermediate token account can require a SOL storage deposit, even for a small swap. The required balance depends on account data size and the active rent rules. An existing usable account avoids that creation deposit. When SOL is also the spending asset, the available balance must cover both the swap input and the transaction’s additional funding requirements.

The storage deposit remains in the account until a permitted recovery operation returns it. Ordinary token accounts generally need a zero token balance before closure; token extensions can add conditions. Wrapped SOL accounts can close with a nonzero token balance to reclaim their underlying SOL. An authorized closure sends the remaining SOL to its specified recipient. If a swap transaction closes a temporary account, that returned balance affects net SOL spending. Closure instructions still require a transaction with a network fee.

Transfer fees on supported tokens

Token-2022 transfer fees arise from a token mint’s configuration and apply separately from pool charges. CPMM and CLMM can handle supported transfer-fee tokens. Compatibility still depends on the mint’s extensions and the execution path. An input transfer fee reduces the tokens credited to the pool vault; an output transfer fee reduces the tokens available in the receiving account.

The mint’s configured rate and maximum fee both affect the deduction. A quoted gross output and a credited spendable amount can describe different quantities. Cost comparisons need the latter, with the quote’s treatment of transfer fees made clear. Pool pricing, token transfer deductions and amount bounds need compatible definitions, because subtracting an output transfer fee again from a quote that already accounts for it understates the expected token credit.

View image file

Unexplained debits and failed attempts

A SOL debit larger than the network-fee estimate can include account deposits or other transfers in the prepared transaction. The fee field and account movements describe separate parts of that debit. Treating the entire wallet balance decrease as a Raydium trading fee misidentifies those costs, especially when SOL itself forms the swap input.

A transaction that executes and fails can still incur a Solana network fee. Its failed instructions do not leave a completed swap: the transaction’s instruction-driven changes roll back. A displayed error or pending notification alone does not establish which charge occurred. The execution record distinguishes a processed failure from a request that never became an executed transaction.

Separate setup transactions have separate outcomes. Successfully created accounts can remain funded when a later swap transaction fails. Additional executed attempts can add network charges, so the paid total may exceed the cost of the eventual successful swap. Refreshing a quote or inspecting an existing record does not require authorizing another exchange.

Final cost from the execution record

The execution record reports network fees separately from token transfers and account funding. Its fee field gives the transaction’s charge in lamports. Token balance changes identify spending and receiving amounts.

The credited output must match the intended mint and receiving account. A current wallet total can include unrelated activity, so the transaction-specific balance change provides the narrower comparison. If the destination account was newly created, its starting token balance is zero; extensions can still affect the spendable credit.

SOL accounting also needs the swap’s actual account transfers, including returned temporary-account funding. One SOL equals 1,000,000,000 lamports. That conversion aligns network records with SOL amounts; it does not value a different token against SOL. A common-value comparison needs the same valuation basis for input, output and additional costs, with recoverable deposits distinguished from consumed fees.

A direct pool swap offers the alternative to a route through several pools when both reach the intended token outcome. The routed path costs less only when its higher quoted output or lower required input outweighs any extra SOL costs under comparable limits. The final record can then show whether the realized output and paid costs matched that comparison.