Jupiter routing through pools and market makers

Managed Execution or Custom Transactions

Transaction modification determines which Swap V2 integration path fits: managed orders provide assembled transactions, while the Router provides instructions for custom construction.

Assembled Swap Orders

The Meta-Aggregator lets Metis, JupiterZ, DFlow, and OKX compete when the request permits their participation. Its order operation returns a quote and assembled transaction together; execute handles the wallet-authorized transaction’s submission and confirmation. The returned message must stay unchanged, so custom instructions require a different integration path.

Custom Swap Instructions

The Router’s build operation returns a quote and raw instructions through Metis. It supports custom construction and cross-program invocation (CPI), where another Solana program calls the swap program. The integration handles simulation and submission through a remote procedure call (RPC) connection or Jupiter’s submission infrastructure. Router transactions cannot use execute.

Token Inputs and Executable Quotes

A routing request specifies the input mint, output mint, and amount in the input token’s smallest units. Mint addresses identify exact assets, while token decimals determine how displayed amounts convert into those units. Comparable quotes need matching amounts and settings. The router field identifies the winning engine; routePlan entries describe venues, token movements, and swap allocations where provided. Building an order transaction also requires the taker’s wallet address. Balance and account requirements can prevent transaction construction even when pricing exists.

A Swap V2 order without a taker returns pricing without a transaction. An empty transaction accompanied by an error indicates that a quoted swap cannot proceed.

Direct Paths, Intermediate Tokens, and Split Routes

Metis supports direct, intermediate-token, and split routes within market and transaction constraints. A direct path connects the chosen mints without an intermediate token, although a longer path can offer more output.

Intermediate Tokens

A multi-hop path exchanges the input through another token before reaching the requested output. Each leg supplies the next, making every market’s liquidity relevant to the complete path. Venue fees and price impact affect its quoted output. Several legs can execute together within one Solana transaction.

Splits Across Liquidity Sources

A split route assigns portions of the input to different paths, potentially reducing pressure on a single pool. An intermediate-token path need not split its input. Allocations describe how the same swap distributes its input, and the selected combination must fit into an executable transaction.

Pool Quotes and Market-Maker Liquidity

Pool quotes derive from an automated market maker’s (AMM’s) state and pricing rules, while request-for-quote (RFQ) offers express market-maker terms. Metis’s integrated AMM quoting implementations read updated account state and must match the pool program’s calculations. Liquidity and trade size affect each venue’s available output.

Dedicated JupiterZ Quotes

JupiterZ’s V1 webhook model requests quotes from market makers for a particular swap. The selected maker validates the taker-signed transaction before co-signing and landing the fill through the Order Engine program. A maker can reject execution during this last-look stage.

Streaming Quotes Inside Metis

JupiterZ’s V2 streaming model publishes orderbook snapshots that Jupiter caches for routing. Metis consumes market-maker liquidity from JupiterZ V2’s streaming orderbooks. These fills use the swap aggregator and RFQ fill program, with maker validation and co-signing. V1 and V2 operate concurrently, using different settlement programs.

Open full-size image

DFlow is a third-party on-chain router, and OKX supplies an additional liquidity source. Both compete through the Meta-Aggregator when eligible.

Why Can a Routable Token Have No Quote for This Amount?

Route availability depends on the requested amount, eligible venues, and their usable liquidity. Metis applies market-listing conditions that can remove a pool from routing, while other engines may still quote the pair through the Meta-Aggregator. Market makers also choose which pairs and sizes they quote, with inventory constraints and market conditions affecting their offers. A request can therefore fail to find liquidity without establishing a permanent token restriction or proving that every Jupiter engine lacks a path.

Routing settings can also remove candidates. On Swap V2 orders, a separate integrator fee payer restricts routing to Metis. Decentralized exchange (DEX) exclusions affect Metis alone, while router exclusions remove entire engines. A venue restriction can eliminate an intermediate leg as well as a direct market.

Account Limits and Routing Speed

Transaction account limits constrain Metis’s liquidity combinations, particularly when custom instructions need additional accounts. Reducing maxAccounts can make a custom transaction fit, but setting it too low can exclude useful pools or splits, worsen pricing, or leave no route. Swap V2’s build operation also offers a beta fast mode that trades quote optimization for lower routing latency. Its Bellman-Ford search avoids splitting and overlaps routing with the priority-fee lookup. That lookup uses global fees because the route’s writable accounts are not yet known, which can make the estimate less accurate. An unsplit path can still contain intermediate tokens. Fast mode may return less output than default routing when splitting would improve pricing, and lower computation latency does not establish successful network execution.

Price Impact, Slippage, and Quote Expiry

Price impact reflects the trade’s effect on its quoted execution price; slippage concerns price movement between quoting and execution. Raising slippage tolerance widens the acceptable range without restoring liquidity or removing quoted price impact. Pool state can change during authorization even when the route remains structurally valid.

The Real-Time Slippage Estimator (RTSE) estimates tolerance at order creation and embeds it in the transaction. The Meta-Aggregator applies it automatically unless a fixed value overrides it; the Router offers an explicit RTSE choice. The estimate does not rewrite a signed transaction as prices move.

Aggregator order transactions have an expiry boundary identified by lastValidBlockHeight; dedicated JupiterZ quotes carry expireAt. JupiterZ V1 reserves maker settlement time, so its forwarding window closes before final expiry. Price movement and maker rejection can prevent completion even within the relevant validity window.

Open full-size image

Route Output and the Received Balance

A completed swap requires successful execution and corresponding token changes; a transaction signature alone can also identify a failed attempt. Solana executes transaction instructions atomically, so a failed swap leg reverts the swap changes. A processed failure can still incur network fees, and submission alone does not establish completion.

Fees distinguish route output from the credited token amount. Meta-Aggregator orders include applicable Jupiter platform fees, while the Router does not charge Jupiter swap fees. Pool fees, network charges, and integrator fees remain separate costs. A Router integration can configure its own platform fee, so that path can still incur swap charges.

Swap V2 execution results distinguish route amounts from wallet amounts. For an order that credits the taker and collects fees in the output mint, outputAmountResult records output before that fee. The quote’s outAmount remains an estimate, while the completed exchange’s final credited amount appears in totalOutputAmount.