Matcha & 0x Aggregator Trades overcounted in dex.trades

Here is a query corresponding to this transaction demonstrating that a “single” token swap is being counted 6x in the dex.trades table.

1. There is double accounting for the same aggregator (0x and Matcha)
2. Each of the 3 “hops” of the trade is being counted on both aggregators.

Realistically, it makes sense to count each of the DEX trades, but for an aggregator protocol, this should only be counted a single trade for the user 0xd3f8f55b6b244afd86f2d0fb7f2de445cc0c10a8 who swapped ICE for USDC.

Or, at the very least only counted as a single aggregator (not two).

[fleupold]

why wouldn’t we necessarily think multi-legs on multi-hop should be all counted? by all aggregators?

My feeling is that aggregators primarily serve users (not liquidity providers) and should therefore report volume based on the user intent (Swap A for B regardless of whether it goes through C). Otherwise an aggregator who is serving the user better (e.g. not using a longer route if the trade execution cost is not worth the price improvement, or matching against a direct market maker) may be represented as worse (they used less hops) when looking at the top line metric.

For Meta DEX Aggregators like CowSwap counting the sum of all hops would also raise the question if we should then count the 0x Volume + underlying AMM volume together (seems silly)? For CowSwap in particular it is better to use less AMMs as this means less potential for MEV (similar to 0x RFQ orders).

[sui414]

thank you both for the comments & elaboration🙏 . currently at team offsite so might have delay respond until mid next week.

one thing to note tho - 0x has both aggregator portion (labeled as “0x API”) and DEX portion (labeled “0x Native”, rfq & open orders i.e. limit orders) - the DEX portion is where we see overlap with paraswap above and is not included in that dash. for that dash, we only count “0x API” /swap endpoint volume. (limit order volume is thru another endpoint orderbook).

appreciate your research in depth on this! we currently don’t log multi-hop events and might need to decode from traces, or do extra clean up on those trades – if we agree to dedup on those cases.

why wouldn’t we necessarily think multi-legs on multi-hop should be all counted? by all aggregators? it does 1: accrue fees; 2: have counterparties if we count LPs.