A sudden spike in DEX new user data is often the most exciting moment for project teams and communities. But there is an easily overlooked trap here: DEX aggregators split a single user transaction into multiple underlying trades. If you count using "raw trade count" or "interacting address count," one real user can easily be counted as three or four "new users."
A leading global cryptocurrency platform,suitable for both beginners and experienced traders.
New user benefit: 20% off trading fees upon registration!！
Eliminate the double counting caused by aggregators first, then assess whether the growth is real. Here are 3 steps.
Step 1: Understand the Difference Between "One Aggregator Trade" and "Multiple Underlying Trades"
The core function of a DEX aggregator is to help users find the best price. To achieve this, it splits a single user swap request into multiple trades across different DEXs. Dune's official documentation directly explains this distinction: the dex_aggregator.trades table condenses the user's original trade into a single record, while the dex.trades table records every intermediate step after the split.
What to do: Before reviewing DEX user data, first confirm whether the data source is "user-level" or "trade-level."
How to do it:
When querying on Dune or similar platforms, prioritize using the
dex_aggregator.tradestable instead of thedex.tradestable. Thedex_aggregator.tradestable is specifically designed to compress aggregator trades back to the user perspective.If your data source only contains underlying trade records, you need to manually deduplicate by
tx_hashandtx_from(the transaction initiator's address). Multiple sub-trades initiated by the same user within the same transaction hash should only count as 1 user trade.
When is this step complete: You have confirmed that the "new user" data you are looking at is based on user intent trades, not on underlying sub-trades.
Common failure mode: Directly treating DEX "unique trading address count" as "unique user count." Under the aggregator routing model, a user signs only one transaction, but three or four interactions may occur at the base layer. If you count by "trading address count," the same user gets double counted.
Step 2: Use "Entity Aggregation" Features or SQL Deduplication
Even when using the dex_aggregator.trades table, if a single user makes two trades in different directions through the same aggregator on the same day, they will still appear twice in your "new address" count. Deduplication by address is needed to count true "new users."
What to do: When counting "new users," group by wallet address and take the first interaction time, rather than counting by number of trades.
How to do it:
If using Dune SQL, use
MIN(block_time)grouped bywallet_addressto find each address's first interaction time. Only addresses whose first interaction falls within the measurement period should be counted as "new users."Use data sources that support "entity recognition" (such as Nansen, Arkham, and other address labeling systems). These systems can identify multiple wallets controlled by the same person, further avoiding double counting caused by "one person, multiple addresses." Aggregators themselves are also moving toward "understanding the person behind the trade" — aPriori's order flow recognition system includes a "wallet clustering" feature designed to determine which addresses belong to the same operating entity.
When is this step complete: The "new user" count you have produced is already the unique address count after wallet-level deduplication. If resources permit, you have also performed entity-level merging.
Risk alert: If a project or protocol's "new user" data shows a noticeable decline after removing aggregator double counting, it suggests that growth may rely more on aggregator traffic distribution than on organic user discovery and recognition. Aggregator traffic can be integrated — the Stabull case shows that after aggregator integration, users may not even know which protocol they used.
Step 3: Cross-Validate the Ratio of "Trade Volume" to "User Count"
This is a quick validation method: if "user count" surges significantly but "total trade volume" or "average trade volume per user" does not grow correspondingly, the "new users" may carry low quality weight.
What to do: Calculate the "trade volume / user count" ratio and observe its trend.
How to do it:
Scenario A (healthy growth): New user count rises while "trade volume / user count" remains stable or increases. This indicates new users are genuinely participating in trading, not shadow addresses "brushed" by aggregator routing.
Scenario B (suspicious growth): New user count explodes, but "trade volume / user count" drops significantly. This may mean a large number of new addresses only made very small test trades — such "users" often come from airdrop farming or bot activity.
OKX DEX's Boost product makes a distinction in its design: to "prevent wash trading arbitrage," they assign different volume multipliers to different trading pairs — stablecoin-to-stablecoin trades only get a 0.1x multiplier, while major-to-altcoin trades get 0.5x. This logic shows that protocol teams themselves are also guarding against counting "low-value swaps" as genuine activity.
When is this step complete: You have calculated the ratio of deduplicated new user count to total trade volume, and determined whether the current growth is "quality growth" or "an inflated illusion."
A leading global cryptocurrency platform,suitable for both beginners and experienced traders.
New user benefit: 20% off trading fees upon registration!！
How to Confirm Your Process Was Correct?
After completing the three steps above, answer these three questions:
Has your data source already excluded aggregator sub-trades? (Did you use
dex_aggregator.tradesordex.trades?)Have new addresses been deduplicated by wallet address? Are multiple interactions from the same user counted only once?
Is the ratio between new user count and trade volume reasonable? More new users accompanied by lower average trade volume is a red flag.
If all three questions check out — correct data source, addresses deduplicated, ratio makes sense — then the "new user surge" you are seeing is most likely real. If any link in the chain is broken, the "surge" may just be a data bubble generated by aggregator routing.
