Aggregator routing: which venues actually matter

You shipped swaps with one aggregator behind them, and in the demo it worked every time. At production volume the math changes: even the best aggregators miss more than 1 in 1,000 swaps. At 100,000 swaps a month that is a hundred users staring at a spinner, and most teams never see it, because a missing quote doesn't throw an error. It just doesn't arrive.

What failure actually looks like

"The swap failed" covers four different product experiences, and they are measured separately. Enso Shield quotes every aggregator on the identical swap and re-simulates the answer against live chain state, which separates the failure modes cleanly:

• No quote. The API returns nothing at all. Your user sees a spinner, then an error you wrote. Measured as no-quote rate, and in a single-aggregator setup this number is simply your outage rate: there is nobody to cover the miss.
• Late quote. An answer arrives, after your front-end timeout already gave up. To your user this is identical to no quote; to the vendor it counts as a served request. Measured as median and p95 latency against your budget.
• A quote that lies. The price on the button is not the price on-chain. Measured as overquote rate (how often) and quote-to-fill drift (how much, in bps).
• A revert. The transaction lands and fails anyway. Gas burned, trust burned. Measured as sim-failure rate, which becomes your on-chain revert rate if you don't simulate.

Each of these lands on a different team's dashboard: support tickets, conversion drop-off, "your prices are wrong" tweets, and gas refund requests. As a PM you own all four, which is why picking on a single headline number, usually price, quietly optimizes one failure mode at the expense of three others.

Routes beat vendors

The instinct is to run a bake-off and pick a winner. The measured data says serious integrations stopped doing that: production setups route through several aggregators at once, and grade each vendor as a member of that composition, not as a solo act.

The reason is arithmetic, not fashion. Failures across independent sources multiply. Two sources that each miss 2% of requests, run together, miss only when both do: 0.04%, which clears the 99.9% bar neither could reach alone. Redundancy turns two mediocre availability numbers into one excellent one.

Two sources that each miss 2% together miss 0.04%. Redundancy is the cheapest reliability you will ever buy.The case for multi-aggregator routing

This reframes the selection question. A vendor with a 4% no-quote rate is a poor solo choice but a perfectly good second source, because a partner covers exactly the failures it drops. route99 encodes this as "redundancy fade": once your route has two or more sources, missing quotes stop being a first-order problem and the grading eases accordingly. What redundancy cannot cover is a source that returns bad quotes, which is why the reliability criteria that survive at full weight are the ones about honesty, not availability.

The four decisions that define a good setup

"Which aggregators do we integrate" decomposes into four decisions a PM can actually own. Everything else is derived.

The same four controls drive route99's live re-grading. Change any one and every score, band, and chart recomputes.

The latency budget deserves special attention because it is the decision most teams never make consciously, and because latency is not a number. It is a distribution. A vendor's median tells you the typical quote; the p95 tells you the tail: 95% of quotes arrive faster than this, which means one in twenty arrives slower. Even a source whose p95 sits inside your budget still delivers a few percent of quotes late, and on top of that sits the no-quote share that never arrives at all. Sum those and a single "fast" source can quietly miss several percent of requests.

This is why composition changes the math. With one source, its whole tail has to fit inside your budget. With several, the median is enough, because the fastest source on each request covers the others' slow ones. That single fact changes which vendors are viable for you.

Latency is also not just a UX number. For some products it decides whether a trading opportunity exists at all by the time the quote returns. And it feeds back into reliability: the longer a quote is in flight, the further the market moves under it, so slow quotes are more likely to drift, fail simulation, or revert. Speed is partly a correctness feature.

The trade-offs you are actually making

Optimizing for price is not free. To route by best price you need at least two usable quotes on every request, one to win and one to keep it honest, so the reliability bar doubles: the route must deliver two survivors, not one. Price-optimized setups therefore start from three sources where a balanced setup starts from two.

Simulation matters for two distinct reasons, and it is worth being precise about both. First, it keeps the market honest: every quote is verified against live chain state before anything is sent, so inflated quotes are re-priced instead of trusted. Don't trust, verify, applied to your own vendors. Second, it protects execution: a quote that would fail on-chain is caught in simulation instead of costing your user gas and confidence.

Simulation also has its own asymmetry, and it is the strongest quantitative argument in the dataset. With simulation on, adding a source can never make your route less reliable: a weak source simply contributes fewer usable quotes. With simulation off, it can. You route by best price, the high-revert source keeps winning auctions it shouldn't, and the whole route inherits its revert rate on every swap it wins. One bad source taxes every trade.

More sources also improve price, with a correct simulation setup: more independent quotes per request means a better best quote to route on. But the marginal source is not free. Every added source is another quote to fetch and simulate on every swap, and simulation has a real infrastructure price. Many aggregators also simply don't quote fast, so a slow source contributes few usable quotes inside your budget while still costing you the calls. In practice the curve flattens quickly: the second and third sources buy most of the reliability and price improvement, and each one after that costs about as much while adding less.

Reading the numbers like an operator

Three reading habits separate a useful evaluation from a marketing comparison.

Know the noise floor. A few hundredths of a basis point of quote-to-fill drift is physics: prices move in the milliseconds between quote and fill, so a little overquoting is normal. Below 0.05 bps, drift is latency, not dishonesty. Past that, it is either malicious (quotes padded to win the comparison) or incompetent (routing that cannot deliver what it promised), and both are dangerous to sit downstream of. Past about 0.4 bps it is a real cost you are paying on every affected trade, and it belongs in your effective fee math.

Price the API like a COGS line, and count all the layers. An aggregator's true cost stacks: explicit per-swap fees in bps, subscriptions that amortize against your volume, and the overquote cost you silently pay on every inflated fill if you don't simulate. All of that comes on top of the opportunity cost that never appears on an invoice: routing that misses better pools or shies away from complex routes delivers worse realized prices on every trade. Published tiers are the floor of truth; "negotiated" enterprise rates can reach 0 bps but are contingent on a deal, so treat them as an option you might exercise, not a number you have. And undisclosed pricing is undisclosed. Never model it as zero.

Watch the tail, not the average. Median latency sells the demo; p95 decides how many users hit your timeout. The gap between the two is the number that predicts support volume.

What redundancy can't fix

The independence assumption is honest about its edges. Redundancy multiplies away failures that hit sources independently. It does nothing for failures that hit every source at once: honeypot tokens, transfer-tax tokens, routes with no real liquidity. Those set a floor no composition clears.

Reaching a true sub-0.1% failure rate in production is therefore two jobs, and only one of them is aggregator selection: enough fast, honest, independent quote sources, plus pre-trade filtering that refuses intrinsically unexecutable routes before they reach the router. Budget for both.

There is a second under-measured axis, and it deserves naming: some aggregators simply route better. Smarter pathfinding, integrations with more liquidity pools, and the discipline to avoid toxic or manipulable pools all show up as better realized prices, and none of them are directly observable in this dataset. Quote-to-fill drift catches part of it, because bad routing eventually shows up as fills that undershoot, but depth of pool coverage and toxic-pool avoidance have no public registry to measure against. Until they do, treat routing quality as the qualitative interview layer on top of the quantitative screen: ask vendors which pools they integrate, how they score pool safety, and what they exclude on purpose.

The playbook

Runnable in an afternoon, most of it inside route99:

1. Write down your real front-end timeout and your real monthly volume. These two numbers change every ranking.
2. Pick the goal that matches your top complaint driver: balanced, price, revert rate, or latency.
3. Turn simulation on, and make simulate-before-send an engineering requirement, not a preference.
4. Let auto-pick assemble the route: it walks the ranked list, adding sources until the composition clears 99.9%.
5. Check the reliability funnel: see where each source drains (no quote, late, failed simulation) and confirm the combined line clears the target with a margin.
6. Check quote integrity: any source in the costly drift band is charging you a hidden fee; decide if its coverage earns it.
7. Re-run the exercise when your volume, chains, or timeout change. The answer is a function of your setup, so it changes when your setup does.

Method & independence

Every measured figure comes from Enso Shield's 7-day benchmark window (retrieved 18 July 2026): every aggregator quoted on the identical swap, every quote re-simulated against live chain state. Coverage and pricing come from provider documentation, linked per row. DFC Research changes none of the numbers; we re-grade and re-plot them for your setup, under six published rules you can use to reconstruct any figure by hand.

One disclosure, made prominently because it matters: route99 is built by DFC Research, and some measured teams are DeFi Founders Club members. That is exactly why no number is ours, the same rules apply to every aggregator, and every figure links to its source.