Slippage on Solana, Explained From the Pool Up

Slippage on Solana is the difference between the price a swap interface quoted and the price the transaction actually executed at. Three separate things create that difference: the pool fee, the price your own order size moves, and any change in reserves between the quote and the moment the instruction ran. Only one of them is the tolerance slider.

That distinction matters because traders routinely fix the wrong component. If your gap is mostly fee, no tolerance setting helps and only a different fee tier or a different venue does. If it is mostly impact, only smaller size or a wider route helps. If it is mostly timing, only faster inclusion or a calmer moment helps. This page separates the three, shows the arithmetic for each, and ends with the diagnostic that tells you which one you actually have.

What slippage actually measures

Slippage is a realised quantity. It is measured after the fact, by comparing a reference price you had before the trade against the price you effectively paid. The reference is usually the quote you were shown, though a stricter desk uses the mid price of the pool at the moment of the decision. Both are defensible; mixing them silently is not, which is why a measurement definition has to be fixed before any comparison is meaningful.

The effective price is easy to compute and hard to argue with: divide the amount of the token you received by the amount you sent. Both figures are visible in the post-transaction token balances. Everything else in a swap interface, including the expected output and the estimated impact, is a prediction. The effective price is the only observation.

A positive number means you did worse than the reference; a negative number means you did better. Both happen. Reporting only the bad half of the distribution is the single most common way traders convince themselves a venue is worse than it is. If you want the full definitional map of the neighbouring terms, the companion piece on spread, slippage and price impact as three distinct costs separates them line by line.

The three sources of the gap

Every unit of slippage on a Solana AMM traces back to one of three mechanisms. They are additive in practice and they behave completely differently as your order grows, which is why lumping them into one percentage destroys the information you need.

1. The fee component

A constant-product pool takes its fee out of your input before the swap math runs. If a pool charges twenty-five basis points, then a quarter of a percent of your input never reaches the curve at all. This component is flat: it is the same percentage on a one-SOL order and a five-hundred-SOL order. On tiny orders it is essentially the entire gap. Different pools of the same pair often run different fee tiers, and that choice alone can dominate small-order execution quality.

2. The size component (price impact)

The moment your input enters the pool, the reserve ratio changes, and the price at which the last unit of your order fills is worse than the price at which the first unit filled. You pay the average of that path, not the starting price. This component starts near zero and grows faster than linearly with size. It is the component people mean when they say a pair is thin.

3. The timing component

Between the instant a quote is computed and the instant the swap instruction executes, other transactions may have touched the same pool. Reserves at execution are not the reserves the quote was built on. This component is unsigned: it can help you or hurt you, and it is the only one of the three that no amount of pre-trade arithmetic can pin down in advance.

The pool arithmetic behind impact

Most Solana volume for a new or mid-sized token sits in constant-product pools, whose invariant is the product of the two reserves. Concentrated-liquidity pools behave differently inside their active range, but the constant-product case is the one worth being able to compute in your head, because it gives you a clean upper bound and a good intuition.

Strip the fee out for a moment and something useful falls out of the algebra. Your execution price is y / (x + in) while the mid price is y / x. The ratio of the two is x / (x + in), so the fee-free price impact of a constant-product swap is exactly the input divided by the post-trade input reserve.

This is the single most useful relationship on this page. It says impact is governed by your size as a fraction of the reserve you are pushing into, and by nothing else. Not by the token's market capitalisation, not by its holder count, not by how the chart looks. Two tokens with identical headline liquidity figures can have very different reserves on the side you are trading, and the one with the thinner input side will cost you more.

Illustrative: the same pool at five sizes

The table below is arithmetic, not observation. It assumes a constant-product pool holding 5,000 SOL and 250,000,000 units of a token, which puts the mid price at 50,000 tokens per SOL, and a pool fee of 0.25%. Nothing here is a measurement of any real market; it exists to show how the two computable components separate as size grows.

Read the columns against each other rather than down. At one SOL the fee is more than ten times the impact, so the entire optimisation problem is fee tier and venue choice. At two hundred and fifty SOL the impact is nineteen times the fee, so fee tier is nearly irrelevant and size management is everything. Somewhere between the two, around the point where your order is roughly one percent of the input reserve, the two components cross over and both start to matter.

What Solana changes about the timing part

The fee and impact components are chain-agnostic AMM mathematics. The timing component is where Solana's specifics show up. Blocks target roughly 400 milliseconds, a transaction references a recent blockhash that remains valid for 150 slots, and transactions reach the current leader through RPC forwarding rather than sitting in a single global public queue.

The short block time helps: the window in which pool reserves can drift away from your quote is measured in hundreds of milliseconds rather than tens of seconds. The forwarding path hurts in a different way: during congestion your transaction may be dropped rather than delayed, and a client that retries is effectively re-submitting an order priced on progressively older information. A quote that was accurate when it was produced can be several slots stale by the time an instruction built from it finally executes.

This is also why the same nominal tolerance behaves differently on a quiet pair and a contested one. On a pair where nobody else is trading in your slot, the timing component is near zero and your realised slippage lands close to the computable prediction. On a pair with heavy contention, the timing component can be larger than the impact component. The mechanics of that flight path are unpacked in detail in the piece on why a quote and a fill diverge.

Tolerance is a cap, not a forecast

The slippage tolerance in a swap interface does not predict your fill and does not aim for it. It is translated into a minimum output amount that is encoded in the instruction. At execution the program computes the real output from real reserves, compares it to that minimum, and aborts the whole transaction if it falls short. Nothing in that mechanism tries to give you a good price; it only refuses a sufficiently bad one.

Two consequences follow. First, raising tolerance never improves your price, it only widens the range of prices you have pre-authorised. Second, lowering tolerance never improves your price either, it converts some bad fills into failures, and failures are not free because the network fee is paid regardless. Choosing the number is therefore a trade between a known small cost paid often and an unknown larger cost paid rarely, which is exactly the framing used in the guide to choosing a slippage tolerance by pool depth and urgency.

What actually reduces slippage

Each lever below addresses a specific component. Applying a lever to the wrong component is the most common wasted effort in execution work, so the component is named in each line.

• Choose the fee tier deliberately. Fee component. Where several pools exist for the same pair, the cheapest tier with adequate depth wins on small orders even if its reserves are smaller.
• Size against the input reserve, not against your conviction. Impact component. Convert your intended order into a percentage of the reserve you are pushing into before you send it.
• Split across pools when liquidity is fragmented. Impact component. Splitting works because impact is convex in size; the reasoning is set out in route splitting and price impact.
• Split across time when the pool refills. Impact component. Only helps if other flow or arbitrage restores the price between your clips; otherwise you are simply paying the fee more times.
• Give the transaction a realistic chance of landing in the next slot or two. Timing component. A transaction that lands late was priced on old reserves.
• Trade the pair, not the token. All components. The same token can have a deep pool against SOL and a shallow one against a stablecoin; the route you take determines which reserves you are actually consuming.
• Do not raise tolerance to fix failures caused by depth. Wrong lever. If the pool cannot deliver your size, a wider tolerance only converts a failure into an expensive fill.

Two of those levers, splitting across pools and splitting across time, are mechanical once the component diagnosis is made, and the mechanical part is where hand execution drifts: clip four is quoted less carefully than clip one. Traders who work the same pair repeatedly tend to push that repetition into a Solana volume bot and keep their own attention on which component they are actually treating. Automation makes applying a lever cheaper; it does not make a wrong lever right.

Reconstructing your realised slippage

Everything above is theory until you measure your own fills. The reconstruction is mechanical and needs nothing but the transaction itself, which makes it the cheapest discipline in execution work.

1. Record the reference before you sign. Store the quoted output and, if you can, the pool reserves at that moment. Without a stored reference there is nothing to compare against later.
2. Pull the pre and post token balances. A confirmed transaction exposes token balances before and after execution. The difference on each side gives you the exact amounts sent and received.
3. Compute the effective price. Divide received by sent. Do it in raw units and only then apply decimals, because mixing decimal conventions is the most common arithmetic error in this exercise.
4. Subtract the known fee. The pool fee is a published parameter, so remove it to isolate impact plus timing. What remains is the part your own behaviour can influence.
5. Estimate the impact you should have paid. Use the closed form above with the reserves you recorded. The difference between predicted impact and observed gap is your timing component.
6. Keep the distribution, not the average. Store every trade. A single number hides the tail, and the tail is where execution quality is actually decided.

Run this over twenty or thirty of your own fills and the dominant component becomes obvious within an afternoon. The full measurement framework, including benchmark choice and how to compare two execution paths without fooling yourself, is covered in measuring execution quality.

Five ways people misread the number

Treating the tolerance as an estimate. A 1% tolerance is not a prediction of a 1% cost. Most fills under a 1% tolerance land far better than 1%; the setting is a boundary condition.

Comparing an interface estimate to a realised outcome. The estimated impact shown before a trade is a model output. Comparing it to your realised gap is a useful diagnostic, but calling the difference an error of the interface confuses a forecast with an observation.

Blaming slippage for a fee problem. On small orders the gap is mostly the pool fee. No routing change, no tolerance change and no timing improvement touches it.

Assuming deeper total liquidity means cheaper trades. Impact depends on the reserve on the side you are entering, in the specific pool your route uses. A large aggregate figure across many pools does not tell you what your route will consume.

Judging a venue on one trade. The timing component is unsigned and noisy. One bad fill is a sample of size one; conclusions about venues need dozens of fills measured under a fixed definition.

Slippage stops being mysterious the moment you stop treating it as a single number. Decompose it into fee, impact and timing, measure which one dominates for the sizes you actually trade, and apply only the lever that touches that component. Everything else on this desk, from routing behaviour to the full cost stack, sits inside the execution basics section and builds on this decomposition.

Frequently asked questions