Each aggregator carries six measured figures from Enso Shield's 7-day window (retrieved 18 Jul 2026), collected by quoting every aggregator on the identical swap and re-simulating against live chain state:

• No-quote rate: share of requests that return no quote at all.
• Sim-failure / revert rate: share whose quote fails simulation (or, with Simulate off, reverts on-chain).
• Median and p95 latency: typical and tail response time, in ms.
• Overquote rate and quote→fill drift: how often, and how far, the delivered price undershoots the quote (bps).

Coverage and API pricing come from each provider's own docs, linked in every row. Your setup is the rest: chain, Simulate on/off, latency budget, monthly volume, the Standard/Negotiated pricing lens, and the route you select. Rule: measured facts are never changed, only re-graded for your setup.

The headline % is the chance your route (the set of aggregators you selected) returns at least k usable quotes on a request. An aggregator is usable when it returns a quote, arrives inside your latency budget, when Simulate is on survives simulation, and survives its own overquote drift.

With Simulate on, aggregators are treated as independent and the route's reliability is the exact probability of ≥ k usable quotes across them (a Poisson-binomial sum). k = 2 for “Optimize for price” (you need two quotes to compare); k = 1 otherwise.

The target is 99.9% (0.1% failure). An aggregator's “green” band for redundancy-covered failures is 0.001^(1/N): the per-aggregator rate at which N independent aggregators still clear 99.9%, capped at 10%, beyond which correlated failures dominate.

A consequence worth knowing. With Simulate on, adding an aggregator can never lower route reliability: a weak aggregator simply contributes fewer usable quotes, and the P(≥k) sum is monotone. With Simulate off, it can: the route inherits the average revert rate and average overquote-drift risk of the set, so one high-revert or heavy-overquote aggregator drags the expectation down for every swap it wins on price. The gauge names the offending aggregator when this happens. This asymmetry is the quantitative case for simulation.

Why overquote is now part of usable. A slippage tolerance is normally sized off the quoted output, not the true one. An inflated quote eats into that cushion before any real market movement happens, so the same drift that costs score points also raises the odds the trade reverts instead of executing — this is exactly the mechanism Enso Shield's own quote-decay research describes. It matters more than a same-block check suggests: Shield's benchmark quotes and simulates essentially instantly (same block), but real routes often don't execute that fast — a wallet-confirmation click or a bridge settlement window can run well past the seconds-scale delay where Shield's own data shows overquote gaps continuing to widen. So the measured sim rate is closest to revert risk at zero elapsed time, not at realistic execution time, and oqSurv is this app's stand-in for that gap: it starts from the same oqCost priced in Rule 3, gated gentler under Simulate (a pre-commit check catches most drift before it's acted on) and steeper without it (the quote is committed, cushion and all). Unlike the score weight in Rule 3, this term is not gated by profile: reliability is a physical estimate of what actually happens, not a preference, so it applies the same way under every goal.

The floor, and why this is not the same number as the score's overquote grade. A quote that was never inflated cannot fail because it was inflated, so at most oq% of an aggregator's quotes can be lost this way: oqSurv is floored at 1 - oq/100. That bound is what separates the two uses of oqCost. This one is a probability and has to stay physically plausible; the Rule 3 grade is a preference scale, free to be as steep as it needs to be to rank aggregators apart. For a while both read off one shared number, which sounded tidy but forced one of them to be wrong: a grade steep enough to separate the field implied more quotes failing than were ever overquoted, and a probability gentle enough to be plausible left the grade unable to punish anything. They now share the input and calibrate separately.

Each aggregator is graded on six criteria in three pairs: reliability (no-quote, sim-failure), price (all-in cost, overquote), latency (median, p95). Every criterion yields a points-kept fraction gc in [0,1]; the score is their weighted average, times ten.

The reliability pair grades on a raw scale, then passes through a difficulty curve so perfection stays at 10 but small imperfections still cost real points:

Why 60% and 20/10%, not a round 100%. These zero-points aren't the value that "should" mean total failure — they're calibrated with roughly the same headroom above the worst aggregator Enso Shield currently measures that Cost's own zero-point already carries (38 bps against a 27 bps worst case, about 1.4×). Applied here: the worst measured no-quote rate is ~42% and the worst sim-failure is ~13%, so 60% and 20% give each about that same margin. Earlier this used 10% and 10/5%, tight enough that an aggregator with 95% real-world availability graded as if it barely worked at all — harsher than Cost or Overquote are on their own worst cases. A single extreme outlier (an aggregator failing outright, most of the time) still lands near the bottom; an aggregator that's merely imperfect no longer reads as broken.

The latency pair is graded two ways, because setting a budget changes the question.

No budget: “how fast is it?” Graded on an anchored scale. L is the half-credit point (800 ms typical, 2,200 ms tail). Below L each halving earns a point; above L each extra L/2 costs one.

Budget set: two questions, both graded. A deadline adds a compliance question without removing the speed question, because 400 ms can clear a 400 ms budget and still feel slow. So a budget re-aims the pair instead of replacing half of it:

The tail is never dropped: p95 is what sets σ, so a heavy tail directly lowers the in-time share. In the weights table below, Median and p95 are the primary and secondary latency criteria; with a budget set they read as compliance and speed.

Why two modes. A budget is a deadline, not a ratio. The anchored curve grades ratios of milliseconds and is deliberately gentle, which caps how far apart two aggregators can land: 93 ms and 628 ms are 2.75 doublings apart, so no one-point-per-doubling curve can separate them by more than 2.75 points, whatever the anchor. Against a 400 ms deadline that is the wrong answer, because the first aggregator beats it on 98% of quotes and the second on 7%. Grading compliance by the in-time share puts the steepness exactly at the deadline, where the decision turns, while the speed criterion keeps rewarding genuinely fast aggregators inside it.

Why the no-budget curve is anchored, not zero-based. The difficulty curve assumes perfection is attainable: 0% reverts is, and several aggregators reach it. A 0 ms quote is not. Grading latency from zero crushed the whole field, so the scale anchors at a realistic half-credit point instead, keeping a reachable top end while staying strict about real slowness.

The two price criteria carry their own reciprocal gc (no square-root curve), so cost is never double-penalised. Fees come from the cost model (Rule 4); overquote is costed as expected loss from inflated quotes. Overquote is weighted only under Optimize for price — every other profile carries it at w=0, so an aggregator that overquotes isn't scored down by a goal that isn't price. The criterion is still computed and shown in every breakdown; outside price it just costs zero score points (rendered as “–”, not “0”). The reliability gauge (Rule 2) starts from the same oqCost but calibrates it separately, as a bounded probability rather than a preference scale; that half is also not profile-gated, since reliability estimates what happens rather than what you prefer.

Why overquote's divisor is so much smaller than cost's. The two look like the same kind of number and are not. All-in cost is a realized bps figure. oqCost is an expected one: a frequency multiplied by a magnitude, which collapses toward zero even when both inputs are alarming. Grading an expected cost on a realized-cost scale was a real defect, not a matter of taste: with a divisor of 8 the curve emptied out around 152 bps while the worst overquoter in the measured field produces 2.09 bps, roughly 73× headroom. The consequence was that the criterion Optimize for price advertises as one of its two leading concerns could not move a ranking: the field's worst overquoter (35.7% of quotes inflated, the widest gap measured) gave up half a point out of ten, and seven of thirteen aggregators lost nothing at all. At 0.5 the curve empties near 9.5 bps, about 4.5× headroom over that worst case, in the same territory as all-in cost's own 1.4×.

The active profile sets the weights. The leading pair is emphasised; everything else stays at 1 — except overquote, which is 0 everywhere except Optimize for price:

Overquote only scores under Optimize for price. Elsewhere its weight is 0: the criterion is still computed and its bps cost still shows in every score breakdown, but it keeps zero points from every other goal's ranking. Low revert rate and Low latency already say as much in their own descriptions above (simulation re-prices overquotes; overquoters are allowed); this is that same intent enforced in the weights, not just the copy.

The scales are absolute, not relative to the field. Every cap, divisor and anchor above is a fixed constant. The worst value in the measured field is used only as a sanity check when choosing a constant, never as an input while grading: nothing here is a percentile, a rank, or a curve fitted to the current dataset. Two consequences worth being explicit about. A score means the same thing across weekly refreshes, so an aggregator improving its own numbers moves its own score and nobody else's. And removing an aggregator, even the worst one on a criterion, leaves every other score bit-identical: drop the field's heaviest overquoter and no remaining grade shifts by so much as a rounding step. The alternative, grading on a curve against the current field, would mean an aggregator's score changed when a competitor changed, and week-to-week comparisons would be meaningless.

The radar chart deliberately does not use these curves. It plots the raw measured dimensions on plain linear axes, sharing this rule's endpoints (no-quote empties at 60%, sim-failure at 20%) but none of its transfer functions. That is on purpose: the curves above are each shaped differently on purpose (square-root for reliability, reciprocal for price, anchored log for latency) because each encodes its own judgment about what counts as bad, which is right for collapsing six things into one number and wrong for a shape you read axis-against-axis. The radar also splits overquote into rate and magnitude across two axes where the score multiplies them into one oqCost, and blends median with p95 where the score keeps them apart. Use the radar to compare an aggregator's shape, the table to compare its score. One thing the radar does borrow: its radius is the square root of each value, so the area a polygon encloses is proportional to the value rather than to its square. Plotting radius directly would overstate every comparison, since area is what the eye actually measures.

Redundancy fade: with more than one aggregator in the route, No-quote weight halves (×0.5) on every profile except Balanced: a missing quote from one aggregator is simply covered by another. Simple view rolls the six into three categories: Reliability = no-quote + sim-failure, Cost = all-in cost + overquote, Latency = median + p95, each the weighted average × 10 of its members.

API cost is expressed as bps at your monthly volume, from each provider's published plan: a floor, a ceiling, and (where offered) a subscription or custom/enterprise tier.

Standard vs Negotiated. In Standard you see the published/free-tier fee at your volume. In Negotiated, any provider that offers a custom/enterprise deal or paid plan is priced at 0 bps: the per-swap rate large integrations secure once they negotiate or pay for it. That 0 is contingent, so those scores carry a ! whose tooltip names what it takes (a custom agreement, or a paid plan and its monthly cost). Providers with no such plan keep their published rate, and genuinely-free APIs are already 0 with no marker. Setting a monthly volume above $1M switches the lens to Negotiated automatically, since integrations at that scale negotiate; the choice stays manual after that. Undisclosed fees stay undisclosed, never assumed zero. Inside the score, fees are capped at 60 bps for the curve, and overquote is costed separately (Rule 3).

Choosing a profile sets the weights (Rule 3), a reliability target k, a starting set size, and default controls, then assembles your route. Ranking uses the same profile-weighted score the table sorts on, so the checked aggregators are always the top rows (no “why isn't #2 selected?”). The target only decides how many to add: walk down the ranked list, adding aggregators until the route clears 99.9%, or the next aggregator is too weak to move it.

The two stopping conditions. Walking the ranked list, the loop also stops adding when the next aggregator's own usable probability is under 3% (it cannot meaningfully move P(≥k), so adding it is integration work for nothing), and a widened set is capped at 8 aggregators to keep the result something a team would actually integrate. Both are practical limits rather than derived ones; they only bind when the target is out of reach, and the gauge's own caption says so when it happens.

The profile stays active while you tune: changing any control (volume, latency, simulation, pricing, chain) keeps the goal and re-runs its pick under the new settings. Setting Auto-pick best N pins the set to exactly the top N for the goal, overriding the target sizing until a profile card or Reset clears it. Only hand-editing rows marks the route Custom (your own edits, not the profile's pick). The goal's weights still apply; Reset restores the profile's own selection.

The independence assumption. The gauge treats aggregator failures as independent. Correlated failures (honeypots, transfer-tax tokens, genuinely illiquid routes) miss every aggregator at once and set a floor no redundancy clears. Reaching sub-0.1% in practice is two jobs: enough fast, honest, independent quotes (modelled here) and pre-trade filtering of intrinsically unexecutable routes (not in this dataset).

Why none of the numbers are ours. route99 is built by DFC Research, the research arm of the DeFi Founders Club; some measured teams are club members. That is exactly why every figure comes unchanged from Enso Shield, every ranking follows these same published rules for every aggregator, and the source is linked throughout so any figure can be verified directly (Enso methodology ↗).