# Two half-orders beat one whole order: splitting, with the arithmetic

> Canonical: https://blazephoenix.xyz/learn/why-splitting-wins
> License: CC BY 4.0 (attribution + link) · © 2026 BlazePhoenix
> Updated: 2026-08-13

Because impact d/(x+d) shrinks faster than the order when you halve it, fifty into each of two identical 1,000-token pools returns 95.2381 against 90.9091 for all hundred into one — 4.76% more output from arithmetic alone, with nobody worse off. But make the pools unequal and a naive even split loses money (89.0454 versus 90.6611); splitting is an allocation problem, not a habit, and the split must be proportional to depth.

Take the fraction from the sizing article: the value you give up to price impact is d / (x + d), where d is your order and x is the pool's reserve of the token you are paying with.

Now notice something odd about it. Halve d and the loss does not halve — it falls by slightly more than half, because the denominator shrinks too. That small asymmetry is the entire reason splitting an order across pools returns more, and it is arithmetic rather than cleverness.

## The clean case: two identical pools

Two pools, each holding 1,000 of A and 1,000 of B. You are trading 100 A. Ignore fees for now so the effect is visible on its own.

Everything into one pool: your loss is 100 / 1,100 = 9.0909%, so you receive 100 - 9.0909 = 90.9091 B.

Fifty into each pool: each half loses 50 / 1,050 = 4.7619%, so each returns 50 - 2.3810 = 47.6190, and the two together give 95.2381 B.

```
one pool of 1000       ->  90.9091 B
two pools of 1000      ->  95.2381 B
                           -------
difference                  4.3290 B  (+4.76%)
```

You did not find a better price, negotiate anything, or take any additional risk. You stopped pushing one pool twice as far as necessary. The 4.3290 tokens are the difference between one 9.09% loss and two 4.76% losses, and 9.0909 - 4.7619 = 4.3290 exactly.

Turn the fee back on and the same thing happens, slightly damped: 99,700 / 1,099.7 = 90.6611 into one pool, against 2 x (49,850 / 1,049.85) = 2 x 47.4830 = 94.9660 across two. The gain is 4.3049 tokens, or 4.75% more output for the same input.

## The general shape

Split an order into n equal pieces across n identical pools and each piece loses (d/n) / (x + d/n) instead of d / (x + d). The loss per piece falls faster than the number of pieces grows, so the total loss falls.

That property has a name — convexity — and it is what a splitting router is exploiting. Note carefully what it is not. It is not an arbitrage, it is not a discount negotiated from anyone, and no one is worse off for it. The pools each receive a smaller order, and a smaller order is exactly what they price better.

It is also why the benefit is largest for the trades that need it most. On a small order the impact is tiny in the first place and splitting saves a tiny fraction of a tiny number. On an order that is a meaningful share of the pool, splitting is often the largest single improvement available to you.

## The case where splitting loses money

Now make the pools unequal, because in reality they always are. Pool A holds 1,000 of each token. Pool B holds 250 of each — a quarter of the depth. Fee back on at 0.3%, and you are still trading 100.

First, the two extremes. All 100 into A returns 99,700 / 1,099.7 = 90.6611. All 100 into B returns 24,925 / 349.7 = 71.2754, which is far worse, exactly as the fraction predicts: 100 into a reserve of 250 is a huge order.

Now split it naively, half and half:

```
into A (50):  49850 / 1049.85  = 47.4830
into B (50):  12462.5 / 299.85 = 41.5624
                                 -------
total                             89.0454

all into A                        90.6611  <- better
```

An even split returned 89.0454, which is 1.6157 tokens worse than not splitting at all. Splitting is not a good thing that you do more of. It is an allocation, and a wrong allocation is worse than none, because it pushes part of your order into the pool least able to absorb it.

## The rule that fixes it

Send each pool a share of the order proportional to its depth. Pool A holds 1,000 against Pool B's 250, a ratio of 4 to 1, so send 80 to A and 20 to B:

```
into A (80):  79760 / 1079.76 = 73.8683
into B (20):  4985 / 269.94   = 18.4671
                                 -------
total                             92.3354

all into A                        90.6611
gain                               1.6743  (+1.85%)
```

Check that 80/20 is really the best of them rather than a convenient number, by testing on either side of it. At 75/25 the total is 69.5727 + 22.6653 = 92.2380. At 85/15 it is 78.1244 + 14.1109 = 92.2353. Both are below 92.3354, so the proportional split sits on the peak.

The intuition is that at the optimum, the next token you add would cost the same amount of impact whichever pool you put it in. If one pool is cheaper at the margin, you should be sending it more; when neither is, you have finished. Proportional allocation is what that condition works out to for pools on the same curve with the same fee.

## Why this is hard to do honestly

Every number above assumed you know the real depth of each pool. That assumption is precisely what an attacker attacks.

A pool can be made to advertise a wonderful price while holding almost nothing, and a splitter that ranks candidates by advertised price will happily route a share of your order into it — where the fraction d / (x + d) then does its work against you, because x is nearly zero.

The defence used here is to anchor on capital rather than on claims. Candidate prices are judged against a centre derived from the pools that actually hold the most tokens, and a candidate whose price sits outside a band of 400 basis points — 4% — around that centre is not treated as credible. A median of the candidates is used only as a fallback, precisely because a median can be voted on by many worthless pools, whereas real balances cannot be faked without real money.

Name the limit here too: this filter rejects the implausible, and it is not a proof of best execution. It cannot tell you that a better price existed on a venue nobody routed to.

## Why not split into twenty pieces

The arithmetic above keeps improving with more pieces, so why stop? Because each additional leg is additional work the chain must be paid to perform, and that cost is charged in the network's own token regardless of whether the extra leg helped.

Past some point the extra output no longer covers the extra work, and the honest plan is the one that stops there. This article deliberately gives you no figure for that crossover, because a gas number is not reproducible without stating the chain, the block, the build and the storage state — and an unreproducible number is worth nothing to a reader trying to check us.

**Verify it yourself:** Quote your full size, then quote half your size and double the result. If the doubled half-quote is larger, the pair benefits from splitting and a split plan should show more than one leg. Compare that against the plan the quote returns.

Related: https://blazephoenix.xyz/learn/sizing-your-trade · https://blazephoenix.xyz/learn/split-routing-convexity · https://blazephoenix.xyz/learn/capital-anchored-split · https://blazephoenix.xyz/learn/phantom-liquidity-for-beginners · https://blazephoenix.xyz/learn/three-prices
