Jupiterswap
Jupiterswap routing connects request checks with execution evidence and bounded recovery
Jupiterswap routing begins with exact Solana token mints and an amount in native units, then selects an eligible path and builds a transaction. Review the quoted output, minimum output and route restrictions before signing. After submission, accept the swap only when its status and final token amounts agree.
Route settings determine which paths can compete
The mode is ultra when no optional parameters are used and manual when optional parameters are present. The mode does not identify the winning router. It shows whether optional settings were present and may have changed swap behavior. A separate payer or router exclusions can narrow the eligible routing engines. Preserve those settings with the quote because comparisons only work when their inputs match.
Default competition
A default order leaves every compatible routing engine eligible to compete. The selected router, expected output and fee fields belong to the same response snapshot. Review them together. A larger output from an earlier request does not prove that the present route is worse because liquidity, market prices and eligible sources may have changed between requests.
Custom restrictions
Manual settings can narrow the search or change execution. Excluding a router removes that engine from competition. A DEX exclusion applies only to Metis and does not exclude the other routing engines. A payer that differs from the taker restricts the order to Metis and requires both taker and payer signatures. A slippage override changes the permitted execution boundary. If a restricted request produces no usable transaction, remove only the restriction under review and request a new quote with otherwise identical inputs.
Exact token identity and native units anchor the request
The input mint, output mint and amount define the routing problem. Match both tokens by Solana mint address because a symbol or display name does not establish identity. The amount uses the input token's smallest unit, so its decimal precision must be applied correctly. A decimal mistake changes the requested quantity before any route calculation begins.
The signing account also needs the selected input balance. It may need SOL for signature, priority or account-rent costs unless the response identifies another payer. Confirm the intended receiving wallet before requesting a signable transaction. A route with correct token mints can still be unsuitable when its amount, signer or destination differs from the intended action.
Quote fields support checks before signing
A coherent quote links the requested mints and input amount to an expected output, a minimum output and a route plan. It can also identify price impact, the fee mint and estimated transaction costs. These fields describe one proposal under the conditions available when the request was processed. They do not establish that execution has occurred.
Expected output
The top-level output amount is the route's estimate before slippage. Read it beside the minimum output rather than in isolation. Price impact describes the quoted trade's effect on its execution price, while slippage tolerance controls how much deterioration the transaction can accept. The fee mint matters because a fee collected from the output can make the wallet-side total lower than the route's produced amount.
Signable transaction
A route ready for authorization includes an unsigned transaction and the request identifier used for execution. Keep both with the quote that produced them. The transaction message should retain the expected signer, token accounts, instructions and recent blockhash. Editing that message creates a different authorization requirement.
Review the wallet request against the same input amount and destination. Stop before signing if the transaction preview conflicts with the quote or introduces an unexplained authority. A matching wallet signature authorizes the assembled message, but it does not prove that validators accepted it or that the route delivered its output.
The route plan separates direct, multi-hop and split execution
A route plan can contain one swap leg, a sequence through an intermediate token or a split across several liquidity sources. Each entry identifies its input mint, output mint, input amount and estimated output. Allocation fields show how the requested amount is divided when a route splits. In a multi-hop path, an intermediate output feeds a later leg, so adding every leg's output would double-count unlike units.
Match the first inputs and final outputs to the top-level request. Unexpected intermediate mints, unexplained allocation gaps or a final mint mismatch are reasons to stop before authorization. A more complex path is not automatically better or worse; its quoted output and execution boundary must justify the additional legs.
Minimum output defines the execution boundary
For an exact-input route, the otherAmountThreshold field records the minimum output allowed after slippage. The transaction may succeed below the initial output estimate when the delivered amount remains above that floor. It should fail when execution cannot satisfy the threshold.
Price impact and slippage answer different questions. Price impact belongs to the quote produced for the chosen amount. Slippage tolerance limits adverse movement between quoting and execution. Increasing tolerance does not create liquidity or guarantee settlement. It authorizes a wider range of possible outputs, which makes the returned minimum especially important.
A very tight boundary can reject a route after a small market movement. A wide boundary permits a larger difference from the estimate. Use the values returned for the exact request instead of carrying a threshold from another amount, token pair or routing mode.
Completion evidence must be read as a set
A transaction signature identifies a submission, and some failed responses can still include one. Treat success status and a zero result code as the first completion evidence for managed execution. If either reports failure, retain the signature and error details while determining whether the transaction reached Solana.
Wallet-side accounting comes from the total input and total output amounts. Route accounting uses the input and output amounts processed by the swap path. Those figures can differ when the fee mint matches one side of the trade. Compare amounts on the same basis rather than treating every output field as interchangeable.
An on-chain check should show the required confirmation status with no transaction error. The transaction record can then establish the affected token accounts and their balance changes. A successful status with the intended output mint and consistent totals is stronger evidence than a wallet notification or a route quote alone.
Recovery starts by locating the failed boundary
Recovery depends on whether the route failed before authorization, during submission or after an uncertain response. Keep the original quote, request identifier and any transaction signature together. That record prevents a second attempt from being confused with the first.
Failure before authorization
No route may indicate incompatible mints, insufficient routable liquidity, an unsupported token condition or an amount that available paths cannot process. A quoted price without a signable transaction is also a stop condition. Recheck the mints, native-unit amount, token balance, SOL requirement and custom restrictions before requesting another order. Do not sign data that lacks the transaction produced for that request.
Uncertain outcome after submission
When execution explicitly fails, use its router and error details to identify the failed boundary. When the outcome is unclear, inspect the existing signature before creating another transaction. A pending record has not established failure. An expired blockhash or route-specific expiry allows a fresh order only after the earlier submission has been reconciled.
A new order requires a new review because its path, output and minimum can differ. Do not reuse a stale signed transaction or attach an old request identifier to a replacement. If the first transaction succeeded, a duplicate attempt would be a separate swap rather than a recovery action.
A bounded routing checklist ends at one reconciled outcome
Use one pass or fail decision at each boundary. Any failed item provides a reversible stop before signing or a specific reconciliation task afterward.
- Pass identity only when the input and output mint addresses match the intended tokens.
- Pass quantity when the native-unit amount decodes to the intended display amount and the signer has the required balance.
- Pass eligibility when the routing mode, exclusions, payer and receiving wallet match the requested configuration.
- Pass the quote when its output, minimum, price impact, fees and route plan form one consistent response.
- Pass authorization when the unsigned transaction matches that response and remains within its stated validity boundary.
- Pass completion when success status, result code, on-chain record and wallet-side token totals describe the same outcome.
Stopping before a signature leaves the proposed swap unsubmitted. After submission, preserve the record and reconcile it before doing anything else. That boundary prevents a replacement route from being confused with the original submission.
Frequently asked questions
Can Jupiterswap return a route quote before a wallet is supplied?
Yes. A quote-only request can omit the taker wallet, which returns pricing without an assembled transaction. That separation allows the route output to be inspected before requesting a signature. To proceed, obtain a fresh order with the signing wallet, then confirm that its transaction still matches the mints, amount and intended receiver.
How can a separate fee payer affect route selection?
A payer that differs from the taker can narrow the eligible routing set because sponsored gas changes which execution paths can participate. The payer covers the reported signature, priority and rent costs, and the transaction requires both taker and payer signatures. Compare the resulting route with an otherwise equivalent request before accepting it.
Where are routing fees and Solana transaction costs reported?
Order data reports the swap fee rate and fee mint separately from signature, priority and estimated rent fees. The route plan describes swap legs, so it is not a complete cost statement. After execution, wallet-side totals and route-result amounts show whether a fee was collected from the input or output token.
Can routed output go to a wallet other than the signer?
Yes, when the request supplies a receiver that differs from the taker. For non-SOL output, the transaction sends tokens to the receiver's associated token account and can add its creation instruction if needed. For native SOL output, it transfers SOL directly. The receiver must be a wallet address rather than a token-account address.
Does an empty transaction field mean the route has no quoted price?
No. An order can contain valid input and output pricing while its transaction field is empty because the selected route could not build a signable transaction for that taker. Stop at that point. Read the router with its error code, correct the stated balance, gas or account condition and request a fresh order.
Updated ยท