Raydium fees can be traced from a route quote to the confirmed transaction and resulting balances

Raydium fees combine the trading charges of every pool in the selected route with Solana network fees and any token-specific transfer charge. Before signing, compare the selected input and output mints, amount mode (whether the input or output amount is fixed), route, expected output, price impact, and slippage boundary. Then use the confirmed transaction and resulting balances to separate the token exchange, the SOL transaction fee, and any SOL used to create an account. Insufficient SOL, an incompatible token, an incompatible receiving account, or a stale quote should stop a first attempt before authorization. These distinctions prevent every difference between input and output from being mislabeled as a fee.

Bottom line: Compare the quoted net output with the confirmed transaction and final balances, while keeping pool, network, and token charges separate.

Pool, network, and token charges on a like-for-like quote

Pool charges affect the exchange calculation, while network charges debit SOL from the transaction's fee payer. A token transfer charge can further change how much reaches a pool or receiving account. Those amounts use different units and bases, so one percentage cannot represent the whole cost.

A like-for-like comparison holds the selected amount, input and output mints, amount mode, and slippage setting constant. It also keeps the priority setting consistent. Compare the final quoted output or required input after checking whether the route uses one pool, several sequential pools, or a split across pools. A route with a lower fee rate can still return less output when its liquidity creates greater price impact.

Automated market maker (AMM) v4 pools normally charge 0.25% of input volume, although a small number of early pools use different stored parameters. Constant-product market maker (CPMM) and concentrated-liquidity market maker (CLMM) pools use configuration tied to the selected pool, so their live rate belongs to the quote rather than a universal Raydium rate. Allocating a trading fee among liquidity providers and protocol accounts does not create another user charge. A separately enabled pool fee can add its own charge.

The quote as the first cost snapshot

A useful quote records the terms that can change before execution. It should identify the input and output mints, exact-input or exact-output mode, route, pool charges, expected result, and slippage boundary. If a supported token applies a transfer fee, its effect also belongs in the net amount being compared.

• Confirm both mint addresses rather than relying on names or icons.
• Read the route and every pool fee applied along it.
• Keep expected output separate from the minimum acceptable output.
• Note price impact as a market effect, not another fee line.
• Review the SOL debit for the transaction before approving it.

The quote is a snapshot of pool state, not a reservation. Liquidity and prices may change while the transaction waits. A refreshed quote therefore replaces the earlier comparison, and any newly selected route must be reviewed on its own terms.

What must be funded before submission?

The fee payer needs enough SOL for the network charge, while the wallet needs the spendable input amount required by the quote. Exact-output mode may require a maximum input that is higher than the quoted estimate because its slippage protection bounds the input side. Exact-input mode instead fixes the amount spent and protects a minimum output.

A receiving token account may also be required for the output mint. If that account does not exist, its creation can require a rent-exempt SOL balance in addition to the transaction fee. That balance funds an on-chain account and is not a Raydium trading charge. It can generally be reclaimed when the eligible account is empty and closed.

Compatibility is another prerequisite. The selected route, token programs, wallet, and receiving account must support the transaction being assembled. If the preview introduces an unexpected account creation, fee payer, or token mint, rejecting the request is the reversible stop.

Pool fees follow the selected route

Raydium can route an exchange through a single pool, through sequential pools, or across split paths. The routing layer does not add a separate trading fee. Each participating pool applies its own configured charge, and the route calculation carries the reduced amount forward.

One-pool routes

A direct route has one pool fee calculation. Its quoted result still depends on the pool curve, available liquidity, trade direction, rounding, and any applicable token transfer behavior. The displayed rate alone cannot predict the final output because price impact is determined by the amount relative to usable liquidity.

Routes with several pools

A route that crosses several pools charges at each hop. Since one hop's output becomes the next hop's input, the charges compound through different token units. Adding the displayed percentages as though they shared one base can therefore misstate the cost. The final quoted output is the useful common measure.

Per-hop charging

Each hop applies the fee and curve rules of its own pool. A split route likewise sends portions of the input through different pools, then combines the resulting output. Review the complete route because an attractive fee on one leg does not describe the other legs.

Final output protection

In exact-input mode, the transaction checks its minimum-output boundary after the routed pool calculations. If the protected route amount falls below that boundary, the swap fails. An output token's transfer fee can still reduce the amount credited to the receiving account. A processed failure can still consume the Solana transaction fee even though the exchange does not complete.

Price impact and slippage beside the fee lines

Price impact is the quote's change from the pool curve as the requested amount moves the market. Slippage tolerance sets the worst acceptable movement between quotation and execution. Neither is an added recipient fee. Raising tolerance does not reduce pool or network charges; it permits a wider execution range and may accept a less favorable result. Compare routes by net output under the same input and settings, while reading price impact as part of the exchange rate rather than a debit paid elsewhere.

Solana base and priority fees remain separate

A processed Solana transaction pays a base fee, and it may add an optional priority fee. The base component reflects the signatures that the runtime verifies. The optional component bids for scheduling priority during congestion, but it does not improve the exchange rate or alter the pool's trading fee.

For legacy and version 0 transactions, the priority amount is derived from the requested compute-unit limit and the price per compute unit. It is based on the requested limit rather than the units eventually consumed. An unnecessarily high limit can therefore increase the bid. Version 1 transactions instead set the priority fee as an absolute lamport amount in the message configuration, making the wallet preview the relevant comparison point.

Network fees are charged when a transaction is processed, including when program execution fails. A request that never lands on-chain has no confirmed transaction fee to reconcile. Distinguish an expired submission from a processed failure by checking for a transaction record and its status.

Token transfer rules can change the net output

A Token-2022 mint with the transfer-fee extension withholds its configured charge when the token moves. That charge belongs to the mint's transfer rules, not to Raydium's pool fee. It applies only when the selected token has the extension enabled and the relevant transfer triggers it.

On the input side, a transfer charge can reduce the amount that reaches the pool before its curve and trading fee are applied. On the output side, it can reduce what reaches the receiving account. A quote that supports the token should express the user-facing result after the applicable transfer calculation. Reconciliation should still compare the actual token balance change because the mint configuration, route, and direction determine where the charge appears.

Account creation is different again. Funding a new receiving account moves SOL into rent-exempt account storage; it does not withhold output tokens under a mint rule. Keeping those two debits separate prevents a temporary account balance from being mislabeled as a trading fee.

How do you reconcile the confirmed cost?

Reconciliation starts with the transaction status, recorded network fee, and pre- and post-transaction balances. A successful status establishes that the instructions completed. The transaction fee field gives the SOL network charge, while token balance changes show the exchange result.

For exact-input mode, compare the intended input with the actual input-token decrease and the output-token increase. For exact-output mode, compare the received amount with the actual input used and the maximum input boundary. Use token units for token changes and lamports or SOL for network costs instead of converting everything through a changing market price.

The fee payer's SOL difference may include more than the recorded transaction fee. Creating a receiving account can move a rent-exempt balance into that account. Other instructions bundled into the same transaction may also move SOL. The explicit transaction fee and account changes explain those differences more reliably than subtracting the wallet's two headline balances.

Next, compare the confirmed output with the expected output and the protected minimum. A result can differ from the initial expectation while remaining within the signed slippage boundary. Pool-state movement, integer rounding, route changes made before signing, and token transfer rules can all affect the final balance under their documented conditions.

Retain the transaction signature with the quote terms used for authorization. The signature anchors status, fee metadata, and balance evidence to one execution. If the wallet interface has not refreshed, the confirmed record and receiving account balance provide firmer evidence than submitting the same swap again.

A deliberate stop point for the first cost comparison

A first comparison should end before signing when SOL is insufficient, a receiving account cannot be created, the mint is wrong, no compatible route appears, or the preview contains unexplained instructions. After confirmation, a stale display calls for checking the recorded balance rather than repeating the swap. When a quote expires, requesting a fresh one preserves the same decision boundary; widening slippage accepts a broader exchange result, while raising priority changes scheduling cost. Re-quoting is the cleaner alternative when the cost inputs themselves have changed.

View image file

Common questions about Raydium fees