> ## Documentation Index
> Fetch the complete documentation index at: https://docs.defiloops.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Does splitting cost less?
> Breaking a large trade into slices, when it saves real money, when it only looks like it, and what the per-slice numbers hide
Breaking a 450,000 USDC buy into three pieces: cheaper, or the same?
Both answers are correct, and the difference between them is one thing:
**whether the market comes back between your trades.** Nothing else about the
arithmetic changes.
Measured on a Base fork at block 50,807,337 unless a figure names its own block.
All three sizes below were priced against that single snapshot, through
`POST /v1/quotes`, because pricing them with separate calls answers a subtly
different question: each call lands on whatever block it lands on, and the rows
then differ for reasons that are not size.
## Two different things are called splitting
| | across **pools** | across **time** |
| ------------- | ---------------------------------------------- | ---------------------------------------- |
| what it is | one trade, several pools at once | several trades, one pool, minutes apart |
| named by | `allowSplit`, `splitAmountIn` | nothing: it is how you choose to execute |
| helps because | pools are independent, so their capacities add | the market refills between your trades |
| covered in | [Bounded execution](/routing) | this page |
They share a word and nothing else. The first is a property of one moment; the
second is a decision about several.
**The first one is automatic here.** Every limit route DeFiLoops sends asks for
it, so a limit fill already spreads across every pool that will take it at your
rate: measured at 94% more filled than the best single pool. Nothing on this
page is needed to get that. What follows is only about the second kind: whether
to break your order up over TIME.
## Back to back, splitting changes nothing
Send the second slice immediately and you gain nothing, because an AMM's price
walk is **path-independent**: buying X then Y from a given pool state lands at
the same place, and hands you the same total, as buying X+Y in one go.
Measured at blocks 50,807,283 and 50,807,284, capping a 450,000 USDC offer at
5 bps to produce the first slice:
| | |
| -------------------------------------- | ------------------------- |
| 450,000 in one trade | 186.745035 WETH, 6.08 bps |
| first slice, 370,343 | 153.704969 WETH, 5.00 bps |
| the remaining 79,657, **quoted fresh** | 33.075579 WETH, 1.51 bps |
The remaining 79,657 can only fetch 33.075579 if the pool has not moved. Sent
straight after the first slice it fetches what the whole trade implies:
33.040066, and the two slices sum back to exactly the single trade. You paid
the same and used more gas.
## The per-slice numbers flatter the split
Look at what those slices **report**: 5.00 bps and 1.51 bps. Neither resembles
6.08.
Split into three and each slice may come back at around 2 bps, which makes it
very tempting to conclude the trade cost 2 bps. It did not. Impact is measured
against the pool **as it is now**, and the previous slice already moved it,
so every slice after the first is quoting from a price your own trading created.
**Impact is not additive, and per-slice impact always flatters a split.** Three
slices reporting 2 bps each is not a 2 bps trade. Compare against what the whole
size costs in one go; that is the only figure that prices the thing you actually
want to own.
## With recovery, splitting is the point
Now the case that works: pay the impact on a slice, **wait for the pool to
return**, and pay it again from a restored price. Each slice is quoted from an
unmoved pool, so each is genuinely cheap.
Every row below is from block 50,807,337:
| slices | each slice | reported impact | total received |
| ------ | ------------ | --------------- | --------------- |
| 1 | 450,000 USDC | 6.08 bps | 186.745035 WETH |
| 2 | 225,000 USDC | 3.04 bps | 186.801916 WETH |
| 3 | 150,000 USDC | 2.84 bps | 186.827100 WETH |
| slices | gain over one trade |
| ------ | ---------------------------------------- |
| 2 | 0.056881 WETH: **3.05 bps** of the trade |
| 3 | 0.082066 WETH: **4.39 bps** of the trade |
At roughly 2,410 USDC per WETH that is about **198 dollars** on a 450,000 dollar
trade, for waiting.
**The gain is front-loaded.** Going from one trade to two captures 3.05 of the
4.39 basis points available: about seventy percent of it. The third slice adds
1.34, and a fourth would add less again. Each extra slice buys a smaller
improvement and costs another transaction, another wait, and another window in
which the market can move against you.
Why the saving is so large here: this pair costs 2.84 bps at 150,000 and 3.04 at
225,000 (almost flat) and then 6.08 at 450,000. The curve is steeply convex
past a point, which is what concentrated liquidity looks like when a trade
leaves the band the liquidity is posted in. Splitting pays best exactly where a
trade is about to run off the end of its depth, and pays almost nothing when the
whole size fits comfortably inside it.
## What "the pool recovers" actually is
It is not the pool healing itself.
Your buy pushed the pool off the wider market's price. An **arbitrageur** now
sells into it until the two agree again, and keeps the difference. The price
comes back because somebody was paid to bring it back. That is genuinely useful
to you (your next slice starts from a restored price) but it is a third party
being compensated for undoing your push, not liquidity appearing from nowhere.
The slower mechanism is **liquidity re-posting**: your trade consumed depth in a
particular range, and LPs may add more there. That happens on its own schedule
and cannot be relied on within minutes.
Neither is guaranteed, and both are outside your control. That is the honest
shape of it: the cap sizes your slice, and the market decides whether the slice
was worth taking separately.
## What you give up
**Impact risk becomes timing risk.** While you wait for slice two the market can
move against you, and a 30 bps trend costs far more than the 4 bps of impact you
avoided. Splitting does not reduce risk; it exchanges one kind for another.
Which one you would rather hold is the actual decision. The arithmetic above only
tells you what the impact side is worth.
## The system already expresses this
Fill what clears at my price, wait, fill more when the market returns; that is a
**resting limit order with `partial` true**. It fires per bite, taking what the
book allows at your rate and waiting rather than chasing.
That is worth knowing because it means you do not have to hand-split and
hand-time: state the price and let the order take what the market offers, when
it offers it.
Evidence for the converse, from our own end-to-end tests: on a fork where nobody
else trades, a partial order's bites decayed 21.72, then 2.22, then 2.02 WETH.
Each slice got a worse deal at the same limit because nothing restored the price,
and the harness had to sell WETH back between bites to make further fills
possible at all.
With no recovery, splitting gains nothing. The whole benefit lives in the time
between the trades, and it is not yours to create.
## Choosing
| situation | do this |
| ------------------------------------- | ----------------------------------------------------------- |
| needs to be filled now | one trade: splitting costs the same and burns more gas |
| can spread over minutes or hours | split, and size the slices with `maxImpactBps` or `costBps` |
| the size fits inside the pool's depth | do not bother: the curve is flat there |
| the size runs past the depth | split; this is where it pays most |
| you have a price in mind | a resting order with `partial`, and let it bite |
## Related topics
- [Slippage is not impact](/slippage.md)
- [Bounded execution](/routing.md)
- [Running it without you](/automation.md)
- [DeFiLoops](/index.md)
- [Every tool](/tools/reference.md)