Jupag routing compares eligible engines to select a Solana swap route

From an assembled order to confirmed execution

The managed path combines a quote and an assembled transaction in an order response, then accepts the signed transaction for execution. The router field identifies the winning engine. An empty transaction string means the engine found pricing but could not construct a usable transaction. The integration must address the reported build error before another execution attempt. Match errorCode with router , because identical numbers can describe different failures across engines.

Execution has its own result. The /execute request carries the signed transaction and its original requestId . A successful response reports status: Success and code: 0 , meaning confirmation. A signature can also appear on a failed response, so its presence alone does not establish success. Signing authorizes the transaction; it does not establish that the swap completed.

Which engines compete in Swap API v2?

Metis, JupiterZ, Dflow, and OKX can compete through the unrestricted Meta-Aggregator path in Swap API v2. Metis searches onchain liquidity. Metis supports multi-hop and multi-split swaps across Solana decentralized exchanges. Multiple hops connect pools through intermediate tokens, while splitting distributes a swap across liquidity paths. Those options expand the combinations that its routing engine can evaluate.

JupiterZ uses request for quote (RFQ), where market makers compete with offers backed by offchain liquidity. Dflow supplies third-party onchain routing, and OKX contributes third-party liquidity.

Open full-size image

A Metis route can involve several underlying pools. Jupiter also sidelines underperforming routing sources through its selection mechanism. The eligible set therefore describes which engines can compete, without promising that each engine supplies a usable offer for every request.

Why do custom settings change the eligible routes?

Custom settings change the requirements that a routing engine must satisfy, so some configurations narrow the competing engines. In Swap API v2, setting payer to a wallet different from taker restricts Meta-Aggregator routing to Metis. This option lets an integration sponsor transaction costs, while removing JupiterZ, Dflow, and OKX from that request's eligible set. A quote under this configuration reflects the remaining engine's liquidity, even when the selected token pair stays unchanged.

Open full-size image

On the managed path, an integrator-sponsored order needs the taker and payer signatures plus referralAccount and referralFee . Automatic Jupiter sponsorship and JupiterZ market-maker payment use other arrangements. A gasless flag alone does not identify the sponsor.

When does a routing quote expire?

JupiterZ quotes expire at expireAt , while Metis, Dflow, and OKX transactions become invalid after lastValidBlockHeight . A price move can still cause slippage failure within the applicable window. Submitting promptly reduces quote staleness without guaranteeing execution. Limit orders and DCA also use Jupiter routing when they execute, but their trigger conditions and schedules govern a different stage from a live swap quote.

Open full-size image

Quoted output and wallet proceeds use different fields

The order's outAmount expresses expected output before slippage, while the execution response distinguishes swap-route amounts from amounts reflected in the wallet. When the fee uses the output token, outputAmountResult records the route's output before that fee. The totalOutputAmount field records the wallet's final output after it. Subtracting the latter from the former isolates the fee collected in that token.

An input-token fee changes the other side of the accounting. Here, totalInputAmount includes the fee deducted from the wallet, while inputAmountResult covers the amount entering the route. Their difference gives the input-token fee. The order's feeMint identifies which token carries the charge, so these relationships apply to their respective fee collection cases.

Route amounts describe execution through liquidity; wallet totals describe the swap token amounts deducted or received. Comparing a quoted amount directly with an unlabelled execution amount can mix those meanings. Token amounts also need their own mint's decimal scaling before any display in whole-token units.

The Router path trades engine breadth for transaction control

The Router path returns raw swap instructions through /build and uses Metis exclusively. This supports custom instructions, cross-program invocation (CPI), and transactions that combine the swap with other operations. Cross-program invocation means one Solana program calls another. The integration controls construction and can handle submission through its own remote procedure call (RPC) service, or use Jupiter's submission service with SOL tips.

Managed Meta-Aggregator transactions do not permit modification. JupiterZ also gives market makers last-look execution rights and requires controlled transaction handling. An integration that needs to alter the returned swap transaction must choose the Router path, accepting its different liquidity scope.

Fee treatment also differs between paths. Managed quotes report a Jupiter platform fee that varies by token pair; the Router path has no Jupiter swap platform fee. Integrator charges and network costs remain separate considerations. The choice follows the required transaction structure: custom composition uses Metis instructions, while an unchanged managed swap can retain competition from JupiterZ, Dflow, and OKX.