Aggregator Revert Rates
Public API: Returns per-aggregator transaction revert rates.
The revert rate is the share of an aggregator's routing transactions that fail on-chain — a distinct reliability metric, reported per chain (there is no cross-chain rollup). A high rate signals routes that frequently don't clear at the expected outcome.
Rates are computed after a sender-level bot filter (methodology v5, effective 2026-07-05) that excludes competing solver/keeper bots — senders with zero successful txs in the window, senders reverting >=50% of 5+ txs, and senders with 100+ reverts at a >=10% personal rate — so the figure is not dominated by solver fill races. Data served before 2026-07-05 used the looser v4 filter and read higher for solver-heavy routers. Known residual: the Odos/Ethereum cell remains inflated by address-rotating spam that no per-sender rule can separate.
Since methodology v6 (2026-07-07) each row also carries a user-only revert rate (user_revert_rate_pct, with user_reverted_txs / user_txs): the same computation restricted to senders whose personal revert rate is under 10%, i.e. whose own transactions succeeded at least 90% of the time over the window. That is a threshold on the outcome being measured, not a classification of who the sender is: bounded under 10% by construction, so read it as the failure rate among consistently-succeeding senders, not as the share of all attempts that fail. It is the number to read for residual cells like Odos/Ethereum, subject to that caveat.
Do not rank across execution models
Each row carries an execution_model and a revert_comparable flag. A revert rate measures reliability only where the failing transaction is the user's own — that is, on a router venue, where the user signs and submits the swap.
On a batch_auction venue (CoW Protocol) the user signs an order and a solver settles a batch; on an intent venue (1inch Fusion, which settles through the Limit Order Protocol) a resolver submits. An order that cannot be filled never becomes a transaction at all. Their on-chain revert rate is therefore structurally near zero no matter how reliably they fill — it reflects solver/resolver settlement, not user experience.
Sorting every row by revert_rate_pct puts CoW and Fusion at the top of the table, and that ordering says nothing about reliability. Filter to one execution model before comparing — ?revert_comparable=true returns only the rows that may legitimately be ranked against each other.
Request
- Base URL: https://cleartracedata.com (the document declares no server; this is the origin it was published from)
- URL: https://cleartracedata.com/api/v1/revert-rates
- Auth: none declared
Query parameters
Filter by blockchain (ethereum, base, arbitrum, optimism).
Filter by aggregator/project name.
Set true to return only venues whose revert rate may legitimately be ranked against each other — the router venues, where the user submits the swap so a failure is a reverted user transaction. Excludes batch-auction (CoW) and intent (1inch Fusion) venues, whose orders never reach the chain when they fail and whose on-chain revert rate is therefore structurally ~0.
Maximum number of rows to return.
Pagination offset.
Response
Per-aggregator, per-chain transaction revert (failure) rates.
Example response
{
"revert_rates": [
{
"project": "kyberswap",
"chain": "ethereum",
"revert_rate_pct": 2.78,
"reverted_txs": 4034,
"total_routing_txs": 145109,
"user_revert_rate_pct": 0.83,
"user_reverted_txs": 1102,
"user_txs": 132812,
"execution_model": "router",
"revert_comparable": true
}
]
}Changes
No recorded changes to this operation across all 1 revision of this API.