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). 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 Rule 2 models a separate survival term for real execution delay rather than reusing this number as-is. Pinned-block figures are not used.
• Underquote rate is carried in the dataset and deliberately not scored: a fill better than quoted costs the integration nothing, so grading it would punish a provider for quoting conservatively.

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 the per-aggregator rate at which N independent aggregators still clear 99.9% — which depends on both N and k, capped at 10%, beyond which correlated failures dominate. At k=1 that is the closed form 0.001^(1/N); at k≥2 there is no closed form, so the band is solved numerically against the same Poisson-binomial above.

Why k has to be in this band. 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, and at its default N=3 the k=1 band (10%) is 5.4× more lenient than the k=2 truth (1.84%) — it painted green on aggregators this profile's own arithmetic disqualifies. The gauge always used the correct k; only the colour bands and this caption did not, and they now do.

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.

Coverage is part of reliability, not a separate topic. The gauge models N aggregators quoting in parallel on every request, which is only true where all N are live. On the pooled All chains view they often are not: Barter is measured on Ethereum alone while claiming 8 chains, OogaBooga on HyperEVM alone. A route can therefore show 99.92% pooled and realise 91.2% on a chain where two of its four members do not exist — and with fewer than k members present, price cannot be compared there at all. So 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 — with the full per-chain breakdown on hover over the number. The pooled average appears in “How it’s computed” whenever the two differ. Coverage also enters assembly, in two bounded ways. Auto-pick guarantees a feasibility floor: every chain the route serves must have 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. And coverage breaks near-ties: 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. Coverage never licenses breaking a goal's own filter: where a goal's eligible pool genuinely cannot reach a chain within the 5-member cap, the route stays as it is and the headline shows the shortfall honestly — only five aggregators are measured on all six chains, so this binds exactly where the field is thinnest.

Two guards on the latency fit, both load-bearing. 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.

A two-point fit has no slack in it. A log-normal has two free parameters, and this page has exactly two published quantiles — median and p95 — to fit them from. That pins the curve with zero degrees of freedom: 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.

What the sim-failure input actually is. 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 above exists precisely because the proxy is known to understate delayed execution. Read the sim-off gauge as the best available estimate, not as a measured revert rate.

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 85% and 30/15%, 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.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.

Calibrated against per-chain rows, not the all-chain aggregate. 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× — and 0.96× means the scale had run out: Velora on Base graded exactly 0.000 on sim-failure, so the criterion could no longer tell 21% apart from 45%. A zero-point a live row can reach is not a zero-point. The rule is now that every constant is sized against the worst value any gradeable row can take, and the check is re-run against per-chain data on each refresh.

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.

Budget set — the default: 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.

Off — “how fast is it?”, no deadline. Graded on an anchored scale instead. 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.

Why a budget is the default, and why 1,200 ms. On this field the anchored scale has an unreachable top: 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, so 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.

Why two modes at all. 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 anchored scale 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. One consequence is visible in the colour: because that scale's 10 is unreachable, the latency column bands against the achievable range when the budget is Off (green from 7.5, amber from 5) rather than the 8.0/5.5 cut every other column uses. With a budget set the scale is reachable and the ordinary cut applies.

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, 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:

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

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, 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.

The same assumption, reached from Standard. 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. So the ! is not gated to the Negotiated lens: any score resting below that provider's published ceiling (bpsMax, the ordinary Standard-tier number) carries it, in either lens. Only the ceiling itself, and rates from providers with a real amortisable plan, are unflagged.

Why the lens no longer zeroes paid plans, and no longer engages itself. 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. Volume now sets volume. Negotiated is a deliberate click, and it now changes the fewest numbers it honestly can.

A hidden rate is not a zero — but a missing fee is. Two situations look alike and are not. 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). If a rate here is wrong, telling us is the fix.

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?”). One thing legitimately moves a checked row away from the top of the visible table, and it is deliberate: the target walk, which stops as soon as 99.9% is cleared and so may not reach a row that scores well but adds nothing. No goal applies a hard eligibility gate. Optimize for price used to drop anything with |drift| above 0.1 bps, and that was wrong twice over: 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 — and 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. Drift is now priced, never gated: it costs score points in proportion to its size, and an aggregator that drifts badly ranks last on its own. 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 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 the route is capped at 5 aggregators to keep the result something a team would actually integrate. Growth is also 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 99.9% was reachable. A consequence worth stating plainly: a repair can pull in an aggregator this goal scores poorly. It is there for coverage, not as an endorsement — the route is quoted in parallel and the best result wins, so a costly member only ever wins when it is genuinely the best net quote, and the table still shows its real score. If no aggregator can help the binding chain while the pooled target is met, growth stops rather than spending slots that change nothing. All 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.

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

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: the paragraph directly above 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."

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

Enso is both the data source and a ranked aggregator. 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.

Check it yourself. "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. If any row fails, this page and the code have drifted, and one of them is wrong.

Every assumption behind the cost and coverage columns, in one place. Both tables are generated from the live dataset at page load — they cannot drift from what the rankings use. If any figure is wrong, tell us ↗: corrections ship with the next data refresh, and disagreement with a published number is exactly the review this page exists to invite. Hover a rate for the full sourcing note.

API pricing at each volume. 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. 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. Effective-rate columns are in bps.

Supported networks. ✓ 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 above. “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.