Aggregators, Slippage and Execution Price
Routing, price impact, slippage tolerance, MEV protection and intent-based swaps: understanding why you don't always receive the amount shown.
The essentials
This guide is general information and does not constitute investment advice.
Why the displayed price isn't the price you get
On a centralized platform, your order meets an order book run by the exchange. On an AMM-type DEX (automated market maker), you trade against a liquidity pool: a reserve of two tokens whose price is calculated by a formula. Each purchase removes tokens from the pool and therefore changes its price.
Two distinct phenomena explain the gap between the quote and the result:
- price impact: the effect of your own order on the pool;
- slippage: what changes between the moment you sign and the moment the transaction is included in a block.
Uniswap's documentation distinguishes them clearly. Price impact comes from the fact that the relative value of the two assets changes continuously while the swap executes; the deeper the liquidity, the smaller this impact. Slippage refers to price changes that occur while the transaction is pending, because other swaps go through in the meantime.
Price impact: the cost of your own size
Price impact is known in advance. If you want to swap a large amount against a shallow pool, you "push" the price against yourself as the trade proceeds. The average price you get is then worse than the price displayed before your order.
Points to remember:
- impact grows with the size of the order relative to the pool's liquidity;
- most interfaces display it before you sign;
- it doesn't depend on time: even executed instantly, a large order in a small pool suffers impact.
A high price impact (several percent) is a red flag: either the pool is too small for your size, or it's an illiquid token, or you've picked the wrong token or network.
Slippage and slippage tolerance
Slippage, by contrast, is uncertain. Between sending and inclusion, other users may trade in the same pool and move the price. To protect you, the interface calculates a minimum amount received from your slippage tolerance.
Uniswap explains it this way: as long as the execution price stays within the tolerance range (for example 1%), the transaction goes through; otherwise the swap fails. The contract checks that the amount obtained isn't below the expected minimum and cancels the operation if it is (an INSUFFICIENT_OUTPUT_AMOUNT-type error).
The setting is a trade-off:
| Tolerance | Advantage | Drawback |
|---|---|---|
| Very low | Little possible loss | Frequent failures, gas fees wasted |
| Moderate | Good balance on liquid pairs | Limited exposure |
| Very high | The transaction almost always goes through | Opens the door to "sandwich" attacks |
A high tolerance doesn't mean you'll necessarily lose that percentage, but that you allow execution up to that threshold. A bot that sees your transaction can exploit exactly that margin.
MEV: when your margin benefits others
MEV (maximal extractable value) refers to the profits an actor can make by choosing the order of transactions in a block. The most common attack against a swap is the sandwich:
- a bot spots your swap in the public mempool (the transaction waiting room);
- it buys just before you, pushing the price up;
- your swap executes at a worse price, but still above your minimum;
- the bot sells right after and pockets the difference.
The wider your tolerance, the bigger the exploitable margin. That's why setting "10% to make sure it goes through" is a bad habit. The topic is covered in more depth in the dedicated guide on front-running.
Possible protections
- Private RPC: instead of broadcasting the transaction to the public mempool, your wallet sends it to a service that passes it directly to block builders. Flashbots states, for example, that transactions sent through its Protect RPC are hidden from front-running and sandwich bots, and that transactions that would fail cost no fees because they aren't included.
- Intent-based swaps: you don't publish a transaction at all (see below).
- Tight tolerance on liquid pairs, to reduce the exploitable margin.
What an aggregator does
A DEX aggregator doesn't hold liquidity. It queries many sources (pools from different DEXs, sometimes professional market makers) and calculates the path that maximizes what you receive, gas fees included.
The 1inch blog, for example, describes its routing algorithm: the order can be split across several protocols, spread over different depth levels, and pass through intermediate tokens acting as "bridges" between the starting token and the destination token, while accounting for gas consumption.
In practice, a route might look like this:
- 60% of the order in an ETH/USDC pool;
- 25% in another ETH/USDC pool on a competing DEX;
- 15% via ETH → WBTC → USDC if that detour offers a better price.
Limits to know
- More gas: a path split into several steps costs more. On a small amount, complex routing can cost more than it earns.
- Indicative quote: the quote is calculated at a given moment; the market moves afterward.
- Spending approval: you often approve the aggregator's contract to spend your tokens. Remember to limit or revoke these approvals.
- Interface fees: some interfaces add a commission. It should appear in the quote details.
Intent-based swaps
A new generation of systems no longer has you send a swap transaction. You sign an intent: a message saying "I'm selling X, I want at least Y." Specialized actors, called solvers or fillers, compete to execute it.
- At CoW Protocol, the documentation specifies that an intent isn't an executable transaction but a signed expression of constraints. Orders are grouped into batches (batch auctions), which lets two users with opposite interests be matched directly ("coincidence of wants"); orders for the same pair in a batch settle at a uniform price, which removes the incentive to reorder transactions. Fees can be paid in the token being sold.
- UniswapX relies on a Dutch auction: the order's price starts high and decays toward a minimum until a filler finds it profitable to execute. The documentation highlights no gas for the swapper, MEV protection and no cost on failure.
Trade-offs: execution isn't always immediate, you depend on active solvers being present on your pair and network, and price quality depends on their competition. The guide on intents and solvers details these mechanisms.
A concrete example
You want to swap 5,000 USDC for ETH on a layer-2 network. The figures below are purely illustrative.
- Quote: the aggregator quotes 1.6200 ETH, with a price impact of 0.05% and routing across two pools. An impact this low indicates the pools are deep relative to your order.
- Tolerance: you set it to 0.5%. The minimum amount received becomes 1.6200 × (1 − 0.005) = 1.6119 ETH.
- Execution: while waiting, the price moves slightly. You receive 1.6185 ETH. The actual slippage is about 0.09%, well below your limit: the transaction goes through.
- Failure scenario: if the market had dropped sharply and the result had fallen below 1.6119 ETH, the contract would have canceled the swap. You'd have lost the gas fees (except via a private RPC or an intent-based system that doesn't charge for failures), but not your USDC.
Compare with a 5,000 USDC order on a small, thinly traded token: the aggregator shows 4% price impact. Here, the problem isn't tolerance but liquidity. Reducing the size, splitting the purchase over time or walking away are more sensible options than raising the tolerance.
Checklist before signing a swap
- Is the destination token the right one (contract address verified, right network)?
- Is the displayed price impact consistent with the order size?
- Does the minimum amount received work for you in absolute terms?
- Is the slippage tolerance suited to the pair (tight on major pairs, justified on others)?
- Are the fees (gas, pool fees, interface commission) visible?
- Does your wallet send the transaction through a public mempool or a protected channel?
- Is the spending approval requested limited to the necessary amount?
Mistakes to avoid
- Setting a very high tolerance by default: it's the ideal setup for a sandwich attack.
- Confusing price impact and slippage: raising the tolerance doesn't reduce the impact of a pool that's too small.
- Ignoring the minimum amount received: it's the only figure guaranteed by the contract, not the quote.
- Retrying a failed swap in a loop while raising the tolerance each time without understanding the cause.
- Neglecting gas on small amounts: multi-step routing can cancel out the price gain.
- Signing without reading: a fake aggregator site can ask for an unlimited approval or a malicious signature. Check the URL.
- Forgetting tax tokens: some tokens take a percentage on every transfer, which can make a swap fail or sharply reduce the amount received.
Key takeaways
- Price impact depends on your size relative to liquidity; slippage depends on what happens while you wait.
- Slippage tolerance sets a minimum amount received: below it, the swap is canceled.
- A tolerance that's too wide offers a margin MEV bots can exploit.
- An aggregator splits and routes your order across several sources, at the cost of sometimes higher gas.
- Private RPCs and intent-based swaps reduce MEV exposure, with their own dependencies.
- Always check the token, the network, the minimum received and the requested approval before signing.