# Splitting a big trade usually does nothing

> Breaking an order into pieces only helps if the market refills between them. Sent back to back, it lands in exactly the same place.

- Source: https://defiloops.com/blog/splitting-a-big-trade-usually-does-nothing
- Published: 2026-06-30
- Category: Strategy
- Tags: trading, slippage, execution, swaps
- Author: DeFiLoops

---
"Split this into five and drip it in" is standard advice, and for a large order it is
sometimes right. The trouble is that it is right for one specific reason, and almost
nobody states the reason — so the advice gets applied where it does nothing except cost
more gas.

The reason is: **the market has to refill between your pieces.** That is the whole thing.
If it does not refill, three trades cost exactly what one would have.

## Two different things share the word

<Compare left="Across pools" right="Across time">
  <Fragment slot="left">
    One trade, several pools at once. Pools are independent, so their capacities add.

    You do not do anything — it is automatic.
  </Fragment>
  <Fragment slot="right">
    Several trades in one pool, minutes apart. Helps only because the market refills
    between them.

    This is a decision, and it is the one people mean.
  </Fragment>
</Compare>

The first one you get for free: any order with a price limit already spreads across every
pool that will take it at your price, measured at **94% more filled** than the best single
pool would have managed. Nothing below is about that.

## Back to back, splitting changes nothing at all

An automated market maker's price walk is path-independent. Buying X and then Y from a
given pool state lands at the same price, and hands you the same total, as buying X+Y in
one go.

Capping a 450,000 USDC offer at five basis points to produce a first piece:

<Spec rows={[
  ['450,000 in one trade', '186.745035 WETH — 6.08 bps of impact'],
  ['First piece, 370,343', '153.704969 WETH — 5.00 bps'],
  ['The remaining 79,657, quoted fresh', '33.075579 WETH — 1.51 bps'],
]} />

That last row only fetches 33.075579 if the pool has not moved. Sent immediately after the
first piece it fetches 33.040066, and the two pieces sum back to exactly the single trade.

You paid the same and used more gas.

## The per-piece numbers are flattering you

This is the trap, and it is a convincing one.

Look at what those pieces report: 5.00 and 1.51 basis points. Neither resembles 6.08. Split
into three and each piece might come back around 2, which makes it very tempting to
conclude the trade cost 2.

It did not. Impact is measured against the pool **as it is now**, and your previous piece
already moved it. Every piece after the first is quoting from a price your own trading
created.

<Callout type="danger" title="Impact does not add up">
  Three pieces at 2 bps each is not a 2 bps trade, and it is not a 6 bps trade either — it
  is whatever the pool actually gave you, which you can only see by comparing the total
  received against the single-trade quote. Per-piece impact always flatters a split, which
  is exactly why the technique feels like it works.
</Callout>

## When it genuinely helps

Splitting across time wins when real liquidity arrives between your pieces. That is a claim
about the market, not about arithmetic:

<Steps>
  <Step title="The pool is actively arbitraged">
    Someone else's flow pushes the price back toward the wider market between your trades.
    Then the second piece really is quoting from a refilled book.
  </Step>
  <Step title="You are large relative to the pool">
    Past roughly a tenth of a pool's depth you are no longer a price taker. Waiting is how
    you stop trading against yourself.
  </Step>
  <Step title="You can actually wait">
    Minutes, not seconds. If the strategy needs the position now, the refill argument does
    not apply and neither does the split.
  </Step>
</Steps>

If none of those is true, you are paying extra gas to watch a number look smaller.

## A figure that gets quoted for the wrong question

You will see "splitting is worth 3–10 basis points, and only above $1 million". That is a
real measurement and it answers a **fixed-size** question: same quantity, better average
price.

A bounded order asks a different question. You have fixed the price you will not cross, so
there are no basis points left to win — the prize is *quantity*, how much you can get done
at your price. Those are not the same optimisation, and the bps figure says nothing about
the second one.

<Callout type="note" title="Which question are you asking?">
  "Move this much, as cheaply as possible" and "get as much as possible without paying more
  than X" have different right answers. Decide which one you are doing before you decide
  how to slice it.
</Callout>

## What to do instead, most of the time

Set a price limit and let the order find every pool that will take it. That is the split
that is free, automatic, and measured.

Then, if the order is genuinely large relative to the venue and you can afford to wait,
split across time — and judge it by the total you received, never by the impact each piece
reported.