A slippage tolerance setting is not a fee and not a prediction. It is a floor you encode into the swap instruction: the minimum output you will accept, expressed as a percentage below the quote you were shown. If the pool would deliver less than that floor at the moment your transaction executes, the instruction fails and nothing moves. Choosing the number well means understanding both what a revert costs you and what an over-generous ceiling authorises.

What the number actually does

When you accept a quote, the interface does not send a percentage anywhere. It converts your tolerance into an absolute token amount and writes that amount into the swap instruction as a minimum-output constraint. The percentage exists only in your interface. What reaches the chain is a specific number of base units that the swap must produce or the whole transaction reverts.

min_out = quoted_out × (1 - tolerance)where quoted_out is the output amount the router computed from the pool state it last read, tolerance is your setting expressed as a fraction, and min_out is the base-unit floor encoded in the instruction

Because SOL carries nine decimals, that floor is a whole number of lamports and the comparison is exact. At execution the program recomputes the output from the reserve state as it stands in that slot, compares it against your encoded floor, and either completes the swap or returns an error. There is no partial fill and no negotiation. It is a binary gate.

This is the single most useful thing to internalise about a slippage tolerance setting: it is a rejection threshold, not a price. It never makes your fill worse than it would otherwise have been, and it never makes it better. It only decides which fills you refuse. Everything that follows is about where to put that refusal line.

Because the floor is encoded in absolute base units, a quote that sits in your wallet for several seconds before signature is already stale relative to the price, but the floor itself does not move with the market. Long signature delays effectively tighten your tolerance without telling you.

The two-sided cost of the number

Both directions cost money, which is why there is no universally safe default. The costs are asymmetric in kind, not just in size, and they show up in different places on your account.

Setting it too low

The transaction reverts. On Solana the direct cost of a revert is genuinely small: a base signature fee of 5,000 lamports plus whatever priority fee you attached. Your input tokens never leave. The expensive part is what happens next. You re-quote, and if the price has moved against you in the interval, your second attempt starts from a worse reference. Repeated failures compound that drift.

Setting it too high

You authorise a worse fill. This matters in two ways. First, if the pool genuinely has moved, you accept the move instead of rejecting it, which is sometimes the correct choice and sometimes an avoidable loss. Second, the gap between your quote and your floor is exactly the room a reordering strategy has to work in. A wider ceiling makes your transaction a more profitable target.

The second point deserves precision, because it is often overstated. A generous tolerance does not create an attack; it bounds how much one can extract if the conditions for it exist. On a deep pair with a small order the extractable amount is negligible regardless of your setting. On a thin pool with a large order it is the whole game. The interaction between size and depth is treated separately in the note on reading depth before you size an order.

How pool depth moves the answer

Depth determines how much the price moves per unit of flow, including flow that is not yours. In a deep pool, the trades that land between your quote and your execution barely shift the reserves, so the realised output stays close to the quoted output and a tight floor is safe. In a thin pool the same absolute flow is a large fraction of reserves and moves the price several per cent.

Worked example: the same order into two invented pools

Take an illustrative pool holding 4,000 SOL against its quote asset, and a second holding 100 SOL. Suppose an unrelated 5 SOL trade lands in the same slot as yours in both cases. In the deep pool that flow is 0.125 per cent of the reserve and the price moves by roughly the same order of magnitude. In the thin pool it is 5 per cent of the reserve and the price moves by several per cent. The identical stranger has produced a forty-fold difference in how far your quote drifted, and your floor has to absorb that difference.

The operational conclusion is that tolerance should scale with your order size expressed as a fraction of reserves, not with the dollar value of your order. A 10 SOL trade is a routine order in a deep pool and a dominant order in a small one. Any slippage tolerance setting that ignores this ratio will be simultaneously too loose on liquid pairs and too tight on thin ones.

How volatility and queue time move the answer

Depth explains how far the price moves per unit of flow. Volatility explains how much flow arrives, and queue time explains how long you are exposed to it. Multiply the three together and you have the shape of the drift your floor must absorb.

A Solana slot targets roughly 400 milliseconds. If your transaction is included in the next slot, your exposure window is short and a tight tolerance is reasonable. If congestion or a low priority fee pushes inclusion out by several slots, the window grows and so does the drift. This is why raising the priority fee and tightening the tolerance are complementary moves rather than alternatives.

  • Higher realised volatility on the pair widens the drift distribution and argues for a looser floor.
  • Longer expected queue time widens the same distribution for the same reason and argues the same way.
  • A longer multi-hop route multiplies the number of pool states that must still be valid at execution.
  • Concentrated liquidity ranges can be crossed mid-window, changing effective depth discontinuously.
  • A quote left unsigned for ten seconds is a stale quote regardless of how good the venue is.

None of these is a reason to abandon a tight floor by default. They are reasons to widen it deliberately in identified conditions and to narrow it again when the conditions pass. The failure mode worth avoiding is setting a loose number once during a volatile launch and leaving it there for months of routine trading.

What auto-slippage is inferring

Auto-slippage features estimate the number for you, and it helps to know what they are looking at. Broadly they combine three inputs: the depth and structure of the route the quote uses, a measure of how much the pair has moved recently, and the complexity of the route in hops. A four-hop route through thin pools produces a wider suggestion than a single deep pool.

That inference set is genuinely more than most traders apply by hand, and for routine swaps an automatic value is a reasonable default. Its limitation is that it cannot see your intent. It does not know whether you would rather fail three times than accept a 2 per cent fill, or whether you must be filled in this block at almost any price. Urgency is yours to supply.

The public routing documentation is the right place to check how a specific aggregator derives its suggestion before you rely on it, since the estimator changes over time and the details are implementation-specific. The aggregator developer documentation is the primary source for that behaviour rather than any third-party summary.

A starting heuristic by depth and urgency

The table below is a starting heuristic, not advice. It exists so that you begin from a considered position rather than from a default value, and every band should be replaced by your own measurements as soon as you have them. Depth bands are expressed as your order size divided by the reserve of the token you are selling, which is the ratio that actually drives impact.

Illustrative starting bands only: a slippage tolerance setting by pool depth and urgency, to be replaced by your own measured distribution
Pair depthUrgencyStarting bandReasoning
Deep major pair (order under 0.05% of reserves)Patient0.1% to 0.2%Drift in a single slot is tiny; a revert costs almost nothing and you can retry freely
Deep major pairNormal0.2% to 0.5%Covers ordinary slot-to-slot movement without leaving useful room for reordering
Deep major pairUrgent0.5% to 1.0%Buys landing certainty; the authorised loss is still small in absolute terms
Mid-depth pair (0.05% to 0.5% of reserves)Patient0.3% to 0.5%Your own impact is measurable, so the floor must clear it before covering drift
Mid-depth pairNormal0.5% to 1.0%Typical working range; widen it only when the pair is visibly moving
Mid-depth pairUrgent1.0% to 2.0%Accepts a worse fill in exchange for a materially higher landing rate
Thin new pool (0.5% to 2% of reserves)Patient1% to 2%Prefer reducing size first; the tolerance is the second lever, not the first
Thin new poolNormal2% to 4%Unrelated flow of ordinary size shifts these reserves by whole percentage points
Thin new poolUrgent4% to 8%The extractable value at this ceiling is real; accept it only with intent
Extremely thin (over 2% of reserves)PatientReduce size insteadNo tolerance value fixes an order that is too large for the pool
Extremely thinNormal5% to 10% with splittingSplit across pools or across time; a single large order pays the whole curve
Extremely thinUrgentReconsider the tradeAt this ratio the price impact alone usually exceeds any plausible tolerance

Two entries in the last band are deliberately not numbers. When your order is a large fraction of the reserve, the dominant cost is your own price impact, which no floor can reduce. Widening the tolerance in that situation does not improve the fill; it merely stops you from noticing how bad it is.

Calibrating your own number by observation

The reliable way to choose a slippage tolerance setting is to measure your own fills on the pair and size you actually trade. The loop below takes an hour of deliberate attention and replaces an inherited default with something derived from evidence.

  1. Fix the variables. One pair, one notional size, one time of day. If you change size and tolerance together, nothing you learn is attributable to either.
  2. Start deliberately low. Begin below the value you would have guessed. A revert costs a base signature fee of 5,000 lamports plus your priority fee and returns your input untouched, so an early failure is cheap information.
  3. Record quoted and realised output. For every attempt log the quoted output, the realised output, whether it reverted, and the elapsed time from quote to confirmation. Ten to twenty attempts produce a usable shape.
  4. Compute realised slippage per fill. Divide realised output by quoted output and subtract from one. Read the distribution, not the average, because the tail is what the floor has to clear.
  5. Set the ceiling above the working tail. Place the tolerance above the bulk of your outcomes and below the fills you would refuse. That gap is your actual room to operate.
  6. Re-run when conditions change. Treat the result as a number attached to a pair and a market state, not as a global preference you set once.

Holding the variables genuinely fixed for twenty attempts is the hard part by hand, because every re-quote invites a small unplanned change in size, venue or timing. Running the loop through an automated Solana volume bot keeps those constant while only the tolerance moves, which is the condition that makes the resulting distribution attributable to the setting rather than to your own inconsistency.

The output of that loop is more valuable than the number itself, because you finish with a picture of how your fills are distributed. That picture is the same input used for the broader diagnostic work described in the treatment of where slippage on Solana actually comes from, and it converts tolerance from a guess into a measured constraint.

Failure accounting: when a low number costs more

The case for a tight floor rests on reverts being cheap. They are cheap in fees and not necessarily cheap in drift, and the arithmetic below shows where the crossover sits. All figures are invented to demonstrate the method.

Consider two candidate settings for the same trade. Setting A uses a tight tolerance: it lands 60 per cent of attempts and the fills it does produce come in 0.25 per cent below the quote. Setting B uses a loose tolerance: it lands 97 per cent of attempts, but because it accepts fills further into the tail, its average realised gap is 0.45 per cent.

Fees do not decide this. At a base fee of 5,000 lamports plus an illustrative 0.0002 SOL priority fee, a failed attempt costs about 0.000205 SOL, which against a 10 SOL trade is roughly 0.002 per cent. What decides it is the adverse drift you suffer while re-quoting after each failure. Call that drift d, expressed as a percentage per failed attempt.

expected cost = realised gap + ((1 / land rate) - 1) × dwhere realised gap is the average shortfall on fills that land, land rate is the fraction of attempts that succeed, and d is the average adverse price drift per failed attempt
Illustrative arithmetic: total expected cost of a tight versus a loose tolerance at three drift assumptions
Drift per failed attemptSetting A totalSetting B totalCheaper
0.10%0.317%0.453%A
0.31%0.457%0.460%Break-even
0.50%0.583%0.465%B

Setting A retries an expected 0.667 extra times per completed trade; Setting B retries an expected 0.031 extra times. Solving the two expressions for equality gives a break-even drift of about 0.31 per cent per failed attempt. Below that the tight floor wins comfortably. Above it the loose floor wins, and it wins by more the faster the market is moving.

This is the whole argument in one line. A tight tolerance is correct in calm conditions because retries are nearly free, and it becomes wrong precisely when the market is moving fast enough that each retry starts from a materially worse reference. Plug your own measured land rate and realised gap into the formula rather than adopting these invented figures.

Four mistakes that make the setting useless

Each of these turns a considered number into a decoration, and all four are common enough to be worth naming.

  • One global value for every pair. A figure that is sensible on a deep pair is far too tight for a new pool and far too loose for routine trading. Tolerance belongs to the pair and the size, not to the wallet.
  • Raising tolerance to fix failures caused by congestion. If a transaction never lands, it never reaches the output check, so the floor was never the reason. Raise the priority fee instead and leave the floor where it is.
  • Setting a loose ceiling once and forgetting it. The number that got you filled during a volatile hour is the number funding someone else during a quiet week.
  • Confusing the ceiling with an expectation. A 3 per cent tolerance does not mean you will pay 3 per cent, and it does not mean you will not. It only means you have agreed not to reject anything better than that.

Putting the setting to work

Practically, treat a slippage tolerance setting as one of three numbers rather than a standalone control. Your tolerance, your priority fee and your order size are a single configuration, because each one changes what the others should be. Cutting size reduces impact and lets you tighten the floor. Raising the priority fee shortens the exposure window and lets you tighten it again. Only when both are already tuned does widening the tolerance become the right remaining move.

Then hold the configuration steady long enough to learn from it. Change one variable, take twenty fills, read the distribution, and change the next. The temptation after a bad fill is to adjust everything at once, which guarantees that the next twenty fills teach you nothing. The wider framework these settings sit inside is laid out across the execution basics section.

The number itself is unglamorous and it is worth the attention anyway. It is the only field in a swap interface that lets you state, in advance and enforceably, which outcomes you will not accept. Used casually it is a rubber stamp on whatever the pool decides to give you. Used deliberately it is the cheapest risk control available on the transaction.

Frequently asked questions

What does the slippage tolerance number actually do?

It is converted into a minimum output amount that is written into the swap instruction. When the transaction executes, the program compares the output the pool would deliver at that moment against the encoded floor. If the output is below the floor the instruction fails and the whole transaction reverts, so you keep your input tokens.

Does a failed swap cost me anything?

Yes, but usually very little. The transaction still consumed network resources, so you pay the base signature fee of 5,000 lamports per signature plus any priority fee you attached. Your swapped tokens are untouched. The real cost of repeated failures is the price drifting away while you retry, not the fees.

Is a high slippage tolerance dangerous?

It authorises a worse fill. On a deep pair with a small order it usually changes nothing, because the fill lands far inside the ceiling. On a thin pair or a large order it defines how much value a reordering strategy can extract from your transaction before your own floor stops it.

Should I use auto-slippage instead of setting it myself?

Auto-slippage estimates the number from route complexity, recent volatility and pool depth, which is more information than most traders apply by hand. It is a reasonable default. It cannot know your urgency or your willingness to retry, so on unusual trades a manually chosen value is still worth the thought.

Why does the same tolerance work on one pair and fail on another?

Because tolerance is a percentage of a quote and pairs differ in how far that quote moves in the seconds before your transaction lands. A deep pair with steady flow rarely moves half a per cent in a slot. A new pool with concentrated flow can move several per cent between quote and execution.

Does raising tolerance make my transaction land faster?

No. Landing speed is a function of priority fee, network congestion and transaction size, not of the minimum output you encoded. Raising tolerance only reduces the chance that a transaction which does land is rejected by its own output check. The two levers are independent and should be tuned separately.

Filed under Execution basics by The SolSpread Desk. Worked examples on this page are illustrative arithmetic, not observed market data. Read how we handle numbers in the editorial policy.