A trader opens a decentralized exchange and finds a token priced at $1. They enter 10,000 USDC into the swap interface, expecting something close to 10,000 tokens in return.
Instead, the quote offers 9,066 tokens.
Nothing has necessarily gone wrong. The exchange may be functioning exactly as designed.
The difference comes from a detail that the displayed token price cannot communicate on its own: how much liquidity is available to absorb the transaction.
Two decentralized exchange pools can show the same starting price and still deliver substantially different results for the same trade. One might return 9,871 tokens, while another returns only 9,066.
The initial price is identical in both cases. The difference emerges as the trade consumes liquidity and changes the pool’s reserves.
This is a defining characteristic of automated market makers, or AMMs, which allow tokens to be exchanged through mathematical pricing rules rather than a traditional order book.
It also explains why three terms commonly displayed in DeFi interfaces—price impact, slippage, and transaction fees—should not be treated as interchangeable.
They describe different costs and risks. Some are already embedded in the swap quote before the user submits anything. Others arise because market conditions change while a transaction is waiting to execute.
And in some cases, the difference between the quoted result and the minimum acceptable result creates an opportunity for someone else to profit.
A $1 Token Price Is Not a Promise to Sell Every Token for $1
In a traditional financial market, traders may encounter an order book showing buyers and sellers at several price levels.
The best available selling price might be $1, but there may only be a limited quantity offered at that level. A sufficiently large market order can consume those offers and continue buying at higher prices.
An automated market maker reaches a similar economic outcome through a different mechanism.
In the constant-product model popularized by Uniswap, a liquidity pool holds reserves of two assets. Their quantities determine the marginal exchange rate.
The basic relationship is expressed as:
x × y = k
Here, x and y represent the two token reserves, while k represents their product. Ignoring fees, a trade must move the reserve balances along a curve that preserves this relationship.
The mathematical model and its implementation are described in the Uniswap v2 whitepaper, which also explains how pool reserves establish marginal prices.
Consider a hypothetical pool containing 100,000 USDC and 100,000 units of Token X.
The reserve ratio suggests a starting price of 1 USDC per Token X.
For a tiny transaction, that price provides a useful approximation of the exchange rate. For a much larger transaction, it becomes increasingly misleading.
Every time someone buys Token X with USDC, the pool receives additional USDC and releases some of its Token X.
With more USDC and fewer Token X remaining, the pool’s marginal price of Token X increases.
The trader therefore does not acquire every token at the initial exchange rate.
Their transaction moves through a sequence of progressively less favorable prices along the AMM curve.
That distinction becomes particularly important when the trade represents a meaningful share of the pool’s available liquidity.
A starting price tells someone where the transaction begins.
It does not tell them the average price they will pay by the time the transaction is complete.
There is another qualification: Token X in this example is hypothetical. Its initial 1:1 ratio with USDC does not imply that the token is redeemable for one dollar, that it is a stablecoin, or that another market would value it identically.
The experiment isolates a simpler question.
What happens when two pools begin at the same price but have different amounts of liquidity?
The 10,000 USDC Experiment: Same Price, Different Outcomes
Ravel modeled two constant-product liquidity pools using the trading formula implemented in Uniswap v2.
Both hold USDC and an otherwise identical hypothetical Token X.
Pool A begins with 1 million USDC and 1 million Token X.
Pool B begins with 100,000 USDC and 100,000 Token X.
Their initial reserve ratios are identical, so both display a marginal price of 1 USDC per Token X.
The difference is scale.
Pool A holds ten times as many tokens on each side as Pool B, giving it substantially more liquidity to absorb a trade.
For the simulation, Ravel applies the standard Uniswap v2 swap fee of 0.30% and assumes no competing transactions, routing changes, gas costs, or additional token-transfer fees.
The calculation follows the getAmountOut function in Uniswap’s official v2 periphery source code.
Expressed in ordinary mathematical notation, the formula is:
Tokens received = (Input × 0.997 × Output reserve) / (Input reserve + Input × 0.997)
The 0.997 factor accounts for the 0.30% swap fee.
For a 10,000 USDC swap, the fee-adjusted input used to calculate the output is 9,970 USDC.
Applying the formula to Pool A gives:
(9,970 × 1,000,000) / (1,000,000 + 9,970)
The estimated result is 9,871.58 Token X.
Applying the same calculation to Pool B gives:
(9,970 × 100,000) / (100,000 + 9,970)
The estimated result is 9,066.11 Token X.
The smaller pool delivers approximately 805.47 fewer tokens, despite displaying exactly the same starting price.
That difference becomes easier to understand when the transaction is evaluated as a share of each pool’s initial USDC reserves.
In Pool A, the 10,000 USDC swap represents just 1% of those reserves.
In Pool B, it represents 10%.
The smaller pool must move much further along its pricing curve to accommodate the same order.
Ravel extended the calculation to several transaction sizes.
| USDC swapped | Pool A output | Pool B output | Difference |
|---|---|---|---|
| 1,000 | 996.01 | 987.16 | 8.85 |
| 5,000 | 4,960.27 | 4,748.30 | 211.98 |
| 10,000 | 9,871.58 | 9,066.11 | 805.47 |
| 20,000 | 19,550.17 | 16,624.98 | 2,925.19 |
All figures are modeled Token X outputs, rounded to two decimals. The reserves, fee rate, and AMM design remain unchanged across the comparison.
The widening gap is the most revealing result.
At 1,000 USDC, the difference between the two pools is relatively small.
At 20,000 USDC, Pool B delivers almost 3,000 fewer tokens than Pool A.
A tenfold difference in liquidity therefore produces increasingly important differences in execution as trade size grows.
This is why an apparently attractive token price does not necessarily indicate an attractive market to trade.
The depth supporting that price matters just as much.
And because the constant-product curve becomes progressively steeper as one reserve is depleted, the cost of a larger transaction does not increase in a simple linear relationship with its size.
The Missing Tokens Are Not All Trading Fees
A user who expects 10,000 tokens but receives 9,066 might reasonably wonder where the other 934 went.
One possible assumption is that the decentralized exchange collected the difference as a fee.
That would be incorrect.
In the simulation, both pools charge the same 0.30% swap fee.
For a 10,000 USDC transaction, that fee corresponds to 30 USDC of the input amount.
Under the standard Uniswap v2 model, trading fees remain with the pool and benefit liquidity providers through their share of the reserves, subject to the protocol’s fee configuration.
The much larger difference in the final token output is primarily a consequence of the pricing curve.
To isolate that effect, Ravel compares the expected output with the fee-adjusted input valued at the pool’s original 1:1 price.
Without any reserve movement, 9,970 USDC would correspond to 9,970 Token X.
But the actual calculations produce less.
| Component | Pool A | Pool B |
|---|---|---|
| Starting-price equivalent | 10,000 | 10,000 |
| Fee-adjusted input equivalent | 9,970 | 9,970 |
| Actual modeled output | 9,871.58 | 9,066.11 |
| Additional shortfall against fee-adjusted baseline | 98.42 | 903.89 |
The 30 USDC fee is the same in both pools.
The additional shortfall is dramatically different.
These are useful analytical components, although the output effect of removing the trading fee from a full AMM calculation is not exactly 30 tokens because fee size and curve movement interact.
That interaction does not alter the central finding: the overwhelming majority of Pool B’s shortfall relative to the fee-adjusted baseline comes from executing a large trade against limited liquidity.
Those tokens have not necessarily been transferred to a hidden intermediary.
They remain in the pool because the trade receives fewer tokens under the constant-product pricing rule.
The resulting reserve changes make the mechanism even clearer.
After the 10,000 USDC purchase, Pool A would hold approximately 1,010,000 USDC and 990,128.42 Token X.
Its new marginal price would be approximately 1.0201 USDC per Token X.
Pool B would hold approximately 110,000 USDC and 90,933.89 Token X.
Its new marginal price would be approximately 1.2097 USDC per Token X.
Both pools started at 1.
The large pool’s marginal price rose by roughly 2.01%, while the smaller pool’s marginal price rose by approximately 20.97%.
Neither number is the trader’s average execution shortfall.
Pool A’s trade delivered about 1.28% fewer tokens than the original 1:1 benchmark, including the swap fee.
Pool B’s shortfall was approximately 9.34%.
The distinction between the ending marginal price and the average execution price matters because a transaction receives liquidity along the curve, not entirely at the final price.
Uniswap’s explanation of price impact identifies the relationship between trade size and available liquidity as the central factor.
Large price impact is not necessarily evidence of market manipulation.
It may simply be the predictable result of asking a small pool to fill a disproportionately large transaction.
The trader’s quote already reflects that cost.
Which raises another question: if the unfavorable result is already included in the quote, what exactly does slippage mean?
Slippage Begins When the Quoted Result Changes Before Execution
Price impact and slippage are often discussed together because both can leave a trader receiving fewer tokens than expected.
But they describe different events.
Price impact comes from how the trader’s own order changes the pool’s reserves.
Slippage, in the usual quote-versus-execution sense, occurs when the amount available at execution differs from the earlier estimate.
Uniswap makes this distinction explicit in its Price Impact vs Price Slippage guide.
Return to Pool B.
At the moment the trader prepares the transaction, the reserves are 100,000 USDC and 100,000 Token X.
The displayed quote for swapping 10,000 USDC is approximately 9,066.11 Token X.
The trader accepts that estimate and submits the transaction.
Before it executes, however, another user swaps 250 USDC for Token X in the same pool.
That earlier transaction changes the reserve balances.
Using the same Uniswap v2 formula to process the 250 USDC transaction first, Ravel calculates that the original trader’s available output falls to approximately 9,023.06 Token X.
The change is about 43.05 tokens, or 0.475% below the original quote.
This additional difference was not present when the trader initially reviewed the swap.
It arose because the pool’s condition changed before execution.
Now suppose the trader had selected a slippage tolerance of 0.5%.
That tolerance is normally applied to the quoted output, not to the initial 1:1 token price.
For the original quote of 9,066.11 tokens, a 0.5% tolerance establishes a minimum acceptable output of approximately 9,020.78 tokens.
The revised output of 9,023.06 remains just above that threshold.
Under the modeled conditions, the swap can proceed.
But consider a larger intervening transaction.
If another trader had swapped 500 USDC in the same direction before the original transaction, Ravel’s model estimates that the available output would fall to approximately 8,980.31 Token X.
That is below the 9,020.78 minimum.
A router enforcing this output floor would reject the swap rather than execute it at the worst price.
The transaction could still consume network gas if it reached the blockchain and reverted.
Uniswap v2’s router implementation enforces an amountOutMin condition on relevant exact-input swaps, providing the contractual basis for this protection.
The distinction exposes a common misunderstanding.
A slippage tolerance of 0.5% does not guarantee that a trader buying a token initially priced at $1 will receive tokens at an effective price within 0.5% of that reference price.
In Pool B, the quote was already approximately 9.34% below the idealized 10,000-token benchmark.
A 0.5% slippage tolerance only limits further deterioration relative to the accepted quote.
The initial price impact has already been incorporated.
Tightening the tolerance cannot reverse it.
It can only restrict how much worse execution may become after the quote is established.
How MEV Can Turn Slippage Tolerance Into an Opportunity
The possibility of a changing quote creates another layer of risk.
Not every transaction that changes a pool’s reserves before another swap is suspicious. Markets are active, and unrelated users can legitimately submit competing trades.
But some participants deliberately exploit the ordering of transactions.
One example is the sandwich attack.
A searcher identifies a pending swap and attempts to place its transaction immediately before it.
The searcher’s first trade changes the pool reserves in a direction that makes the pending swap execute at a worse price.
After the original trader’s swap moves the price further, the searcher places a second trade to unwind the initial position and attempt to capture a profit.
The mechanism is described in Ethereum’s official MEV documentation, which distinguishes sandwich trading from other forms of transaction-ordering activity.
The important point is that the attacker does not need to convince the victim to accept an entirely different token price after the transaction has been submitted.
The victim has already defined an acceptable range through the minimum output condition.
If an attacker can alter pool conditions while keeping the victim’s resulting output within that range, they can extract some of the available execution value.
This does not mean every swap with a generous slippage tolerance will be sandwiched.
A profitable attack also depends on transaction visibility, available liquidity, gas costs, competing searchers, the execution route, and the attacker’s ability to influence transaction ordering.
It does mean that slippage tolerance has a dual role.
For traders, it provides flexibility when prices move.
For adversarial searchers, that same flexibility may reveal how much unfavorable movement the trade will tolerate before reverting.
A narrow tolerance reduces the acceptable deterioration, but it can also increase failed transactions in volatile conditions.
A wide tolerance reduces the likelihood of certain failures while allowing a less favorable execution.
The trade-off cannot be eliminated simply by selecting one universal percentage for every market.
This problem has also motivated new proposals.
In August 2026, a draft Ethereum standard called ERC-8377, Reference-Relative Slippage Bounds, proposed evaluating acceptable swap output against a reference price observed at execution rather than relying solely on a static minimum established earlier.
The proposal explicitly addresses the weakness of a potentially outdated quoted minimum.
It remains a draft and should not be treated as a protection already adopted across decentralized exchanges.
Nor does its design claim to eliminate all forms of MEV.
Its relevance is that it identifies a deeper limitation in ordinary slippage controls: the protection often depends on information captured before the transaction actually executes.
That information can become stale.
For traders, evaluating a swap therefore requires more than checking whether the interface displays a small slippage percentage.
The first consideration is liquidity depth. A large trade relative to available reserves may produce significant price impact before any competing transaction enters the picture.
The second is the expected output itself, compared with alternative routes or deeper pools.
Routing a trade through multiple pools or dividing execution across available liquidity can sometimes improve the result, although additional hops, fees, gas costs, and execution risks must also be considered.
The third is execution protection: how the minimum acceptable output is calculated, whether the transaction uses suitable deadlines, and whether available routing mechanisms reduce exposure to adverse ordering.
Private transaction routing and other MEV-aware execution methods can help in certain circumstances, but their protections depend on implementation and are not absolute.
These considerations reveal what the displayed token price leaves out.
A pool may offer a marginal price of $1 without having enough depth to fill a meaningful order anywhere near that price.
A quoted swap may already contain a substantial liquidity cost before slippage occurs.
And a transaction that looks acceptable when signed may produce a different result if pool conditions change before execution.
The mathematical rules are public. The reserve balances are observable. The resulting output can be calculated.
None of that guarantees that the price shown at the beginning of a trade represents the price the trader will actually receive across the entire order.
In decentralized markets, the number beside a token is only the beginning of the calculation.
What matters is how much liquidity stands behind that number and what remains available when the transaction executes.
