How Cross-Chain Routers Select Destination Pools

Cross-chain routers select a destination pool by comparing executable paths from the source token to the requested destination token, then ranking the resulting quotes against cost, output and speed preferences. A “pool” may mean the destination decentralized exchange pool used for a swap, or liquidity inventory used by a bridge or relayer; those are different components. The route quote joins them into an ordered plan, but there is no universal router rule that picks one best pool for every transfer.

A request supplies the source and destination chains, token addresses, amount and recipient. The router checks which bridge tools can carry value between those chains and which exchanges can trade the arriving asset into the requested token. A path might swap before bridging, bridge a common asset and swap after arrival, or use a bridge that delivers the requested asset directly. For a concrete account of how a relay bridge can combine movement and swapping, see how a relay bridge combines move and swap. The final choice depends on available quotes and the request’s constraints.

What does a router compare when choosing a destination pool?

A router compares the amount the destination pool can return after accounting for price impact, fees, gas and bridge costs. It first needs a valid token path: the bridge must support the source and destination assets, and the destination swap venue must have a route from the delivered asset to the requested token. If one link is unavailable, that candidate path drops out even if its other steps look cheap.

For an automated market maker, the quoted output reflects the pool’s reserves and pricing curve at quote time. A larger trade relative to available liquidity moves the price farther along that curve, so the nominal pool price is not the user’s execution price. An aggregator may also split a swap across several pools or exchanges when its routing engine finds that the combined estimated output beats a single venue. The split adds transactions or calldata complexity and can expose the route to more points of failure.

The quote then accounts for bridge fees and chain gas. A route that promises more destination tokens can still be worse if it consumes more value in fees or requires costly transactions on both chains. Routers expose estimates such as expected output, minimum output after slippage, fee costs and gas costs. Some APIs let an integrator prefer fastest or cheapest routes, allow or deny particular bridges and exchanges, or hide routes above a price-impact threshold. Those settings shape the candidate set and ranking; they do not change the pool’s liquidity.

How do bridges and relayers change the pool choice?

Bridge architecture determines what “destination liquidity” means. A liquidity-network bridge may rely on a relayer that fronts tokens from its inventory on the destination chain, then settles against the user’s source-chain deposit later. In that design, the user may receive tokens without waiting for the original assets to traverse a canonical bridge, while the relayer bears inventory and settlement risk.

Across provides one specific example of this intent model. The user’s origin-chain `SpokePool` records a `depositV3()` with the destination chain, output token and output amount. A relayer can call `fillV3Relay()` on the destination chain’s `SpokePool` using its own tokens. The destination fill is separate from a DEX pool swap: if the requested output token differs from what the relayer holds, another swap may be needed. The protocol later validates fills against deposits and settles relayer repayment. The router’s quote must therefore price both the destination delivery and any required swap; calling both stages one “pool” obscures where liquidity actually comes from.

Pool availability is also dynamic. A route can quote well while the destination pool has sufficient reserves, then lose output or fail if another trade changes those reserves before execution. Bridge inventory can be constrained too, and relayer fees can vary with route conditions. A router’s estimate is a decision aid based on current inputs and tool quotes, not a reservation of every pool or relayer balance in the path.

How should users read a quoted route?

Read the route as a sequence of dependencies, not just as a headline output number. Check which bridge is named, which destination token it delivers, whether a swap follows, and what minimum output the transaction enforces. The route response’s transaction request encodes the actions, while its estimate summarizes expected amounts and costs. If the quote permits destination calls, inspect whether the final swap or other call is included in the destination execution.

• Compare minimum output. Estimated output can move; the slippage bound is the more useful figure for judging what the submitted transaction permits.
• Inspect the path. Confirm whether tokens are swapped before or after the bridge and whether the destination asset is native, wrapped or a bridged representation.
• Account for all-chain costs. Include source and destination gas, bridge fees, swap fees and the effect of price impact.
• Refresh before signing. Pool reserves, gas prices, bridge availability and relayer quotes can change between quote and execution.

For most users, the better route is the one with acceptable minimum output and total cost that still has a clear, executable path—not necessarily the quote with the largest estimated amount or shortest stated time. When a route crosses several components, the weakest component sets the practical outcome: a deep destination pool cannot compensate for an unsupported bridge asset, and a fast bridge cannot rescue a swap whose slippage bound is too loose.