Slippage Settings Decide Which Trades Reach Settlement
A slippage limit sets the worst fill a trader accepts, trading protection from poor execution against failed transactions, gas costs and liquidation risk.
Slippage settings change trade execution by defining the worst price a wallet will accept before the transaction fails. That resolves a common desk puzzle: a pool can report ample total value locked while a modest sale still cannot clear near the quoted price. The headline liquidity number includes both assets and says little about depth along the proposed route. A tighter setting protects the mark but may leave the desk holding the original token; a wider one gets more trades settled while authorizing a larger transfer of value to liquidity providers, arbitrageurs or transaction-ordering searchers.
How does a slippage setting execute an onchain trade?
The setting becomes a minimum output written into the swap call. First, a fund manager selects an input amount and a router reads current pool reserves to produce a quote. The wallet converts the chosen tolerance into a minimum received amount, then signs the transaction and commits the input token plus native gas. No collateral is posted in a spot swap: the trader delivers one asset, while liquidity providers' pooled inventory supplies the other side. A validator or sequencer orders the transaction; the automated market maker recalculates reserves at that moment. The contract releases output tokens only if the result meets the minimum. Otherwise, the swap state reverts, the fund keeps its input, and the gas fee is still spent.
Why can higher slippage produce a worse fill?
A higher tolerance does not command the protocol to charge more; it enlarges the range of prices at which the trade may legally settle. Consider a numerical example, not a live market quote. A desk offers 500 ETH and receives a quote for 1,000,000 USDC. At 0.5% tolerance, its minimum is 995,000 USDC, so a block-time output of 993,000 reverts. At 2%, the minimum is 980,000, so the same trade settles at 993,000: the realized shortfall is $7,000, not the full $20,000 allowance. If reserve changes or adversarial ordering push output to 982,000, the wider setting still accepts an $18,000 shortfall.
Consensus affects who can order transactions, as this Frax Swap comparison of proof of stake and proof of work explores. Slippage tolerance answers the narrower execution question: whether the swap remains valid after that ordering changes the pool state.
Is slippage tolerance the same as a limit order?
No: it resembles a market order with a price collar, but the analogy breaks at settlement. A limit order rests at a stated price and may receive a partial fill. An exact-input automated-market-maker swap usually computes one route against changing reserves and either returns at least the minimum or reverts. The quote can age between simulation and inclusion, the public transaction can reveal exploitable room, and failure can still consume gas. Price impact is the movement caused by the desk's own size; slippage is the difference between the expected and realized result, including intervening trades and routing changes.
What slippage setting should a trading desk use?
A desk should set tolerance from executable depth, urgency and an independent price limit, not copy a wallet default.
- Measure output across the actual route and size, rather than relying on pool TVL.
- Translate the maximum acceptable basis-point loss into a minimum token amount.
- Split size, seek request-for-quote liquidity or use protected routing when exposure to public ordering is costly.
- For collateral top-ups or liquidation exits, compare the cost of a bad fill with the loss from a reverted, late transaction.
The verdict is asymmetric. Wider tolerance gives the transaction—and potentially searchers around it—more capacity to clear; the trader absorbs the execution shortfall. Narrower tolerance preserves price discipline but shifts risk into non-execution, repeated gas and, for leveraged accounts, liquidation exposure. That distribution of capacity and cost matters more than whether the interface labels one setting “recommended.”
Topics
- Exchange liquidity and execution costs