DEX split routes: compare net quotes

A DEX aggregator can split one swap across several liquidity paths to improve the amount received. Compare the complete executable route after pool fees, separate charges and network costs, using the same input and recent state. More paths help only when their additional output exceeds their additional costs. Quotes that reuse a pool cannot be treated as independent offers.

This comparison concerns an exact-input swap on one chain, with the sender paying gas. Cross-chain transfers, sponsored execution and auction-based orders need their own cost and settlement models. The numerical pools, prices and gas estimates below are hypothetical.

Distinguish a split from an extra hop

A split allocates portions of the input to different paths. A 70/30 split of 100 X sends 70 X along one path and 30 X along another. A hop is a conversion within a path: X to Z to Y has two hops, even if no input is split. One plan can combine both structures.

Extra paths can access liquidity without pushing the entire trade through one pool. Extra hops can reach a useful intermediate market. Both can add execution work, and neither guarantees a better result.

Coverage also limits the search. In its Pathfinder routing explanation, 1inch says it compares rates, liquidity, price impact and gas across supported sources. It also explains why an existing pool may be unavailable because its execution behavior is unsupported. A selected route therefore reflects a provider's supported market and search rules; it does not establish a universal optimum across every pool on-chain.

Keep the complete path visible when comparing providers. Two branches with different names might ultimately touch the same pool. Conversely, two pools from the same protocol can be independent liquidity sources.

Define what the output figure includes

Define comparable net Y as the Y delivered, less separately paid costs converted into Y.

This is an economic comparison, not a claim that the wallet literally receives that net token amount. If gas is paid in ETH, the recipient can receive the full quoted Y while the sender separately spends ETH. Converting that charge to Y requires a named, timestamped exchange rate.

For each provider, determine whether its displayed output already reflects pool trading fees, its own charge and any integrator fee. Do not subtract embedded charges again. The route's price impact is also part of its simulated output; it is not another invoice to add after calculating that output.

Separate a price preview from transaction-ready instructions. The 0x Swap API guide distinguishes its indicative price request from its firm quote step. Its example responses expose fields including block number, buy amount, minimum buy amount, fees, route fills and network-fee information. Those fields provide useful comparison evidence, but their meaning belongs to that API version. A firm quote label does not freeze subsequent chain state.

Work through two independent pools

Suppose the instruction sells exactly 100 X for Y. Both synthetic pools start with a reserve ratio of 100 Y per X before trading fees, but they have different sizes and fees.

Assume ordinary tokens, constant-product pricing, fees retained in pool reserves, no other trading charges and no intervening transactions. For each pool, calculate effective input as a = input × (1 − fee). Multiply the Y reserve by a, then divide by the sum of the X reserve and a to obtain output.

This generalizes the fee-adjusted reserve calculation in the Uniswap v2 library. That implementation uses a fixed 0.30% fee; B's 0.05% fee here is a synthetic assumption, not another Uniswap v2 fee tier. These calculations use continuous token units; an actual contract rounds in token base units.

All 100 X through A produces 9,871.580344 Y. All 100 X through B produces 9,672.736657 Y: B's lower fee cannot compensate for its smaller reserves at this size.

Now test one candidate split, without claiming it is the optimal allocation. Sending 70 X to A produces 6,930.631125 Y; sending 30 X to B produces 2,968.826578 Y. Because these are independent pools, their outputs sum to 9,899.457704 Y.

For a network-cost comparison, assume Ethereum layer 1, an estimated effective gas price of 20 gwei, ETH valued at $3,000 and Y valued at $1. Assume either single-pool plan uses 120,000 gas and the split plan uses 220,000 gas. These are invented estimates, not measured router costs.

Ethereum's gas documentation defines the execution charge from gas used and the price per gas unit, with one gwei equal to one-billionth of an ETH. Applying that relationship to the estimates gives 0.0024 ETH for a single route and 0.0044 ETH for the split.

The split adds 27.877360 Y of pool output and 6 Y of estimated gas cost, improving comparable net output by 21.877360 Y. Calculate before rounding; the table displays two decimals.

Pool fees have already reduced these output figures. For example, the split's input fees total 0.225 X: 0.21 X in A and 0.015 X in B. Subtracting their value from the table again would count them twice.

The ranking depends on gas. Under the same pool state and conversion assumptions, each extra gwei costs the split another 0.3 Y relative to A: 100,000 additional gas multiplied by one-billionth ETH and $3,000 per ETH. Its 27.877360 Y output advantage disappears at approximately 92.9245 gwei. At 100 gwei, A's net is 9,835.58 Y and the split's is 9,833.46 Y, so A leads by about 2.12 Y.

That threshold is a sensitivity calculation. It is not a current gas forecast or a rule for another route. Approval transactions, rollup fee components, different ETH/Y conversions and changed pool state would alter the comparison.

Reusing a pool invalidates independent addition

Suppose two paths use different first hops but both end at the same Z/Y pool. Each final leg expects to sell 50 Z. Independently quoting both against the initial reserves overstates what the combined plan can receive because the first swap changes the pool before the second.

Consider another hypothetical constant-product pool with 1,000 Z, 100,000 Y and a 0.30% input fee. A standalone quote for 50 Z gives 4,748.297376 Y. Adding two such fresh-state quotes suggests 9,496.594752 Y.

In sequential execution, the first leg leaves 1,050 Z and 95,251.702624 Y in the pool. The second 50 Z then produces 4,317.222690 Y. The actual modeled total is 9,065.520066 Y, about 431.07 Y below the independently added figure. The full input, including the retained fee, enters the reserve update.

This is why the inspected Uniswap smart-order-router route-combination code excludes pool reuse across its candidate splits: it explains that reuse would invalidate the separate quotes. That is one implementation's solution. Another routing system could model sequential interactions or construct a combined leg. Its final transaction must still account for the shared state.

For concentrated-liquidity pools, substitute the correct tick-aware simulation for this simple reserve formula. The explanation of positions moving out of range helps identify why deposited liquidity may cease to participate at the relevant price. A path label or a total liquidity figure cannot replace an execution model.

Align quote age, costs and authorization

A route comparison needs a common observation window. Record the quote's block reference where supplied, retrieval time and intended broadcast time. Comparing a fresh single route with a split route saved before an approval transaction mixes different market states.

Uniswap's API freshness guidance recommends refreshing quotes more than 30 seconds old before broadcasting. It also states that simulation does not guarantee on-chain success because conditions can change before inclusion. That interval is provider guidance, not a universal safe lifetime for every pair.

After approval or a long signing delay, refresh the complete plan and its gas estimate. Review the absolute minimum output again. Expected net output ranks candidates; the signed output floor defines what deterioration the transaction may accept. Gas paid separately is not automatically covered by a token-output minimum.

The deadline and slippage comparison explains those independent authorization bounds. A longer deadline cannot make an old ranking current, and wider tolerance can allow an execution that loses the split's estimated advantage.

Also avoid using reported venue volume as a shortcut for executable liquidity. The volume checks for possible wash trading explain the evidence limits of that figure. Route evaluation needs the actual supported pools and quantities available to the proposed instruction.

Keep one row per complete executable plan

Use this worksheet before treating a higher quote as preferable:

An unsupported token transfer rule, missing allowance or incompatible pool hook can make an attractive path unusable. Resolve those conditions from the actual transaction evidence instead of assuming a higher gas budget fixes them. If an included attempt reverts, add its actual charge to the trading intention's ledger before evaluating a retry; the failed-swap gas worksheet covers that reconciliation.

After execution, preserve the transaction result, recipient token amount and actual network charge. Keep the estimate and the receipt as separate observations so execution drift remains visible. The useful comparison is one complete, current plan against another, with every separately paid cost explained and every shared pool represented only through a consistent state simulation.