SLICE a hook I'm building. not finished. block —

execution, sliced.  →  kept the plain one:

one order.many blocks.

A Uniswap v4 hook that splits your order inside the pool, one slice per block, with nothing running off-chain to push it along.

26 slicesone per block, maximumthe next swap carries yours
NOT DEPLOYED contract: none chain: you: if a $SLICE contract exists today, it isn't mine.
01 — WHY

A fee is posted. Impact isn't. You pay it for being big, and for being in a hurry.

Only one of those is necessary. Splitting an order over time is the oldest trick on any trading desk, and onchain the only way to get it is to hire someone: an off-chain bot holding an approval, dripping your order out, watching your full intent before the market does.

That's a strange thing to need in a system built to remove exactly that person.

So: put the splitting in the pool. A v4 hook runs inside the swap, with the pool's own state. That's enough to hold a resting instruction and act on it. You register once, nothing leaves, and there's no agent to trust because there's nothing left for one to do.

02 — HOW A FILL HAPPENS
  1. You register once

    Amount and slice count go into the hook. Your tokens stay in the pool contract, under a schedule you set at registration.

  2. Somebody else swaps

    Any swap on the pool runs beforeSwap. If a slice is due and the block has moved on, the hook executes exactly one, then lets their swap through.

  3. They keep the fee on it

    The swapper who carried your slice collects the fee accrued on it. That's the entire incentive. No keeper network, no whitelist, no bot to keep alive.

    What this means if you're the one swapping →

    This is the part people argue with, and fairly. It's a piggyback pattern — the same shape as any protocol that needs work done without a trusted operator. Nothing here is new except what's being piggybacked.

  4. Until it's done, or you cancel

    One slice per block, maximum. Nobody can accelerate it to get in front of the rest of your order, because the rate limit is a contract condition rather than somebody's policy.

03 — SCRATCHPAD

This is the sheet I keep open while working on it. Constant product, fees stripped out of both sides so the comparison is impact only. Drag things until it stops agreeing with me.

one swap
sliced
difference
saved on this order
verdict
04 — REGISTER

The wallet, the chain reads, the block feed and the encoding are all live. The send is not, because there's nothing at the other end yet.

walletnot connected
account
chain
native
token
balance
allowance
registerOrder(bytes32,bool,uint256,uint16)0x4ce2d438
connect a wallet to build the calldata
05 — OPEN QUESTIONS

Kept public because I'd rather be told now than after an audit.

Every slice is public state. What stops a searcher sitting on all of them?

Partly answered: small impact means small extraction per slice, so the per-slice prize is thin. But thin isn't zero, and slicing reduces both my impact and the cost of predicting me. No clean answer yet.

What happens in a pool with no traffic?

The order stalls. Slices ride other people's swaps, so 26 slices can take far longer than 26 blocks, and by design there is no fallback keeper. The schedule is a ceiling on speed, not a floor. I think that's the right trade. I'm not certain.

What's the right rebate?

Too small and nobody routes here. Too large and the resting order is quietly paying for its own execution quality. This number has to come out of real pool volume, and I don't have that data yet.

Is a fixed one-slice-per-block cadence even right?

It's legible and it's easy to reason about, which is most of why it's there. Volume-weighted would probably fill better and would definitely be harder to verify by reading the contract.

06 — LOG
  • Wrote the front end before the contract. Which is the wrong order and I know it. It does mean the ABI here is a guess, and it will change.
  • Killed the 3D hero. Built a WebGL version of the curve. It looked expensive and said less than the flat bar does. Deleted.
  • Relabelled every number as illustrative. The −3.06% / −0.42% pair comes from a curve, not a backtest. It stays labelled until it's simulated against a real pool's liquidity profile and the simulation is published next to it.
  • Found the video is wrong. The grid clip shows four orders filling in parallel on one pool. The queue is FIFO — they fill one after another. Noted in the docs until one of the two is fixed.
  • Added the drift slider after someone pushed back. The first version of the scratchpad only ever showed slicing winning. That was flattering and useless.
SLICE — one order. many blocks. docs writing pre-deployment no token sale. no allowlist. nothing to mint.