Route Splitting and Price Impact on Solana

A DEX aggregator route split is one order divided into several parallel legs that execute against different pools inside a single transaction. It exists for one reason: on a constant-product curve, price impact grows faster than the size you trade, so two half-size fills against two pools cost less than one full-size fill against one. Below is the arithmetic, and the point where the logic reverses.

A route is a path, a split is a set of parallel legs

A route is a sequence. You hold token A, you want token C, and no pool holds both, so the router sends A into a pool that pays out B, then pushes that B into a second pool that pays out C. That is a two-hop route. The hops are ordered and dependent: the output of the first leg is the input of the second, so a shortfall on hop one is inherited by hop two.

A split is parallel. The router takes your single order and divides the input into two or more amounts that each hit a different pool trading the same pair, then sums the outputs into one fill. The legs never feed each other. In practice a router quote usually contains both structures at once: several parallel legs, one or more of which is itself a multi-hop path rather than a single pool.

The distinction matters because the two structures move cost in opposite directions. Adding a parallel leg spreads your size over more total depth and reduces impact. Adding a hop forces the whole amount through one more pool, paying one more fee and absorbing one more dose of impact. Splitting is a benefit that shrinks with each addition; hopping is a cost that compounds with each addition.

Why splitting lowers price impact

Start with the curve. A constant-product pool holds reserves of two tokens whose product is held constant across a trade, written X × Y = k. When you push an amount into the pool, the reserve you are adding to grows and the reserve you are taking from must shrink so the product stays fixed. The output you receive is not linear in your input, and that non-linearity is the entire story.

Rearranged, the price impact of that trade is a / (X + a). The important property is that this expression is convex in a: doubling your size more than doubles the impact you pay. That is what makes splitting profitable. If the cost of size were linear, dividing an order across venues would be pointless, because every piece would cost exactly the same rate as the whole.

There is a shortcut worth memorising. When you split proportionally across constant-product pools that quote the same mid price and charge the same fee, the blended impact collapses to a / (S + a), where S is the sum of the reserves you touched. Splitting therefore behaves exactly as though you had traded against one synthetic pool whose depth is the sum of the real ones. Sizing decisions follow directly from that, which is why reading pool depth before you size the order is the step that precedes any routing question.

The optimal split equalises marginal price

The router is not choosing amounts at random. It is solving a small optimisation: allocate the order so that no lamport would be better off somewhere else. The test is the marginal price of each leg, meaning the price you would receive on one more unit sent down that leg after the allocation already made. If one leg still has a better marginal price than another, moving size toward it improves the total.

At the optimum every leg reports the same marginal price. Notice the shape of the denominator: it is squared, so marginal price degrades faster than average price, and the equalisation condition bites early. This is the formal reason a router stops adding to a pool long before that pool is exhausted. The pool is not full; its marginal price has simply fallen to the level of the next candidate.

Now apply the condition to the simplest case. If two constant-product pools quote the same mid price and charge the same fee, equal marginal price means an equal ratio of allocation to reserve. In other words, the split is proportional to depth. A pool holding 4,000 SOL of depth beside one holding 2,500 receives about 61.5 percent of the order against 38.5 percent. That is why real splits look like awkward percentages rather than clean halves.

Everything that differs between pools pushes the allocation further away from proportional. A higher fee lowers a leg's marginal price at every allocation, so it receives less than depth alone suggests. A pool quoting a slightly better mid price receives more, until trading into it drags its marginal price down to the others. Concentrated-liquidity pools do not follow the constant-product denominator at all, so their allocations can look arbitrary until you look at where their liquidity is placed.

Every hop pays its own fee

Fees are charged per pool touched, not per order submitted. A single-hop trade through a pool charging 0.25 percent pays that once. A two-hop route through two pools each charging 0.25 percent pays it twice, and the two charges compound rather than add: the second pool charges its rate on the amount that survived the first. Illustratively, that is a total fee of about 0.4994 percent rather than a flat 0.50 percent.

Impact stacks the same way. Each hop is a separate curve with its own depth, and the intermediate token is frequently the thinner side of the pair. A route that looks attractive because its first hop is deep can still deliver a poor fill if the second hop meets a shallow pool, and the quote will show that as a single blended number that hides which leg caused the damage.

The compounding also affects certainty. Each hop's input is the previous hop's output, which the router estimated when it built the quote. If the first pool's state moved slightly, the second hop receives a different amount than planned and lands at a different point on its curve. Estimation error at hop one is not corrected at hop two; it is carried forward and amplified by the second curve.

Where splitting stops paying

Because blended impact behaves like a / (S + a), the benefit of each additional pool is governed by how much depth it adds relative to the depth you already have. The first extra pool of meaningful size is worth a lot. The fourth is worth much less, because S is already large and the derivative of that expression with respect to S falls away quickly as S grows.

Against that shrinking benefit sits a cost that does not shrink. The new leg pays its own pool fee on its own slice, and if it is a cheap pool you are already using elsewhere the fee is a wash. If it is an expensive or exotic pool, the extra fee lands on real size. Working through the algebra of the two effects produces a rule of thumb that is easy to apply at the quote screen.

Read that plainly. If your split is currently paying about 0.77 percent of impact and someone offers you an additional pool that charges 1.25 percentage points more than your existing venues, the extra pool cannot pay for itself no matter how much depth it adds. When impact is large, expensive pools are worth reaching for. When impact is already small, they are not, and the fifth leg is usually noise.

Applying that test by hand on every order is the discipline people abandon first, which is why it usually ends up embedded in software instead. A multi-DEX Solana volume bot that prices each venue before allocating a split is running this same comparison on your behalf, and the figure worth checking in its output is still the same one: whether the fee premium of the marginal pool is smaller than the impact the split is currently paying.

There is a second, softer cost on the same side of the ledger. Every leg adds accounts, compute units and transaction bytes. Those costs are not priced into the quote, so a router optimising purely for output will happily hand you a route whose expected value is worse once the probability of failure is included. That gap between quoted price and realised price is where most disappointment with splitting comes from.

Route length versus failure risk

A Solana transaction is a fixed-size object. The whole thing must fit inside a 1,232-byte packet, every account it references costs 32 bytes as a raw address, and every signature costs 64 bytes plus a base fee of 5,000 lamports. A route with more legs and more hops references more pools, more token accounts and more program addresses, and each one consumes part of a budget that does not grow.

Address lookup tables exist precisely because of this ceiling. A versioned transaction can reference an address stored in a lookup table by a one-byte index instead of embedding all 32 bytes, which is what makes long aggregated routes fit at all. If a route will not fit, the router must drop legs, and the quote you eventually sign is not the quote the optimiser first produced.

Compute is the second budget. A transaction is capped at 1,400,000 compute units, and each instruction is allowed 200,000 units by default unless the transaction explicitly raises the limit. Every pool invocation costs units, so long routes must request a higher limit, and requesting a higher limit changes what you pay in priority fees for the same landing behaviour.

Then there is time. Slots target roughly 400 milliseconds, and every pool on your route can be traded by someone else during the interval between your quote and your landing. A four-leg, six-pool route has six independent pieces of state that can invalidate your assumptions, against one for a direct swap, which is why longer multi-hop routes fail more often and why it is worth understanding how a transaction actually lands on Solana before blaming the router for a revert.

The failure cost is asymmetric. A reverted transaction still charges the base signature fee and any priority fee you attached, and it costs you the position you were trying to take at the price you were trying to take it. A route that improves your quoted output by a small margin but reverts a meaningful share of the time is a worse route, even though nothing in the quote says so.

Illustrative: one 60 SOL order, four ways

The table below is invented arithmetic, not observed market data. It prices a 60 SOL order against four constant-product pools for the same pair, all quoting the same mid price, with SOL-side depths of 4,000, 2,500, 1,200 and 600 SOL. Pools A, B and C charge 0.25 percent. Pool D charges 1.50 percent. Allocations are proportional to depth, which is the equal-marginal-price solution for equal-fee pools.

Read the last two columns together. The move from one pool to two saves about 0.34 SOL, which is by far the largest single improvement available. The move from two to three saves about 0.08 SOL, roughly a quarter as much, because the third pool adds only 1,200 SOL of depth to a base that already stands at 6,500. The benefit is real but it is already fading fast.

The fourth row is the one to study. Adding pool D does reduce price impact, from 0.7713 percent to 0.7153 percent, exactly as the convexity argument promises. But D charges 1.50 percent against the 0.25 percent charged elsewhere, a premium of 1.25 percentage points on a split that was only paying about 0.77 percent of impact. The break-even test fails, the blended fee rises to 0.3404 percent, and the order ends about 0.02 SOL worse than the three-pool version.

That is the general shape rather than a coincidence of these particular numbers. Impact savings from extra depth are bounded by the impact you are currently paying, so once impact is small, any pool whose fee premium exceeds it is a losing addition. A router that reports only output can still pick correctly here, but a router that is optimising a stale or partial fee model will not.

When to force a simple route

Most routing interfaces let you cap the number of legs or hops, or restrict the venue set. That control is worth using in specific, identifiable situations rather than as a default. The following conditions each independently argue for the simplest route that clears your size, even at a slightly worse quoted output.

• Your order is small relative to the deepest available pool, so the impact you could save is a rounding error next to the transaction cost.
• The quoted improvement from the complex route is smaller than the priority fee you would need to raise to land the larger transaction.
• Conditions are volatile and every extra pool is another piece of state that can move inside a 400-millisecond slot.
• You are executing a sequence of related trades and a single revert would leave you in an inconsistent position.
• The complex route includes a venue you cannot independently price or verify, so you cannot tell whether the quote is honest.
• Your last several attempts on this pair reverted and you have not yet isolated which leg is responsible.
• You need a deterministic, auditable fill for accounting or for a strategy that compares execution paths against each other.

The last condition on that list deserves more weight than it usually gets. If your purpose is to compare two execution paths, a deterministic route is worth a slightly worse quote, and the same requirement applies to anything placing the orders for you: a volume bot for Solana that silently changes route shape between clips produces a log you cannot draw a conclusion from, however good the individual fills look.

None of these say complex routes are bad. They say complexity has to be paid for in reliability, and that the payment is only worth making when the price improvement is large enough to notice. The decision is structurally the same one covered in the comparison between aggregated routes and direct pool swaps, applied one level down inside the aggregator itself.

Reading a router quote before you sign

Almost everything above is visible in a quote if you look at it in the right order. The point of the sequence below is to separate the two numbers that matter, price impact and fee, from the single blended output figure that hides them, and then to sanity-check the structure against the size you are actually trading.

1. Read the impact number first. It tells you how large your order is relative to the depth the router found. A high figure means the route is depth-constrained and splitting will help; a low figure means you are near the flat part of the curve and further complexity is unlikely to pay.
2. Count the legs and the hops separately. Legs are parallel and lower impact. Hops are sequential and multiply fees. A quote with two legs and one hop each is a very different object from a quote with one leg and three hops.
3. Check the venue fees against the impact. Apply the break-even rule. If an unusual high-fee venue appears in a route whose impact is already small, that leg is probably subtracting value.
4. Look at whether the split is proportional. Wildly disproportionate allocations to a shallow pool suggest either a fee or price difference worth understanding, or a quote built on stale reserve data.
5. Set tolerance against the whole structure. More legs means more independent state, so a tolerance sized for a single-pool swap will revert a multi-leg route more often than you expect.
6. Re-quote if you hesitated. A quote is a snapshot of pool state. If you spent time reading it, the state it describes has already been overwritten several times.

Router behaviour differs by implementation, and the parameters that control leg count, venue filtering and slippage are documented per aggregator; the Jupiter developer documentation is the reference point most Solana routing work starts from. The rest of the routing material on this site, including venue selection and split behaviour under thin liquidity, sits in the routing section.

The summary is short. Split because impact is convex, and split proportionally to depth because that is what equalising marginal price produces. Stop splitting when the fee premium of the next pool exceeds the impact you are still paying. Keep routes short because length is paid in fees, compute units, bytes and reverts, none of which appear in the output number you are shown.

Frequently asked questions