Slippage, price impact, and prices: what integrators need to know

Last updated: June 22, 2026

Integrators frequently mix up a few related but distinct concepts: price impact, slippage, the different "prices" in a trade, and what the API actually controls. This article clarifies each and explains how 0x Swap API behaves, so you can set correct expectations for your users.

Price impact vs. slippage — not the same thing

These two get conflated constantly, but they describe different things:

Price impact is how your own trade moves the market price of an asset. It's the influence a single buy or sell order has on the market price of the asset being traded, and it's directly correlated to the asset's liquidity — high on illiquid assets and large trades, lower on liquid ones. Price impact is knowable before you trade.

Slippage is when the price drifts between the moment a quote is generated and the moment the transaction confirms on-chain, caused by external market movement rather than your own order. It refers to the change in an asset's price caused by external market factors and not your individual trade — for example, volatility shifting the price between order placement and completion. Slippage is measured after execution.

A useful way to hold the distinction: price impact is caused by the size of your trade relative to liquidity; slippage is caused by on-chain activity in the window between quote and confirmation. A fee-on-transfer token's fee, by contrast, affects neither — it changes the realized price, not impact or slippage.

The three prices in a trade

Because several variables move a trade's price, it helps to separate three prices, as 0x defines them:

Quoted price — the "sticker price," the price advertised for a given trade
Executed price — the price at which the trade actually completed, after accounting for things like market volatility during settlement
Adjusted price — what the user ultimately ends up with after accounting for gas fees and transaction fees

Why this matters: the best quoted price doesn't necessarily mean the best adjusted price, and adjusted price is the more reliable metric when comparing aggregators — which is exactly what 0x's smart order routing optimizes for.

What the API controls: slippage, not price impact

This is the most important operational point, and the source of most confusion:

0x Swap API has a parameter to control slippage. It does not have a parameter for price impact. In practice, that means if the price moves against the user beyond their tolerance before the transaction confirms, the trade reverts rather than filling at a bad price. But if a user requests a swap that moves an illiquid market by a large amount, the API will still return a quote as long as the full amount can be liquidated — protecting against price impact is the integrator's responsibility, not something the API blocks by default.

Practical guidance for integrators:

Always set a sensible slippage limit. This is the single most effective protection against bad execution during volatility. A very high or unlimited slippage setting invites poor fills on any liquidity source
Surface liquidity/price-impact information to your users if you support long-tail tokens, so they understand when a trade is large relative to available liquidity. The quoted output amount is shown before signing; users should be able to see and accept it
The guarantee 0x can make is "execution within the slippage tolerance" — not a guarantee about market movement or price impact on illiquid pairs

A note for integrators coming from v1

If you previously integrated 0x Swap API v1, two things changed in v2:

There is no estimatedPriceImpact field in v2. v1 returned this value (and a priceImpactProtectionPercentage parameter that could block trades above a set impact threshold). v2 does not return a price-impact estimate. If you need to show price impact in your UI, you'll need to calculate it yourself using external price data — a common approach is comparing the USD value of the sell side against the USD value of the buy side using a third-party price source
The v1 "slippage protection" toggle no longer exists. In v2, you control execution tolerance directly through the slippage parameter.

A common confusion: positive slippage and trade surplus

Sometimes what looks like large "price impact" in a UI is actually positive slippage that was captured as trade surplus. If the market moves in the user's favor between quote and execution, the difference can be retained as surplus by the configured fee recipient rather than passed to the user. A naive (valueIn − valueOut) / valueIn calculation will surface this as price impact even though it isn't. If you want users to share in positive slippage rather than have it fully captured, the quote request supports capping the surplus share — see the Swap API reference for the current parameter.