You are a product manager shipping a swap feature. Somewhere below your button sits a DEX aggregator API, and here is the number nobody puts in the sales deck: even the best of them miss more than 1 in 1,000 swaps. This is a guide to choosing swap APIs the way serious teams do, as a composition of several vendors rather than a single bet, using data from route99, an independent benchmark of 15 aggregators built by DFC Research.
Contents
The problem your uptime dashboard will not show you
Vendor status pages report whether the API answered. Your user cares whether the swap happened at the price on the button. Those are different questions, and the gap between them is where swap products quietly bleed trust.
route99 measures that gap. Every one of the 15 aggregators is asked for a quote on the identical swap, and every answer is re-simulated against live chain state by Enso Shield, an independent data provider. DFC Research never alters a measured value. It re-grades the raw numbers for your specific setup under six published rules, so anyone can reconstruct any figure by hand. The 7-day window behind this article was retrieved on 18 July 2026.
The headline finding is blunt. No single aggregator, not one, delivers the 99.9% reliability a production swap flow should target. The best still miss more than 1 swap in 1,000. That is not a reason to panic. It is a reason to stop evaluating vendors as solo integrations and start evaluating them as members of a team. That reframe changes almost every downstream decision, which is why route99 grades each vendor as part of a multi-aggregator composition, not on its own.
Four ways a swap API fails your user
Before the framework, name the failure modes in product terms. There are exactly four.
- No quote. The API returns nothing. In a single-aggregator setup, this is simply your outage rate. Your user taps the button and gets a spinner.
- Late quote. The answer arrives after your front-end timeout. To the user this is identical to no quote. To the vendor it counts as a served request, which is why it never shows up in their numbers.
- A quote that lies. The price on the button is not the price on-chain. route99 measures this two ways: overquote rate, how often the fill comes in worse than quoted, and quote-to-fill drift, how much worse, in bps. A basis point, bps, is one hundredth of a percent.
- Revert. The transaction lands on-chain and fails anyway. Gas is burned, nothing is swapped. route99 measures this as sim-failure rate: the share of quotes that fail when dry-run against live chain state. If you do not simulate, this number becomes your on-chain revert rate, paid in your users' gas.
The benchmark organizes its six measured criteria around these modes, in three pairs: reliability (no-quote rate and sim-failure rate), price (all-in cost and overquote), and latency (median and p95). Coverage and API pricing come from provider documentation, linked on every row. Note that some entries are meta-aggregators: they route across other aggregators rather than holding direct DEX liquidity, which matters when you think about independence later.
Stop asking which aggregator is best
The instinctive procurement question is a ranking question. Which vendor tops the table? Integrate that one, move on. The data says this question is malformed, and latency shows why most clearly.
Latency is a distribution, not a number. The median tells you the typical quote. The p95 tells you the time 95% of quotes beat, meaning one request in twenty is slower than that. Even a source whose p95 fits comfortably inside your front-end budget still delivers a few percent of quotes late. Add the no-quote share that never arrives at all, and a single "fast" source quietly misses several percent of requests. One in twenty is not a tail event at product scale. It is every twentieth user.
Latency is also not just a UX concern. Sometimes it decides whether the trading opportunity still exists at all. And slow quotes are stale quotes: they drift more, fail simulation more, and revert more. Speed is partly a correctness feature.
With one source, its entire latency tail has to fit your budget. With several, the median is what matters, because on each request the fastest source covers for the rest. The same logic applies to outages, to overquoting, to everything. So the right question is not "which aggregator is best." It is "which combination of aggregators, under my latency budget and my traffic, clears 99.9%." That is a question about composition, and composition has arithmetic.
The redundancy math, worked by hand
Failures across independent sources multiply. Two sources that each miss 2% of requests together miss 2% of 2%: 0.04%. That single multiplication is the entire economic case for multi-aggregator routing. Two individually mediocre sources compose into a route ten times better than the 0.1% target, provided their failures are independent.
route99 formalizes this as the probability of getting at least k usable quotes per request, computed with a Poisson-binomial distribution, which is just the multiplication above generalized to sources with different miss rates. The k matters. If you are optimizing for price, k is 2, because you need a second quote in hand to keep the winning quote honest. Otherwise k is 1: any usable quote serves the user. Accordingly, price-optimized routes start from three sources in the benchmark, balanced routes from two.
Two consequences of the math are worth internalizing:
- Redundancy fade. Once a route has two or more sources, route99 halves the weight of no-quote rate in each vendor's grade, because a partner covers the misses. A vendor that looks weak alone can be a fine second source.
- The green band moves. The per-source failure rate that still lets an N-source route hit 99.9% is 0.001 to the power 1/N, capped at 10%, because beyond roughly 10% correlated failures start to dominate and the independence assumption stops paying out.
Diminishing returns arrive fast. Sources two and three buy most of the benefit; the curve flattens after that, while every marginal source keeps adding quoting and simulation cost per swap. Many aggregators also simply do not quote fast, so a fourth or fifth source contributes few usable quotes inside a real latency budget. Two to three well-chosen sources is usually the efficient frontier.
Simulation is not optional
Simulation means dry-running a quoted transaction against live chain state before sending it. It has two jobs. First, honesty: every quote is verified before it is trusted, so an inflated quote gets re-priced instead of filled. Don't trust, verify, applied to your own vendors. Second, execution safety: a quote that would revert on-chain is caught in software instead of costing the user gas and confidence.
The strongest quantitative argument in the whole dataset is an asymmetry between the two regimes.
With simulation on, adding a source can never make your route less reliable. With it off, one bad source taxes every swap it wins.route99 methodology, DFC Research
The mechanics: with simulation on, a weak source just contributes fewer usable quotes, and the probability of getting at least k usable quotes only goes up as sources are added. It is monotone. With simulation off, you route by best price, and a source with a high revert rate keeps winning auctions precisely because its optimistic quotes look cheapest. Your route inherits the average revert rate of the whole set. The same integration decision, adding a source, is risk-free in one regime and a per-swap tax in the other.
A little drift is normal physics: prices move in the milliseconds between quote and fill. Below 0.05 bps, treat it as latency, not dishonesty. Past that it is either malicious, quotes padded to win comparisons, or incompetent, routing that cannot deliver what it promised. Both are dangerous. Past roughly 0.4 bps it is a real per-trade cost that belongs in your fee math.
What the setup actually costs
Cost stacks in layers, and only the first layer appears on an invoice.
- Explicit fees. Per-swap fees in bps, evaluated at your monthly volume. route99 caps fees at 60 bps inside its scoring curve.
- Subscriptions. Fixed plans that amortize against volume. Cheap at scale, punishing at low volume.
- Overquote cost. The silent layer: money paid on inflated fills if you do not simulate.
- Opportunity cost. Routing that misses better pools or avoids complex routes delivers worse realized prices. This never invoices you at all.
On pricing, treat published tiers as the floor of truth. "Negotiated" enterprise rates can reach 0 bps, but they are contingent on a deal, and route99 flags them with a "!" rather than assuming you will get one. Undisclosed pricing is never modeled as zero. If a vendor will not publish a number, the benchmark refuses to pretend the number is favorable, and so should your procurement process.
Against these costs, more sources do improve price, given a correct simulation setup: more independent quotes means a better best quote, and k=2 keeps the winner honest. But the marginal source is not free. This is the same efficient-frontier logic as reliability: two to three sources, chosen well, capture most of the price benefit before per-swap costs eat the remainder.
Where the model stops working
Two honest limits, because a framework you cannot break is a framework you cannot trust.
Correlated failures. The multiplication in the redundancy math assumes independent failures. Honeypot tokens, transfer-tax tokens, and genuinely illiquid routes miss every source at once, and no amount of redundancy clears that floor. Getting below 0.1% in production is therefore two jobs, not one: enough fast, honest, independent sources, plus pre-trade filtering that keeps intrinsically unexecutable routes out of the funnel in the first place.
Routing quality. Some aggregators simply route better: smarter pathfinding, more liquidity pool integrations, deliberate avoidance of toxic or manipulable pools. This axis is real and under-measured. It is not directly observable in the dataset, though drift catches part of it, since routing that overpromises shows up as quote-to-fill slippage. Treat it as the qualitative interview layer of your evaluation. Ask vendors which pools they integrate, how they score pool safety, and what they exclude on purpose. A vendor with a crisp answer to "what do you refuse to route through" is telling you something no benchmark can.
The four-decision playbook
Everything above compresses into four controls, and route99 exposes exactly these four. Set them and every score and chart re-grades live for your setup.
| Decision | The question in product terms | Sensible default |
|---|---|---|
| Goal profile | What does my product punish hardest: bad prices, failed swaps, or slow quotes? | Balanced (equal weights, k=1, starts at 2 sources) unless you have a reason. Price-focused flows use Optimize for price (cost x3, overquote x2, k=2, starts at 3 sources); wallets sensitive to failed transactions use Low revert rate (sim-failure x3); trading UIs use Low latency (median x3, p95 x2). |
| Latency budget | How long will my front end wait before giving up on a quote? | Match your real front-end timeout. The Low latency profile assumes 400 ms. |
| Simulation | Do I verify quotes against live chain state before sending? | On. Every profile defaults to it, and the asymmetry above is the reason. |
| Volume and pricing lens | What do fees cost at my monthly volume, and do I trust published tiers or a negotiated deal? | Enter real volume; start with the published lens. Switch to negotiated only for rates you actually hold. |
The four controls in route99. Profiles change criteria weights, the required quote count k, and the starting source count; auto-pick then walks the ranked list, adding sources until the composed route clears 99.9%.
From there, the tool does the composition work. Auto-pick assembles the route. A reliability funnel chart shows where each source drains, to no quote, to late arrival, to failed simulation, and what the combined route survives. A quote-integrity chart plots overquote frequency against fill drift, which is where you separate normal physics from padded quotes.
route99 is built by DFC Research, and some of the measured teams are DFC members. That is exactly why no number in it is ours: every measurement comes unchanged from Enso Shield, the same six published rules apply to every aggregator, and every figure links to its source so you can check the work.
The playbook, then. Accept that no single vendor clears 99.9%. Pick two to three sources whose failures are independent, watching for meta-aggregators that share upstreams. Turn simulation on and leave it on. Fit medians, not tails, to your latency budget. Price the whole stack, including the overquote layer, at your real volume. Filter unexecutable routes before they hit the funnel. Then interview for routing quality, because the best number in the dataset still cannot tell you what a vendor refuses to route through.
Try it on your own setup
Every figure in this article re-grades live at route99.xyz. Set your goal profile, latency budget, simulation toggle, and monthly volume, and the scores, funnel, and auto-picked route recompute for your product. The six grading rules, worked examples, and the Enso Shield measurement pipeline are documented at route99.xyz/methodology, in enough detail to reconstruct any number by hand. Data: 7-day window, retrieved 18 July 2026.
The DFC Research index
The rule book behind route99, event notes, and the crypto neobanking stack, in progress for H2 2026.