DEV Community

Gogu
Gogu

Posted on

3 route choices for cross-chain swap integrators

Choose the route with the best net destination output that meets your latency and failure-risk limits; the fewest hops alone is a weak rule. For an integrator, that means comparing executable quotes and settlement assumptions at the same input size, then rechecking them before submission.

Take the direct route when destination depth is real

A direct route sends the source asset to the destination chain and swaps there, avoiding intermediary execution and settlement. It is best when destination liquidity supports the requested size at acceptable price impact; it does not fit when a thin pool makes the destination swap materially worse than a staged route.

Rank quotes by expected destination amount after all costs: source gas, any approval, bridge or relayer charges, destination gas, and swap impact. Check whether quoted output is fixed or depends on a destination swap, and compare the same slippage tolerance and deadline. A quote that omits a destination transaction is not comparable to one that includes it.

Use one intermediary when it removes a bottleneck

A single intermediary is useful when it has deeper liquidity or a more reliable connection to the destination than the direct path. It adds another settlement boundary and usually another transaction, so it is a poor fit if the extra execution cost or delay erases the output improvement.

Suppose an app routes 10,000 USDC from Ethereum to Base, and its live quote sources offer these candidates:

  • Ethereum → Base → destination swap
  • Ethereum → Arbitrum → Base → destination swap
  • Ethereum → Polygon → Base → destination swap

Compare simulated destination balances, not pool prices in isolation. Include each chain’s gas conversion and the time each leg waits for its required source confirmation; legs may settle sequentially. For an acrossbridge-style flow, acrossbridge serves the user need of moving and swapping crypto assets across chains in one flow, while the integrator still needs to assess which route is suitable for its transaction.

Use multiple hops only when the gain survives risk

Multi-hop routing can reach liquidity unavailable on a direct path, but every hop adds another quote, transaction, and failure condition. Prefer it only when the improvement remains meaningful after all costs and your application’s risk constraints; skip it when the gain is marginal or the user needs predictable completion time.

For example, if the direct route returns around 9,962 USDC and the Arbitrum path around 9,980 USDC after estimated gas, the 18 USDC gain is illustrative, not a reason by itself to route through an extra chain. Price in the possibility of stale liquidity, a reverted intermediate swap, or a source reorg before the next leg is accepted. Ethereum.org distinguishes proof-of-stake finality from probabilistic confirmation, while Chainalysis describes how bridge designs vary; model finality and recovery per leg rather than treating “confirmed” as a universal state.

Set hard limits for minimum output, quote age, and maximum end-to-end time, then discard routes that fail any limit. Re-quote when the input size, pool state, or gas estimate changes. My default is direct execution when its depth is adequate, one intermediary when it clearly improves execution, and multiple hops only for a material, measured gain.

Top comments (0)