How the Routescore is produced

Routescore is a pre-trade scoring layer. For every candidate swap route it produces a single 0–100 score and a per-component breakdown. This page mirrors the public methodology page: the formula, the sign convention, the weights, and a glossary, so the score is auditable on any confirmed block.

The scoring formula

Each component is independently normalised to 0–100 against the same trade evaluated across all candidate routes, then combined with the published weights. The sign convention is explicit: higher Routescore = better route. The two risk penalties (MEV risk, slippage) are subtracted; the two quality / efficiency terms (gas efficiency, liquidity depth) are added.

# Higher Routescore = better route.
# RISK penalties are SUBTRACTED; QUALITY / EFFICIENCY terms are ADDED.
 
Routescore = 100
           - w1 · MevRiskPenalty        # RISK  (subtracted)
           - w2 · SlippagePenalty       # RISK  (subtracted)
           + w3 · GasEfficiency         # QUALITY/EFFICIENCY (added)
           + w4 · LiquidityDepth        # QUALITY/EFFICIENCY (added)
 
# Component definitions (each normalised to 0..100 over candidate routes)
# RISK terms — higher = worse, enter the formula with a MINUS sign:
MevRiskPenalty = sandwich_probability + frontrun_probability       (detector v0.4.2)
SlippagePenalty = |mid_price - executed_price| / mid_price * 1e4    (bps, magnitude)
 
# QUALITY / EFFICIENCY terms — higher = better, enter with a PLUS sign:
GasEfficiency  = min(gas_cost_usd_over_routes) / gas_cost_usd       (1.0 = cheapest)
LiquidityDepth = pool_1bp_depth_usd                                 (deeper = better)
 
# Weights — see /methodology#weights for rationale (and #glossary for signs)
w1 = 0.40   w2 = 0.25   w3 = 0.15   w4 = 0.20
 
# Output bounds
0 <= Routescore <= 100   (higher = better execution-adjusted route)

Weights

Glossary · risk vs quality terms

Every term is labelled so the sign is never ambiguous. RISK terms are penalties (subtracted); QUALITY / EFFICIENCY terms raise the score (added). Higher Routescore always means a better route.

Calibration evidence and public claims

The public calibration surface compares source-specific baseline forecasts with their own measured quantities, and the public claim gate is source-specific. These baselines forecast their own measured quantity from prior observations; they are not the composite Routescore (heuristic.route_score.v1), which the calibration surface does not evaluate. Overall Brier score and expected calibration error are shown as transparency summaries; they are not sufficient on their own for a public claim.

Routescore does not pool these distinct quantities as if they were the same measurement. A cohort becomes public-eligible only when at least two distinct independence groups each independently clear the gate for the same exact measurement quantity. Different quantities never corroborate one another. Only sources in the published measured-quantity table above can count — a source whose measured quantity is not mapped ("unknown measured quantity") is shown for transparency but never counts toward public eligibility. The three sources provide separate acquisition paths and measured quantities, which reduces reliance on any one source; that diversity alone does not qualify a claim or eliminate common-mode failure, observable market anomalies, or model error, since two of the paths read the same on-chain pool state.

The per-source gate a source must clear on its own outcomes is:

• ≥ 30 confirmed labels and ≥ 30 probability-eligible pairs;
• labels count only at label confidence ≥ 0.6;
• Brier ≤ 0.2 and ECE ≤ 0.1;
• a "bad outcome" is the source's own measured quantity reaching ≥ 30 bps — for settled execution cost that is an incurred loss; for the two dispersion sources it is a ≥ 30 bps dispersion, not an incurred loss;
• and the source must measure a known quantity (in the table above).

For one exact measurement quantity, at least two distinct independence groups must clear this gate independently. Groups measuring different quantities do not count toward the same claim. Brier and ECE test probability calibration only — not discrimination, route-ranking skill, or causal savings; a naive base-rate forecaster can score well on calibration. Calibration is a floor to clear, not proof of usefulness.

The dashboard can still show an overall blended Brier/ECE for inspection, but that blended row is not the claim basis. A cohort that does not clear the gate is not hidden: its diagnostic Brier/ECE and counts remain visible for transparency, carrying a "no public claim" badge, and it is simply not designated public-eligible. Cohorts are one-dimensional breakdowns (by chain, venue, token pair, size bucket, freshness, or source), not joint slices. Drift suppression is currently applied at the overall snapshot level — a flagged downgrade withdraws all public claims together until they recover; per-cohort drift suppression is a future enhancement. In addition, every public-eligible claim must be bound to a recorded source-set version/hash before it is shown — an unbound snapshot is always "no public claim". Today the surface exposes that version and hash (not a downloadable observation bundle), so a published number is pinned to a fixed, recorded reference that can be cited and disputed.

What the score does not include

The Routescore number deliberately excludes risks that should not be mixed into a price-execution score. These are surfaced as separate signals on the route detail, not folded into the number:

• Oracle risk — a 100/100 route on a pool with a fresh oracle compromise is still a bad trade, surfaced separately.
• Bridge risk — cross-chain routes carry bridge exposure that is not modelled in the score.
• Smart-contract risk — audit, bug-bounty, and age-of-deployment signals are surfaced separately; we do not mix exploit-tail risk into a price-execution score.