How a DEX aggregator finds and splits a route

From finding pools to the transaction you sign: how an aggregator prices pools, searches paths, splits an order and checks the result, with real numbers.

A DEX aggregator has one job: turn the token you have into the token you want, in a single transaction, for as much output as the market allows after costs. It does not hold liquidity. It reads other people's pools and decides how to use them.

That decision has more moving parts than it seems. This post walks through them in order, from finding pools to the transaction you sign, with a small worked example and a real route from BNB Chain.

Step 1: find the pools that matter

BNB Chain has a very large number of pools across dozens of DEXes. No router can price all of them for every request in a fraction of a second, so the first job is narrowing the field.

The pools that matter for most trades fall into a few groups:

• The pair itself, on every DEX and fee tier where it exists.
• Hub pairs. Liquidity concentrates around a few tokens such as WBNB, USDT, USDC, BTCB and ETH. A trade between two minor tokens usually travels through at least one of them.
• Bridge tokens. Some tokens trade mostly against something other than a hub, for example a project's own ecosystem token. Recent transfers show which ones.

Tirio's public list of the venues it routes through, from classic and concentrated-liquidity pools to on-chain market makers and launchpad curves, is at /bsc/protocols.

Step 2: price each pool exactly

Each pool family has its own math, and a router has to reproduce it to the last unit.

• Constant-product pools follow x × y = k. The Uniswap V2 library computes the output with integers as amountIn × 997 × reserveOut ÷ (reserveIn × 1000 + amountIn × 997) for a 0.3 % fee. PancakeSwap V2 uses 9975 and 10000 for its 0.25 % fee.
• Concentrated-liquidity pools (Uniswap V3 and V4, PancakeSwap V3 and Infinity) only behave like x × y = k between two initialised ticks. A large trade has to be walked tick by tick. Our post on concentrated liquidity explains why.
• Venues without a public formula, such as on-chain market makers, some hooked pools and launchpad curves, are priced by asking the venue on chain at several sizes and interpolating between the answers.

Getting this exactly right matters because the transaction you sign carries a minimum output. A model that is slightly optimistic produces quotes that fail.

Step 3: search for paths

With the pools priced, the router searches for paths: sequences of swaps that start with your token and end with the one you want. BNB to USDT can go direct, or through BTCB, or through ETH and BTCB, and so on.

The number of possible paths explodes with each extra hop, so routers limit the length and prune aggressively. Tirio looks at paths of up to four swaps by default, keeps only the most promising amounts reaching each intermediate token, never visits the same token twice, and ranks candidates by output minus gas.

Step 4: split the order

Here is where an aggregator earns its keep. Instead of putting your whole order through the single best path, it can divide it.

A small worked example. Two constant-product pools quote the same price, 770 USDT per BNB, with a 0.25 % fee. Pool A holds 1,000 BNB and 770,000 USDT. Pool B holds 400 BNB and 308,000 USDT. You sell 50 BNB.

Route	You receive
All 50 BNB into pool A	36,579 USDT
All 50 BNB into pool B	34,146 USDT
35.7 BNB into A, 14.3 BNB into B	37,083 USDT

The split pays about 503 USDT more, 1.4 %, than the best single pool. The reason is price impact: every BNB you sell into a pool makes the next one worth less. The best split is reached when one more unit would earn the same in either pool. Here that happens at about 716 USDT per extra BNB in both. Because both pools started at the same price, the best split simply follows their depth, about 5 to 2.

Real routers rarely solve this exactly. A common approach is to cut the order into chunks and hand each chunk to whichever path pays most for it at that moment. With ten chunks of 5 BNB, that greedy method ends up at 35 and 15 BNB and 37,081 USDT, within about 1 USDT of the best split. Tirio uses a chunked allocation of this kind and refines it afterwards.

Gas decides whether a split is worth it

Each extra pool costs gas. On BNB Chain the gas price is currently 0.05 gwei, so an extra pool of roughly 120,000 gas costs well under a cent at a BNB price around $770. That is why splits make sense here at sizes where they would not on more expensive chains. For a small trade in a deep pair, though, the best answer is often a single pool, and a good router returns exactly that. Our post on reading a quote shows a 1 BNB trade where splitting gained only 0.06 USDT.

A real route

Here is what a large order looked like on 2026-10-01. We asked Tirio's API for an indicative price for selling 2,000 BNB for USDT. At block 125,105,134 it returned a route with a price impact of 0.44 %:

A few things stand out. The largest share did not go straight to USDT. It went through BTCB, because the router found that the two PancakeSwap V3 pools on that path paid more for that part of the order than the direct pools would have. An on-chain market maker took 15 %. And the last 8.8 % was spread over seven small paths through ETH, USDC, BUSD and BTCB, each one worth adding because it paid more than its gas.

Step 5: settle in exact integers

A route on paper uses idealised amounts. On chain, every intermediate amount is an integer, and every pool rounds in its own favour. Before returning a quote, a careful router re-quotes each leg with the exact amounts the contract will see. In Tirio's case the first hop pulls fixed amounts, intermediate tokens are shared out by proportion, and the last pool on each token takes whatever remains, so nothing is left behind.

Step 6: simulate before you sign

Even exact math can be wrong about the world: a pool's state changes, a hook behaves differently for a router than for a quoter, a token has a tax nobody detected. The only reliable check is to run the real transaction against the latest block without sending it.

Tirio does this for every quote you sign. The complete transaction is simulated, the simulated output and gas replace the estimates, and if the route fails, its pools are dropped and the order is routed again. The fast price you see while you type is routed the same way but not simulated, which is why the quote you review can differ slightly.

Step 7: one atomic transaction

The result is a single transaction from your wallet. Every hop, split and wrap runs inside it, and the contract checks the amount that actually reached you against your minimum received. If it falls short, everything reverts and you pay only gas. There is no half-filled state.

What a router cannot do for you

• It cannot stop the market from moving between your signature and the block that includes it. That is what slippage tolerance is for. See price impact vs slippage.
• It cannot make a thin pool deep. Splitting reduces price impact. It does not remove it.
• It cannot fix a bad token. Taxes, blacklists and paused contracts break routes. See our token checklist.

The overview in our docs describes Tirio's routing in more technical detail, and the API returns each path with its share and every hop with its pool, fee and amounts, so you can inspect any route yourself.