Which DEXes BlazePhoenix routes across, on every chain — and how to verify it yourself

Every aggregator publishes a list of integrated exchanges. Almost all of those lists are prose, maintained by hand, and quietly wrong within a month. Ours is on-chain, and this article is mostly about teaching you to read it — because a registry you can enumerate yourself is worth more than a logo grid you have to believe.

Eight venue families, one dispatcher

The router does not carry one adapter contract per exchange. It carries a single dispatcher that speaks eight AMM species: constant product (Uniswap V2 and its many forks), concentrated liquidity (Uniswap V3 and Algebra), the Solidly stable curve used by the ve(3,3) family, Curve's stable and crypto pools, Balancer's weighted pools, and Uniswap V4's singleton with hooks.

The doctrine matters as much as the coverage. Where a closed-form formula is the truth, we compute it exactly — constant product is evaluated as a single expression with the division deferred to the last step, so the only rounding is the final floor. Where only the venue's own bytecode is honest, we ask it: Curve's get_dy and Solidly's getAmountOut are called directly, because the same code that will enforce the invariant at execution produced the number. Quote and fill cannot diverge when the quote came from the executor.

One consequence worth stating: supporting a family is not the same as routing a specific exchange. Any fork of a supported family becomes routable the moment its factory is registered — which is why coverage grows without new contract code.

What is actually live: read the registry

Each chain has its own Hub, and the Hub holds the registered factories for that chain. That registry — not this paragraph — is the authoritative answer to "what do you route across here". Enumerating it takes two calls: ask how many factories are registered, then read them by index.

Do this on any chain we are deployed on and you have a current, unarguable list. If a venue you care about is missing, that is the honest state of the deployment on that chain today, and you have found it without asking us.

Addresses for every chain are published at /verify and /api/manifest.

How many venues are registered on this chain:
  cast call <HUB_ADDRESS> "factoryCount()(uint256)" --rpc-url <RPC_URL>

Read each one by index:
  cast call <HUB_ADDRESS> "factories(uint256)(address)" 0 --rpc-url <RPC_URL>

The returned addresses are factory contracts — look each up on the
chain explorer to see which exchange it belongs to.

Robinhood Chain, as a worked example

The newest deployment is the clearest illustration, because it was wired end to end recently and its registry is small enough to read in one sitting: seven venues across the Uniswap V2, V3 and V4 families plus PancakeSwap V2 and V3, SushiSwap V3 and SwapHood V2, with WETH and USDG serving as the bridge assets that multi-hop routes pass through.

Every one of those addresses is verifiable on the chain's Blockscout explorer, and the contracts running there are the same bytecode as on Base, Ethereum, Optimism and Arbitrum. That is the property that makes the registry approach safe: adding a venue never changes the math, only the candidate set.

Known gaps, stated plainly

On Ethereum, Curve and Balancer are not currently wired into the registry, which is why a small set of stablecoin and correlated-asset pairs quote worse here than the aggregate market. That has its own article, because it deserves an explanation rather than a footnote.

We would rather list the gap than let the logo grid imply completeness. An integration list is a promise about what your trade can reach; the version of it you can enumerate yourself is the only one worth making.

Related engineering

• Why some Ethereum pairs quote differently here than the price you see elsewhere ›
• The Eightfold Dispatcher: one quote function for eight species of AMM ›
• CREATE2 discovery: verifying a pool is who it claims to be ›
• On-chain quoting: why the price you see is the price the contract computed ›