Price Impact on Thin Solana Pairs

Price impact is the gap between the price a pool quotes before your order and the average price your order actually gets. On a constant-product pool it is set by one ratio: your order size divided by the reserve you are spending into. Send 10 SOL into a pool holding 500 SOL and the curve alone costs about 2 percent, before any fee.

That is the whole mechanism, and it explains why a token can look busy and still fill badly. Depth is a property of the reserves at the instant your transaction lands. It has nothing to do with the daily figure on the token card. This note works through the formula, shows where the cost genuinely bends, tests whether splitting an order helps, and sets out how to choose a tolerance without guessing.

Three things that are not the same

Readers routinely collapse three separate quantities into one word. The spread is the distance between the best price to buy and the best price to sell at a given size; on an automated market maker it is produced by the pool fee rather than by competing quotes. Price impact is the cost your own order creates by moving the reserves along the curve. Slippage tolerance is a protective parameter you set before signing.

The practical difference is when each one is knowable. Price impact is deterministic and computable from the reserves before you sign: given the pool state and your size, the output is fixed arithmetic. Slippage is what happens because the pool state changes between the quote and the landing, when other transactions execute in the same slot range. A fuller treatment of the boundary between the three sits in this breakdown of spread, slippage and price impact.

The confusion has a cost. A trader who sees a wide fill and blames slippage will raise the tolerance, which does nothing about impact and quietly widens the range of prices the transaction will accept. A trader who understands the split will reduce size instead, because size is the only input that changes impact. One response addresses the mechanism; the other addresses the symptom.

Depth measured against your size

There is no absolute definition of a thin pair. A pool holding 500 SOL is deep for a 1 SOL order and shallow for a 100 SOL order. Depth is only meaningful as a ratio, and the correct denominator is the reserve of the asset you are spending. Everything else — the market capitalisation, the holder count, the day's volume — is irrelevant to what your particular order will cost.

For a constant-product pool with reserves x and y satisfying x × y = k, an input of dx after a fee factor f returns an output of dy = (y × f × dx) / (x + f × dx). Divide the input by the output and you have the effective price of the fill. Compare that to the spot ratio x / y and you have the premium you paid.

Doing that algebra once produces a result worth remembering. The ratio of effective price to spot price simplifies to 1/f + dx/x. The fee contributes a constant term. The curve contributes exactly your order size as a fraction of the reserve. A 4 percent order against the SOL side costs 4 percent in curve terms, no more and no less, whatever the token side happens to be. Reading the reserve figures directly is covered in the note on reading a Solana liquidity pool.

Why the cost curve bends

The formula above looks linear, and in one narrow sense it is: the average price premium rises in proportion to dx/x. That is a genuinely useful simplification and it is where most explanations stop. It is also the reason the word convex gets used loosely. The convexity is real, but it lives in three other places, and each one matters for a different decision.

First, the quantity of tokens you forgo grows with the square of the order. The shortfall against a hypothetical zero-impact fill is y × dx² / (x × (x + dx)). Against a 500 SOL reserve, a 10 SOL order forfeits a certain quantity; a 50 SOL order forfeits roughly twenty-three times that, not five times; a 100 SOL order forfeits roughly eighty-five times it. Cost in units, which is what you actually lose, is quadratic.

Second, the marginal price at the end of your order is worse than the average. After a fee-free trade the new spot ratio is the old one multiplied by (1 + dx/x)². Your last unit fills far worse than your average, and the next trader inherits that displaced price. Third, at fixed order size the impact is hyperbolic in depth: halving the reserve doubles the impact of the same order, and the last stages of a draining pool degrade very quickly.

Those three convexities are why routers treat size as the primary lever and why anyone sizing a position on a shallow pair should think in terms of the reserve rather than in terms of a dollar figure. The distinction between a bonding curve and a conventional pool changes the shape of this cost materially, which is the subject of curve liquidity versus pool liquidity.

Splitting an order, and its limits

The intuitive fix for a large order is to break it into pieces. This is worth testing rather than assuming, because constant-product pools have a property that defeats the intuition. Sequential fills against the same reserves telescope. Ignoring fees, three consecutive trades of one third the size each leave the pool in precisely the state a single full-size trade would have left it, and return precisely the same total output.

Once the fee is included, the split is marginally worse, not better. Each fill pays the fee on its own input, and the intermediate states the later fills trade against are already displaced by the earlier ones. There is no arithmetic route by which slicing an order against one pool recovers value. Anyone who observes an improvement from slicing is observing something else: elapsed time, outside flow, or execution across more than one venue.

That last case is where splitting genuinely works. Two pools each holding 500 SOL absorb a 20 SOL order at the cost appropriate to a 20 SOL order, twice, rather than at the cost of a 40 SOL order once. This is the mechanical reason aggregator routers split orders across venues, and the routing behaviour is documented in the aggregator's public developer documentation. The pieces have to reach different reserves for the split to buy anything. That is the one specification question worth asking about any scheduling tool, including an automated Solana volume bot: whether its slices are routed to distinct pools or fired sequentially into the same one, because only the first arrangement changes the cost arithmetic above.

A worked example on one pool

Take a pool with reserves of 500 SOL and 20,000,000 tokens, so k is 10,000,000,000 and the spot rate is 40,000 tokens per SOL. Assume a fee of 0.30 percent charged on the input and retained by the pool. That fee level is an assumption chosen to make the arithmetic reproducible; it is not a claim about what any particular venue charges. Effective price is the input divided by the tokens received.

Read the last two columns together. A 100 SOL order into a 500 SOL reserve pays a 20 percent curve premium and leaves the pool at 600 SOL against 16.68 million tokens, a spot rate roughly 44 percent above where it started. The buyer is the person who moved it there, and any exit through the same pool starts from the displaced side of the curve. The round trip, not the entry, is the real cost.

Now the split test. Take a 60 SOL order against the same starting pool, and compare one fill against three fills of 20 SOL each, executed back to back with no outside flow in between, and against three fills of 20 SOL each sent to three separate pools with identical reserves.

The middle row is the useful one. Slicing recovers nothing against a single pool and costs a little, and the deficit is a rounding-scale quantity rather than a dramatic loss. The bottom row is a 7.7 percent improvement in tokens received for the same input, entirely because each 20 SOL piece met a fresh 500 SOL reserve. Venue count, not slice count, is what changes the outcome.

Setting a tolerance you can live with

Slippage tolerance is the maximum adverse difference from the quote you will accept before the transaction reverts. It is a floor on the output amount encoded in the instruction. On Solana the whole transaction fails atomically if the floor is breached, so the choice is a trade between two failure modes: a reverted transaction that costs fees and time, and a filled transaction at a price you would not have chosen.

The common mistake is treating the tolerance as a dial for reducing cost. It is not. Setting a 1 percent tolerance on an order whose computed price impact is 12 percent does not produce a 1 percent fill; it produces a revert, every time, because your own order breaches the floor before anyone else's does. The tolerance has to sit above your own impact before it protects against anything external at all.

1. Compute your own impact firstDivide your order size by the reserve you are spending into, then add the pool fee. That is the floor below which no tolerance setting can succeed.
2. Add a margin for outside flowThe margin covers other trades landing between your quote and your slot. A pair with steady flow needs more margin than a quiet one.
3. Check what the margin authorisesMultiply the tolerance by your order size in quote terms. That product is the worst-case value you have agreed to hand over; if the figure is uncomfortable, the order is too large.
4. Prefer a lower priority fee to a wider toleranceLanding sooner narrows the window in which the pool can move against you. Widening the tolerance does the opposite of narrowing that window.
5. Re-quote rather than retry blindlyAfter a revert the pool state has usually changed. Pull fresh reserves and recompute rather than resubmitting the same instruction with a wider floor.

Solana's roughly 400 millisecond slot target matters here in a specific way. The interval between your quote and your landing is short but not zero, and during congestion a transaction can sit for several slots before inclusion. A tolerance that was reasonable at quote time is being applied to a pool state that is several seconds older than you assumed. Priority fees influence inclusion, not price, and are worth separating in your own accounting.

When the order is simply too large

Some orders cannot be executed acceptably at any tolerance, in any number of slices, through any router. The test is not whether a transaction will land. Almost any order will land if the floor is set low enough. The test is whether the round-trip cost is smaller than the move you expect from holding the position, and on a shallow pair that comparison often fails before the entry is placed.

Work it in reserve terms. An order equal to a tenth of the reserve costs roughly 10 percent on entry in curve terms, and the exit, priced from a displaced curve, costs again. The combined figure is the hurdle the position must clear before it breaks even, and it is set entirely by the ratio you chose at entry. No configuration recovers it, because it is not a configuration problem.

The remaining options are honest ones: reduce the size until the ratio is tolerable, wait for the reserves to deepen, accept execution over a longer period so that outside flow shares the burden of moving the price back, or decline the trade. A large headline volume figure on the token card does not change this arithmetic, for reasons set out in the anatomy of Solana trading volume. Flow and depth are different quantities and only one of them fills your order.

Common questions about bad fills

Why did my small order fill badly when the chart looked liquid?

Charts are drawn from executed trades, not from reserves. A pair can print a continuous line while holding very little on either side, because a sequence of small trades produces a smooth chart regardless of depth. Pull the reserve figures for the specific pool your route touched and compute the ratio yourself.

Does raising the slippage tolerance improve the price I get?

No. The tolerance defines the worst output you will accept, not the output you receive. Raising it never improves a fill and only widens the range of outcomes you have pre-approved. The only inputs that change the price are your order size and the reserves you trade against.

Why does the quoted impact change between the quote and the signature?

Because the reserves changed. Any trade landing between the two moments moves the curve, and your quote was computed against the earlier state. This is the practical boundary between price impact, which is yours, and slippage, which is everyone else's.

Is the fee or the curve the bigger cost?

On a small order relative to the reserve, the fee dominates. On a large one the curve dominates and the fee becomes a rounding term. In the table above the crossover sits where the order reaches a fraction of the reserve equal to the fee rate, which is why sizing discipline matters more than fee shopping on thin pairs.

Can I avoid impact by using a limit order instead?

A limit mechanism changes when you trade, not what the pool charges when the trade executes. If the fill eventually goes through the same reserves at the same size, it pays the same curve cost. What it can do is wait for deeper reserves or for other flow to move the price in your favour first.

Should I compare impact across pools before trading?

Yes, and compare it at your intended size rather than at a default one. A pool that quotes well at 1 SOL may be the worse venue at 30 SOL if its reserve is smaller. The comparison that matters is output tokens per unit of input, computed for the exact size you intend to send.