Most decentralised exchange volume does not arrive at the exchange. It arrives at an aggregator, which splits the trade across whichever pools produce the best result and sends it on. For anyone providing liquidity, how DEX aggregators choose a route decides whether the pool earns anything.
What an aggregator is actually solving
Given a token in and a token out, how DEX aggregators choose a route comes down to searching for the path that leaves the trader with the most. That path is frequently not one pool. It may be a split across several venues, or a multi-hop route through an intermediate asset, or both at once.
This is why a pool can hold real depth and still receive nothing. If a competing route is a fraction cheaper, it takes the whole trade. Routing is winner-take-most, not proportional.
The four things that decide how DEX aggregators choose a route
- Price impact at the requested size. The dominant factor, and the reason depth matters more than fee tier on large trades.
- Pool fee. Decisive between pools of similar depth, irrelevant between pools of very different depth.
- Gas cost of the path. A route across four pools may quote better and net worse once execution is paid for, which is why aggregators favour shorter paths on expensive chains.
- Whether the pool is indexed at all. Not a factor so much as a precondition. An unindexed pool is not considered.
Why the best quote is not always the best fill
A quote is a calculation against the pool state at quote time. Between then and inclusion, other trades land, and on a thin pool the difference between quoted and received can be substantial.
Routes that split across many pools are more exposed to this, because every leg can move independently. A slightly worse quote through a single deep pool often fills better than an optimal-looking split, which is the practical case for depth over cleverness.
How a pool gets included
Indexing is usually automatic once a pool clears a liquidity threshold and shows trade history, but two things are not automatic and both are commonly missed.
The first is token metadata. Name, symbol, decimals and logo come from token lists that aggregators read, and a token absent from them displays as a bare address in the routing interface. The second is the exchange itself: on a newer venue, the aggregator may not have integrated the exchange’s contracts at all, and no amount of pool depth changes that. Check whether other pools from the same exchange already appear before funding one.
What this means for a token launch
Concentrate liquidity rather than spreading it. Two shallow pools on two exchanges lose to one adequate pool on either, because the aggregator routes to the better one and the other earns nothing while still holding capital.
Pair against an asset that routes cleanly. A pair against a major stablecoin or the chain’s native asset is one hop from almost anything. An exotic pairing forces the aggregator into multi-hop paths, which raises cost on every trade and pushes flow toward whoever did the simpler thing.
The full sequence for getting listed, indexed and found is in our guide to listing a token on a DEX, and the pool sizing question is covered in low-slippage stablecoin pools.
What to check as a trader
Expand the route before confirming. A quote that beats every competitor usually does so by routing through something the others exclude, and that something is frequently a bridge or an unaudited venue.
Compare the amount received rather than the headline rate, since gas and bridge fees sit outside the quote. On a small trade a shorter, slightly worse route often nets more than an optimal one. The wider set of checks is in how to choose a reliable DEX.
Operating a pool once it is live
Deploying the pool is the short part. What decides whether it earns is a set of checks repeated after every change to the pair, the fee tier or the token itself, and each takes minutes once somebody owns them. Treat the pool as infrastructure with a maintainer rather than as a launch task that closes the week the liquidity lands.
Testing how DEX aggregators choose a route
Quote your own pair through the interfaces your users actually open, at the sizes they actually trade. A small quote and a large one frequently take different paths, and the size at which your pool stops being chosen is the number worth knowing. Do this from a clean session, since saved settings and a custom slippage figure change what the interface returns.
Expand the route on each quote and read the venues in it. If your pool appears at small sizes and disappears at larger ones, the pool is thin rather than excluded. If it never appears at any size while a competing pool on the same pair does, the problem is indexing or metadata, and adding depth will change nothing until that is fixed.
Repeat the test after anything changes: a new pool on the same pair, a fee tier switch, a token contract update, a bridged deployment elsewhere. Routing is a comparison against whatever else exists, so a pool that was chosen last month can stop being chosen without anyone touching it. A monthly quote check catches that while the liquidity can still be moved.
Understanding how DEX aggregators choose a route matters most where the answer disagrees with the interface your own site links to. Users arriving from your documentation trade through whatever that page embeds, so test the embedded widget as well, and check that the pair it defaults to is the pool you funded rather than one on a venue the project no longer uses.
Getting token metadata accepted
Token lists are read by aggregators and wallets, and a token missing from them shows as a bare address next to names a trader recognises. Verify the contract on the explorer, submit the logo through the explorer’s own process, and then check how the token renders inside the routing interface rather than assuming it inherited anything from the verification.
Each list has its own submission and its own criteria, and acceptance by one does not propagate to the others. Work through the lists that the interfaces your users open actually consume, and keep a record of which accepted the token and when. If a symbol or logo changes later, that record is what tells you where the update has to be repeated.
A token with a common symbol needs this work more than others, because the interface has to disambiguate and traders will pick wrongly. Publishing the canonical address prominently, in the documentation and in the community room, costs less than handling the support load that follows the first trader who buys a copy of your ticker and blames you.
Sizing and funding the pool
Size the pool against the trade you want to serve rather than against a total budget. Pick the largest trade that should execute without visible slippage, calculate the depth that requires, and fund to it. A pool sized from whatever was left after everything else usually lands below the point where routing starts choosing it, which wastes the entire amount.
Fund one pool properly before opening a second venue. Concentration is operational as much as it is about routing: two pools mean two positions to monitor and two places where a rebalance has to happen, while flow still goes to whichever quotes better and leaves the other holding capital that earns nothing for as long as it sits there.
Plan the exit before funding. Withdrawing a large position from a thin pool moves the price against you, so the size that can be removed without damage is part of what the position actually costs. Projects that treat pool capital as recoverable at will discover otherwise during the week they need it, which is usually the week everything else is already difficult.
Decide in advance what the pool is allowed to cost. A position in a volatile pair carries an inventory risk the fees may not cover, and that arithmetic belongs in the funding decision rather than in a write-up afterwards. Set the point at which the position gets reduced and who approves it, so the choice is not made by whoever happens to be awake during the move.
Reading the flow you actually receive
Measure trades that landed in your pool rather than quotes or total pair volume. Fees earned, the count of filled trades, the size distribution of those trades and the share of the pair they represent tell you where the pool sits in the routing order. A pool receiving only small trades is being used as the tail of splits.
Compare against the same pair elsewhere. If a competing pool takes the large trades consistently, the difference is depth, fee tier, path length or the venue itself, and each of those has a different fix. Checking monthly turns a vague sense that the pool is quiet into a decision about adding depth, changing the tier or withdrawing entirely.
Watch for flow that arrives only during incentives. Volume that appears when a rewards programme runs and stops the week it ends was never routed on price, and treating it as demand leads to a pool sized for traffic that has already left. The honest read of any pool is the volume it takes during the quiet weeks.
When routes stop reaching your pool
Work in order: confirm the pool still holds the depth you believe it does, quote the pair on an interface that previously routed to it, confirm the token metadata still resolves, then check whether a competing pool appeared. Most disappearances are competition rather than a technical fault, and the fix is a decision about capital rather than a support ticket.
If the exchange itself is the problem, the pool cannot be rescued where it sits. A venue that loses an integration, changes its contracts, drops the pair or stops being read by the interfaces your users open takes its pools out of routing regardless of depth. Check whether other pairs on the same exchange still appear before concluding that something specific to your token broke.
Gas conditions change routing without anything else changing. On an expensive chain a path through your pool that was competitive during a quiet hour gets dropped for a shorter one when costs rise, and it returns later without intervention. Judge routing across a period rather than on a single quote taken at an unusual moment on an unusual day.
Incentives, fee tiers and migrations
A fee tier change creates a new pool rather than editing the old one, so liquidity has to move and the original keeps whatever stays behind. Decide first whether the pair is fee sensitive at all, since between pools of very different depth the tier does not decide the route, and an unnecessary migration splits depth for as long as anyone leaves capital in the old pool.
When an exchange releases a new version, treat the migration as a scheduled operation with a date and an owner. Interfaces and aggregators move their support at their own pace, so quote the pair on both versions through the transition and move the remaining liquidity once the newer one is being routed to. Announcing ahead of the routing produces trades executed against the emptier pool.
Size liquidity incentives to reach the depth at which routing starts choosing the pool, rather than spreading them thinly to look generous. Below that point the rewards buy deposits that earn no fees and leave the week the programme ends, and the pool returns to exactly where it started with the budget already spent and nothing to show a treasury report.
Contracts and who does this work
Somebody has to own the pool the way somebody owns a server. Name them, give them the wallet access and the monitoring, and put the monthly checks in a calendar. The common failure is that the pool was funded by whoever ran the launch and nobody opened it again until a trader complained about slippage in the community room.
If a market maker or agency is involved, define the obligation in terms observable on chain: depth maintained at a stated size on a named pair and venue, plus the reporting that proves it. Arrangements written around effort rather than depth produce monthly commentary about market conditions, and the pool is exactly as thin at the end of the term as it was at the start.
Agree who holds the position and what happens when the agreement ends. Tokens lent for market making, the fee income, the reporting and the withdrawal schedule all need writing down while the relationship is good, because the conversation happens when it is not. The wallet holding the liquidity should be one the project controls without asking anyone.
Keep a record of every change made to the pool, with dates. Which tier, which venue, how much was added and when the incentives ran. Months later the only way to explain why fee income fell is to line those changes up against the flow, and reconstructing it from block explorers afterwards takes far longer than writing it down at the time.
What aggregators do not do
- Vet tokens. Inclusion in a route is not an endorsement and implies no review of the contract.
- Guarantee the quote. It is an estimate against pool state that changes before inclusion.
- Protect against front-running. Some offer private submission, most do not by default.
- Create liquidity. They find the best available route and cannot improve on what exists.
For projects, the practical consequence is that liquidity work and distribution work are the same project. Depth nobody can route to earns nothing, and a well-routed pool with no demand behind it earns very little either. How we run launch distribution across explorers and crypto media is on our crypto traffic acquisition page.