Slippage is the difference between the price you expected when you placed a trade and the price you actually received when it executed.
It happens in almost every market. In DeFi, it's a function of how liquidity is structured — and understanding it helps you avoid paying more than you need to.
Why Slippage Happens
In an AMM (automated market maker), prices are determined by the ratio of assets in a liquidity pool. When you execute a trade, you're moving that ratio — and the larger your trade relative to pool size, the more you move the price against yourself.
A $100 swap on a $10M pool barely moves anything. The same $100 swap on a $50K pool could shift the price by several percent before your transaction confirms.
This is called price impact — the effect your own trade has on the price. Slippage and price impact are related but distinct:
- Price impact is the movement caused by your trade size
- Slippage also includes movement caused by other transactions that execute between when you submit and when your transaction confirms (in high-traffic conditions)
On-chain transactions aren't instant. Other trades can execute in the same block or between blocks, changing the price before yours settles.
Slippage Tolerance: What the Setting Actually Does
Most DeFi interfaces show a slippage tolerance setting — typically defaulting to 0.5% or 1%.
This is a maximum acceptable deviation from your quoted price. If the actual execution price would be worse than your tolerance allows, the transaction reverts automatically rather than executing at an unfavorable price.
Setting it too low means more failed transactions in volatile conditions. Setting it too high means you accept larger price deviations — sometimes exploited by sandwich bots that front-run your trade to worsen your execution.
For large trades on thin liquidity, you may need to raise tolerance. For small trades on deep liquidity, the default is usually fine. For anything meaningful on AMM-based DEXes, it's worth checking price impact before confirming.
Slippage in Perp DEXes vs Spot DEXes
Perpetual futures markets handle pricing differently from AMM-based spot markets — and in most perp venues, slippage in the traditional sense doesn't apply the same way.
Orderbook-based perp DEXes match buyers and sellers. Slippage comes from market depth: a large market order may need to fill across multiple price levels, moving your average execution price away from the top-of-book.
Oracle-priced perp DEXes reference an external oracle feed for trade execution rather than using pool ratios or orderbook depth. You open a position at the oracle price — the same price regardless of how large your trade is (up to the venue's open interest limits). There's no pool to move and no orderbook to slice through.
This is a structural difference. For traders moving significant size, oracle-priced perps eliminate the price impact problem entirely. Your execution price is the oracle price, not a function of how much liquidity you're moving.
LeverUp uses oracle-referenced pricing: positions are opened and closed at the mark price derived from Pyth's oracle feed, not at a pool-based or orderbook-based execution price. There is no price impact from position size within the protocol's open interest parameters.
Where Slippage Still Matters in Perp Trading
Oracle-priced perps don't have slippage in the AMM sense, but two related concepts still apply:
Oracle latency. If the oracle feed lags behind the actual market price, you're executing at a stale price — which can be better or worse than where the market actually is. This is why oracle freshness matters: a faster oracle update cycle means less divergence between mark price and true spot. Read more about how oracle freshness affects your trades →
Funding rate as cost. In perps, the ongoing cost of holding a position isn't slippage, but the funding rate is a real and continuous expense that compounds similarly to how repeated AMM slippage would on high-frequency spot trading. For holding costs, the relevant number to watch is the funding rate, not a slippage tolerance setting.
Frequently Asked Questions
What is slippage tolerance in DeFi? A maximum acceptable price deviation you set before confirming a trade. If the execution price would be worse than your tolerance allows, the transaction reverts. It protects you from extreme price movement between submission and confirmation, but setting it too high exposes you to sandwich attacks.
What causes high slippage? Three main factors: low liquidity in the pool (small pool relative to trade size), high volatility (rapid price movement between blocks), and network congestion (more transactions competing for the same block, increasing the window for price movement before yours confirms).
Is slippage always bad? No — slippage can be positive (execution at a better price than quoted) or negative (worse than quoted). The concern in practice is negative slippage, which is the more common outcome for large trades on thin liquidity.
Do perp DEXes have slippage? Oracle-priced perp DEXes don't have price impact from trade size the way AMM spot DEXes do. Your execution is at the oracle price regardless of size (within OI limits). Orderbook-based perp DEXes can have slippage if your order is large enough to consume multiple price levels.
What is a sandwich attack? A sandwich attack occurs when a bot detects your pending transaction and front-runs it by buying just before (pushing the price up) and back-running it by selling just after (taking profit). This exploits your slippage tolerance — setting it to 0.5% means a bot can guarantee you pay up to 0.5% more than quoted. Using private mempools or MEV-protected RPC endpoints reduces exposure.
Where to Go From Here
Oracle pricing is central to how modern perp DEXes like LeverUp handle execution. For a deeper look at how oracle freshness affects trade quality: What Is Oracle Pricing in DeFi? →
For a full overview of how perpetual futures work: What Are Perpetual Futures? →
Trade on LeverUp with oracle-referenced pricing — no price impact from position size: app.leverup.xyz