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 sign convention is explicit so you never have to guess a sign. The two risk penalties (MEV risk, slippage) are subtracted; the two quality / efficiency terms (gas efficiency, liquidity depth) are added. A higher Routescore always means a better execution-adjusted route.
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
| Symbol | Component | Sign | Weight | Why this weight |
|---|---|---|---|---|
| w1 | MEV risk | Risk · subtracted | 0.40 | Sandwich + frontrun probability dominates ex-ante loss on retail-size swaps. Largest weight by design — more modeled MEV pushes the score down. |
| w2 | Slippage | Risk · subtracted | 0.25 | Modeled execution slippage vs the mid quote, pulled per-DEX from the aggregator quote step. More slippage pushes the score down. |
| w3 | Gas efficiency | Quality · added | 0.15 | Inverse gas-cost per unit notional, normalised to the cheapest available route on the same trade. A cheaper route pushes the score up. |
| w4 | Liquidity depth | Quality · added | 0.20 | Deeper pools reduce execution risk and push the score up. Measured as 1bp-depth at the prevailing mid. |
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.
| Term | Class | Direction | Definition |
|---|---|---|---|
| MevRisk | RISK | Higher = worse → subtracted | Modeled sandwich + frontrun probability for the route. A penalty: more MEV risk lowers the Routescore. |
| Slippage | RISK | Higher = worse → subtracted | Modeled price move between the mid quote and the executed price, in signed bps. A penalty: more slippage lowers the Routescore. |
| GasEfficiency | QUALITY/EFFICIENCY | Higher = better → added | Inverse gas cost per unit notional, normalised across candidate routes. A quality term: a cheaper route raises the Routescore. |
| LiquidityDepth | QUALITY/EFFICIENCY | Higher = better → added | Pool depth at 1bp around the prevailing mid. A quality term: deeper liquidity raises the Routescore. |
| Routescore | QUALITY/EFFICIENCY | Higher = better route | The published 0–100 output. Risk penalties are subtracted and quality/efficiency terms are added, so a higher Routescore always means a better execution-adjusted route. |
Calibration evidence and public claims
The public calibration surface compares predictions with realized outcomes, but the public claim gate is source-specific. Overall Brier score and expected calibration error are shown as transparency summaries; they are not sufficient on their own for a public claim.
| Source | Realized quantity | Prediction basis | Public-claim rule |
|---|---|---|---|
dex_quote_diff_reconciler | Cross-venue quote dispersion: best-vs-worst aggregator spread across the quote grid, in bps. | routing_leak_baseline.v1, a trailing baseline over the source's own prior observed spreads. | Must independently clear the sample floor and Brier/ECE ceiling. |
onchain_settlement_reconciler | On-chain settlement cost versus reconstructed pre-trade Uniswap V3 pool mid, in bps. | settlement_cost_baseline.v1, a trailing baseline over the source's own prior realized costs. | Must independently clear the sample floor and Brier/ECE ceiling. |
Routescore does not pool those two quantities as if they were the same measurement. A cohort becomes public-eligible only when at least two independent sources each clear the source-specific gate, and only sources in the published measured-quantity table above can count — a source whose realized quantity is not mapped ("unknown measured quantity") is shown for transparency but never counts toward public eligibility. The dashboard can still show an overall blended Brier/ECE for inspection, but that blended row is not the claim basis. In addition, every snapshot must be bound to a recorded source-manifest version/hash before any public-eligible claim is shown — an unbound snapshot is always "no public claim", so a published number can be tied to exactly which sources produced it.
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.
Score and component outputs are modeled, point-in-time decision support and not investment advice. The full inputs, caveats, and audit instructions live on the methodology page; known limitations are published at /limitations.