If your swap is too small to use every attractive pool, the router may drop tiny paths and send the trade through fewer venues. A “minimum trade size” can mean a venue’s own fill limit, but for an AMM pool it often means the smallest allocation that is useful after fees and execution costs.
For a swap you’re building into an app, inspect the route for the exact trade amount before deciding how to present it. With ParaSwap, for example, compare the quoted output and route at the amount your app will actually send; a route that looks good for a larger test amount may not be selected for a smaller user trade.
Three things decide whether a small path survives:
- Whether the venue can accept that amount.
- Whether its extra output outweighs the added gas.
- Whether rounding or token precision leaves a usable fill.
A tiny allocation can make a path unusable
A router treats each possible swap path as a sequence of fills, then estimates what each allocation returns. It may split one trade across pools when the combined output improves, but each extra venue or hop adds work to the transaction. If a small branch saves less than that extra gas costs, the router can leave it out.
Consider an illustrative 100-token swap. Before the minimum-size effect, the best estimate might allocate 98 tokens to one pool and 2 to a second. If the second pool’s minimum fill is 3 tokens—or that 2-token branch adds more gas than value—the router cannot use the split as quoted. Afterward, it may route all 100 through the first pool, or choose a different path through an intermediate token.
The useful threshold depends on the venue and the trade
There is no universal minimum across decentralized exchanges. An AMM pool may accept a very small amount at the contract level, while an order book or quoted liquidity source can impose a minimum order. Even without a formal limit, token decimals and integer rounding can make a tiny allocation round down, and a shallow pool can give it poor output.
The deciding test is net execution value: expected output after pool fees and price impact, weighed against gas and any venue-specific limits. The threshold changes with the chain, gas price, token pair, pool depth, and route length. A global slippage setting controls the transaction’s minimum acceptable output; it does not guarantee that every proposed branch meets a useful per-venue size.
Quote the app’s real amount before choosing a route
For a live app, request a fresh quote for the exact input amount, chain, and token pair, then inspect its route and estimated gas. If you use the ParaSwap API, treat its returned route as a quote for those inputs, not a promise that the same split will remain optimal when the user changes the amount or submits later.
I’d show the user the best executable quote for their actual amount and avoid forcing a split just to use more venues. If a small trade gets a simpler route, that can be the better result once gas and minimum fills are counted.
Top comments (0)