Why split routes cannot treat a shared pool as independent

Split routes are not independent when they use the same pool. The first use changes the state available to the next use. Adding separately calculated branch outputs can therefore overstate the combined result.

A shared final hop

Imagine two hypothetical branches: A-to-C-to-B and A-to-D-to-C-to-B. Both finish through the same C/B pool. Quoting each branch alone against the original C/B reserves assumes exclusive access to that state.

Executing both together requires accounting for their combined C flow or their ordered uses. The C/B pool cannot supply two separate first-trade outcomes from one set of reserves.

A small numerical illustration

Assume a fee-free C/B pool initially contains 1,000 of each token. A standalone 100 C swap would receive about 90.909 B. Adding that quote twice suggests 181.818 B.

But 200 C passing through that one pool produces only about 166.667 B under the same constant-product assumptions. The higher sum belongs to two independent untouched pools, not one shared pool.

The arithmetic is hypothetical. Uniswap's reserve-pricing documentation supplies the model, and network-routing research treats market interactions within one combined optimization.

How an optimizer can handle it

A router can explicitly model the shared state, merge compatible flow through the common operation, or avoid combining overlapping candidates. Different implementations make different tradeoffs.

The overlap can be difficult to see in a simplified interface. Two branches bearing different upstream venue names may still converge on the same final pool. Pool identity, not merely protocol branding, determines whether the reserve is shared.

When reviewing a route calculation, check whether every quoted branch assumes a mutually compatible state. This is a correctness issue in the plan's accounting, separate from whether splitting would be economically useful if all branches were independent.