A TWAP order splits one large parent order into smaller child orders and releases them at regular intervals over a set window. The goal is an average fill close to the time-weighted average price of that window, instead of wherever a single market order would have pushed the book.

On an exchange app, TWAP is a convenience feature. For a fund moving size, it decides whether you pay the spread or pay the book. Kaiko’s 2026 data put Ethereum’s average depth within 1% of mid at roughly $2.1M to $3.2M. A $1M market order on an average book eats a third or more of that, and the fill price shows it.

This guide is written for fund desks: how TWAP works, when it beats a market order and when it loses, how to size one, why crypto needs it across venues, how to measure the result, and what happens to the fills afterwards.

Where Renesis fits

Renesis is a portfolio management and execution system for crypto funds. The execution side runs TWAP, ladder, sweep and smart order routing across connected exchanges for spot and perpetuals. Every child fill lands in the same reconciled book that produces P&L, NAV and LP reports, so execution quality and fund accounting are not two separate projects. The Arkangel case study shows what that looks like for a systematic fund trading spot and perps.

How a TWAP order works

Every TWAP starts with the same inputs: what to trade, how much, and over what window. The algorithm divides the size by the number of slices and the window by the same number. Buy 300 ETH over two hours in 24 slices and you get 12.5 ETH every five minutes.

Production implementations add a few controls on top of that schedule:

• Limit price. A ceiling for buys or a floor for sells. If the market moves through it, the TWAP pauses instead of chasing.

• Randomization. Slice sizes and timing vary around the schedule, so the footprint is harder for other traders to spot.

• Catch-up logic. If slices fail to fill, the algorithm trades a little more later to finish on time, still inside the limit price.

• Slice aggressiveness. Each child order can rest passively and earn the spread, or cross the spread to guarantee the fill.

• Venue selection. One exchange, or a router that picks the best venue for each slice.

A TWAP does not make liquidity appear. It gives the order book time to refill between your slices.

That is the whole mechanism. Everything else is choosing the parameters well.

When TWAP beats a market order, and when it loses

The trade-off is market impact against timing risk. Trading fast costs impact: you consume liquidity faster than it comes back. Trading slowly costs exposure: the price can drift away while you wait. TWAP picks a point on that curve and holds it.

It tends to win when:

• The order is large relative to the depth near mid on the venues you can reach.

• There is no information urgency. The trade is a rebalance, a subscription being deployed or a redemption being raised, not a reaction to news.

• The market is range-bound over the window.

• The asset is a mid-cap or long-tail token where one market order can move the price several percent.

It tends to lose when:

• The market trends against you during the window. A rigid schedule keeps buying into a rally.

• The trade is driven by information the market is about to price in. Speed beats stealth here.

• The schedule is naive. Fixed-size slices on a fixed clock are easy to detect.

There is a subtler weakness. Talos makes the point that expected market impact is inversely proportional to available liquidity, and a TWAP ignores the intraday liquidity curve. In crypto, volume shifts with time zones and weekends, so a pure clock schedule puts the same size into thin hours as into deep ones. That argues for windows that avoid known thin periods, and for routing across venues.

TWAP vs VWAP, POV and iceberg orders

TWAP is one of a small family of execution algorithms. They differ in what drives the schedule.

In equities, VWAP is the default institutional benchmark. In crypto its edge shrinks. Definitive argues that in 24/7 markets with volume spread across hundreds of venues, accurate VWAP is hard to implement and TWAP delivers most of the benefit with fewer data dependencies. Our guide to algorithmic trading in crypto covers the full set and how to choose between them.

Sizing a TWAP: a worked example

Say a fund needs to buy $3M of ETH to deploy a subscription, with no view on direction over the next few hours. Start from depth, not from the clock.

1. Measure depth on the venues you can reach. With depth within 1% of mid around $2.5M on a typical ETH book, a single $3M market order would consume more than all of it on one venue.

2. Cap each slice at a small share of that depth. A common rule of thumb is around 5% of the depth near mid. Here that is roughly $125K per slice.

3. Derive the slice count. $3M divided by $125K is 24 slices.

4. Set the interval from how fast the book refills. Five minutes between slices gives a two-hour window. Thinner books need longer gaps.

5. Add a limit price. For example 0.75% above the arrival price. If ETH rallies through it, the TWAP pauses and the desk decides whether to continue.

6. Randomize. Vary slice size and timing by around 20% either side of the schedule.

These numbers are illustrative. The right slice share depends on the asset, the venue and how much timing risk the fund can carry. The method holds: depth sets slice size, slice size sets the count, and refill speed sets the interval.

Why one venue is not enough

Crypto liquidity is fragmented across exchanges, and depth differs a lot between them. Kaiko data reported by CryptoSlate puts Bitcoin depth within 1% of mid at around $30M on Binance, $16M to $20M on Coinbase and $10M to $15M on other major venues.

A TWAP pinned to one exchange is capped by that exchange’s book. Routing each slice to wherever price plus fees is best lets the order draw on the combined depth of every connected venue, and it shrinks the footprint on any single one. That is the job of a smart order router.

Perpetuals add their own variables. Maker and taker fees differ by venue, funding accrues on open positions, and a hedge leg should move in step with the spot leg it offsets. Funds running basis or delta-neutral strategies usually run both legs as linked TWAPs so the hedge ratio holds during execution.

Fragmentation also changes measurement. Crypto has no consolidated tape, so the benchmark price has to be built from aggregated, fee-normalized data across venues.

Measuring a TWAP: arrival price and implementation shortfall

The honest benchmark is the arrival price: the mid price at the moment the decision was made. Slippage against arrival, in basis points, is the average fill minus the arrival price, divided by the arrival price, times 10,000 for a buy.

Implementation shortfall, the framework André Perold introduced in 1988, goes one step further. It adds fees and the opportunity cost of whatever did not fill. A worked example:

• Decision: buy 1,000 ETH. Arrival price $3,000, so the paper trade is $3,000,000.

• The TWAP fills 950 ETH at an average of $3,006. Execution cost: 950 × $6 = $5,700.

• ETH rallies through the $3,030 limit and the last 50 ETH are cancelled. Opportunity cost: 50 × $30 = $1,500.

• Fees of 2 bps on $2,855,700 traded: about $571.

Total shortfall is about $7,771, or 25.9 bps of the intended trade. Compare the fills with the window’s TWAP as well. If they beat the window TWAP but lost to arrival, the market moved during execution and the algorithm did its job. If they lost to both, look at slice size and venue choice. Our explainer on slippage in crypto breaks down the components.

After the fill: TWAP in P&L and NAV

The algorithm ends at the fill. The fund’s books start there. A 24-slice TWAP routed across three exchanges can produce a hundred or more fills, each with its own venue, fee and timestamp, and some in different quote currencies.

Each of those has to land correctly:

• Cost basis is the fee-inclusive, volume-weighted average across every fill, per venue and in aggregate.

• Positions must reconcile against each exchange’s balances, including partial fills and cancels.

• Perpetual legs start accruing funding the moment they open, which moves P&L before price does.

• Realized and unrealized P&L, and then NAV, depend on all of the above being right.

When fills reach the books through exports and a spreadsheet, NAV runs hours or days behind the trading. LPs increasingly ask for evidence of execution quality alongside performance, as our piece on what LPs look for in crypto fund reporting covers. Running execution and portfolio management on one system closes that gap. The method for turning reconciled positions into a fund NAV is in our guide to calculating NAV for a DeFi-native crypto fund.

Frequently asked questions

What is a TWAP order in crypto?

An execution algorithm that splits a large order into smaller orders sent at regular intervals over a set window, so the average fill price tracks the time-weighted average price of that window and market impact stays low.

Is TWAP better than VWAP for crypto?

Often, in practice. VWAP needs a reliable volume forecast, and crypto volume is spread across many venues and trades around the clock. TWAP is simpler and easier to verify. Where a good volume model exists, VWAP or an implementation shortfall algorithm can do better.

How long should a TWAP run?

Long enough that each slice is small relative to the depth near mid and the book can refill between slices, and short enough that timing risk stays within what the fund will accept. For liquid majors that is often minutes to a few hours. For long-tail tokens it can be a day or more.

Can a TWAP be front-run?

A naive one can. Fixed sizes on a fixed clock are visible to anyone watching the tape. Randomizing size and timing, routing across venues and using limit prices make the footprint much harder to exploit.