How smart order routing finds a token swap path

Smart order routing selects how a requested trade should use available liquidity. It must find eligible paths, calculate their outputs for the actual amount and choose an allocation under its objective and execution constraints.

Start with a fully specified request

The route needs asset identities, a network, an amount and a trade mode. For exact input, the natural raw objective is to maximize output for the fixed spend. For exact output, it is to minimize required input for the target receipt. Additional costs and restrictions can change the final objective.

A token ticker and an indicative price are not enough. The optimizer needs the state and rules of the particular pools or offers it can use.

Discover feasible paths

A direct path exchanges A for B in one pool. A multi-hop path might use A-to-C and C-to-B. Several paths can receive portions of one order. Uniswap's router repository describes searching routes while considering splitting and gas costs.

Candidate discovery usually applies practical limits. An application may restrict venues, intermediary tokens, hop counts or the number of branches. Those choices define the search space; they are not merely display preferences.

Calculate at the requested size

AMM output is nonlinear, and dealer offers can have bounded size. A router cannot identify a good path by multiplying a tiny reference quote by the user's full amount. It needs the amount that each stage receives and the state changes caused by using it.

Shared pools require special care. Two branches cannot both assume they alone consume the same original reserves. An optimizer must model that dependence or exclude conflicting combinations.

Choose and encode

The selected plan becomes an executable transaction or a fulfillment proposal, with user-level amount conditions. The onchain component enforces the applicable rules when execution occurs; it does not necessarily redo the entire search.

Research on routing across constant-function market makers formalizes the optimization problem and shows how fixed execution costs change it. Practical services solve bounded versions using current information and engineering constraints.

“Best route” should therefore be read with its assumptions: best among the considered alternatives, under the chosen objective, at the observed state. That is a useful result, but it is narrower than a guarantee of the strongest possible outcome across every market at future execution time.