Why some Ethereum pairs quote differently here than the price you see elsewhere

If you quote certain Ethereum pairs here and compare against a price aggregator, you may find our number is worse. We would rather explain that than let you discover it mid-trade, so here is the actual reason.

It is not a pricing error, and it is not the fee. It is coverage: a route can only be as good as the venues it is allowed to consider, and on Ethereum the deepest liquidity for some pairs sits on venues our registry does not currently include.

Which pairs, and why those

The pattern is consistent: stablecoin-to-stablecoin pairs, and pairs between assets that track each other closely — a liquid staking token against the asset it represents, or two wrappers of the same underlying. Those pairs migrated years ago to venues whose curves are purpose-built for correlated assets, because a constant-product pool is a poor instrument for trading two things that are meant to have the same price.

On Ethereum that means Curve, whose stable and crypto pools dominate correlated-asset flow, and Balancer, whose weighted pools hold a large share of the rest. If most of a pair's depth is there and we are routing across the venues we do cover, our best available route is genuinely worse than the market's best route — and the honest thing is to show you our real number rather than a market average we cannot actually fill at.

What is and is not missing

The mathematics is not the gap. The Eightfold Dispatcher already speaks eight AMM families, including Curve's stable and crypto curves and Balancer's weighted pools — and for exactly those venues it uses the ask-the-pool doctrine: it calls the venue's own bytecode rather than reimplementing its formula, so the number cannot drift from what the pool would enforce at execution.

What is missing is registry coverage on Ethereum: those venues are not currently wired into the Hub on that chain, so the Solver never sees their pools as candidates. That is a configuration and verification job — each factory has to be registered and its pool derivation proven — not a rewrite. It is on the roadmap, and we are not going to put a date on it here that we might miss.

How to tell whether it affects your trade

Two checks, both quick. First, the route: our quote shows how many legs it used and across which venues. If your pair is a stable-to-stable or a correlated pair and the route looks thin, that is the case described here.

Second, compare directly. Quote the pair here and on any venue you like, at the same size in the same minute, and look at tokens received. If the difference is material, take the better route — we mean that. A tool that tells you when someone else is better on a specific pair is a tool you can believe when it says it is better on the rest.

For the majority of pairs — volatile tokens, the long tail, anything trading mainly on constant-product and concentrated-liquidity venues — this does not apply, and our on-chain-computed quote is exactly what the Router will realise.

Compare like for like, same minute, same size:
  curl 'https://blazephoenix.xyz/api/quote?chain=eth&in=USDC&out=USDT&amountIn=1000000000'

Then quote the same pair wherever you normally trade, and compare
the raw output amounts — not percentages.

Why we publish this at all

Because the alternative is that you find out by losing a few basis points and concluding we are either careless or dishonest. Neither is true, and neither is worth the silence.

A protocol that names its own coverage gaps in public is making a claim you can test: that when we say a number is the best we can find, that statement means something. The gap is real, it is bounded to a describable set of pairs, and it will close.

Related engineering

• The Eightfold Dispatcher: one quote function for eight species of AMM ›
• On-chain quoting: why the price you see is the price the contract computed ›
• Which DEXes BlazePhoenix routes across, on every chain — and how to verify it yourself ›
• Price impact, explained: why your own trade moves the price ›