ClearTrace Scorecard · Edition 2 of a recurring series

DEX Aggregator Execution Scorecard
Edition 2 — August 2026

The rated record of DEX aggregator execution quality: quote accuracy, execution slippage, and revert rates — measured the same way for every aggregator on this board, by a third party with no routing product, and frozen so the numbers can't be edited after the fact. The board is not a complete census: venues withheld from ClearTrace's published outputs, and venues we do not yet sample, do not appear on it at all.

Why a rated edition exists

Every aggregator claims best price and high reliability, and those claims are self-reported — published by the routing product being measured. Meanwhile MiCA transposes MiFID-style best-execution duties into crypto: under Regulation (EU) 2023/1114, Article 78 obliges a CASP executing client orders to take all necessary steps to obtain the best result and to evidence it on request, with record-keeping under Article 68. The regime applied from 30 December 2024, and the transitional window that let existing providers keep operating without full authorisation closed, at the latest, on 1 July 2026, so evidencing best execution is already in force. Compliance dashboards (e.g. DefiLlama's MiCA tracker) cover exchange-level obligations — not execution quality at the routing layer, where the trades actually happen.

This scorecard is a neutral, methodology-published, third-party rated record: we operate no router and take no order flow, the method is published, and each edition is numbered, dated and hashed. A rating you can cite in a governance forum, a marketing page, or a best-execution file. The snapshot below is what the hash covers, so the numbers cannot be back-dated or quietly revised; the findings text on this page is not hashed, and corrections to it ship as dated, additive notes whose full history is public in git.

Errata & changes since Edition 1

This scorecard corrects earlier editions in the open, never by silent edit. Edition 1's frozen snapshot and hash are unchanged; the corrections below travel forward with the record.

• Edition 1's first finding is withdrawn. It ranked revert rates across venues that settle differently — pairing Odos and Tokenlon as the two ends of a reliability spread. A revert rate measures reliability only where the failing transaction is the user's own, i.e. on a router. Tokenlon is an RFQ venue whose submitter we had not established, and its 0.04% is not the rate at which its users' swaps fail. The Edition 1 page carries a dated erratum to the same effect; its snapshot and hash are unchanged.
• Revert rates are now tagged by execution model and ranked only within one. Every venue carries an execution model — router, batch auction, intent, or unclassified where we have not established who submits the settlement transaction. Batch-auction (CoW) and intent (1inch Fusion) venues appear in the table with their rate shown but flagged n/c (not comparable), never ranked against a router's.
• Revert methodology moved from v4 to v5+v6. Edition 1's revert figures used the v4 sender filter. This edition uses v5 (a stronger address-rotating-bot filter) and reports the v6 genuine-user rate alongside every headline — the rate among senders who behave like real users, which is the honest number for bot-contaminated cells.
• The RFQ-at-$1M column and its finding are withdrawn. Edition 1 reported a per-venue "RFQ @ $1M" share and a finding that RFQ routing at size doesn't guarantee a tighter quote. That share was a detection artifact: our sampler only parsed the RFQ flag from KyberSwap's quote format, so KyberSwap read ~86% while every other sampled venue, including venues we know route heavily through RFQ desks, read exactly 0.0%. A metric where most venues are exactly zero is unmeasured, not zero, so it is removed rather than ranked. The internal RFQ flag is still used for sim-coverage bookkeeping; it is no longer published or compared.

Edition 2 findings

• Most of what a headline revert rate counts is not the user's own failed swap. Every headline here splits into two terms: transactions from senders our v6 classifier counts as genuine users (personal revert below 10%), and everything else it did not classify as a bot. The second term is the larger part of the difference between venues: across the 7 pooled routers it accounts for more than half the headline gap in 18 of 21 venue pairs. So the 4.5× headline gap between OpenOcean (5.87%) and Bitget DEX (1.31%) is substantially a difference in traffic mix; on the user-only rate the same two are 0.76% and 0.47%, a 1.6× gap. What this does not show: the residual bucket is bounded by the classifier's own thresholds, so its pooled rate (18.6%–27.1% here) sits inside a corridor we set, and should not be read as a measured constant. Only the share of traffic in it (3.2%–19.4%) varies freely. Every reliability finding below is stated on the user-only rate.
• Genuine-user revert rates span 0.71 percentage points; headline rates span 4.56. Genuine-user revert rates (v6) across the 6 routers where the rate is comparable and uncontaminated run from 0.29% (SushiSwap) to 1.00% (KyberSwap). 4 of the 6 route measurably more reliably for genuine users than the direct-Uniswap default (1.05%). OpenOcean and KyberSwap are lower but within measurement error (two-proportion z, p > 0.05), so they should be read as no worse rather than better. The baseline itself, and the 3 routers with no genuine-user rate this edition (OKX, Odos, LI.FI), are outside this pool.
• Reverts are not comparable across execution models. A revert rate is a reliability signal only where the failing transaction is the user's own — on a router, where the user submits the swap. On a batch auction (CoW Protocol) or an intent venue (1inch Fusion), a solver or resolver submits, so an order that cannot be filled never becomes a transaction and the on-chain revert rate is structurally near zero however reliably the venue fills. The table tags every venue with its model; the reliability findings above rank routers only, and non-router rates are shown flagged n/c, never ranked.
• Most aggregators do not beat the venue default. Against the direct-Uniswap execution baseline (8.82 bps median), 3 of the 8 venues we measure on-chain deliver cheaper realized execution: Bitget DEX (2.24 bps), Bebop (6.66 bps), 1inch (6.9 bps). The other 5 route worse than the default they are competing with. 6 venues carry no on-chain execution data this edition (Odos, OpenOcean, SushiSwap, LI.FI, 1inch Limit Order Protocol, DODO X) and are unmeasured here. Unlike revert rate, realized execution cost is a per-fill outcome the trader gets whoever submits the transaction, so it is compared across every settlement model; the model is shown for each venue so a reader can scope it further.

Provenance: Bitget DEX, OpenOcean, SushiSwap, DODO X and Bebop are named above, and we have not ingested their own published deployment addresses. Their figures rest on our labelling of which contracts belong to them, and should be read as provisional.

The rated table

Rated = ≥30 realized fork-simulation quote samples spanning ≥7 days. On-chain metrics (slippage, reverts) cover every trade/transaction we attribute to the venue in the window, not a sampled subset of them — but attribution is entrypoint-framed, so the denominator is the flow entering through contracts we can tie to the venue, not the venue's total volume. Baseline = the direct-venue default aggregators are implicitly compared against. Revert rate shows the headline with the v6 genuine-user rate in parentheses; n/c marks a venue whose settlement model (batch auction, intent, or unclassified where we have not established who submits the settlement transaction) makes its on-chain revert rate not comparable to a router's. A venue marked wound down has shut down: its numbers are frozen history for the window measured, not a live venue. A venue marked unestablished is one whose own published deployment addresses we have not ingested: its numbers rest on our labelling rather than on the venue's list, and should be read as provisional. An execution-cost cell marked all-chain means the venue has no row on this chain, so the figure is its median across every chain we measure, shown as context and excluded from every finding. A dash (—) means we hold no measurement for that cell this edition, whether the venue had no qualifying traffic, fell below the query's reporting floor, or is not yet quote-sampled; it never means zero. Router counts differ between findings because each states its own pool: the residual decomposition includes the venue default, the genuine-user comparison does not.

Verify this edition

The findings above are computed from a frozen snapshot. To verify nothing has changed since publication, hash the snapshot and compare:

The snapshot is committed to a public git history at publication time, which independently timestamps it.

Methodology & scope

Full methodology: cleartracedata.com/methodology and the open-dataset README. In brief: execution slippage is the median per-fill gap vs a 1-minute VWAP oracle over all on-chain trades; revert rate counts failed routing transactions from raw on-chain data; quote accuracy is a forward-captured fork-simulation sample (quoted vs realized). Aggregators we don't yet quote-sample appear with on-chain metrics only. Preliminary cells are shown but never rated. Quote-sample windows differ by venue (each venue is rated once it has enough samples of its own), so the quote column is not a single shared window the way the on-chain columns are. Scope: Ethereum for this edition; the live leaderboard is the free preview layer that accrues between editions.

Cite or commission

Cite this edition as: ClearTrace DEX Aggregator Execution Scorecard, Edition 2 (August 2026), sha256:79069bbe93d8… — link https://cleartracedata.com/scorecard/edition-2. For a private cut of your own routing versus peers (per-pair, per-size, with the failure modes), or a subscription to future rated editions for a best-execution evidence file, book a working session.

ClearTrace is an independent measurement firm: we operate no router, no frontend, and take no order flow. Editions are immutable once published; corrections, if ever needed, ship as an errata note in the next edition — never as a silent edit. · Home · Live leaderboard · Research