Aggregators vs Direct Pool Swaps on Solana

The aggregator versus direct swap decision is a trade between price and reliability. A direct pool swap touches one venue, uses the fewest accounts and compute units, and either works or fails for reasons you can name. An aggregator searches many venues and buys you a better price, paying for it with a bigger transaction and more state that can move underneath you. Size decides which is right.

Two paths to the same fill

A direct pool swap is the primitive. You choose a pool, you call that pool's program with your input amount and a minimum acceptable output, and the program moves tokens along its own curve. Nothing surveys alternatives, nothing divides your order, and nothing decides anything on your behalf. The transaction references your token accounts, the pool's vaults, its state account and the program itself.

An aggregator adds a search layer and a construction layer on top of that primitive. The search layer enumerates pools that can move you from your input token to your output token, including paths through intermediate tokens, and solves for an allocation that maximises output. The construction layer turns that plan into a single transaction that invokes each pool program in the correct order with the correct amounts.

Both paths end in the same place: pool programs moving tokens along curves. The aggregator does not invent liquidity and does not have a private price. What it sells is the search, and the search is only valuable when there is something to find. If one pool holds nearly all the depth for your pair, the best possible search result is that one pool, and you have paid for machinery you did not need.

When a direct pool swap is genuinely better

Direct is not a fallback for people who cannot find a router. It is the correct choice under conditions that occur constantly, and recognising them saves both money and reverts. The first and most common is concentration: if a single pool holds the overwhelming majority of the liquidity for the pair, there is no meaningful split to make and every additional venue in the route is a rounding error dressed up as optimisation.

The second is size. On a constant-product curve the impact of a trade is the input divided by the reserve plus the input, so a small order relative to a deep reserve sits on the nearly flat part of the curve. Below some threshold the entire price improvement available from splitting is smaller than the priority fee difference between a two-account transaction and a twelve-account one.

The third is landing. A minimal transaction is a small transaction, and a small transaction with modest compute demand is the easiest thing to get confirmed under contention. When you care more about being filled than about being filled at the last basis point, the simplest possible instruction set is the correct instrument, and it is worth deliberately choosing it.

Two situations complete the list. If your program is already invoking that pool's program for other reasons, adding a direct swap costs almost nothing incrementally, whereas introducing a router means a second program, its accounts and its versioning to manage. And if you need deterministic behaviour, where the same call produces the same structure every time, a direct swap gives you that and a router explicitly does not, because its output depends on a search over changing state.

When aggregation wins

Aggregation earns its complexity when the liquidity for your pair is fragmented. Several pools of comparable depth across several venues means no single pool can absorb your order cheaply, and the blended cost of trading against all of them together is materially lower than trading against the best one alone. The mechanics of that saving, including why the legs come out uneven, are set out in the article on route splitting and price impact.

It also wins when your order is large relative to any single pool. This is the same condition seen from the other side. Once the ratio of your input to the reserve stops being small, the convexity of the curve turns every additional unit into a disproportionately expensive one, and spreading the order over more total depth is the only lever that addresses the dominant cost.

The third case is structural rather than numerical. Some pairs have no direct pool at all, so the trade must pass through an intermediate token. Constructing that path manually means picking both pools, estimating the intermediate amount and setting a minimum output that accounts for two curves. A router does this as a matter of course, and doing it by hand is error-prone in ways that do not announce themselves until the fill is bad.

The fourth case is simply not knowing. New pairs and newly deployed pools change which venue is deepest from week to week, and a habit of always trading the same pool quietly becomes a habit of trading a pool that is no longer the market. A router quote is a cheap way to discover the current answer, even when you then execute the trade directly against whichever venue it identified.

That fourth case is the reason routing is worth automating even for traders who prefer to execute directly. A volume bot on Solana DEXs re-discovers which venue is deepest on every order instead of inheriting the answer that was true last month, and that discovery has value whether or not you let it place the trade.

Compute units, accounts and landing

The costs that separate the two paths are not visible in the price. A Solana transaction must fit inside a 1,232-byte packet. Every account it references costs 32 bytes when written as a raw address, and every signature costs 64 bytes plus a base fee of 5,000 lamports. A direct swap references a handful of accounts. An aggregated route references those accounts once per pool touched, plus the router's own.

Address lookup tables are the mechanism that makes long routes viable, because a versioned transaction can refer to a stored address by a one-byte index instead of the full 32 bytes. That is a large saving, but it is not free: the lookup table must exist and be referenced, and the transaction still grows with every leg. When a route will not fit, legs get dropped, and the executed plan is no longer the optimised plan.

Compute is the parallel budget. A transaction is capped at 1,400,000 compute units, and each instruction is allotted 200,000 units by default unless the transaction raises the limit explicitly through the compute budget program, which is described in the Solana documentation. A direct pool swap generally sits comfortably inside the default. A multi-leg route does not, so it must request more.

Requesting more matters because the requested limit feeds into how a transaction is prioritised relative to others competing for the same block space. A larger request at the same priority price means a larger absolute fee, and an under-request means the transaction exhausts its budget and fails outright. This is a genuine cost difference between the two paths, and it belongs in any honest breakdown of what a swap actually costs.

The failure profile is different, not just larger

A direct pool swap has a short list of failure modes. The pool moved past your minimum output and the instruction reverted. Your token account did not exist. Your compute budget was too low. Your transaction did not land inside the blockhash validity window. Each of these is individually diagnosable from the transaction result, and each maps to a specific parameter you can change.

An aggregated route inherits all of those and adds a category of its own: the plan itself can become invalid. The route was computed against pool reserves observed at some moment; slots target roughly 400 milliseconds, and every pool on the route can be traded by someone else in the interim. A stale route does not merely fill worse, it can fail an intermediate minimum and revert the entire transaction with nothing executed.

The important asymmetry is that these failure sources are close to independent. If each pool on a route has some small chance of moving enough to break the plan, the chance that none of them does falls as the route lengthens. This is why a route with a marginally better quoted output can still be the worse choice: the quote prices the good case and says nothing about the frequency of the bad one.

Price improvement versus reliability

State the trade explicitly and it becomes easy to decide. Aggregation offers a price improvement measured in a percentage of your order. Direct execution offers a reliability improvement measured in a reduced probability of paying a fee for nothing and missing the trade. The two are comparable once you express both in the same units, which means putting the price improvement into absolute terms.

That conversion is the whole trick. A price improvement of a small fraction of a percent is trivial on a small order and substantial on a large one, while the cost of an extra revert is roughly constant regardless of order size. So the correct answer flips with size, and it flips faster than most traders expect. The next section prices exactly that flip with invented but internally consistent numbers.

One more asymmetry deserves mention. The price improvement is uncertain, because it is quoted against state that will have changed by the time you land. The reliability cost is comparatively knowable, because it depends on transaction structure rather than on other people's behaviour. When two effects are close in expected magnitude, prefer the one you can predict.

Side by side on eight dimensions

The figures in the price rows come from the worked example in the next section and are illustrative arithmetic, not observed market data. The remaining rows describe structural properties of the two paths rather than measurements.

Worked example: a small order and a large order

All numbers below are invented for illustration. Assume a pair with three constant-product pools each charging 0.25 percent, holding 5,000, 1,500 and 400 SOL of depth on the side you are selling. The direct path uses only the 5,000 SOL pool. The aggregated path splits proportionally across all three, which for equal-fee pools quoting the same mid price is the equal-marginal-price allocation.

The two examples differ by a factor of five hundred in size and by a factor of roughly two hundred thousand in the value of aggregation. That is the convexity of the curve doing its work: the saving from spreading an order over more depth scales with the square of size, while the cost of a more complex transaction is essentially flat. Nothing else in the comparison moves that fast.

Note what the small-order case does not say. It does not say the aggregator was wrong; it found a genuinely better price. It says the improvement is too small to justify the extra failure surface. That is a different judgement, and it is the judgement the checklist below is built to make quickly.

The decision checklist

Answer these before you sign. A clear majority of yes answers points to a direct pool swap; a clear majority of no answers points to aggregation. Mixed answers usually mean the order is near the flip point, in which case take the simpler transaction, because the price difference is small by construction.

• Does one pool hold most of the liquidity for this pair, rather than depth being spread across several comparable venues?
• Is your order small relative to the reserve of the deepest pool, so you are on the flat part of the curve?
• Is the quoted improvement from the aggregated route smaller than the extra priority fee the larger transaction would need?
• Does the pair have a direct pool, so no intermediate hop is required to complete the trade?
• Do you already know which venue is deepest, from reserves you queried rather than from habit?
• Do you need the transaction to land more than you need the last basis point of price?
• Are conditions volatile enough that pool state will plausibly move inside the interval between quote and landing?
• Do you need the same call to produce the same structure every time, for accounting, testing or a controlled comparison?
• Is your program already invoking that pool's program, so a direct swap costs almost nothing incrementally?
• Would a revert on this trade leave a related position half-executed or otherwise inconsistent?

The checklist is deliberately biased toward simplicity, because the failure of an over-complex route is silent in a way the failure of an under-optimised one is not. A simple route that fills slightly worse tells you so in the output amount. A complex route that reverts tells you nothing about the price you would have received, so its cost never appears in any comparison you run afterwards.

Use both instruments rather than picking a side. Query an aggregator to discover where the depth currently sits, then execute directly when the answer is one venue and your size is small, and let the router build the transaction when the answer is several venues or your size is large. The rest of the venue and routing material, including how splits behave under thin liquidity, sits in the routing section.

Frequently asked questions