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 four AMM families across six kinds: 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, and Uniswap V4's singleton — native ETH included, hooks screened by address arithmetic.

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: Solidly's getAmountOut is 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 reads: ask how many factories are registered, then read the registration events, which name every one.

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>

List them from the registration events (one per add or update; factories are never removed,
so the distinct addresses must number exactly factoryCount()):
  cast logs --address <HUB_ADDRESS> "Factory_(address indexed,uint8,uint8)" --from-block <HUB_DEPLOY_BLOCK> --rpc-url <RPC_URL>

The addresses in the first topic 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, the Curve and Balancer families sit deliberately outside the routed set — excised in a trust-boundary hardening round — which is why a small set of stablecoin and correlated-asset pairs can quote below the aggregate market here. That has its own article, because a deliberate boundary 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.