The Math Behind Uniswap Prices: Bonding Curves, Slippage Formulas, and Predicting Execution Price

A trader wants to swap 10 ETH for USDC on Uniswap but has no way to know the exact price they will receive until the transaction settles. The wallet shows an estimated amount and a “maximum slippage” warning, but what determines that price? The answer lies not in a central order book or price feed, but in a mathematical formula that governs a liquidity pool. Understanding that formula reveals why executing large trades destroys value, why liquidity depth matters more than listed volume, and how to predict the true cost of any transaction before pressing approve.

Uniswap’s core engine is an automated market maker built on a deceptively simple equation: x × y = k. This constant product formula replaces traditional market makers with a mathematical rule that accepts all trades at a price determined entirely by the ratio of assets in a liquidity pool. Every trade moves the ratio, which moves the price. Every transaction costs gas, and most transactions also incur slippage—the difference between the displayed estimate and the actual execution price. These costs are not hidden fees; they are direct consequences of the protocol’s design. Mastering the math allows a trader to predict slippage before committing capital and to understand why certain strategies minimize loss while others amplify it.

The constant product formula and pool equilibrium

At the heart of Uniswap’s price discovery mechanism is the equation x × y = k, where x represents the quantity of one token in a liquidity pool, y represents the quantity of the paired token, and k is a constant. This formula is the defining characteristic of the constant product formula, and it guarantees that the product of the two token quantities remains fixed across all trades. When a trader deposits token A and withdraws token B, the pool absorbs the deposit into x, reduces y by the withdrawal amount, and maintains the invariant k. If the invariant is violated, the transaction fails.

The equilibrium price at any moment is simply y / x, the ratio of the two assets. If a pool holds 100 ETH and 200,000 USDC, the price of ETH in USDC terms is 2,000. This is not a price quoted by an exchange or derived from a median of external sources. It is the instantaneous price implied by the pool’s composition. As soon as a trader removes 10 ETH from the pool, x becomes 90, and k must be maintained, so y becomes 200,000 multiplied by (100 / 90), which equals 222,222.22 USDC. The price of the next infinitesimal trade is now 222,222.22 / 90, or approximately 2,469 USDC per ETH. The price has moved upward because removing liquidity from the pool of one side increases its scarcity relative to the other side.

This self-adjusting price mechanism has profound implications. There is no order book, no market maker deciding to widen or tighten spreads, and no central authority setting prices. Instead, the formula enforces a rule: larger withdrawals from a pool incur higher prices because they move the ratio more dramatically. A withdrawal of 1 ETH from that same 100/200,000 pool costs roughly 2,020 USDC; a withdrawal of 10 ETH costs roughly 22,222 USDC, not 20,200. The difference is not a hidden fee but a direct result of the math. This difference is called price impact, and it is the primary cost of trading on an automated market maker beyond network gas fees.

The security of this system rests on the immutability of k and the permission-free nature of liquidity provision. Anyone can deposit tokens into a pool and receive liquidity provider shares proportional to their deposit. Anyone can withdraw by burning those shares and receiving their portion of both tokens. The protocol does not care who the liquidity providers are or why they are providing liquidity. The constant product formula guarantees that as long as k is preserved, arbitrage traders can rebalance pools toward fair market value relative to external prices. This mechanism keeps Uniswap prices anchored to broader market conditions without relying on any centralized oracle or authority.

Deriving the slippage and price impact equation

To predict slippage before submitting a transaction, a user must derive the relationship between the size of a trade and the price impact incurred. Start with the constant product formula: x × y = k. If a user deposits an amount Δx of token A, the pool must absorb it, so the new x becomes x + Δx. For k to remain constant, the new y must become k / (x + Δx). The output of the trade is the amount of token B removed, which is y − k / (x + Δx).

Let’s call the output amount Δy, so Δy = y − k / (x + Δx). Because y = k / x, we can rewrite this as Δy = k / x − k / (x + Δx), which simplifies to Δy = k × (1 / x − 1 / (x + Δx)) = k × ((x + Δx − x) / (x × (x + Δx))) = k × (Δx / (x × (x + Δx))). Since k = x × y, substituting back gives Δy = (x × y × Δx) / (x × (x + Δx)) = (y × Δx) / (x + Δx).

This formula reveals the core mechanism of price impact. For a small trade where Δx is much smaller than x, the formula approximates to Δy ≈ (y × Δx) / x, which is simply the spotPrice × Δx—the expected output without impact. As Δx grows relative to x, the denominator (x + Δx) increases more than the numerator, and the effective price (Δy / Δx) decreases. The exact execution price for a trade of size Δx is therefore (Δy / Δx) = (y / (x + Δx)), which is lower than the spot price y / x. The difference between the spot price and the execution price is the slippage.

Slippage can be expressed as a percentage: (spotPrice − executionPrice) / spotPrice. Using the equations above, this becomes ((y / x) − (y / (x + Δx))) / (y / x) = (1 − (x / (x + Δx))) = Δx / (x + Δx). For small trades, this approximates to Δx / x, which is the percentage of the pool size being traded. A 1% trade against the pool incurs roughly 0.5% slippage (the approximation omits the second-order term); a 10% trade incurs roughly 5% slippage; a 50% trade incurs roughly 25% slippage. These are not flat fees charged by Uniswap but mathematical consequences of reshaping the pool’s composition. The trader pays the slippage implicitly through a worse execution price.

Liquidity concentration and V3-style pricing

Uniswap V2 distributes liquidity evenly across the entire price curve from zero to infinity. A liquidity provider deposits equal values of both tokens, and those tokens sit passively until a trade passes through the current price. Much of that liquidity may sit unused if prices remain in a narrow range. Uniswap V3 and later versions introduced concentrated liquidity: a provider can specify a price range and deposit liquidity only within that range. The same amount of capital can support far more trading at a chosen price level, which reduces slippage for traders willing to stay within that range.

The math shifts when liquidity is concentrated. Instead of one global x and y, the V3 and later formulas track liquidity at discrete price tiers. The constant product formula still applies at each tier, but with a local x and y rather than pool-wide aggregates. When a trader swaps at a price level supported by concentrated liquidity, they move through less virtual capital to achieve the same trade size, incurring higher price impact than they would in a pool with dispersed liquidity. Conversely, if a pool has deep concentrated liquidity at the current price, a moderate trade incurs much less slippage than in a V2 pool with the same total liquidity spread across all prices.

This change makes V3 and V4 pricing more complex to predict without a calculator or simulation. A user cannot simply estimate slippage from pool size; they must also consider where the liquidity is positioned relative to the current price. A 100 USDC trade might incur 0.01% slippage in a concentrated liquidity range with deep capital but 1% slippage in an empty or distant range. This is why modern Uniswap interfaces always display an estimated output amount: the calculation is no longer a simple algebra problem but a simulation through the pool’s actual liquidity distribution. The underlying principle remains the same—larger trades relative to available liquidity incur higher price impact—but the practice of predicting the price before transaction submission requires checking the interface estimate or running a simulation library.

Fee structures and their effect on the bonding curve

Uniswap pools charge a fee on every swap, typically 0.01%, 0.05%, 0.30%, or 1.00% of the input amount, depending on the pool’s tier. This fee is paid to liquidity pools in proportion to their holdings. The constant product formula does not include fees directly; instead, fees are deducted from the input before the formula is applied. If a trader inputs 1,000 USDC into a 0.30% pool, the pool credits 999.70 USDC to x, and the remaining 0.30 USDC is distributed pro-rata to all liquidity providers. The effective price impact is then calculated on 999.70, not 1,000.

This structure means that fee tiers alter the effective bonding curve. A 0.01% fee pool is cheaper for small trades but attracts deeper liquidity because the returns to liquidity providers are thinner; a 1.00% fee pool is expensive but may attract specialized liquidity providers willing to take on higher risk or volatility. The relationship between fee level and price impact is not linear. A trader choosing between pools must consider both the listed fee and the liquidity available at that fee tier. A 0.05% pool with shallow liquidity might actually cost more total than a 0.30% pool with deep liquidity, because slippage from low liquidity exceeds the fee difference.

The math can be extended to show that for a trade of size Δx, the total cost is roughly (fee × Δx) + (0.5 × (Δx / x) × y), where the first term is the explicit fee and the second approximates the price impact cost. For small trades, fees dominate; for large trades, impact dominates. A liquidity provider’s choice of fee tier should ideally match the expected trade size of users and the volatility of the pair. If only large trades occur, the higher slippage in the lower-fee pool can offset the fee savings. If only small trades occur, the fee tier matters more than liquidity depth.

Real-world execution with MEV and intent-based protocols

The equations above describe how prices move in a frictionless system, but real transactions on Ethereum face additional costs: gas fees, miner/validator tip, and maximal extractable value (MEV). A user submits a swap transaction to the mempool, where it sits in a queue alongside every other pending transaction. A block builder can observe that the user intends to swap a large amount, and that this swap will move the pool’s price. A builder can extract MEV by inserting a transaction before the user’s swap to move the price unfavorably, execute the user’s swap at a worse price, and then extract the difference—a practice called sandwich attack.

To mitigate this, Uniswap supports MEV protection through a separate service, UniswapX, which batches intent-based swaps and executes them through competing solvers rather than exposing them to the public mempool. An intent-based swap is a user’s statement of what they want (swap 10 ETH for at least 18,000 USDC), without specifying the exact route or timing. Solvers can compete to fulfill that intent profitably, and the solver extracting the least MEV wins. This mechanism preserves the security guarantee that a user’s slippage protection remains enforceable, even if the exact execution price differs from the estimate.

The mathematical reality is that MEV protection is not free. Solvers must be compensated, and the compensation comes either from the user or from executing the swap on the user’s behalf at a price slightly worse than they would have received in the public mempool. In efficient markets with many solvers, this cost approaches the MEV that would have been extracted anyway. For very large swaps or volatile markets, MEV can exceed 0.5%, so intent-based execution becomes a net gain. For small swaps in stable pools, the overhead of using UniswapX may exceed the MEV protection benefit, and direct pool interaction may be cheaper. Understanding how the leading decentralized exchange works in 2026 includes recognizing when to use each execution path based on trade size, market conditions, and risk tolerance.

Predicting execution price before transaction submission

To forecast the exact price a user will receive, they must know the pool’s exact x and y values at execution time and apply the formula Δy = (y × Δx) / (x + Δx). In practice, this requires querying the blockchain or an off-chain data source in real time, applying the calculation, and then checking whether the pool’s composition has changed since the query. Because block times are typically 12 seconds on Ethereum, and significant events or price movements can shift pool composition within that window, any prediction is provisional until the transaction is mined.

Modern Uniswap interfaces use a multi-step process. First, they query the current pool state from the blockchain or a cached index. Second, they simulate the user’s trade against that state, calculating the expected output. Third, they apply a slippage tolerance—typically 0.5% to 1%—and set the minimum acceptable output to (expected output × (1 − slippage tolerance)). If the price moves unfavorably before the transaction is mined, and the actual output would be less than this minimum, the transaction reverts, protecting the user from unexpectedly bad execution.

For a user wanting to verify this calculation themselves, the steps are: (1) retrieve the pool’s current x and y from the blockchain, (2) substitute them into Δy = (y × Δx) / (x + Δx), (3) subtract the protocol fee to get the net output, (4) divide by Δx to find the execution price, and (5) compare to the spot price y / x to quantify impact. Libraries like ethers.js or Web3.py can fetch pool state; mathematical frameworks like Python or spreadsheets can run the formula. For a 10 ETH swap in a 100 ETH / 200,000 USDC pool with 0.30% fee, the calculation would be: net input = 10 × 0.997 = 9.97; output = (200,000 × 9.97) / (100 + 9.97) = 1,994,000 / 109.97 ≈ 18,139 USDC; execution price ≈ 1,814 USDC/ETH, compared to the spot price of 2,000 USDC/ETH, for a slippage of approximately 9.3%.

Practical implications for traders and liquidity providers

For a trader, the math reveals that large single trades are expensive. Splitting a trade into multiple smaller swaps across different pools or moments reduces slippage because each individual trade moves the price less. The total gas cost may increase, but on-chain execution costs can be offset by better prices. This principle explains why sophisticated traders use swapping algorithms and why Uniswap V3 concentrated liquidity benefits traders who can source deep, narrow pools rather than shallow, wide pools.

For a liquidity provider, the formula shows that earning capacity depends directly on trading volume and volatility. A pool earning 0.30% fees with $100 million in daily volume and 10% annual volatility generates revenue that must compensate for impermanent loss—the cost of prices moving away from the provider’s entry point. The math of impermanent loss is subtle but crucial: if a provider deposits equal values of two tokens at a 1:1 price and the price moves to 1:2 (a doubling), the provider’s holdings shift toward the asset that lost value, and their net position is worth less than if they had simply held both assets without providing liquidity. Concentrated liquidity makes this worse by amplifying the effect within the chosen range, requiring higher fees or lower volatility to remain profitable.

Choosing a fee tier and price range requires balancing capital efficiency (earn fees on more volume with concentrated liquidity) against impermanent loss risk (volatile pairs require wider ranges and thus lower capital efficiency). The mathematics of this trade-off has no single answer; it depends on the pair’s history, the provider’s risk tolerance, and their ability to actively manage the position. A provider offering on a stablecoin pair with low volatility can concentrate liquidity tightly and earn steady fees; a provider offering on a newly launched token with wild swings must either accept lower capital efficiency or exit the position when losses become unacceptable.

Gas efficiency and the total cost of swapping

Gas costs complicate the price impact calculation because they are paid in ETH on Ethereum and Layer 1, while price impact is denominated in the tokens being swapped. A typical Uniswap V2 swap costs 40,000 to 60,000 gas units; a V3 swap costs 80,000 to 120,000 units depending on the number of hops and price ticks crossed. At a gas price of 50 gwei per unit and an ETH price of $3,000, a V2 swap costs roughly $6 to $9 in gas fees. For a $100,000 trade, this is 0.006% to 0.009%—negligible. For a $1,000 trade, it is 0.6% to 0.9%—material. For a $100 trade, it is 6% to 9%—prohibitive.

Layer 2 networks like Arbitrum, Optimism, and Base reduce gas costs to 0.1 to 0.5 gwei and offer compression, making swaps cost-effective at much smaller sizes. The mathematical comparison shifts: a swap on Layer 2 might cost $0.01 to $0.10, moving the break-even swap size downward by 100-fold. This is why users with smaller positions increasingly migrate to Layer 2 Uniswap deployments. The bonding curve math remains identical; only the gas component of the total cost changes. A trader choosing between Layer 1 and Layer 2 execution is making a mathematical decision: which network’s combined fee and gas cost is lower for the specific trade size?