Jupiterswap
Jupiterswap fees before a first swap
Jupiterswap fees combine the charge shown in a live order with Solana transaction costs and the price effect of the chosen route. Before approving a first swap, compare the quoted input amount and expected output with the fee token, network payers, slippage limit and price impact from that same order.
A useful cost comparison holds the amount, token pair and settings constant, then checks the settled balance changes.
Where each cost appears from order to settlement
A first cost check starts with the live order, continues in the wallet request and ends with the confirmed balance changes. Each point answers a different question. The order estimates the exchange, the transaction names the accounts and fee payers and the settled record shows what actually changed.
At the order
The order should identify the input amount, expected output, total fee rate and fee mint. It may also expose a separate platform-fee amount and rate. Read these values together because a percentage without its charged token does not show which balance will change. The expected output also reflects the route selected under the liquidity available at that moment.
At authorization
The unsigned wallet request is the final review point before authorization. Check that its input mint, output mint and amount match the order. The transaction can also reveal who pays the Solana signature fee and whether new token accounts are created. A quote with attractive output is not ready for approval if the transaction requests different assets or authority.
After confirmation
A confirmed transaction records the outcome, but status alone does not measure cost. Compare the total input removed, final output received and any SOL change attributable to network charges or account funding. If those balances do not reconcile with the submitted transaction, keep its signature and inspect the record before considering another attempt.
What does the live order charge?
The managed order path includes a Jupiter platform fee, while the custom build path has no Jupiter swap fee. For a first swap using a prepared order, the live response is the controlling cost snapshot. Its top-level fee rate represents the total swap fee for that order. One basis point equals 0.01 percentage point.
The nested platform-fee rate isolates Jupiter's portion. It can differ from the total when another supported cost is recouped through the swap, including some gasless arrangements. The amount, rate and fee mint must come from the same response. A rate remembered from another pair or an earlier quote is not a reliable input for this decision.
Five fields that make one quote comparable
These order fields identify the expected output, displayed charge, fee token and account assigned the signature fee. Their values are quote-specific, so record the returned values instead of substituting a remembered rate. The field names also provide a repeatable comparison when two candidate orders use the same input and settings.
| Order field | Value to compare |
|---|---|
outAmount
|
Expected output in the token's smallest unit before slippage |
feeBps
|
Total swap fee rate returned for that order |
platformFee
|
Jupiter fee amount, rate and mint for that order |
feeMint
|
Mint of the token used to collect the swap fee |
signatureFeePayer
|
Address assigned to pay the Solana signature fee |
| Comparison rule | Keep the amount, token mints and optional settings unchanged |
The expected output is not a promise of the final wallet amount. It is the route estimate before execution, subject to the transaction's slippage boundary. Fee fields explain explicit deductions, while the payer field identifies responsibility for one network cost. The execution result is still needed to determine whether input-side or output-side collection produced the expected balance change.
Platform, integrator and route costs
Three cost layers can affect the amount surrendered or received, yet they do not necessarily appear as three wallet transfers. The recipient and method of collection distinguish them.
Jupiter platform fee
Jupiter receives the platform component on a managed order. The response reports its amount, basis-point rate and mint. Collection occurs in the token selected as the fee mint, so the user's input can be reduced before routing or the route's output can be reduced before delivery. The final execution amounts reveal which side changed.
Integrator charge
An app that integrates the swap flow can add a referral or integrator fee through supported parameters. That charge belongs to the app's configured fee arrangement, not to Solana validators or the underlying liquidity source. Its presence should be visible in the live order's total fee data. Compare the final output rather than assuming two interfaces produce equal costs for the same route request.
Route economics and spread
A liquidity pool's trading cost or a market maker's spread can affect the quoted exchange rate without appearing as another debit labelled as a fee. When a route charge exists, its recipient is the liquidity source or its liquidity providers. Treat that effect as part of route output and price quality. A spot token swap has no financing charge such as borrowing interest or perpetual funding unless a separate product introduces one.
How do network costs change the comparison?
Network costs change both who needs SOL and how much value leaves the participating accounts. Solana execution can include a signature fee, a priority fee and rent for new token accounts or other required accounts. A priority fee pays for greater scheduling priority; it is separate from the swap's platform charge.
The order's fee-payer fields show whether each cost is assigned to your wallet, an integrator, a market maker or a sponsor. The term gasless therefore describes the payer arrangement, not the absence of economic cost. Some sponsored flows recoup network spending through a higher total swap fee, while other payers absorb it. Compare the total fee rate and final output with the payer fields from that same order.
Price impact, spread and slippage are different
Price impact
Price impact estimates how the requested size changes execution against available liquidity. It is an exchange-quality effect, not a transfer to a named fee account. A larger input can select a different path or consume less favourable liquidity. Compare impact only between quotes for the same token mints, direction, amount and time window.
Spread
Spread is the gap built into a quoted exchange rate relative to a reference or opposing price. An on-chain pool and an off-chain market maker can express this cost differently, but the expected output captures its practical effect. A narrow fee line cannot compensate for an inferior output amount when every other input is held constant.
Slippage tolerance
Slippage tolerance sets an execution boundary between the quote and settlement. It is not an amount that is automatically charged. More tolerance can allow a transaction to complete after a larger adverse move, while a tighter limit can cause failure sooner. Compare quotes with the same slippage policy because changing that boundary changes the accepted outcome, not merely the label.
Matching quotes without changing the test
A reproducible comparison holds the exact input and output mints, direction, amount, slippage policy and timing as close as possible. Keep optional routing exclusions, fee parameters and payer settings aligned too. Compatibility is decisive: a route that cannot support the same payer or transaction requirements is not a like-for-like alternative. Refresh both candidates together when liquidity or network conditions move.
From quoted charge to realized cost
Keep the order response beside the transaction signature. The order records expected output, fee terms and payer assignments before authorization. Signing authorizes that transaction, while submission sends it for execution. The execution response records whether it settled and reports the token amounts used for reconciliation.
If the fee mint is the input token, subtract the amount routed from the total input removed. If the fee mint is the output token, subtract the final wallet output from the route's output. Those differences identify the collected swap fee without guessing from a percentage. Token decimals must be applied before presenting the result as a human-readable quantity.
Network spending needs a separate SOL balance check for the account named as payer. New-account funding should also be separated from the trading charge because it leaves an account on-chain rather than paying for the exchange itself. Keeping these amounts separate prevents account funding from being mistaken for a swap fee and keeps an expected quote distinct from completed settlement.
First-swap checks before and after submission
Before authorization, the reversible stop point is the unsigned transaction. Stop there if the mint addresses, amount, fee mint, payer or minimum output conflicts with the reviewed order. Request a fresh order if it has expired or market movement has made the comparison stale.
After submission, do not treat a missing interface update as permission to repeat the swap. Check the transaction signature and account changes first. A confirmed failure may still leave a network fee, while a successful record should reconcile with the total input deducted and final output delivered. You can then stop after resolving the submitted transaction's status and balance effects instead of sending another one.
Jupiterswap fees FAQ
When can a first swap require token-account rent?
Token-account rent can be required when the receiving account for the output mint does not yet exist and the transaction creates it. That amount funds the new on-chain account rather than paying for the exchange. The assigned rent payer may be your wallet, an integrator or a sponsor. An emptied token account can later be closed by its authority to reclaim its remaining rent balance.
How is the charged token identified after execution?
The feeMint value identifies the token used for the swap fee. If it matches the input mint, compare total input removed with the amount sent into the route. If it matches the output mint, compare route output with final wallet output. Apply that token's decimals after calculating the difference so raw smallest-unit values are not mistaken for display quantities.
Does the smallest fee rate always produce the best swap outcome?
No, the smallest displayed fee rate does not always produce the greatest final output. Route price, price impact, spread, network payer and account-creation costs can outweigh a narrower fee line. Compare orders only when token mints, direction, amount and settings match. The useful decision value is the expected net output under equivalent conditions, followed by reconciliation after settlement.
Can an integrating app add a fee to the swap?
Yes, an integrating app can add a supported referral or integrator charge to an order. The live response should incorporate that arrangement into the total fee data and identify the fee mint. The app's configured fee account receives its applicable portion; it is not a Solana validator charge. Compare the order itself because another interface may use a different fee configuration.
Are gasless swaps free of every cost?
No, gasless describes who pays designated Solana charges, not whether the swap has zero economic cost. A sponsor, market maker or integrator may cover the signature fee, priority fee or account rent. Some supported arrangements recoup that spending through the swap fee. Read the total fee rate, platform component, fee mint and payer fields together before comparing output.
Updated ยท