Execution is a primitive, not a product

Why order splitting belongs inside the pool.

The tax on being large

Every AMM charges you twice. Once in fees, which are posted and honest. Once in price impact, which is not a fee at all — it is the pool correctly repricing itself as you consume its liquidity. The second charge is invisible until you look at your fill, and it scales superlinearly with your size.

There is no clever routing around this. Split across three pools and you pay impact in three pools. The only real lever is time: liquidity replenishes, arbitrage pulls the price back toward the wider market, and the pool you drained ten seconds ago is not the pool you are hitting now. A trade spread across many blocks pays a fraction of the impact of the same trade compressed into one.

This is not a discovery. It is the reason TWAP and VWAP algorithms exist and have existed on every equity desk for four decades. What is strange is that onchain, in a system built specifically to remove intermediaries, the only way to get this is to hire one.

Two bad options

Today a large onchain order has two paths.

Send it. One swap, one block, full impact. Simple, trustless, expensive.

Hand it to a bot. An offchain agent holds your funds or an approval, and drips your order out over time. You now depend on a party that can go offline, that sees your full intent before the market does, and that has no obligation to you beyond its own reputation. You have reintroduced exactly the counterparty you came onchain to avoid — and you are paying it.

The second option is dominant not because anyone likes it, but because the pool has never offered the first-class alternative. Splitting an order has always been something done to the pool, from outside, by someone watching.

Putting the splitter inside

Uniswap v4 hooks change what a pool is allowed to know about itself. A hook runs inside the swap, in the same transaction, with the pool's own state. That is enough to hold a resting instruction and act on it.

SLICE is that instruction:

Fill this order in N pieces, no more than one piece per block.

You register the order once. It sits in the hook, in the pool, denominated in the pool's own tokens. Nothing leaves. No approval is handed to a third party. There is no offchain agent, because there is nothing left for one to do.

Who pushes the button

The obvious objection: a resting order needs something to move it. Blocks do not execute themselves, and a hook only runs when a swap runs.

SLICE does not solve this with a keeper. It solves it with the traffic that is already there.

Every swap that touches the pool carries one slice with it. The mechanism is in beforeSwap: if a pending order exists and the current block is past the last slice's block, the hook executes one slice against the pool's own liquidity, then lets the incoming swap proceed. The swapper's transaction did the work. In return, the swapper receives the fee accrued on that slice.

There is no signup, no whitelist, no bot to run. Any address that was going to swap anyway gets slightly better economics for having shown up. The order fills because a pool with liquidity worth trading against is a pool with a steady arrival of trades.

This is a piggyback pattern, and it is not novel — the same shape appears anywhere a protocol needs work done without a trusted operator. What is specific here is what gets piggybacked: not a treasury sweep or an oracle update, but somebody else's execution schedule.

What you actually get

Three properties fall out, and none of them require trusting anyone:

Custody never moves. Your tokens are in the pool contract, under a hook you can read, subject to a schedule you set at registration. No agent holds an approval.

The schedule is public and fixed. N slices, one per block maximum, cancellable by you. Nobody can accelerate it to front-run the rest of your order, because the rate limit is a contract condition, not a policy.

The work is unowned. If the party that built SLICE disappears, the order still fills, because the entity executing it is whoever swaps next.

What this does not fix

Honesty here is worth more than a fifth bullet point.

Each slice is visible. A resting order is public state. Anyone can read that a slice will execute on the next swap, and in which direction. On a chain with a public mempool this is a sandwich target, slice by slice. The impact per slice is small — that is the whole point of slicing — so the extractable value per slice is also small, but "small" is not "zero," and a determined searcher can sit on every slice of a large order. Slicing reduces impact and it also reduces the cost of predicting you. Anyone claiming otherwise has not thought about it.

No traffic, no fill. The order only advances when someone else swaps. In a deep, busy pool this is a non-issue. In a thin pool at 4am it means your 26-slice order may take considerably longer than 26 blocks, and there is no fallback keeper by design. The schedule is a ceiling on speed, not a floor.

The rebate has to be calibrated. Too small and there is no reason to prefer this pool. Too large and the hook is subsidising swaps out of the resting order's own execution quality, which is just a slower way of paying impact. The correct number is a function of pool volume and gas, and it should be derived from real flow, not chosen because it looks good in a launch post.

Slicing is not free money. Against a trending market, splitting an order means filling later at a worse price. TWAP is protection against your own impact, not against direction. A trader who is right about direction and slices anyway will underperform the trader who sent it.

Status

SLICE is pre-deployment. No contract is live, no address exists, and any address circulating that claims to be $SLICE is not.

The numbers used in the launch material — a −3.06% single-swap fill against a −0.42% sliced fill — are illustrative. They come from a curve, not a backtest. Before those numbers appear anywhere without the word "illustrative" next to them, they need to be simulated against the real liquidity profile of the target pool, and the simulation needs to be published alongside them.

What is true and checkable today: v4 hooks can hold state, can act in beforeSwap, and can execute against pool liquidity within the swap. Everything else is engineering that has not been audited yet.

SLICE — one order. many blocks.