Skip to main content
Smart Slippage uses token market data to choose server-side slippage defaults and provide per-step recommendations instead of relying only on one flat value for every trade.

​
The problem

One flat slippage value can’t fit every token. A value that is too tight can cause a trade to revert after the market moves; one that is unnecessarily loose widens the range of adverse execution the user accepts. The appropriate tolerance depends on the assets and route.

​
How LI.FI solves it

LI.FI uses Smart Slippage in two related but distinct ways. Before route generation, it can choose a server-side default from the request’s source and destination tokens. After routes are generated, it can enrich each returned step with an advisory recommendedSlippage derived from the tokens that step actually touches. The pre-route default cannot inspect intermediate route tokens because the route does not exist yet. For same-chain requests it uses a one-step assumption; for cross-chain requests it uses a two-step assumption. A slippage value you pass yourself is always respected and takes precedence over the server-side recommendation.

​
What you see as an integrator

When Smart Slippage is enabled for your integrator key, eligible steps in the route response carry a recommendedSlippage field. Read it as advisory metadata for that generated step. It may differ from the default selected before route generation because it uses the route’s actual steps and intermediate tokens. The field has three states, and the distinction matters:
  • A number. A recommendation resolved for that step, expressed as a decimal fraction. For example, 0.005 means 0.5 percent.
  • null. The feature is active for your integrator, but no complete recommendation resolved for that step, usually because at least one required token record was missing or stale. This is distinct from “feature not enabled.”
  • Field absent. The feature isn’t enabled for your integrator, so no recommendation was produced.
An enabled step in the route response includes the field:
Your own slippage always wins. If you pass a slippage value on the request, LI.FI uses it and doesn’t override it with a recommendation.

​
How recommendations are derived

LI.FI keeps a recommendation per token, produced by its market-data pipeline from that token’s recent market behaviour. For each step it reads the recommendations of every token that step touches, adjusts each value for the route’s step count, and uses the highest adjusted value — the worst case among the tokens in play. All of the step’s tokens must have current data; a value is never computed from a subset of them. The step-count adjustment compounds the tolerance across the route: a route with n real execution steps uses the n-step value for each of its steps, and a route with more than three real steps uses the three-step value. The count covers the swaps, bridges and composer steps the route actually executes; helper steps such as fee collection or token wrapping do not count. Recommendations are data-driven rather than a permanent per-token constant, so values can change as the underlying records are refreshed. Each token’s value is read fresh when the quote is built rather than cached client-side, so a request reflects the current record. The underlying data sources and refresh cadence are operational details rather than a stable API contract. A token’s record is only usable while it is current. If any token required by a step has no current record — because none was produced, or because it aged out — the field resolves to null for the whole step rather than being calculated from incomplete data. See What you see as an integrator above.

​
Chain and token coverage

Smart Slippage is enabled per integrator and does not expose a separate public endpoint that lists current token coverage:
  • If every token a step touches has current data, that step carries a numeric recommendation.
  • If Smart Slippage is enabled for your key but any token required by a step lacks current data, the step’s recommendedSlippage resolves to null — this is how you tell “no complete recommendation right now” apart from “feature not enabled” (the field is absent in the latter case).
  • Coverage can change as LI.FI refreshes or extends the underlying data.
Tell the LI.FI team which chains and tokens you route most when you request access, so coverage can be confirmed for your integrator key up front.

​
Using this with the SDK and Widget

The SDK and Widget both accept a top-level slippage value (slippage in RouteOptions, slippage in the Widget config). That parameter behaves the same way with Smart Slippage enabled as it does without it:
  • You set slippage. Your value is sent on the request and always wins — LI.FI uses it and doesn’t override it with a recommendation, in the SDK and Widget exactly as it does for direct API calls.
  • You omit slippage. With Smart Slippage enabled for your integrator key, LI.FI applies the resolved recommendation as the server-side default for the quote, so routes fetched through the SDK or Widget without an explicit slippage value are quoted using the recommended tolerance without any extra client-side work.
This switches on whether the request actually carries a slippage value, not on which client sends it. If your integration always sets one — an app-level default, for example — every quote uses that value and the recommendation stays advisory. The Widget currently leaves its slippage setting undefined by default. Unless your Widget configuration or the user supplies a value, the route request omits slippage, allowing an enabled server-side Smart Slippage default to apply. To read the advisory value itself, inspect recommendedSlippage on each step in the raw route or quote response. SDK type support depends on the @lifi/types version in your application; do not assume older SDK typings declare this additive response field.

​
Worked example

The following illustrative values show how the field can differ across a route; they are not live recommendations or coverage guarantees for these tokens. A route from a stablecoin to a long-tail token, crossing one bridge, might return the following abbreviated shape. In a real response, each step’s action.fromToken and toToken are full token objects (address, chain, symbol, decimals and more), and each step carries far more than this:
Here:
  • The first two steps move a stablecoin, so their recommendations are tight — 0.002 and 0.005 (0.2% and 0.5%). All three values are adjusted for the route’s three real execution steps, so the difference between them comes from the tokens each step touches.
  • The final swap into a more volatile, less liquid token carries a wider recommendation — 0.031 (3.1%) — because that token needs more room before a normal price move would cause a revert.
  • The values shown are advisory fields calculated after the route exists. They do not prove that 0.031 was the server-side default used to generate this route; that earlier calculation only had the request’s source and destination tokens and an estimated step count.
  • If you pass your own slippage (say, 0.01), that value is used for the whole route instead, regardless of what any step’s recommendedSlippage says.

​
Scope

  • Enabled per integrator. When it’s off, the recommendedSlippage field is absent and quote behavior is unchanged.
  • Applies to both same-chain and cross-chain routes.
  • Recommendations reflect the currently available records. Where LI.FI cannot resolve all data needed for a step, the advisory value is null; server-side quoting can still fall back to the existing Smart Slippage V1 logic or the downstream chain default.
  • See the Slippage and price impact FAQ for how slippage and toAmountMin work more generally, including for integrators who don’t have Smart Slippage enabled.

​
Availability

Smart Slippage is an enterprise feature, enabled per integrator.

Contact the LI.FI team to enable

Tell us which tokens and chains you route most. We confirm coverage and enable Smart Slippage for your integrator key.