Uniswap
Uniswap routing links direct and multihop pool paths for token swaps.
Uniswap routing compares direct and multihop paths through liquidity pools, then proposes the path that gives the strongest effective outcome for the requested token swap. A direct route uses one pool. A multihop route passes through one or more intermediate tokens when that sequence can improve output enough to justify extra pool fees and network cost. The router may also divide an order across paths when pooled liquidity makes a split more efficient. Before approval, inspect the input and output token identities, selected network, quoted output, minimum output, route, pool fees, price impact, and network cost. Uncertainty about any of those fields is a reason to stop before signing.
Updated ·A reversible stop before approval
Route readiness begins with the selected assets, amount, and network. Token symbols alone are insufficient because unrelated contracts can use the same name or ticker. The intended input balance must be available in the connected wallet. A classic pool transaction also requires the network’s fee asset. An eligible UniswapX order can be signed without a network fee once any required onchain approval is complete.
A quote is still reversible. Compare the proposed pool path with the requested exchange, then check whether its quoted output and minimum output remain acceptable after fees and price impact. An unexpected intermediate token, a changed recipient, or an unfamiliar contract deserves investigation before authorization. The route cannot move funds merely because it appears on screen, and declining the wallet request leaves the proposed swap unexecuted.
From quote to recorded swap
Quote formation starts with current pool states and the requested amount. The routing search evaluates direct pools, intermediate paths, and eligible split paths, then estimates the network work required to execute each candidate.
Approval state is separate from route selection. If the executing contract lacks sufficient permission to spend the input token, the wallet may first request an approval. That authorization does not itself exchange the token.
A classic multihop swap normally executes atomically. Output from one pool becomes input to the next pool inside the same transaction, without requiring the wallet to handle each intermediate token as a separate action.
The signed request fixes the route instructions for that classic pool transaction. Pool state may change while the request awaits execution, but the network does not substitute a different path. If the encoded limits cannot be met, the transaction can revert instead.
For a classic pool route, a successful transaction receipt and the resulting output balance confirm completion. A pending wallet display is not final settlement. Checking the recipient, output-token contract, and recorded amount separates a completed route from a delayed interface update.
When does a multihop route beat a direct pool?
A multihop route wins when its intermediate pools improve the exchange enough to outweigh every added pool fee and the extra network cost. A deep pair of linked pools may offer less price impact than a shallow direct pool, while a small swap may favor the shorter path. The default router evaluates price, liquidity, and network cost when selecting among eligible paths. The preferred route can therefore change when the amount, pool state, or cost estimate changes.
Output, fees, and network cost
Route quality is measured by the complete quoted outcome, not by hop count alone. More pools create more opportunities to find useful liquidity, but each execution step has a cost.
Expected output and minimum output
Expected output reflects the pool states used for the quote. For an exact-input swap, minimum output is the execution boundary derived from the selected slippage tolerance. Price impact describes movement caused by the trade itself, while slippage covers adverse movement between quoting and execution. These values answer different questions and should be read separately.
Costs created by the path
Pool fees and network cost affect the route in different ways.
Pool fees
Each added hop executes another pool swap, so that pool’s fee and price movement affect the amount passed onward. A higher-fee pool can still contribute to a better path when its available liquidity produces a stronger net quote.
Network cost
Network cost pays for transaction execution rather than pool liquidity. Extra hops or split paths may require more computation, so the router estimates whether their output improvement justifies that work. The estimate can change before submission as network conditions move.
Route parameters and control points
Route settings divide control between the swapper and the routing system. The swapper defines the desired exchange and execution tolerance, while the router searches within the eligible liquidity and configured complexity limits.
| Route parameter | Control point |
|---|---|
| Selected assets and amount | The swapper chooses the input asset, output asset, and amount. |
| Candidate pool set | Default routing searches eligible liquidity; trade options can narrow the permitted versions. |
| Maximum hops | The active routing configuration limits the length of candidate conversion paths. |
| Maximum splits | The active routing configuration limits how many parallel allocations are considered. |
| Slippage tolerance | The selected tolerance defines the execution limit for the quoted swap. |
Restricting the pool set does not preserve the previous quote. It triggers a smaller search space that may return less output, a different path, or no viable route. Every settings change therefore calls for a fresh comparison before signing.
What happens when the chosen route becomes invalid?
An invalid route needs a fresh quote before signature; after submission, an unmet execution limit causes the classic pool swap to revert. Simulation can catch many failures, but it cannot freeze liquidity or network conditions.
Before signature
A pool update may remove the advantage that justified an intermediate hop. The smallest reversible response is to return to the quote and let the router search again with the same intended assets and amount. If the replacement remains unacceptable, changing the amount or waiting preserves control without granting a broader token allowance.
After submission
Atomic execution rolls back the pool exchanges when a required hop fails or minimum output cannot be delivered. The reverted transaction can still consume the network’s fee asset because the network processed it. Before retrying, confirm the failure status, preserve enough fee balance, and request new transaction data. If the receipt shows success, inspect the output balance before sending any duplicate swap.
Split paths and version boundaries
Split routing sends portions of one requested swap through different paths when the combined effective outcome is stronger. Eligible liquidity may come from Uniswap v2, v3, or v4 pools, whose liquidity placement, fees, and pool behavior can differ. Some default trades may instead use UniswapX, where third-party fillers compete to execute an order. For an eligible UniswapX swap, the wallet signs an order that fillers compete to execute; a classic pool route instead asks the wallet to submit the swap transaction. Verify a filled order or successful transaction, as applicable, and then check the output balance.
Helpful answers about Uniswap routing
Does each pool hop need its own token approval?
No. A multihop route normally needs spending permission for the input token, not a separate approval for every intermediate token. The executing contract passes intermediate output into the next pool within the same transaction. An existing allowance may remove the need for a new approval, while a missing or insufficient allowance can require separate authorization. The precise prompt depends on the wallet, interface, and allowance method.
Are intermediate tokens left in my wallet after a multihop swap?
No, not during a normally completed classic route. Intermediate tokens pass between pools inside the transaction, while the designated output token goes to the specified recipient. They should not appear as separate wallet holdings merely because the path used them. If execution reverts, the pool exchanges also revert, so those intended intermediate movements do not settle as independent transfers.
Can a multihop route bridge assets between networks?
A classic multihop pool route stays on one network. Its intermediate tokens connect liquidity pools within that network rather than acting as bridge assets. A crosschain swap is a separate flow that combines bridging with swap routing where supported. Check the source and destination networks shown in the transaction flow because same-network routing and crosschain execution have different costs, timing, and completion evidence.
Why might a higher-fee pool appear in the selected path?
A pool’s fee is only one part of the effective outcome. A pool with more usable liquidity near the required price may create less price impact than a lower-fee alternative. The router compares the combined output of the complete path and its estimated network cost, so a higher-fee hop can remain worthwhile. The decision can reverse when the swap amount or pool state changes.
Which token behaviors can disrupt a routed quote?
Transfer charges, rebasing behavior, or other nonstandard token mechanics can break assumptions used to quote and execute a route. Compatibility may differ by protocol version, pool, and transaction method. A quote or token symbol does not prove that every transfer behavior is supported. If simulation fails or the interface shows a token warning, stop before approval rather than repeatedly submitting the same route.