The gap used throughout this page is Shield's immediate, same-block re-simulation — the first of the five points Shield measures (t=0, then +12s, +24s, +36s, +48s).

It is therefore drift at zero elapsed time, the most conservative of the five, and the reason § 2.8 models a separate survival term for real execution delay rather than reusing this number as-is. Pinned-block figures are not used.

• Live — the provider's own registry, read daily and served from this origin. Authoritative when present.
• Declared — the provider's published docs count, reviewed by hand. Used when no live reading is available. A live reading never overwrites it, so a failed or stale refresh falls back to a real number rather than to nothing.
• Enumerated — the chains this site can actually name: the curated per-chain index plus the measured rows. Used only when the other two are absent.

Chain counts are informational only and never scored. Needing 60 chains and needing 2 are different jobs, so no criterion in Rule 3 reads this number, and the coverage tie-break in § 2.11 uses measured chains rather than claimed ones.

The rankings column, its tooltip, the radar's coverage axis, the coverage bars, the chain finder and the data appendix all call the same resolver, and a live refresh repaints all six together. Previously the refresh updated the coverage chart alone, so the other surfaces could show a stale figure until a control was touched — the page disagreed with itself. route99SelfTest() now asserts the precedence, the fallback and that a live reading leaves the declared snapshot intact.

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.

An aggregator's “green” band for redundancy-covered failures is the per-aggregator rate at which N independent aggregators still clear the active target — which depends on both N and k, capped at 10%, beyond which correlated failures dominate.

At k=1 that is the closed form target^(1/N); at k≥2 there is no closed form, so the band is solved numerically against the same Poisson-binomial in § 2.4.

A single number for both goals was wrong by more than a rounding step. Under Optimize for price the route needs two usable quotes, not one, because price cannot be compared with only one result.

At its default N=3 the k=1 band is 5.4× more lenient than the k=2 truth — it painted green on aggregators this profile's own arithmetic disqualifies.

• The gauge calculation always used the correct k.
• Only the colour bands and this caption used the wrong value.
• That display inconsistency has been corrected; they now use the same k.

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 σ floor of 0.05 stops a degenerate p95 ≈ med from collapsing the distribution to a point mass. On current data the smallest real σ is 0.139, so it never binds — it is a guard against future rows, not an active adjustment.
• The p95 = max(p95, med × 1.02) guard handles the arithmetically impossible case of a reported p95 at or below the median (rounding, or a thin sample), which would otherwise give a negative or zero σ and an inTime of 0 or 1 with no middle.

Both are stated here because a reader reconstructing inTime by hand from the two published quantiles would otherwise not reproduce our number.

There is no third point to check the shape against, so a real latency distribution with a heavier tail than log-normal (a slow RPC, a congested block) will read as more “in time” at your budget than it actually is, especially past p95 where the fit is pure extrapolation, not data.

This is a property of fitting any two-parameter curve to two quantiles, not a bug in this implementation, and it is the reason the guard above exists rather than a shape check: with only two points there is nothing left to check the shape against.

Treat inTime as the best estimate the published data supports, most reliable near the median and least reliable in the tail your budget actually depends on.

Enso Shield measures failure of an immediate re-simulation against the latest block, with RPC-error simulations excluded.

That is not the same event as a revert after your own execution delay — wallet confirmation, gas movement, settlement windows and mempool exposure all sit between a quote and a landed trade.

With Simulate on the distinction barely matters, because the check happens pre-trade either way.

With Simulate off this page uses that number as a modelled proxy for revert risk, and the oqSurv term (§ 2.8) exists precisely because the proxy is known to understate delayed execution.

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 § 3.6, 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).

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 § 3.6 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.

The score computed from all measured rows across chains. On the pooled All chains view the members are often not all live: Barter is measured on Ethereum alone while claiming 8 chains, OogaBooga on HyperEVM alone.

Reliability recomputed from each chain's own measured rows, restricted to the route members present on that chain.

Every chain served by a route must have at least k live members.

Per-chain reliability is recomputed from each chain's own measured rows, restricted to the route members present, and on All chains the headline is that realised floor — the weakest chain the route serves.

The full per-chain breakdown is on hover over the number. The pooled average appears in “How it's computed” whenever the two differ.

Conclusion. A route can show 99.92% pooled and realise 91.2% on a chain where two of its four members do not exist. The pooled score can materially overstate the reliability actually realized on the weakest chain — and with fewer than k members present, price cannot be compared there at all.

Auto-pick guarantees that every chain the route serves has at least k members live on it, because below that price cannot be compared there at all and P(≥k) is exactly zero rather than merely low.

Short chains are topped up with the highest-scoring eligible aggregator measured there, never one that would break the goal's own filter.

Where two aggregators sit within 0.15 points, the one measured on more chains wins, since on the pooled view an absent member contributes nothing.

Each aggregator is graded on six criteria in three pairs: reliability (no-quote, sim-failure), price (all-in cost, overquote), latency (median, p95).

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.06 bps worst case, 1.40×).

Applied here: the worst measured no-quote rate is 59.52% and the worst sim-failure is 20.84%, so 85% and 30% give each about that same margin (1.43× and 1.44×).

Sim-off stays deliberately twice as strict as sim-on, because an uncaught failure reverts on-chain rather than being caught pre-trade.

An earlier calibration used 10% and 10/5%, tight enough that an aggregator with 95% real-world availability graded as if it barely worked at all. 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.

This is the correction that produced the numbers above, and it is worth stating plainly because the previous ones were justified against the wrong population.

The constants used to be sized on the all-chain view (~42% no-quote, ~13% sim-failure), but grading runs on per-chain rows, where the real worst cases are 59.52% (Eisen on BSC) and 20.84% (Velora on Base). That left 1.008× and 0.96× headroom instead of 1.4×.

The latency pair is graded two ways, because setting a budget changes the question. Every goal but Low latency measures against a 1,200 ms budget by default (Low latency uses a stricter 400 ms); Off is the deliberate opt-out, for reading raw speed with no deadline attached.

A deadline adds a compliance question without removing the speed question, because 400 ms can clear a 400 ms budget and still feel slow.

The tail is never dropped: p95 is what sets σ, so a heavy tail directly lowers the in-time share.

In the weights table (§ 3.7), Median and p95 are the primary and secondary latency criteria; with a budget set they read as compliance and speed.

“How fast is it?”, no deadline. L is the half-credit point (800 ms typical, 2,200 ms tail).

A category grade of 8.0 needs roughly a 100 ms median and a 275 ms p95, and 9.0 needs 50 ms/137 ms. Nothing measured here is that fast.

The whole 15-aggregator field lands in 3.4–8.0 with the top two points of the scale dead — and since green starts at 8.0, only the single fastest aggregator ever cleared it, rendering the second-fastest in the field amber. That reads as “this aggregator is mediocre at latency,” which is false.

Re-weighting cannot repair it: the median and p95 grades are collinear on this data, so however the pair is weighted the latency category moves by at most ~0.13 points. A budget is the only lever with real separation in it.

1,200 ms rather than 800 because at 800 the curve cliffs just past the anchor — a 1,025 ms and a 1,133 ms aggregator both collapse to 2.4, overstating the difference between 800 ms and 1,000 ms — where 1,200 grades them 6.6 and 5.1: clearly worse, not annihilated.

And not 400 ms everywhere, because 400 is genuinely selective (a 576 ms median falls to 2.8): right for the goal whose job is finding fast aggregators, wrong as a global default.

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.

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 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, so the criterion Optimize for price advertises as one of its two leading concerns could not move a ranking — the field's worst overquoter gave up half a point out of ten, and seven of thirteen aggregators lost nothing at all.

The divisor is sized on per-chain rows for the same reason the reliability pair is: the worst measured oqCost is 10.03 bps (Odos on Ethereum, 63.4% of quotes inflated), not the 2.09 bps of the all-chain view.

A divisor of 0.5 empties the curve at 9.5 bps — below that worst case, leaving the field's heaviest overquoter past the end of the scale. At 0.75 it empties near 14.25 bps: 1.42× headroom, matching Cost's 1.40× and the reliability pair's 1.43×.

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. In Balanced, where no pair leads, cost carries overquote's zeroed weight (×2) instead of just dropping it, so the price pair still totals the same as reliability and latency:

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 (§ 5.4); this is that same intent enforced in the weights, not just the copy.

Balanced is the one place this needs a second step: dropping overquote's weight there without compensating would leave the price pair (cost + overquote) totalling half the weight of reliability (no-quote + sim-failure) and latency (median + p95) — quietly contradicting "no single pair dominates" even though every other number in the row still read as 1. Cost absorbs the difference so all three pairs total the same weight.

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.

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.

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.

It plots the raw measured dimensions on plain linear axes, sharing this rule's endpoints (no-quote empties at 85%, sim-failure at 30%) 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.

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.

In Standard you see the published/free-tier fee at your volume.

In Negotiated, a provider that publishes a paid plan is priced at its amortised rate — bpsMin + subMax/V×1e4, the formula already above — because that is what the plan costs per swap at your volume, and it is arithmetic rather than assumption.

Only a provider advertising a custom/enterprise tier with no published rate at all is shown as 0 bps under Negotiated, since there is no number to compute instead. That 0 is contingent, so those scores carry a ! whose tooltip names what it takes. Genuinely-free APIs are already 0 with no marker.

A provider with no published low end (no subMax plan to amortise) is still interpolated toward its disclosed range's bottom as volume rises, because that is what the range is for.

But nothing published confirms that low end is reachable without negotiating — it is the same unconfirmed floor Negotiated shows explicitly at 0, just reached gradually instead of in one step.

Pricing every negotiable provider at 0 bps threw away a number this model already computes, and it made a provider publishing a $799/mo plan score identically to one publishing nothing — the lens penalised disclosure.

It was also the largest single ranking lever here: at $10M/mo it moved one aggregator seven places on a 2.94-point swing, entirely on an assumption.

Worse, picking a volume above $1M used to flip the lens on automatically, so a user who only chose a volume was shown contingent rates they never opted into.

If a provider charges a fee whose rate it does not publish, that silence conceals a real number, and scoring it as free would make “tell nobody your prices” the most profitable thing a provider could do here.

Those are scored at the worst published effective rate in the field at your volume, flagged in the breakdown.

If instead no fee exists to find — nothing in the docs, no fee field, fee recipient or fee line in returned quotes — that absence is itself weak evidence, and it points at 0. Those are read as 0 bps and marked “unverified”.

Imputing a punitive rate there would publish a number we have positive reason to believe is false, about a named team; the flag carries the doubt instead of the score.

An affirmative “we charge nothing” is a third thing again — a disclosure — and counts as published.

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, evaluated at the size the route will actually be, so the checked aggregators are the top rows of the pool this goal is drawing from (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 your reliability target, or the next aggregator is too weak to move it.

Optimize for price used to drop anything with |drift| above 0.1 bps.

• Fill drift is already inside all-in cost (drift + API fees on one bps scale, weighted ×3 here) and inside overquote (×2), so gating on it counted the same defect a third time.
• Because the test was on absolute drift it also excluded aggregators that underquote, i.e. fill better than they quote, contradicting Rule 1's promise that conservative quoting is never punished.

The visible symptom was an aggregator showing the field's second-highest score and the word FILTERED in the same row.

What is not deliberate, and has been fixed, is ranking that depended on what was selected before the pick: the no-quote weight halves at more than one aggregator, so scoring during assembly used to read the previous route's size.

Scoring now takes the candidate size explicitly and the target walk iterates to a fixed point, so assembly and the table are always scored in one context.

• The loop 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.
• The route is capped at 5 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 caption names the binding chain when it happens.

Growth is coverage-aimed: while the weakest chain the route serves is under target, the next pick is aimed at that chain — an addition absent from the binding chain cannot move the number the gauge shows.

The aimed pick is ranked by what it does to that chain, not by its overall score.

Those are different questions, and ranking the repair by score picked an aggregator that scored well overall but was weak precisely where the route was short, leaving the chain under target when the target was reachable.

If no aggregator can help the binding chain while the pooled target is met, growth stops rather than spending slots that change nothing.

Auto-pick is a convenience, not a rule: it seeds the smallest set that reaches this goal's target and keeps that set fresh while the set is still auto-managed, so changing any control (volume, latency, simulation, pricing, chain) re-runs the pick under the new settings.

• Auto-pick best N is an explicit request for the top N and so overrides a hand-edited set.
• Changing chain filters out rows not measured on the new chain (an aggregator you picked may have no data there) rather than discarding your set.

Restore auto-pick hands the set back to the goal.

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.

The gauge is capped at 99.999%+, and that is not a rounding choice. The arithmetic above will happily return 99.99999% for a set of four or more strong aggregators, and printing that as 100% would be the model asserting something it has no standing to assert.

§ 6.1 says correlated failures set a floor no redundancy clears, and that floor is not in this dataset. Past the fourth digit the number is a statement about the independence assumption, not about the aggregators. So the display stops there.

Read anything above 99.9% as “the modelled quote-supply problem is solved for this set; what remains is the correlated-failure and unexecutable-route problem, which is a different job.”

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 ↗).

Enso is scored here on the same six criteria and the same published rules as everyone else, with no special handling: 11th of 15 under Balanced, 12th under Optimize for price, 7th under Low revert rate, 13th under Low latency (each at that goal's own default settings).

We do not adjust Enso's inputs, weights, or curve differently from any other row, and the numbers above are reproducible from the same public dataset every other score comes from.

“The code matches this page” is an assertion, and given who publishes route99 it should be cheap to falsify.

Open your browser console on this page and run route99SelfTest(). It asserts every formula above against a hand-computable expected value — Poisson-binomial at k=1 and k=2 with unequal inputs, the green band at both k, the log-normal inversion, latency-curve continuity and clamping, every zero-point and divisor, dollars-to-bps, both pricing lenses, and the display cap — then prints a pass/fail table.

Every assumption behind the cost and coverage columns, in one place. Both tables are generated at page load from the same embedded dataset the rankings use — they cannot drift from what's shown there. This is about consistency, not freshness: the dataset itself is the dated snapshot named above, re-read the same way every time the page loads. Hover a rate for the full sourcing note.

Standard = the published or free-tier rate at that monthly volume, with paid plans amortised into bps where that is cheaper. Negotiated = genuinely unpriced custom/enterprise tiers at their contingent 0 (Rule 4).

LP/pool fees, bridging, gas and consumer-UI fees are excluded throughout. Effective-rate columns are in bps.

• unverified marks a provider where no fee could be found in the docs or in returned quotes and no official “no fee” statement exists either — read as 0 bps and flagged, not imputed.
• rate not published marks a provider that does charge a fee but publishes no rate — scored at the field's worst published rate at that volume, never assumed free.
• A provider with no amortisable plan whose Standard-lens rate has been interpolated below its published ceiling carries the same flag as a Negotiated 0 — the confirmed number is the ceiling, not wherever your volume happens to land inside the range.

✓ marks a chain with a measured Enso Shield row in this dataset — the checkmark grid makes gaps visible at a glance, which is exactly what names the shortfall in Optimize for price's Polygon coverage (§ 2.11).

“Claimed” is the provider's own network count linked to its source (live registry where available, otherwise official docs); hover it for source quality and how much sits beyond what's measured here, which we cannot independently verify.

For the interactive version — pick your chains, see who covers them — use the finder in the Network coverage section of the rankings page.