Skip to content

Routing and Aggregation

Canonical

Purpose

Routing determines how a swap is executed across available liquidity. Better routing can reduce price impact or improve output, but it does not guarantee best possible execution.

Concepts

Routes may be direct, multi-hop, split across multiple pools if supported, or supplied by an aggregator. Route scores may consider output, fees, price impact, gas, risk, or other parameters.

Flow

  1. Input and output tokens are selected.
  2. Available pools are identified.
  3. Token and pool statuses are checked.
  4. Candidate routes are generated.
  5. Output, fees, gas, and price impact are estimated.
  6. Risk flags are added.
  7. Selected route is displayed.
  8. User confirms the swap.
  9. Transaction executes or fails.

Route Record

A route record should include route identifier, input token, output token, hops, pools, expected output, fees, price impact, gas estimate if available, risk flags, aggregator used if any, and status.

Aggregation Considerations

External aggregators add dependency risk. The best output may not be the best risk-adjusted route. Gas cost can reduce effective output. Route results can change before execution. Aggregation must not hide token or pool warnings.

Risk Considerations

Routing is subject to liquidity, fees, chain conditions, token availability, pool safety, external aggregators, and execution timing.

Route Failure Model

A route request contains input and output assets, amount, network, slippage limit, deadline, and permitted sources. A routing component may compare direct, multi-hop, or external quotes when implemented. Missing liquidity, stale data, unsupported assets, excessive price impact, provider failure, or policy blocks must return no executable route. No aggregator or router is claimed active.

Released as living documentation for the Axodus ecosystem.