Cross-Frontend Attribution Engine
Technical Methodology for Forensic-Level DEX Trade Attribution
ClearTrace solves this with a Cross-Frontend Attribution Engine that uses four advanced
on-chain forensics vectors to identify hidden frontends, institutional routing, and wallet-native swap
extensions. This methodology is built on Dune Analytics SQL queries analyzing the
dex.trades and ethereum.traces tables.
The Four Attribution Vectors
What are the four attribution vectors used by ClearTrace? ClearTrace utilizes four on-chain forensics vectors to identify hidden DEX trades: 1) Calldata Suffix Trapping to catch wallet extensions, 2) Proxy-Router Hunting for institutional flow, 3) Multi-Hop Origin Tracing for user churn, and 4) Fee-Recipient Attribution to unmask anonymous frontends.
1. Calldata Suffix Trapping
What it catches: Hidden mobile apps, wallet extensions, and private portfolio interfaces
Many modular frontends and wallet-native swap extensions (Phantom, MetaMask Swap, private portfolio
apps) append a static hex suffix to the end of the execution calldata (tx.data).
Because this suffix sits outside the standard ABI function parameters, contract decoders ignore
it—but it remains fully visible in raw trace data.
Implementation Strategy:
- Inspect the raw
datafield of transactions interacting with main routers (Uniswap UniversalRouter, 1inch Router, etc.) - Filter for rows where
length(data)exceeds the standard expected bytecode length for that function signature - Use regex string parsing on the last 4-8 bytes of the binary payload to isolate repeating hex fingerprints
- Group these unknown hex footprints by
tx_fromand volume
The Alpha: You quickly find clusters of millions of dollars in volume originating from specific unidentified mobile apps or private interfaces that you can now uniquely attribute.
SELECT
RIGHT(tx.data, 16) AS calldata_suffix,
COUNT(DISTINCT tx.tx_hash) AS tx_count,
SUM(tx.amount_usd) AS total_volume_usd
FROM dex.trades tx
WHERE LENGTH(tx.data) > expected_length
GROUP BY 1
HAVING SUM(tx.amount_usd) > 1000000
ORDER BY total_volume_usd DESC;
2. Proxy-Router Hunting (tx_to vs project_contract_address Mismatch)
What it catches: Custom enterprise frontends and institutional smart wallets
When a user swaps on a standard interface, tx_to is often the public router. But hidden
frontends or institutional desks frequently route transactions through their own proprietary,
un-decoded proxy contracts before hitting the actual DEX pool. In dex.trades,
the project_contract_address will show up as the Uniswap Pool, but the intermediate
layer is masked.
Implementation Strategy:
- Perform a LEFT JOIN between
dex.tradesandethereum.tracesontx_hash - Look for instances where
tx_to != project_contract_addressANDtx_tois NOT a known aggregator - Aggregate these unknown intermediate
tx_toaddresses by volume and chain
SELECT
t.blockchain,
t.tx_to AS hidden_proxy_contract,
COUNT(DISTINCT t.tx_hash) AS tx_count,
SUM(t.amount_usd) AS total_masked_volume
FROM dex.trades t
LEFT JOIN dex_aggregator.trades a
ON t.tx_hash = a.tx_hash AND t.blockchain = a.blockchain
WHERE a.tx_hash IS NULL -- Exclude known aggregators
AND t.tx_to != t.project_contract_address
GROUP BY 1, 2
HAVING SUM(t.amount_usd) > 100000
ORDER BY total_masked_volume DESC;
Result: This isolates the exact contract addresses of custom enterprise frontends and institutional smart wallets actively bypassing public tracking.
3. Multi-Hop Origin Trace (Behavioral Sequence Analysis)
What it catches: Interface churn patterns and user loyalty metrics
To prove to a protocol that their users are switching to other interfaces, you need to track sequential transaction habits. If a wallet swaps on Uniswap, where did they interact 5 minutes before? This reveals absolute churn vectors.
Implementation Strategy:
- Create a window function pipeline over
dex.tradesgrouped bytx_from(the EOA) - Order by
block_time - Use
LAG()andLEAD()to map immediate interface hops
WITH ordered_swaps AS (
SELECT
tx_from,
block_time,
project AS current_frontend,
amount_usd,
LAG(project, 1) OVER (PARTITION BY tx_from ORDER BY block_time) AS previous_frontend,
LAG(block_time, 1) OVER (PARTITION BY tx_from ORDER BY block_time) AS previous_swap_time
FROM dex.trades
WHERE block_time >= NOW() - INTERVAL '30' DAY
)
SELECT
current_frontend,
previous_frontend,
COUNT(*) AS transition_count,
AVG(DATE_DIFF('minute', previous_swap_time, block_time)) AS avg_time_between_hops
FROM ordered_swaps
WHERE previous_frontend IS NOT NULL
AND current_frontend != previous_frontend
GROUP BY 1, 2
ORDER BY transition_count DESC;
Insight: This lets you tell CowSwap: "When users leave your interface, 68% of them execute a trade on Uniswap within 14 minutes."
4. Fee-Recipient Attribution
What it catches: Anonymous frontends monetizing through hidden fees
Many "hidden" frontends monetize by baking a 10-50 basis point fee directly into swap parameters, routing that cut to a custom multisig wallet during transaction execution. Even if the interface is completely anonymous, the Fee-Recipient Address is a permanent, static, on-chain identifier.
Implementation Strategy:
- Look up sub-traces inside
ethereum.tracesor transfer events within the sametx_hashas the swap - Isolate secondary Transfer events or native asset transfers (
value > 0) that route small percentages of trade volume to an independent EOA or multisig - Cluster these fee-collection wallets
Result: Attribute volume to anonymous interfaces by their fee collection patterns, even when all other identifiers are masked.
Data Sources
- Dune Analytics:
dex.trades,dex_aggregator.trades,ethereum.traces— batch attribution queries and historical analysis - Alchemy: Multi-chain RPC infrastructure powering real-time contract resolution,
token balance lookups (
alchemy_getTokenBalances), and asset transfer tracing (alchemy_getAssetTransfers) across all supported chains - DefiLlama: Protocol TVL, stablecoin market caps, yield data, and protocol financials
- Chains Supported: Ethereum, Base, Arbitrum, Optimism (all via Alchemy multi-chain RPC)
- Update Frequency: Batch pipeline via the Dune API (not a real-time feed); the live dashboard shows the last-sync date
- Historical Depth: 30-90 days rolling window
Execution Quality Metrics
Once trades are attributed to their true frontend, we compute:
- VWAP Slippage: Difference between the expected price (1-minute volume-weighted average) and the actual execution price, in basis points
- Slippage Score (0-100): Derived from median slippage as
100 - slippage_bps(clipped); higher = lower slippage. A slippage-only metric — MEV and revert rates are reported separately, not folded in - Sandwich / MEV Exposure: Sandwich attacks detected in block ordering, reported as attack counts and total value sandwiched (a separate metric, not a per-aggregator scored rate)
- Revert Rate: Percentage of routing transactions that fail on-chain — a distinct,
per-aggregator metric. Computed after a sender-level bot filter (methodology v5,
effective 2026-07-05) that excludes competing solver/keeper bots: senders that never landed a
successful transaction in the window, senders reverting ≥50% of 5+ transactions, and senders with
100+ reverts at a ≥10% personal revert rate. Their failed fill races (limit-order and Dutch-auction
fills, solver settlement) are not user execution failures; a sender-concentration audit showed they
inflated headline rates up to 20× over what genuine users experience. Figures published before
2026-07-05 used the looser v4 filter and overstate rates for solver-heavy routers. Alongside the
headline, each cell also reports a user-only revert rate (methodology v6,
effective 2026-07-07): the same computation restricted to senders whose personal revert rate is
under 10% — the measured experience of genuine users, published as
user_revert_rate_pctin the open dataset
Why This Matters
For Protocols: Understand which frontends drive your volume and which provide the best user experience.
For Users: Verify execution quality claims with hard on-chain data instead of trusting marketing.
For Researchers: Access forensic-level attribution data that no other analytics platform provides.
Limitations & Future Work
- Known revert-rate residual (Odos on Ethereum): One cell remains contaminated
after the v5 bot filter — Odos's Ethereum router attracts spam that rotates addresses (1-2
transactions each, occasional wins), which no per-sender rule can separate from a genuine user
retry. Its headline rate overstates what users experience — the 2026-07-05 diagnostic measured a
~17% headline against ~0.2% among senders classified as genuine; the live user-only rate described
below is the current number. We publish the honest headline number and flag the contamination rather than
hand-editing it. Since methodology v6 (2026-07-07) the revert query also publishes each cell's
user-only revert rate (
user_revert_rate_pctin revert_rates.csv andonchain_user_revert_rate_pctin leaderboard.json) — reverts measured over only the senders whose personal revert rate is under 10%, the same "genuine user" bucket the diagnostic uses — so residual cells show the measured user rate alongside the flagged headline - Chain Coverage: Currently Ethereum-focused; expanding to L2s and Solana
- Calldata Suffix Whitelist: Building a database of known multi-call patterns to reduce false positives
- Refresh Latency: Currently a periodic batch refresh; working toward more frequent updates
- Flashbots Integration: Planning to integrate Flashbots Protect API for authoritative MEV data
Citations & Further Reading
Last Updated: July 2026 (revert-rate methodology v6)
Contact: For research partnerships or methodology questions, visit cleartracedata.com