JIT Swap

Off-chain routing has a ceiling. You can make the algorithm faster, the liquidity graph deeper, the quote fresher - but you cannot control what happens between the moment a route is computed and the moment it actually executes. Pool states shift, other trades land, liquidity moves. No matter how good the off-chain computation is, there will always be a window where the plan and the reality diverge.

JIT Swap was built to close that window. This post is about how it works, and how often the route it executes differs from the one you were quoted.

Routes are snapshots

When you request a swap on Jupiter, Metis - our routing engine - evaluates liquidity across Solana's entire DEX landscape and returns a route. A route is two things: which pools to trade through, and how to split your order across them. The goal is to minimise price impact and maximise output.

But a route is a snapshot. It's computed off-chain, against pool states that were fresh at query time. Between the moment you see the quote and the moment your transaction lands, pool states change. Other trades execute, liquidity shifts, prices move. The route was built for a market that has already moved on.

We explored this gap in why you don't get what you were quoted. JIT Swap addresses one part of it - the staleness between quote and execution.

JIT Swap

What if the route didn't have to be final at quote time? Instead of locking the routing decision off-chain, what if the on-chain program could re-evaluate at the moment of execution, against the real-time state of each pool?

That's JIT Swap (referred to as DynamicSwap in the program). It carries candidate pools into the on-chain program and re-quotes them against the exact pool states the swap will execute with. If a different pool or a different split produces a better outcome at that moment, the route changes and executes immediately.

The experiment

The first version shipped with Metis v7 as a constrained experiment. The on-chain program could select the best pool from a candidate set, but it couldn't split across them. No weight optimisation, no rebalancing. The entire footprint was kept to roughly 100k compute units (CU) per transaction.

At the time, we deliberately kept the CU footprint small - simpler contract, less block space consumed - and even moved from Anchor to no-std to keep it lean. But the results showed that the pool selected on-chain frequently differed from the off-chain pick. Pool states were going stale between quote and execution, and correcting for that on-chain produced better outcomes. The signal was clear.

JIT Swap today

Solana blocks have a 60M CU cap, but they currently run at about 40% capacity (source). That unused block space gave us room to build a far more capable version.

The current JIT Swap runs at an average of 600k CU - six times the original footprint - and re-optimises splits across multiple venues. It evaluates six venues on-chain, including non-prop AMMs like Orca (Whirlpool) and Raydium. The off-chain route computes splits up to single basis point resolution. JIT Swap can re-split across pools up to 5% increments. At execution, the program compares both and executes whichever produces the better outcome.

This isn't single-venue selection. It's multi-venue re-optimisation with split rebalancing, running at execution time.

To measure the impact, we compared every JIT Swap over a 14-day window: the route computed off-chain at quote time against what JIT Swap actually executed on-chain. A swap is counted as "rebalanced" when any pool's share of the order moves by more than 0.5%. Reallocation magnitudes are the largest single-pool share change within each swap.

Pool changes

26.89% of JIT Swaps executed through a different set of pools than the off-chain quote had planned.

More than a quarter of the time, the venues that looked best when you asked were no longer the best when your trade landed. A static route would have pushed your order through the stale set and handed you whatever that produced.

Split rebalancing

Even when JIT Swap kept the exact same set of pools, it frequently changed how the order was distributed across them.

57.82% of same-pool swaps had their split rebalanced at execution.

In more than half of swaps, the market had moved enough between quote and execution that the original split would have left value on the table. Every rebalance represents a case where the off-chain plan was no longer the best allocation - and the further the market moved, the more value was at stake. The table below shows the scale.

It starts off-chain

These aren't edge cases - in the majority of swaps, the market had moved enough to warrant a different route. That's the gap JIT Swap closes.

Every just-in-time correction captured on-chain is a case where a fixed off-chain route would have executed the stale plan. The gap between the two is value that would otherwise have leaked as slippage.

But on-chain re-optimisation is not a replacement for good off-chain routing - it's a refinement of it. The off-chain route sets the foundation: the candidate pools and the initial split. JIT Swap optimises the last mile - re-splitting and re-routing across those candidates at execution time.

The quote you see isn't meaningless. It's the starting point that determines how much room JIT Swap has to optimise. A capable off-chain router paired with on-chain re-optimisation is what produces the best executed price. The two are not alternatives - they compound.

Constraints

On-chain routing faces real constraints. The binding limit today is Solana's 64-account cap per transaction. Every pool in the candidate set costs accounts - for the pool itself, its token vaults, its program. This caps how many venues can be carried into a single transaction.

Compute is another factor. At 600k CU average, JIT Swap uses a meaningful share of the per-transaction budget. As the set of candidate pools grows, so does the CU cost of re-quoting each one. And if general block space utilisation increases, larger CU transactions will face stiffer competition for inclusion - heavier transactions are harder to land when blocks are fuller.

What's next

These constraints shape what's possible today. As Solana's transaction model evolves - larger account limits, higher compute budgets - so will the scope of what on-chain routing can do. More venues, finer splits, deeper re-optimisation.

On-chain routing is an area we're actively pushing on. If there's a routing behaviour you'd like to see improved, or a pair that isn't getting the price you expect, we want to hear about it. What we ship next is shaped directly by what you tell us.