Cross-Frontend Attribution Engine

Technical Methodology for Forensic-Level DEX Trade Attribution

The Problem: When users swap tokens on decentralized exchanges, the actual frontend they used (MetaMask, 1inch Wallet, Uniswap Web, etc.) is often hidden or misattributed. Protocols lose visibility into which interfaces drive their volume, and users can't verify execution quality claims.

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 corroborate 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: Corroborating evidence that a frontend or wallet tagged a trade. It does not name one on its own.

Modular frontends and wallet-native swap extensions often 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 leaves the call no longer a whole number of ABI words, and that is what we test for.

Implementation:

  1. A well-formed call is a 4-byte selector followed by some number of 32-byte words, so the test is arithmetic on the calldata length alone: len > 8 and (len - 8) % 64 != 0 over the hex payload.
  2. The suffix bytes are never read. No fingerprint is extracted, compared, or clustered across transactions, and nothing is grouped by suffix value.
  3. A match raises confidence to high only where the originating contract's own label already names a wallet or a frontend. On its own (an unlabeled originator, or an aggregator router whose suffix may belong to a third-party UI layered on top) the transaction returns unattributed at low confidence, flagged as fingerprinted.

What this vector cannot do: it cannot name a frontend the label layer could not already name, so it discovers no new interface by itself. At the aggregate (Dune) grain the test is applied per trace, so any internal call in a transaction carrying a remainder tags the whole trade: suffix volume is a large overlay that re-counts dollars already counted in the conserved buckets, is deliberately excluded from total_volume_usd, and cannot discriminate between frontends at that grain. 

# app/attribution_kernel.py :: has_calldata_suffix
# n = length of the calldata as hex characters, prefix stripped.
# 8 chars = the 4-byte selector; 64 chars = one 32-byte ABI word.
return n > 8 and (n - 8) % 64 != 0

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:

  1. Perform a LEFT JOIN between dex.trades and ethereum.traces on tx_hash
  2. Look for instances where tx_to != project_contract_address AND tx_to is NOT a known aggregator
  3. Aggregate these unknown intermediate tx_to addresses 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:

  1. Create a window function pipeline over dex.trades grouped by tx_from (the EOA)
  2. Order by block_time
  3. Use LAG() and LEAD() 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:

  1. Look up sub-traces inside ethereum.traces or transfer events within the same tx_hash as the swap
  2. Isolate secondary Transfer events or native asset transfers (value > 0) that route small percentages of trade volume to an independent EOA or multisig
  3. 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

Execution Quality Metrics

Once trades are attributed to their true frontend, we compute:

A second, separate measurement: quoted-vs-realized

Everything above is measured from settled on-chain trades. ClearTrace runs a second measurement alongside it, on a different lineage, and the two are never read against each other. In trading this second comparison is implementation shortfall, quoted price against achieved price, serving a best-execution obligation; the source calls its own instance quoted-vs-realized. The quote sampler asks an aggregator for a real quote, then replays that aggregator's own swap calldata in a fork simulation and reads the output the route produces. The shortfall against the quote is split into the fee the venue took and an unexplained residual, with gas reported as its own line rather than folded into the shortfall.

Why the two must not be compared. The on-chain slippage above is measured against a minute-level off-chain reference price and contains whatever MEV was extracted from the real trade. A fork contains no adversary, so the sampler's residual is MEV-free by construction. They are different quantities. The same rule applies to reliability: the sampler's "fails to realize" signal is not the on-chain revert rate above.

Two limits on the sampler side, stated here so neither page flatters it. The fork is not the market: the taker is a token-rich holder rather than a user, its ETH balance is overridden, an approval is bundled ahead of the swap, and off-chain RFQ routes cannot be simulated at all. And the split into fee and residual is unavailable on 35.8% of rows carrying a measured gap, where the fee could not be observed; those rows still carry the total shortfall. Full detail, including what is oracle-priced and what is not, on the research page below.

A third limit, and it is structural rather than a coverage gap. A quoted-vs-realized shortfall cannot see a fee taken from the sell token before routing. That fee is inside both the quote and the fill, so it cancels, and the venue reads as quoting almost exactly what it delivers. This is not hypothetical: LI.FI quotes within a fraction of a basis point of what it fills and takes a flat 25 bps under its default integrator, disclosed in its own quote response. The leaderboard therefore publishes each venue’s disclosed fee in its own column beside the quote gap. The two are deliberately not added together: a fee skimmed from the output token already shows up inside the gap, so one combined figure would double-count those venues. A dash in that column means the venue disclosed no fee, which is not the same as charging none.

Full formulas, thresholds and corrections: How the execution-quality numbers actually work.

Why This Matters

For Protocols: Understand which frontends drive your volume and which provide the best user experience.

For Users: Check an aggregator's execution claims against its own on-chain fills, per chain and per trade size.

For Researchers: Access forensic-level attribution data that no other analytics platform provides.

Limitations & Future Work

Citations & Further Reading

Last Updated: September 2026 (quoted-vs-realized documented as a separate lineage; revert-rate methodology v6)
Contact: For research partnerships or methodology questions, visit cleartracedata.com