A DeFi router helps determine how one token can be exchanged for another through available onchain liquidity. The route might use one pool, pass through an intermediate token, or divide an order among several paths. Its purpose is to turn a request such as “exchange this amount of token A for token B” into an executable plan with defined costs and limits.

Understanding that plan is useful even if you never write a smart contract. Two swap screens can show different results for the same pair because they search different liquidity, apply different fees, or estimate execution differently. DeFiRouter.com is an independent educational resource. The explanations and examples here do not provide executable quotes or operate an exchange.

First, separate the routing engine from the router contract

People use “router” for two related components. A routing engine searches candidate paths and estimates their outcomes. It may run in an application, a software library, or an API service. A router contract receives transaction instructions and coordinates the specified actions on a blockchain. A route can be calculated without moving funds; executing it requires the appropriate authorization and transaction.

This distinction explains why a beautiful quote screen is only part of the process. The displayed plan must become valid transaction data, target the correct contracts, and satisfy its execution conditions. The wallet authorizes a transaction or signed order; the blockchain or settlement mechanism determines what actually happens. A calculated route is neither a reservation of every pool balance nor evidence of a completed swap.

For a concrete implementation, Uniswap’s routing guide shows how a routing library constructs multi-pool swap paths and supplies parameters for execution. That guide documents its particular SDK and version, rather than a universal interface that every provider must follow.

What information defines a routing request?

A useful request identifies a network, an input asset, an output asset, and an amount. Token symbols alone are inadequate identifiers: different contracts can share a symbol. Network context also matters because an asset represented on one chain is not automatically spendable on another.

The request must also establish which side is fixed. An exact-input swap specifies how much of the starting token to spend and estimates the output. An exact-output swap specifies the desired receipt and estimates the required input. Reading a quote correctly starts with knowing which of those two questions it answers.

  • Asset identity: the network and verified contract address, or the provider’s documented native-asset representation.
  • Trade size: the amount in the token’s correct units, with the intended input or output fixed.
  • Execution context: the relevant wallet, recipient, permitted sources, and other supported restrictions.
  • Protection settings: the acceptable output floor or input ceiling and any expiry conditions.

These inputs describe a particular request. A quote for a smaller amount, a different recipient, or another network is not a substitute. Our routing overview introduces the vocabulary used to read these choices.

Three shapes a route can take

A direct path

A direct path exchanges A for B in a pool that contains both assets. It is straightforward to inspect and may require fewer operations. However, directness says nothing by itself about available depth. A shallow direct pool can produce less output than a longer path with sufficient liquidity.

A path with an intermediate token

A multi-hop path exchanges A for C and then C for B. The intermediate token connects markets that may have better combined execution than the direct pair. The route must account for both steps, including their fees and the way the first step’s output becomes the second step’s input. An extra hop is useful only if the complete result justifies it.

A split path

A split route sends portions of the input through different paths and combines their outputs. Splitting can avoid pushing one pool too far along its pricing curve. It also adds work and may raise execution costs. The number of branches is therefore not a quality score: a well-chosen single path can be more economical than an elaborate split.

A hypothetical route comparison

Suppose an educational simulator compares two paths for 1,000 units of token A. Path One estimates 980 units of token B and network costs equivalent to 2 B. Path Two estimates 986 B and costs equivalent to 9 B. Ignore every other charge for this hypothetical exercise.

On those assumptions, the estimated economic result is 978 B for Path One and 977 B for Path Two. Path Two has the higher displayed token output, but Path One has the higher result after the modeled network cost. This does not mean the wallet literally receives 978 B: it might receive 980 B while paying gas separately in the network’s native asset.

The distinction matters when reading a label such as “net output.” Determine whether it means the token amount transferred to you, an economic estimate after converting gas into that token, or an amount after selected platform fees. A comparable result needs the same cost boundaries on both sides. See our swap-cost guide for a fuller accounting framework.

Expected output and minimum output answer different questions

Expected output describes the estimated result under the quote’s assumptions. Minimum output defines a lower execution limit when that protection is supported and correctly encoded. In a hypothetical exact-input quote of 100 B with a 0.5% tolerance, a simple percentage calculation produces a minimum of 99.5 B before token-unit rounding and provider-specific rules.

That tolerance is not a service fee automatically removed from every swap. Nor does it repair an unattractive starting quote. A route that already has substantial price impact can remain unattractive even with a small tolerance. Price impact concerns how the trade interacts with available liquidity; slippage concerns differences between the quoted and executed result.

Execution conditions can cause a transaction to revert instead of accepting an outcome outside its bounds. Reverted onchain transactions can still incur network costs. Some advanced routers support explicitly permitted partial failures, so the actual transaction semantics deserve attention rather than a blanket assumption that every command always succeeds or fails together.

Why the route can change before execution

Between requesting a quote and submitting a transaction, other users may trade, liquidity providers may change positions, and fee estimates may change. A wallet approval can add another interval before the swap itself. Refreshing a stale quote is therefore a separate action from merely repainting the same old number on screen.

Consider a hypothetical quote reviewed at lunchtime and signed much later. The issue is not whether its arithmetic was correct when generated. The issue is whether its assumptions still match the available state and the user’s intent. An interface should make a meaningful change visible and allow another review.

Route availability is another independent question. If an application cannot find a usable path, an empty result is more informative than a made-up estimate. Check whether the pair, amount, network, or allowed sources explain the result. Reducing the amount changes the request; it does not establish that the original amount could have executed under the smaller quote’s terms.

Read permissions alongside the price

For many ERC-20 workflows, a spender needs an allowance to transfer the input tokens. Approving that allowance and executing the swap are distinct authorizations, even when an interface presents them as one journey. Review the token, spender, amount, and network whenever approval is requested.

A routing result does not certify that an unfamiliar token is legitimate or that every component is free of vulnerabilities. Operational review should include the website address, the transaction destination, the recipient, and the permissions being granted. Our security guide explains those checks without requiring a wallet connection.

Use the route to ask better questions

A useful route explanation lets you identify the assets, follow the path, understand the costs, and locate the execution limits. You should also be able to tell whether the operation stays on one network. Moving value between chains introduces additional settlement steps that a same-chain path description does not cover.

Before interpreting any result as preferable, ask what was compared, which costs were included, how recent the quote is, and what authorization execution requires. Those questions turn routing from a mysterious percentage into an inspectable process. The goal is to understand the transaction you are considering, including the conditions under which the estimate may stop applying.