Two measurements of Uniswap execution landed on the same surface this month, and at a glance they look like the same measurement. A public study on ethresear.ch, "When Multiple Pools Behave Like One: Impact-Constrained Capacity Concentration in Uniswap v3," reconstructs how much liquidity a pair actually holds. ClearTrace measures what a trader's order actually received. A desk evaluating execution needs both, and using one where the other belongs is a mistake worth naming.
What the study measured: available capacity
The study reconstructs daily Uniswap-v3 pool state from Mint, Burn, and Swap events, then runs a capacity optimizer: for a given pair on a given day in a given direction, what is the maximum notional you can push at a fixed price-impact tolerance (it tests 10, 25, 50, and 100 bps), on the single best pool versus split across the pair's sibling fee-tier pools? It scores concentration with the Herfindahl index of per-pool capacity shares, HHI = Σ sp2, and reports its reciprocal Neff = 1/HHI, the effective number of pools.
The headline result, across 293,273 family-day-direction-impact cells over 78 pairs (Ethereum, 2024-01-01 to 2026-06-29): median Neff of 1.076, a single fee tier holding a median 96.3% of impact-constrained capacity, capacity-concentration HHI of 0.926. Despite multiple fee-tier pools per pair, the depth that matters at a fixed impact tolerance sits in one of them. Multiple pools behave like one.
The author scopes it tightly, and the scope is the whole reason this note exists. The optimizer "measures impact-constrained capacity at the liquidity layer; gas, routing frictions, MEV, and cross-layer causality are out of scope," it "is not a welfare benchmark," and it is a "selected multi-pool pilot, not a representative sample." It is a supply-side, counterfactual measurement: how much could be executed, not what was.
What ClearTrace measures: realized fills
ClearTrace starts from the opposite end. It takes an aggregator's quote, quoted_out, and the fill that actually settles, realized_out, and measures the gap, then decomposes it into the pieces that caused it:
output_gap_bps = (quoted_out − realized_out) / quoted_out × 10,000
slippage_bps = output_gap_bps − fee_bps − mev_bpsReverts are never forced into that formula; a failed trade decomposed nothing, so it is counted as a rate across a batch instead. That decomposition runs at the aggregator and frontend layer, over actual and fork-simulated fills at fixed sizes ($1k / $10k / $100k / $1M). It includes precisely the three things the study sets aside: MEV, reverts, and routing topology. The formula-level version is written up in how the execution-quality numbers actually work.
The numbers it produces are realized outcomes. On the 2026-08-26 sampler export, across Ethereum aggregators, the median fill lands at or within a fraction of a basis point of its quote at every size cohort, while fork-verifiable quotes fail to realize at a low single-digit rate that varies by size (3.6% at $1k, 2.2% at $100k, 4.5% at $1M). These are demand-side measurements: what a specific order got, after the router did its work.
Why they are different objects
The study reconstructs the liquidity a pair holds. ClearTrace scores the fills a trader received. Available capacity is a ceiling; a realized fill is a result, and the distance between them is exactly the routing, MEV, and reverts the study places out of scope. The author says as much directly: observed flow concentration and reconstructed capacity concentration "are different objects," and the comparison "does not imply that traders fail to use capacity, that observed routing is inefficient, or that the optimizer is efficient."
Two consequences follow, and both matter for reading either number correctly. A pair with Neff ≈ 1 can still deliver a clean fill, because a router works around a shallow book by splitting across venues. And a pair with ample impact-constrained capacity can still realize badly, because MEV or a revert lands on the actual trade and never touches the counterfactual optimizer. Neither measurement validates the other's figures. They answer different questions about the same pair.
Concretely: ClearTrace runs nothing resembling the study's method. There is no pool-state reconstruction, no Herfindahl of capacity shares, no Neff, no impact-constrained optimizer anywhere in its codebase. It never needed one, because it measures the trade rather than the terrain.
The one place they connect
There is a real link, and stating it precisely is more useful than overstating it. The study describes the terrain a router faces on Ethereum: at the AMM layer a pair is effectively one deep pool, not a spread of independent ones. ClearTrace's realized data shows median fills holding near their quote across sizes anyway. Those two facts are consistent with each other only if size-aware routers are spreading orders across mechanisms rather than leaning on that one pool, and that is what the per-trade routing data shows: in the same export, 83.7% of sampled $1M routes split across more than one venue (median three distinct venues per route), against 69.0% at $1k.
The routing data also shows where those extra venues come from, and at size they are increasingly not AMM pools at all. On the same export, the share of KyberSwap's sampled Ethereum routes touching at least one RFQ leg (an off-chain market-maker quote, detected from desk names such as Hashflow and Native on the quote's own route) rises from 2.2% at $1k to 10.0% at $10k, 21.5% at $100k, and 81.1% at $1M over the full sample span. That last number moves: it held in the 80s through July, dipped into the 60s in early August, and stands at 73.8% for August to date, so read it as a range, not a constant. Three scope caveats keep the figure honest. It counts routes that touch RFQ, not RFQ's share of routed volume; a $1M order that fills one leg through a desk and the rest through pools counts once. It is a per-source figure for KyberSwap only, because most aggregators' quote responses expose no route at all (six of the eleven sampled sources are structurally unreadable on this dimension, so their zeros mean the route cannot be seen, not that no RFQ was used). And rather than undercutting the capacity comparison, it sharpens it: RFQ depth is exactly the liquidity a pool-state reconstruction cannot measure, so at $1M the realized fills in this data route dominantly through depth that is invisible to the study's optimizer by construction.
So the study offers a supply-side explanation for why aggressive size-aware routing exists, and ClearTrace measures whether that routing actually delivers. The study explains the terrain; ClearTrace scores the drive. They are independent, they were built by different people for different reasons, and they do not overlap. That is what makes the pairing worth writing down rather than a coincidence to wave at.
What it means for a desk
If you evaluate execution, you want both views and you should not substitute one for the other. The supply view tells you how much a venue can absorb before impact bites, which is a property of the pool. The demand view tells you what your order actually received, which is a property of your trade and the route it took. A venue can look deep and fill you badly; a venue can look shallow and fill you well through a router. One number without the other is half the picture.
Sources
All capacity-concentration figures (293,273 cells, 78 families, Neff 1.076, top-tier share 96.3%, capacity HHI 0.926) are the study author's, reported from the ethresear.ch post, retrieved 2026-08-28; quoted scope language is the author's. All ClearTrace figures (fail-to-realize rates by size, median fill-vs-quote, multi-venue route shares, KyberSwap RFQ-touch shares by size) were re-derived for this note from the 2026-08-26 21:33 UTC sampler export, Ethereum, sim-supported cells; the measurement pipeline is documented in the interactive execution-quality explainer and its companion methodology write-up.