Judging a Router Honestly: What a Quote Does Not Tell You

You cannot verify that a router got you the best price, because the best price is a counterfactual and the chain records only what happened. What you can verify is the router's disclosure, its revenue model, the parameters it exposes, and whether its behaviour is repeatable across a controlled sequence of your own orders. That is the whole basis of an honest assessment.

This matters because the industry's default comparison is two quotes on two screens. That comparison is cheap, feels rigorous, and answers a question nobody asked. A quote is a projection produced by one party's model of state it recently read, adjusted by whatever margin that party takes. Two projections are not two results, and the gap between them is not evidence about either.

A quote is a claim about a counterfactual

When a router displays an output figure, it is asserting that if you sign now, this path will produce approximately this result. When it displays a comparison against another venue, it is asserting something stronger: that the alternative would have produced less. The first claim is testable after the fact by opening the transaction. The second is not testable at all, because the alternative never executed.

Nothing dishonest need be involved. The comparison is genuinely useful as a design tool and genuinely unverifiable as a performance claim. The correct posture is therefore to treat quoted comparisons as descriptions of the router's own model and to move your scepticism to the places where evidence actually exists: the transaction, the parameters, and the disclosure.

Six disclosures and what silence implies

Assessment starts with what a router chooses to publish. Absence is informative, though not conclusive, and the useful exercise is to note which of the six you had to infer.

The fastest way to check several of these at once is to read the developer documentation rather than the product page. An API surface is a confession: the parameters a service exposes are the things it controls, and the ones it omits are the things it either does not control or does not want configured. Public aggregator documentation such as docs.jup.ag shows what a fully specified quote interface looks like, which gives you a baseline for judging any other.

The conflict map

A router faces choices where two good things cannot both be maximised. Its behaviour at those points is its actual character, and its revenue model predicts that behaviour better than its documentation does.

None of these conflicts implies misconduct. They are structural, they exist in every intermediated market, and the mature response is to map them rather than to be scandalised by them. A router that names its own conflicts is demonstrating a level of self-awareness that correlates well with the rest of its conduct.

Tests that survive scrutiny

Four tests are available to any trader with a wallet and an explorer, and they assess the router rather than the market.

1. Quote-to-fill consistency. Record the quoted output and the realised output for a series of attempts. You are not testing whether the router is optimal; you are testing whether its own projection is reliable. A router whose quotes are consistently optimistic is telling you something about its model, and the size of the bias is more informative than any single trade.
2. Parameter honesty. Turn off a venue class using whatever exclusion control exists, then check the resulting transactions on explorer.solana.com to confirm that the excluded venue really does not appear. Controls that do not control are worth discovering early.
3. Failure behaviour. Force a failure with a deliberately tight constraint and observe what happens. Does it retry, does it fall back to a different path, does it tell you, and what did the attempt cost. This is the test most people skip and the one that most often changes their configuration.
4. Fee visibility. Open a completed transaction and try to reconstruct every deduction from the account changes and the fee lines described in the Solana documentation. If part of the cost cannot be reconstructed, that part is embedded, and you now know the revenue model regardless of what the marketing said.

What these four have in common is that they do not require a benchmark, a control group or a statistical apparatus. They are properties of the router's own behaviour, observable in a handful of transactions, and they are the tests a desk can realistically repeat when something changes.

Metrics that flatter

The first row is the one worth internalising, because it applies to your own record keeping as much as to a vendor's reporting. If your log contains only fills, your measured performance will improve every time your configuration becomes more fragile, since the worst outcomes simply stop being recorded. Logging attempts rather than fills is the single change that makes everything else assessable.

Two routers, one hundred attempts each

Illustrative arithmetic with stated assumptions, not observed data. Two routers are tested with alternating orders in the same session, same pair, same sizes. Router A quotes better and lands less often; router B quotes worse and lands more often.

On the average, router A wins by three basis points. On the tail, router B is dramatically better. Which one you should use depends entirely on whether your strategy can absorb the occasional bad outcome, and that is a question about you rather than about the routers. Presenting only the average line, as almost every comparison does, would have hidden the only difference that could plausibly change a decision.

Note also what this table does not claim. It does not say router A is worse. It says that under these assumed inputs the two are close on the mean and far apart in the tail, which is exactly the kind of finding that a hundred-attempt test can support and a two-quote screenshot cannot. Any tool that touches your order deserves the same treatment, whether it is an aggregator, a wallet's default path, or an execution product such as Solana Volume Bot Pro; the standard is disclosure, incentive and repeatability, applied identically to all of them.

Three router failure modes worth naming

Routers do not usually fail loudly. They fail in ways that look like market conditions, which is why the failures persist. Three shapes account for most of what a desk will actually encounter.

All three are detectable with the quote-to-fill record described above, and none is detectable from a single trade. That is the practical case for keeping a running log even when everything seems fine: the log is not there to catch a dramatic failure, it is there to make a slow drift visible before it has been paying for itself for six months.

The questionnaire

Ten questions. If a router's documentation, support channel or API answers eight of them, you are dealing with a serious operation, whatever else you conclude.

• What do you charge, and does the charge appear in the transaction?
• Can a fill come from a party that is not a public pool?
• Does any third party pay for access to this flow?
• What does the router maximise when quoted output and landing probability conflict?
• Which venue classes can I exclude, and is the exclusion enforced?
• What happens when a route fails: retry, fallback, or return?
• Who bears the cost of a failed attempt?
• Is any part of the deduction not reconstructible from the transaction?
• How often does the routing set change, and is the change announced?
• What would you consider evidence that the router performed badly?

The tenth is the most revealing and the least often asked. An operation that has thought about how its own product could be shown to be failing has a different relationship with its users than one that has only thought about how to show it succeeding.

When to stop evaluating

Evaluation has a cost, and past a point it stops paying. Three signals indicate that you have learned what is available.

The first is convergence. When two configurations differ by less than the ordinary variance of your own flow, further testing will not separate them, and choosing on secondary grounds such as reliability, support or simplicity is rational rather than lazy.

The second is exhausted disclosure. Once you have all six disclosures and have run the four tests, the remaining uncertainty is about conduct you cannot observe. More testing does not reduce it; only a change in what the counterparty publishes would.

The third is a shift in scale. Assessment should be proportional to what is at stake. A desk moving small size occasionally has already over-invested by reading this far, and should pick a reputable path, keep constraints sensible, and spend the saved effort on the trade itself.

What remains after all of it is a residual you cannot close: you will never know what the alternative would have produced. Accepting that honestly is more useful than any metric, because it redirects attention from an unanswerable question about optimality to answerable ones about disclosure, incentive and consistency. Those are the only questions a router can actually be judged on.