Okxdex
Okxdex slippage
Slippage tolerance on OKX DEX controls the permitted change between a swap quote and execution. For swaps with a fixed sell amount, output below the minimum received amount blocks execution. Capped mode adds another condition: the dynamically calculated tolerance must stay within the ceiling that you set.
Last updated ·
How do the slippage modes differ?
| Mode | Setting and execution condition |
|---|---|
| Dynamic | OKX DEX recommends a tolerance using market conditions, including token volatility and liquidity. Execution remains subject to the resulting tolerance. |
| Fixed | You choose the tolerance. It sets the permitted deviation; the actual slippage does not have to equal that percentage. |
| Capped | Dynamic recommendations operate within your chosen upper limit. Execution is allowed only when the optimized tolerance stays at or below that cap. |
| Compare the minimum received for the same network, token pair, and sell amount to see what each setting permits in output-token terms. | |
Quote quality and execution movement
- Quoted swap rate
- The estimated receive amount relative to the sell amount for the selected swap. It describes the proposed trade before settlement.
- Price impact
- The effect of the swap size on pool liquidity and execution price. A large order relative to pool depth can produce an unattractive quote before any subsequent market movement.
- Execution slippage
- The difference between the quoted and executed prices. Other trades can change pool conditions while the transaction waits for inclusion in a block.
X Routing simulates available paths and can split an order when the combined simulated result is better than the unsplit result. That can improve the proposed swap, while volatility and confirmation delays can still change the execution outcome.
A higher tolerance allows a wider execution range. The quality of the starting quote still depends on liquidity and routing, so a swap can remain within its tolerance and still offer poor value relative to a displayed market price.
Translating tolerance into minimum output
For a fixed sell amount and a tolerance expressed as a percentage reduction in quoted output, the arithmetic is
minimum_output = quoted_output * (1 - tolerance_percent / 100)
. Both amounts use the output token's units;
tolerance_percent
is the permitted percentage reduction.
Increasing that percentage lowers the output floor. The transaction-specific boundary is the minimum received amount shown for the order: if execution cannot meet that boundary, the swap fails. Network fees remain a separate cost.
Evidence to inspect before retrying
- Quote and minimum received
- Compare the failed order's quoted output and minimum received with a fresh quote for the same sell amount. Check the selected mode and, for Capped, whether the dynamic recommendation exceeds your ceiling.
- Liquidity and order size
- Review pool liquidity and trading volume. An order that is too large for the available pool can fail or cause excessive price impact. A smaller amount or a route through a more liquid intermediary may improve execution conditions.
- Token restrictions
- Review the token risk assessment for honeypot or blacklist restrictions. A change to the price tolerance does not remove a token contract restriction.
- Balance and network fees
- For ordinary wallet-paid execution, check the native-token balance that covers network fees: ETH on Ethereum or SOL on Solana. Multiple similar submissions can also fail when the available trading balance covers only one.
- Transaction status
- Check DEX order history and the blockchain explorer record before another submission. If an Intent Swap has no valid solver quote or its onchain settlement fails, OKX DEX continues retrying while the order is active, up to its five-minute expiry. A transaction that was processed onchain can consume network fees even when the swap fails; an execution refusal alone does not establish that gas was spent.
MEV protection addresses a separate source of execution risk. Where supported and enabled, it routes transactions away from the public mempool to reduce exposure to front-running and sandwich attacks. The minimum-output condition still applies.