Pool Turnover Isn’t Execution Cost: Pricing a $50,000 Uniswap v3 Swap
Contents
What a fixed-block quote reveals about pool activity, price impact, fees, and slippage tolerance.

Overview. Historical pool activity describes past trading; execution cost depends on the current pool state, trade direction, size, and fee tier. The right-hand quote is a fixed-block, single-pool simulation.
A decentralized-exchange (DEX) dashboard can make a pool look reassuring before I have asked the only question that matters for an order: what will I receive? In a GeckoTerminal snapshot captured at 2026-10-09T00:19:11Z, the Ethereum Uniswap v3 WETH/USDC 0.05% pool 0x88e6…5640 showed about $77.4 million of 24-hour volume and $95.3 million of reported liquidity. Its turnover was about 0.814×. That is a lot of activity. It is not a quote for my next $50,000 trade.
The pool looks busy
Volume records trades that already happened over a window. For this example, I use GeckoTerminal's dollar-denominated Liquidity field as the pool-level capital measure in the Volume/TVL ratio. I call it reported liquidity below; it is a dollar-denominated pool-level metric, not a direct measure of liquidity available at every price. Dividing trailing 24-hour volume by that field gives the turnover ratio used here:
At the snapshot, the prior 24-hour volume was substantial relative to reported liquidity. The ratio still omits the order details that determine execution: direction, size, fee, current price, and which liquidity ranges are active.

Fig. 1. What the dashboard tells me. GeckoTerminal's
Ethereum page for Uniswap v3 WETH/USDC 0.05%, captured 2026-10-09T00:19:11Z.
24h Vol and Liquidity are native fields. The
0.814× ratio is calculated externally from the corresponding API values
around the same time; it is not a native metric.
The timestamp matters. This trailing activity does not describe every pool state during those 24 hours. A pool can process many small trades or repeated arbitrage without that history specifying the execution curve my order will face.
For comparable constant-product pools, larger proportional reserves improve local depth. Volume/TVL still cannot tell me how far a particular order travels through the current automated-market-maker (AMM) state.
What happens when I send the order?
In a limit order book, I inspect quantities at successive prices. An AMM uses a curve and, in Uniswap v3, active liquidity ranges. The trader's question is the same: how does execution cost change as the order gets larger?
The previous article introduces how a constant-product curve turns a starting quote into an order-wide execution price.
I tested three order sizes against the same real pool state: $1,000, $10,000, and $50,000. The average execution price becomes slightly worse as the order grows.

Fig. 2. How execution cost changes with trade size. Single-pool QuoterV2 simulations for USDC→WETH at the selected 0.05% pool and a fixed Ethereum block. Total quote gap includes the 5 bp fee; fee-adjusted curve impact removes that baseline. These are not router quotes, frontend price-impact labels, or realized trades.
The block's starting marginal price was about $2,477.35 per WETH. The $50,000 input returned about 20.1651 WETH, or $2,479.53 per WETH on average. Its total quote gap was 0.0879%. The pool charges a 5-basis-point input fee; under this exact-input benchmark, the fee-only effective-price gap is about 0.05003%. The fee-adjusted curve impact is 0.0378%, using the multiplicative decomposition in the appendix. The pool was deep at this block, but a similar turnover ratio can accompany different ranges, fees, direction, or active depth.
When the numbers move together
First, imagine this exact pool state—with the same active liquidity and fee—but with twice as much trading volume yesterday. Turnover would rise from 0.814× to about 1.63×. My next $50,000 quote would not change. The AMM prices this order against its current state, not yesterday's transaction count.
Second, imagine reported capital staying near the same level while liquidity providers move capital away from the current trading range. In a concentrated-liquidity pool, the depth available along my execution path can fall even while the dashboard continues to show substantial capital. The same order can receive a worse quote, with little change in turnover. This is not a claim that TVL is irrelevant; it is a reminder that similar reported capital need not sit in the same price ranges.
Finally, imagine I have already accepted a quote and the pool state changes before execution. The quote can worsen. Slippage tolerance does not restore the original quote; it sets a minimum-output condition for whether I accept the changed result.
These are constructed scenarios, not three observed market events. Yesterday's trading volume does not tell me what is available now. I still need a quote for my order, and I need to decide how much that quote can worsen before I trade.
Price impact, slippage tolerance, and realized slippage
The initial marginal price is the price of the next infinitesimal part of an order, not the price of the whole order. As I buy WETH, later portions execute at higher prices. That is price impact. Here, I measure the order-size-dependent curve effect as the change in average execution price relative to the starting marginal price after removing the pool-fee baseline.
In the previous article, a constructed trade started at $2,000 per ETH but averaged $3,000 across the order. The final marginal price reached $4,500. Those are three different prices: where the trade began, what I paid on average, and where the pool ended.

Fig. 3. Where price impact comes from. In this constructed,
fee-less constant-product AMM, buying 3.3333 ETH moves the marginal price
from $2,000 to $4,500 per ETH. With q as cumulative ETH
purchased, the curve is p(q) = 200,000 / (10 − q)². The shaded
area is the $10,000 paid; dividing that area by the ETH received gives the
$3,000 average execution price. This is not an observed Uniswap v3
execution.
In this fee-less example, the average execution price was 50% above the starting marginal price: $3,000 instead of $2,000. The final marginal price was 125% above the start, but it was not the price paid for the entire order.
In the real Uniswap v3 example here, the effect was much smaller: the $50,000 USDC order moved from about $2,477.35 per WETH at the start to a quoted average price of $2,479.53. The 0.05% fee explains part of that difference; on the same average-versus-starting benchmark, the fee-adjusted curve impact was 0.0378%.
Slippage is different: the quote already reflects the expected impact of my order. A 0.5% tolerance sets how much further deterioration I accept before a minimum-output condition makes the swap revert; it does not reduce price impact. Because I did not submit a transaction, there is no realized slippage to measure here.
For a $50,000 order, I specify direction and size, then inspect expected output, effective price, fee tier, and whether the quote comes from one pool or a router that may use several. Only then do I set slippage tolerance as protection against a worse result than that quote.
In this case, the simulated single-pool execution cost was small, even for a $50,000 order. That was a property of the pool state and my order, not yesterday's turnover. Before trusting how much a pool traded, I want to know how much I can trade.
Appendix
- Data. Dashboard values are from the GeckoTerminal pool page, captured at 2026-10-09T00:19:11Z. The raw API values were about $77.57 million of trailing 24-hour volume and $95.25 million of reported liquidity.
- Method. The execution ladder uses Uniswap v3's
QuoterV2against the WETH/USDC 0.05% pool at Ethereum block 26,151,210. It is a fixed-state, single-pool simulation; it excludes gas, routing, and realized execution. - Fee benchmark. For an exact-input trade with a 0.0005 fee rate, the fee-only effective-price gap is 0.050025%, not exactly the 0.050000% fee rate. The decomposition is multiplicative:
Equivalently,
For the $50,000 quote, using the unrounded total gap g_total = 0.000878635913 (0.0878635913%):
- Code. GitHub Gist contains the fixed-block QuoterV2 inputs, raw-output checks, and fee decomposition behind Fig. 2.
- Related reading. TVL, Marginal Price, and Liquidity in an AMM explains why the current quote and an order's average execution price can diverge.