Do several aggregators really give you more liquidity?

Two aggregators can expose the same pool. Comparing both interfaces gives you two ways to request execution, not necessarily twice the underlying liquidity. Deduplicate the actual venues before summing capacity.

Follow the pool identity

Suppose hypothetical Aggregator A accesses pools X and Y, while Aggregator B accesses Y and Z. A combined source list has three unique pools, not four. If Y carries most of the useful depth, treating its presence in each interface as independent capital badly overstates the total.

Pool identity includes network, protocol version and the actual contract or pool identifier. A ticker pair alone is not enough: several distinct pools can share the pair, and the same pool can appear under several interface labels.

Capacity can also share a bottleneck

Two apparently different paths may both use a thin connecting pool. Their maximum outputs cannot necessarily be added as if that shared pool could serve each path from its original state. Executing one path can change the shared state used by the other.

Uniswap describes each pool as a separate trading venue. The interface that discovers or presents it is a different layer from the capital held in that venue.

Keep source coverage and result quality distinct

A second aggregator may still provide value through different quoting, additional venues or different execution costs. The correction is not that duplicate coverage is useless; it is that duplicate coverage should not be counted as extra deposited capital.

For a liquidity report, list unique sources and shared dependencies. For a user cost comparison, obtain matched final quotes from each interface. Do not estimate the benefit of using several aggregators by adding their advertised TVL, source counts or independently quoted maximum trade sizes. Those figures can overlap both in ownership of capital and in the state they assume.