Skip to content
DeFi Reference

Routing and aggregation

1. TL;DR

Section titled “1. TL;DR”

Routing splits one trade across many pools and venues so the trader ends up with the most output; aggregators such as 1inch, Matcha and Jupiter do it on the user’s behalf. Ignoring per-pool fixed costs, optimal routing over constant-function pools is a convex optimisation problem that is tractable at scale and detects arbitrage as a special case; adding gas or compute costs per pool makes it mixed-integer and forces heuristics. On Solana, where over 40% of DEX swap volume flows through aggregators, Jupiter’s Metis engine and a “meta-aggregator” that pits on-chain routing against off-chain quotes carry most retail order flow.

2. Explain it simply

Section titled “2. Explain it simply”

Analogy

Section titled “Analogy”

You need to change 100 large notes into coins at several station kiosks, each with a limited float. Each kiosk gives a good rate for the first few notes but worse as its coins run low. The best plan is to give each kiosk just enough notes that the last note at every kiosk gets the same rate — and to skip a kiosk entirely if walking there costs more than the better rate saves. A routing engine does this arithmetic for hundreds of kiosks in milliseconds.

ELI5

Section titled “ELI5”

When you swap one token for another, there is rarely one place to do it: many pools and traders will take the other side, each at a slightly different price that gets worse the more you push through it. A router looks at all of them at once and splits your trade so that every piece gets the best price available, sometimes going through a third token on the way. Doing this well is a maths problem with a neat answer when each extra pool is free to use, and a harder one when each pool costs a fee to touch. Aggregators are the services that solve it for you and hand back a ready-to-sign transaction.

Step-by-step walkthrough

Section titled “Step-by-step walkthrough”

Scenario: a trader sells 100 ETH for USDC across two constant-product pools with a 0.3% fee. Pool A holds 1,000 ETH and 3,000,000 USDC; Pool B holds 4,000 ETH and 12,000,000 USDC. Both quote 3,000 USDC/ETH at the margin.

  1. Quote each pool alone. Before: trader 100 ETH, 0 USDC. All 100 ETH into A would return 271,983 USDC (2,719.8 per ETH); all into B would return 291,827 USDC (2,918.3 per ETH).
  2. Find the split where marginal prices match. Because both pools have the same spot price, the optimal split is proportional to their depth: 20 ETH to A, 80 ETH to B.
  3. Execute. Pool A: 1,000 ETH → 1,020 ETH, 3,000,000 → 2,941,349.5 USDC; trader receives 58,650.5. Pool B: 4,000 → 4,080 ETH, 12,000,000 → 11,765,398 USDC; trader receives 234,602.0.
  4. After: trader 0 ETH, 293,252.5 USDC — 1,425.8 USDC more than the best single pool. Both pools now quote about 2,883.7 USDC/ETH at the margin, so no arbitrage remains between them.
  5. Fixed costs. If touching a second pool costs $10 in gas the split still wins by $1,415.8; for a 1 ETH trade the gain (about 0.14 USDC) would not cover it, so a good router uses one pool.

Common misconceptions

Section titled “Common misconceptions”
  • Myth: The best route is the single deepest pool. Reality: Angeris et al.’s five-pool, three-token example shows optimal trades that reverse direction and change sparsity as size grows; “even in this very simple example, the optimal trades are not obvious”.
  • Myth: An aggregator’s quote is what you get. Reality: On Solana a proprietary AMM’s price can move between quote and execution when the market maker lands an oracle update; Jupiter counters with “a self-learning mechanism that automatically sidelines underperforming sources” (as of 2026-08).
  • Myth: Aggregators are neutral. Reality: They are platforms “relying on external parties to fill a trade” that decide the rules of engagement (Neuder & Bahrani, 2026); Jupiter’s meta-aggregator charges a platform fee (as of 2026-08).
  • Myth: Routing is only about AMM pools. Reality: Modern routers blend on-chain pools, order books and off-chain quotes; JupiterZ’s off-chain makers “often beat onchain routing by 5-20bps on major pairs” (as of 2026-08).

If you only remember one thing

Section titled “If you only remember one thing”

Optimal routing means equalising marginal prices across every venue you touch, and the reason it is hard in practice is that each venue costs something to touch.

3. How it works

Section titled “3. How it works”

The network model (Angeris, Chitra, Evans, Boyd, 2022)

Section titled “The network model (Angeris, Chitra, Evans, Boyd, 2022)”

Consider mm constant-function market makers (CFMMs) trading subsets of nn tokens. CFMM ii trades nin_i tokens with reserves Ri∈R+niR_i \in \mathbb{R}^{n_i}_+, trading function φi\varphi_i (concave, increasing) and fee parameter γi∈(0,1]\gamma_i \in (0,1] (so a 0.3% fee is γi=0.997\gamma_i = 0.997). A matrix Ai∈Rn×niA_i \in \mathbb{R}^{n \times n_i} maps the pool’s local token indices to global ones. A proposed trade tenders basket Δi≥0\Delta_i \ge 0 and receives Λi≥0\Lambda_i \ge 0; it is valid iff φi(Ri+γiΔi−Λi)=φi(Ri).\varphi_i(R_i + \gamma_i \Delta_i - \Lambda_i) = \varphi_i(R_i). The network trade vector sums the net flows: Ψ=∑i=1mAi(Λi−Δi)\Psi = \sum_{i=1}^m A_i(\Lambda_i - \Delta_i). The trader’s preferences are a concave, increasing utility U(Ψ)U(\Psi), with U=−∞U = -\infty encoding constraints such as “do not spend more of any token than I hold”. The optimal routing problem is max⁡Ψ,Δi,Λi U(Ψ)s.t.Ψ=∑iAi(Λi−Δi),  φi(Ri+γiΔi−Λi)≥φi(Ri),  Δi,Λi≥0.\max_{\Psi, \Delta_i, \Lambda_i}\ U(\Psi)\quad \text{s.t.}\quad \Psi = \sum_i A_i(\Lambda_i - \Delta_i),\ \ \varphi_i(R_i + \gamma_i\Delta_i - \Lambda_i) \ge \varphi_i(R_i),\ \ \Delta_i, \Lambda_i \ge 0. Relaxing the equality to ≥\ge makes the feasible set convex; any solution of the relaxed problem satisfies the constraint with equality because leaving value in a pool is never optimal for an increasing UU. Modelling languages such as CVXPY solve it “in just a few lines of code”.

Optimality conditions and marginal prices

Section titled “Optimality conditions and marginal prices”

With Lagrange multipliers ν∈Rn\nu \in \mathbb{R}^n (marginal utilities of the tokens) and λi≥0\lambda_i \ge 0, the conditions are ∇U(Ψ)=ν\nabla U(\Psi) = \nu and γiλiPi≤AiTν≤λiPi,Pi=∇φi(Ri+γiΔi−Λi),\gamma_i \lambda_i P_i \le A_i^T \nu \le \lambda_i P_i,\qquad P_i = \nabla\varphi_i(R_i + \gamma_i\Delta_i - \Lambda_i), where PiP_i are the pool’s post-trade unscaled prices. Read: at the optimum, every pool’s marginal price (adjusted for its fee) brackets the trader’s marginal utility — the “equalise marginal prices” rule from the walkthrough. The no-trade condition replaces PiP_i with ∇φi(Ri)\nabla\varphi_i(R_i): if current prices already bracket your marginal utilities, do nothing.

Special cases

Section titled “Special cases”
  • Linear utility U(z)=πTzU(z) = \pi^T z: the problem separates into mm single-pool problems.
  • Liquidating a basket into token kk: U(z)=zkU(z) = z_k subject to hinit+z≥0h^{\text{init}} + z \ge 0; the optimal value u(t)u(t) as a function of the amount tendered is increasing and concave.
  • Arbitrage detection: with any increasing UU whose domain is Ψ≥0\Psi \ge 0, an arbitrage exists iff the optimum is nonzero; the no-arbitrage certificate is a positive price vector gg with γiλiPi≤AiTg≤λiPi\gamma_i\lambda_i P_i \le A_i^T g \le \lambda_i P_i for every pool — “no arbitrage if we can assign a set of positive prices … for which no CFMM would trade”. In the paper’s numerical example the network yields about 7 units of token 3 for zero input.

Fixed costs

Section titled “Fixed costs”

Each pool touched costs qiq_i (gas on Ethereum, compute units and account locks on Solana). Introducing booleans ηi∈{0,1}\eta_i \in \{0,1\} and 0≤Δi≤ηiΔimax⁡0 \le \Delta_i \le \eta_i \Delta_i^{\max} gives max⁡U(Ψ)−qTη\max U(\Psi) - q^T\eta, a mixed-integer convex program. Exact solvers (Mosek, Gurobi) or brute force over 2m2^m subsets work for small mm; otherwise relax η∈[0,1]m\eta \in [0,1]^m, threshold or sample, and re-solve. This is the theoretical shape of every production router’s “how many hops/splits” heuristic.

Production engines

Section titled “Production engines”
  • Jupiter Metis (Solana) is “a heavily modified variant of the Bellman-Ford algorithm” that streams input tokens to build a route incrementally, splitting and merging at any stage and reusing the same DEX across splits; it quoted 5.22% better than the previous engine and was capped at 4 DEXs per swap by Solana’s 64-account lock limit (as of 2024-09, Jupiter). Jupiter’s meta-aggregator now runs Metis, the JupiterZ RFQ, DFlow and OKX in parallel and returns the best; the Router path returns raw Metis instructions for composability (Jupiter docs, as of 2026-08). Dynamic slippage (August 2024) sets tolerance per trade (Helius, as of 2025-01).
  • DFlow (Solana) streams every account update into a live price graph across AMMs, CLMMs, DLMMs, proprietary AMMs and CLOBs, pricing “exclusively” from on-chain state; it passed $2B in 30-day volume (as of 2025-08, Helius, secondary).
  • Ethereum aggregators (1inch, Matcha/0x, Kyber) read pool state, request RFQ quotes, and may fill “partially onchain and partially through an RFQ” (Neuder & Bahrani, 2026); Uniswap’s interface backstops UniswapX fillers with its Smart Order Router across v1–v4 (Adams, 2023). CoW solvers are routers that also net orders against each other (see /exchange/batch-auctions/).

Routing on Solana versus Ethereum

Section titled “Routing on Solana versus Ethereum”

On Solana a route is one transaction touching many accounts, bounded by account locks and compute budget, and proprietary-AMM prices depend on the maker’s last oracle update. On Ethereum a route pays gas per hop inside one 12-second block; Uniswap v4’s singleton and flash accounting cut the per-hop cost (see /exchange/v4-hooks-and-am-amm/).

4. Worked numeric example

Section titled “4. Worked numeric example”

Same scenario as §2. For a constant-product pool with reserves (x,y)(x, y) and γ=0.997\gamma = 0.997, input Δ\Delta returns $$\text{out}(\Delta) = \frac{y,\gamma\Delta}{x + \gamma\Delta},\qquad \frac{d,\text{out}}{d\Delta} = \frac{\gamma x y}{(x + \gamma\Delta)^2}.$$

Single pool. A: 3,000,000×99.71,099.7=271,983.3\dfrac{3{,}000{,}000 \times 99.7}{1{,}099.7} = 271{,}983.3. B: 12,000,000×99.74,099.7=291,826.7\dfrac{12{,}000{,}000 \times 99.7}{4{,}099.7} = 291{,}826.7.

Optimal split. Set marginal outputs equal: xAyA(xA+γΔA)2=xByB(xB+γΔB)2\dfrac{x_A y_A}{(x_A + \gamma\Delta_A)^2} = \dfrac{x_B y_B}{(x_B + \gamma\Delta_B)^2}. With xAyA=3×109x_A y_A = 3\times10^9 and xByB=4.8×1010x_B y_B = 4.8\times10^{10}, taking square roots gives xA+γΔAxB+γΔB=0.0625=0.25\dfrac{x_A + \gamma\Delta_A}{x_B + \gamma\Delta_B} = \sqrt{0.0625} = 0.25. Since xA/xB=0.25x_A / x_B = 0.25 already, the condition holds when ΔA/ΔB=0.25\Delta_A / \Delta_B = 0.25: ΔA=20\Delta_A = 20, ΔB=80\Delta_B = 80. Check: 1,019.94/4,079.76=0.251{,}019.94 / 4{,}079.76 = 0.25.

Outputs. A: 3,000,000×19.941,019.94=58,650.5\dfrac{3{,}000{,}000 \times 19.94}{1{,}019.94} = 58{,}650.5. B: 12,000,000×79.764,079.76=234,602.0\dfrac{12{,}000{,}000 \times 79.76}{4{,}079.76} = 234{,}602.0. Total 293,252.5293{,}252.5 USDC, versus 291,826.7291{,}826.7 for the best single pool: +1,425.8+1{,}425.8 USDC (+0.49%).

Post-trade prices. A: 2,941,349.5/1,019.94=2,883.82{,}941{,}349.5 / 1{,}019.94 = 2{,}883.8; B: 11,765,398/4,079.76=2,883.811{,}765{,}398 / 4{,}079.76 = 2{,}883.8. Equal marginal prices confirm optimality (condition (4) of the paper with a linear utility).

With fixed costs. Let q=10q = 10 USDC per pool. Two pools: 293,252.5−20=293,232.5293{,}252.5 - 20 = 293{,}232.5. One pool (B): 291,826.7−10=291,816.7291{,}826.7 - 10 = 291{,}816.7. Split wins by 1,415.8. For a 1 ETH trade the same split gains only ≈0.14\approx 0.14 USDC, so η=(0,1)\eta = (0,1) — use B alone — is optimal. This is the mixed-integer step in miniature.

5. Where it’s used

Section titled “5. Where it’s used”

Ethereum

Section titled “Ethereum”
  • 1inch, Matcha (0x), KyberSwap — aggregators combining on-chain pools with RFQ quotes (Neuder & Bahrani, 2026). ethresear.ch/t/25543
  • Uniswap Smart Order Router + UniswapX — the interface routes across v1–v4 pools and lets fillers compete against that baseline (Adams, 2023). See /exchange/rfq-and-intents/.
  • CoW Protocol solvers — route the net imbalance of a batch after peer-to-peer matching. See /exchange/batch-auctions/.

Solana

Section titled “Solana”
  • Jupiter — Metis on-chain routing plus meta-aggregation over JupiterZ, DFlow and OKX; over 1.7 billion swaps and 48 million traders (as of 2025-06, Helius); proprietary AMMs get 88–99% of their volume from aggregators (as of 2025-07, Helius). developers.jup.ag/docs/swap
  • DFlow — low-latency aggregator with a streaming on-chain price graph; integrated by Phantom, Kamino and Jupiter (as of 2025-08, Helius). dflow.net
  • Titan — meta-aggregator comparing quotes from multiple aggregators; over $500M beta volume, claimed 81% win rate (secondary, as of 2025-06, Helius).
  • Proprietary AMMs (SolFi, HumidiFi, ZeroFi, Tessera) — venues that exist almost entirely as routing targets; Jupiter’s single integration gives them distribution to retail flow. See /exchange/lp-toxicity-and-jit/.

6. Risks, attacks, and incidents

Section titled “6. Risks, attacks, and incidents”
  • Routing through thin liquidity: the WIF backrun, 10 January 2024. A user bought $8.9M of WIF in one transaction when it traded at $0.20 with a few million dollars of liquidity; Jupiter routed across three pools, the price wicked to $3, and a searcher backran it (Helius, as of 2025-01). Root cause: the route respected the slippage setting; the user misjudged price impact.
  • Quote spoofing by venues. Proprietary AMMs on Base quoted tight at the end of a flashblock, then widened at the start of the next block, filling routed orders at much worse prices absorbed by slippage (0x research, cited by Neuder & Bahrani, 2026). Jupiter’s reputation-based sidelining and on-chain route selection at execution time are the mitigations.
  • Stale or halted venues. A proprietary AMM’s price is only as fresh as its last oracle update; if the updating authority stops, “swaps in that pool likely halt” (Helius, 2025). Routers must handle reverts gracefully; Solana users pay for failed transactions.
  • Sandwiches on public routes. Routes that touch public pools are sandwichable; Jupiter’s MEV Protect sends transactions only to Jito block engines at higher cost, and anecdotally many bot users decline it for speed (Helius, as of 2025-01). See /mev/solana-mev/.
  • Aggregator as trusted intermediary. Paradigm lists aggregators among intent systems whose “only use best price” promise rests on reputation, not proof; a dominant aggregator is an order-flow chokepoint (Konstantopoulos & Kilbourn, 2023).
  • Solver/resolver contract risk. Aggregator settlement contracts hold approvals and have been exploited: CoW Swap (2023-02, ~$166K) and 1inch Fusion resolvers (2025-03, ~$5M) — see /exchange/batch-auctions/ and /exchange/rfq-and-intents/.

7. Open problems

Section titled “7. Open problems”
  • Scaling the mixed-integer problem. Angeris et al. offer only threshold/randomised heuristics; production engines are proprietary heuristics without optimality guarantees.
  • Route size limits. Metis was capped at 4 DEXs per swap by Solana’s 64-account lock limit (as of 2024-09); gains from larger routes are untested publicly.
  • Quote freshness vs execution. DFlow argues “even millisecond-level lag can widen spreads”; on Ethereum a 12-second block makes any quote stale, motivating intents and MEV taxes rather than better routing (Robinson & White, 2024).
  • Reputation as permissioning. Sidelining “underperforming sources” is “not so different from the permissioned/trusted/reputation-based setup of RFQs” (Neuder & Bahrani, 2026); whether routing can be made verifiably neutral is open.

8. Ethereum vs Solana

Section titled “8. Ethereum vs Solana”
AspectEthereumSolana
Aggregator share of DEX volumeSignificant via 1inch/Matcha/Uniswap interface (no figure in sources)Over 40% of swap volume; 88–99% of proprietary-AMM volume (as of 2025-07/08)
Per-hop costGas per pool; singleton/flash accounting in v4 reduce itCompute units and account locks; 4-DEX cap per swap (as of 2024-09)
Liquidity sources routedAMM pools + RFQ makers (off-chain)AMMs, CLMMs, DLMMs, proprietary AMMs, CLOBs + JupiterZ RFQ
Quote stalenessOne 12 s block; sandwiches on public routesSub-slot oracle updates by makers can move price between quote and fill
Dominant engineMultiple aggregators; UniswapX fillersJupiter (Metis + meta-aggregator); DFlow, Titan challengers

Ethereum routing drifted off-chain to market makers because on-chain quotes are stale for a whole block; Solana routing stayed on-chain because makers can keep curves fresh within a slot, so the aggregator became the distribution layer for all liquidity. On both chains the aggregator, not the pool, is where retail price competition happens.

9. Reference doc

Section titled “9. Reference doc”

The reference

Section titled “The reference”

Optimal Routing for Constant Function Market Makers — Guillermo Angeris, Tarun Chitra, Alex Evans, Stephen Boyd; arXiv:2204.05238, 11 April 2022 (dated December 2021). arxiv.org/abs/2204.05238

Summary of the reference

Section titled “Summary of the reference”

The paper studies how a trader should execute an order involving several tokens across a network of CFMMs. The introduction notes that aggregators already execute “several billion dollars per month” on Ethereum and that prior routing work covered special cases; the contribution is a general formulation for any baskets and any concave trading functions.

§1 sets up the network: mm CFMMs and nn tokens as a bipartite graph, local-to-global index matrices AiA_i, tendered and received baskets (Δi,Λi)(\Delta_i, \Lambda_i), the trading rule φi(Ri+γiΔi−Λi)=φi(Ri)\varphi_i(R_i + \gamma_i\Delta_i - \Lambda_i) = \varphi_i(R_i) with examples (sum, geometric mean, weighted geometric mean), the network trade vector Ψ=∑iAi(Λi−Δi)\Psi = \sum_i A_i(\Lambda_i - \Delta_i), and a concave increasing utility UU with −∞-\infty values encoding constraints. The optimal routing problem (1) maximises U(Ψ)U(\Psi) subject to validity; problem (2) relaxes the equality to ≥\ge, is convex, and is shown to have the same solutions because any slack could be converted into more received tokens. Implementation is left to the chain’s semantics — sequential trades or a flash loan to net everything atomically.

§2 derives optimality conditions from the Lagrangian: ∇U(Ψ)=ν\nabla U(\Psi) = \nu and γiλiPi≤AiTν≤λiPi\gamma_i\lambda_i P_i \le A_i^T\nu \le \lambda_i P_i with PiP_i the post-trade unscaled prices. The interpretation is that the network optimum is also optimal for each CFMM alone under a linear utility whose prices are the marginal utilities of the overall trade. A no-trade condition follows by evaluating at zero.

§3 gives examples: linear utility separates the problem; liquidating a basket into one token, with the value function u(t)u(t) increasing and concave; purchasing the largest multiple of a target basket; arbitrage detection (nonzero optimum with domain Ψ≥0\Psi \ge 0); and a no-arbitrage certificate as a positive global price vector consistent with every pool’s local prices.

§4 is a numerical example: five CFMMs (a weighted geometric mean with weights (3,2,1), three constant-product pools, one constant-sum pool) over three tokens, with fees between 1% and 4%. Tendering tt of token 1 for token 3, u(0)≈7>0u(0) \approx 7 > 0 reveals an arbitrage; as tt grows flows reverse sign (token 1 is received from CFMM 1 below t=11t = 11 and tendered above) and sparsity changes. Figures 2–4 plot u(t)u(t), the optimal trades, and the flow graphs at t=0,20,50t = 0, 20, 50.

§5 adds fixed transaction costs qiq_i with booleans ηi\eta_i and bounds Δi≤ηiΔimax⁡\Delta_i \le \eta_i\Delta_i^{\max}, yielding a mixed-integer convex program solvable exactly by Mosek or Gurobi, by brute force for mm under ten, or approximately by relaxing η\eta, thresholding or sampling, and re-solving. Appendix A derives the dual conditions; Appendix B lists the CVXPY code.

Key quotes

Section titled “Key quotes”

“When we ignore the fixed cost associated with executing an order on a CFMM, this optimal routing problem can be cast as a convex optimization problem, which is computationally tractable.” (Abstract)

“the optimal trades for the network of CFMMs are also optimal for each CFMM separately, when they use a linear utility, with prices equal to the marginal utility of the overall trade.” (§2)

“there is no arbitrage if we can assign a set of positive prices (given by g) to the tokens, for which no CFMM would trade.” (§3, No-arbitrage condition)

“Even in this very simple example, the optimal trades are not obvious and involve trading with and among multiple CFMMs.” (§4)

How to read the original

Section titled “How to read the original”

Background needed: what a CFMM trading function is (see /exchange/cfmm-math/), basic convex optimisation (concave objective, convex constraints, Lagrange multipliers). Skip Appendix A on first pass and run Appendix B’s code instead. The hardest paragraph is the argument that the relaxed problem (2) solves (1): suppose a pool constraint holds with strict inequality; then you could take a little more out of that pool, which increases Ψ\Psi and, for an increasing UU, the objective — contradiction. Everything else follows from the marginal-price conditions.

What changed since

Section titled “What changed since”
  • Jupiter’s Metis (September 2024) implemented incremental, split-and-merge routing on Solana via a modified Bellman-Ford, and by 2025 a meta-aggregator that competes on-chain routing against RFQ quotes — production answers to the fixed-cost problem the paper leaves to heuristics.
  • Uniswap v4 (August 2024) reduced per-hop costs via a singleton contract and flash accounting, changing the qiq_i in §5 for Ethereum.
  • The routing frontier moved to blending off-chain quotes (UniswapX, JupiterZ) with on-chain pools; Neuder & Bahrani (2026) describe aggregators filling “partially onchain and partially through an RFQ”, outside the paper’s pure-CFMM model.

Secondary references

Section titled “Secondary references”
  1. Angeris, Agrawal, Evans, Chitra, Boyd, “Constant Function Market Makers: Multi-Asset Trades via Convex Optimization” (2021) — read if you want the single-CFMM theory the routing paper builds on.
  2. Jupiter, “Metis Routing” research post (2024-09) — read if you want the production algorithm’s design choices and the 4-DEX limit.
  3. Neuder & Bahrani, “Proprietary AMMs and Ethereum” (2026) — read if you want the sequence diagrams for AMM, RFQ, aggregator and proprietary-AMM flows.
  4. Helius, “How DFlow Uses LaserStream” (2025) — read if you want how a real-time price graph is built from raw account state.

The reference

Section titled “The reference”

Jupiter Developers — Swap API — Jupiter, developer documentation, fetched 29 August 2026. developers.jup.ag/docs/swap

Summary of the reference

Section titled “Summary of the reference”

The page describes the Swap API at https://api.jup.ag/swap/v2 as two paths. The Meta-Aggregator path (/order + /execute) has all routing engines compete — Metis, JupiterZ, Dflow and OKX — and returns a fully assembled transaction that the user signs and Jupiter lands through its own pipeline with optimised slippage and priority fees; it charges a Jupiter platform fee, supports referral fees and automatic gasless swaps, and does not permit modifying the transaction. The Router path (/build + /submit) uses Metis only and returns raw swap instructions for custom transaction building, cross-program invocation and composability; there is no swap fee, integrators add their own platform fee, and landing is self-managed or via tx.jup.ag with SOL tips.

The docs recommend starting with the Meta-Aggregator because “all routers compete, including RFQ market makers who often beat onchain routing by 5-20bps on major pairs”. A routing-engines table lists Metis (on-chain multi-hop, multi-split routing, also published as an independent public good at metis.builders), JupiterZ (RFQ, off-chain market-maker liquidity, meta-aggregator only), Dflow (third-party on-chain router) and OKX (third-party liquidity). Two constraints on JupiterZ are stated: Jupiter runs safety and validation between integrators and makers, and makers “have last-look execution rights”, which requires controlled transaction handling; JupiterZ transactions cannot be modified after return, so CPI or custom-instruction use cases must use the Router path. All endpoints require an API key. A closing section invites AMM operators to integrate into Metis and market makers to integrate into JupiterZ via webhook (V1) or gRPC streams (V2).

Key quotes

Section titled “Key quotes”

“Jupiter’s routing combines multiple engines and selects the best execution price across all of them, with a self-learning mechanism that automatically sidelines underperforming sources.” (Routing engines)

“RFQ (Request for Quote) system where market makers compete to provide off-chain liquidity. Often beats onchain by 5-20bps on major pairs.” (Routing engines table, JupiterZ)

“Jupiter runs safety and validation mechanisms between integrators and market makers, and market makers have last-look execution rights, which requires controlled transaction handling to ensure validity and prevent spam.” (Routing engines)

How to read the original

Section titled “How to read the original”

Background needed: Solana transaction structure (instructions, accounts, CPI; see /foundations/accounts-and-execution/) and the difference between a quote and a signed transaction. Skip the endpoint tables on first pass. The hardest idea is why JupiterZ is unavailable on the Router path: an RFQ fill is a maker-signed commitment whose validity depends on the exact transaction bytes, so the transaction cannot be edited and the maker keeps a last look.

What changed since

Section titled “What changed since”
  • Metis began as Jupiter’s v3 routing engine (September 2024, 4-DEX cap); the meta-aggregator model with JupiterZ default-on dates from December 2024 (Helius, as of 2025-01).
  • Kamino Swap’s Pyth Express Relay auction — a competing Solana RFQ approach — was wound down by Pyth governance in July 2026.

Secondary references

Section titled “Secondary references”
  1. Helius, “Solana MEV Report” (2025) — read if you want dynamic slippage, MEV Protect and JupiterZ context.
  2. Helius, “Solana’s Proprietary AMM Revolution” (2025) — read if you want the aggregator-share statistics behind Jupiter’s distribution power.

10. Sources

Section titled “10. Sources”