# TWAP order: how slicing works, API fields and tested code

URL: https://fincodelabs.com/en/blog/twap-order · Publisher: Fincode (Fincode Yazılım ve Teknoloji A.Ş.), Istanbul, Turkey · Category: Exchange APIs · Published: 2026-11-06 · Updated: 2026-11-06

TWAP order explained: how a parent order is sliced, TWAP vs VWAP, native API fields on five venues, what happens on failure, and a tested Python slicer.

**Short answer:** A **TWAP order** (time-weighted average price) splits one large parent order into smaller child orders sent at regular intervals over a chosen period. TWAP describes the schedule, not a promised price, and the average fill can differ from the market's TWAP. As read on 5 November 2026, Binance, Coinbase, Hyperliquid, Kraken and OKX document native TWAP API orders, and what they do when a slice fails differs.

In this guide TWAP means an execution method: a parent order, a set of slices and a schedule. In DeFi the same letters usually name an on-chain oracle price, which is a different thing.

Venue facts come from official pages read on 5 November 2026, as examples, not recommendations. Nothing here says what, when or how much to trade, which duration to use, or claims that slicing gets a better price. Automated trading can lose money.

## What is a TWAP order?

A TWAP order is a parent order divided into child orders of roughly equal size, sent at regular intervals until the quantity is done or the time runs out.

> **Hypothetical example.** 100 units over 60 minutes with 5-minute spacing is 12 slices. With a lot step of 0.001, 100 / 12 rounds down to 8.333, and 12 x 8.333 = 99.996, so the remaining 0.004 goes on the last slice, which becomes 8.337.

Venue minimums can refuse a small slice, so a schedule may need fewer slices than the clock suggests. Jitter is a small random shift in time or size; Hyperliquid and Bybit document a randomize option of up to ±20% on slice size. The [TWAP calculator](https://fincodelabs.com/en/tools/twap-calculator) builds such a schedule.

## The TWAP benchmark vs the average price you get

The market's TWAP is an average of prices sampled at equal time steps, your average is total paid divided by total quantity, and the two differ even when nothing goes wrong.

```
market TWAP   = (p1 + p2 + ... + pn) / n
your average  = sum(fill qty x fill price) / sum(fill qty)
```

- **Sampling.** Twelve slices see twelve moments, not the whole hour. In the synthetic run below, every slice fills with no costs modeled and the average still sits 3.7 basis points (bp) below the market TWAP.
- **Partial fills.** They reweight the average toward whichever periods filled.
- **Costs.** Fees and spread sit outside the benchmark.

Measuring it from your own fills is [transaction cost analysis](https://fincodelabs.com/en/blog/transaction-cost-analysis).

## TWAP vs VWAP

TWAP paces an order by the clock, while VWAP paces it by expected market volume.

**TWAP and VWAP as execution methods**

|   | TWAP | VWAP |
| --- | --- | --- |
| What sets slice size | Time: equal quantity per interval | Forecast volume: more when the market is expected to be busy |
| Extra data needed | None | A historical volume curve |
| Benchmark | Mean of prices at equal time steps | sum(price x volume) / sum(volume) |
| How it drifts | Equal slices become a large share of thin periods | The day's volume differs from the forecast |

On [Kraken's public one-minute candles](https://docs.kraken.com/api-reference/market-data/get-ohlc-data) for XBT/USD, over the 10 hours to 20:00 UTC on 5 November 2026, hourly TWAP (mean of minute closes) and VWAP differed by a median 2.81 bp and at most 27.17 bp. That is one day and one pair. VWAP depth is in [execution algorithms](https://fincodelabs.com/en/blog/execution-algorithms).

## Native TWAP order APIs: fields and failure behavior

Native TWAP orders hand slicing to the venue, so failure behavior matters most.

**Official pages read 5 November 2026 (alphabetical, not a ranking)**

| Venue and request | Limits | Price limit | Failure, as documented |
| --- | --- | --- | --- |
| **Binance USD-M:** `POST /sapi/v1/algo/futures/newOrderTwap` | 300 to 86,400 seconds; above 1,000 USDT, maximum 5 to 50 million by symbol; `quantity * 60 / duration` above `minQty`; 30 open; UID weight 3000 | `limitPrice` optional, market if absent | `success: true` does not guarantee execution; failed balance or position checks end as `expired`; its [help page](https://www.binance.com/en/support/faq/80655cc54d8a4b2bb8ea097001844fd1) (30 January 2026) says one order failing margin requirements ends the whole TWAP |
| **Binance Spot:** `POST /sapi/v1/algo/spot/newOrderTwap` | 300 to 86,400 seconds; maximum notional 200k, 2mm or 10mm by symbol; 20 open; UID weight 3000 | Same | [Algo Orders FAQ](https://www.binance.com/en/support/faq/detail/91d7e7d0633846adb0ef9020037cc391) (30 March 2026), not the API page: pauses beyond the limit price; can expire or end partly filled on a short balance |
| **Coinbase Advanced Trade:** `twap_limit_gtd` with `number_buckets`, `bucket_size`, `bucket_duration` | No values on the page; failure reasons include `BUCKET_SIZE_SMALLER_THAN_BASE_MIN` | `limit_price` | Create Order says canceled at `end_time`, while the [user channel](https://docs.cdp.coinbase.com/api-reference/advanced-trade-api/websocket/user) reports `EXPIRED`; no rule for a failed bucket on these pages |
| **Hyperliquid:** `twapOrder` with `a`, `b`, `s`, `r`, `m`, `t` | 5 minutes to 7 days; $100 minimum; suborders as often as every 30 seconds | Max/min price on the order types page; no such field in the API action shown | 3% maximum slippage per suborder; underfilled size is caught up at up to 3 times normal, and the order may not finish |
| **Kraken Spot:** `POST /private/AddStrategy`, added 27 October 2026 | At least 60 seconds; start and end within 30 days | `price` when `ordertype=limit`; children are IOC limit orders either way | Shortfall moves to later children; short funds leave it open with `reason: insufficientFunds`; `expired` if the window closes first, with fills kept |
| **OKX:** `POST /api/v5/trade/order-algo`, `ordType=twap`, with `szLimit`, `timeInterval` | 20 pending; minimum `minSz` x 2; maximum `maxTwapSz` | `pxLimit` required | [Help page](https://www.okx.com/en-us/help/xiii-time-weighted-average-price-twap) (5 August 2026): slices follow IOC rules and the order suspends beyond the limit price; states include `order_failed` and `partially_failed`; `failCode` covers stop, trailing and trigger orders only |

Two pairs of documents conflict. Binance's Spot API page allows 300 to 86,400 seconds, while its FAQ says 1 minute to 3 days. OKX's cancel endpoint covers unfilled algo orders, yet the comment in its Python sample excludes TWAP orders. Neither could be tested without a real key; the request shapes above come from the documents only. Stop calls: `DELETE /sapi/v1/algo/futures/order` (and spot), `twapCancel`, `CancelStrategy`.

Help pages without placement fields:

- **Bitget Futures** (10 December 2025): if any individual order fails, the whole TWAP stops, and each order must be worth at least 10 USDT.
- **Bybit** (29 September 2026): 5 minutes to 24 hours, one order every 5 to 120 seconds, and insufficient balance ends the run.
- **KuCoin Futures** (31 December 2025): child orders are Market IOC or Limit GTT, and full execution is not guaranteed.

## How to build a TWAP slicer in Python

A slicer needs rounding, a schedule, a request budget, a stop path and a final reconciliation, and all of it can be tested without a venue.

```python
import math, random
from decimal import Decimal as D

def build_slices(total, seconds, every, lot, min_notional, ref_px, jitter=0.2, seed=7):
    n = max(seconds // every, 1)
    while n > 1 and total / n // lot * lot * ref_px < min_notional:
        n -= 1
    size, gap, rng = total / n // lot * lot, seconds / n, random.Random(seed)
    if total % lot or size * ref_px < min_notional:
        raise ValueError("off the lot step or below the minimum")
    plan = [[(i + rng.uniform(0, jitter)) * gap, size] for i in range(n)]
    plan[-1][1] += total - size * n
    return plan

def path(t):
    return D(str(round(100 + 0.4 * math.sin(t / 500) + t / 4000, 4)))

class FakeVenue:                                # synthetic, no keys
    def __init__(self, trouble):
        self.trouble, self.fills, self.calls = trouble, {}, 0
    def send(self, cid, qty, t):                # immediate-or-cancel child order
        self.calls += 1
        event = self.trouble.get(cid)
        if event == "reject":
            return None
        filled = (qty * D("0.6")).quantize(D("0.001")) if event == "partial" else qty
        self.fills[cid] = (filled, path(t))
        if event == "timeout":
            raise TimeoutError(cid)             # filled, but the reply was lost
        return self.fills[cid]
    def lookup(self, cid):
        self.calls += 1
        return self.fills.get(cid)
    def cancel_open(self):
        self.calls += 1

def run(plan, venue, limit_px, budget=(5, 60), stop_at=1e9, max_rejects=2, catch_up=3):
    due, done, rejects, sent, local, end = D(0), D(0), 0, [], {}, "schedule ended"
    for i, (t, qty) in enumerate(plan):
        due += qty
        if t >= stop_at:
            venue.cancel_open()
            end = "operator stop"
            break
        spent = sum(s > t - budget[1] for s in sent) >= budget[0]
        if spent or path(t) > limit_px:         # a buy: skip above the limit
            continue
        sent.append(t)
        cid = f"parent1-{i:04d}"
        try:
            fill = venue.send(cid, min(due - done, plan[0][1] * catch_up), t)
        except TimeoutError:
            fill = venue.lookup(cid)            # look it up, never resend blind
        if fill is None:
            rejects += 1
            if rejects > max_rejects:
                end = "too many rejects"
                break
            continue
        local[cid] = fill
        done += fill[0]
    return local, end

plan = build_slices(D(100), 3600, 300, D("0.001"), D(50), D(100))
print("slices", len(plan), "first", plan[0][1], "last", plan[-1][1])
print("after minimums", len(build_slices(D(1), 3600, 60, D("0.001"), D(5), D(100))), "of 60")
print(f"market TWAP {sum(path(s) for s in range(0, 3600, 60)) / 60:.4f}")

TROUBLE = {"parent1-0002": "partial", "parent1-0004": "timeout", "parent1-0007": "reject"}
REJECTS = {f"parent1-{i:04d}": "reject" for i in range(3)}
for name, trouble, kw in [("normal", {}, {"limit_px": 102}),
                          ("trouble", TROUBLE, {"limit_px": D("100.90")}),
                          ("stop", {}, {"limit_px": 102, "stop_at": 1800}),
                          ("budget", {}, {"limit_px": 102, "budget": (1, 900)}),
                          ("rejects", REJECTS, {"limit_px": 102})]:
    venue = FakeVenue(trouble)
    local, end = run(plan, venue, **kw)
    qty = sum(q for q, _ in local.values())
    avg = f"{sum(q * p for q, p in local.values()) / qty:.4f}" if qty else "none"
    match = sum(q for q, _ in venue.fills.values()) == qty
    print(f"{name:8}{qty:>8} avg {avg} calls {venue.calls:>2} reconciled {match}: {end}")
```

Output, from Python 3.11 on 5 November 2026, all synthetic:

```
slices 12 first 8.333 last 8.337
after minimums 20 of 60
market TWAP 100.4616
normal   100.000 avg 100.4246 calls 12 reconciled True: schedule ended
trouble   91.663 avg 100.3817 calls 12 reconciled True: schedule ended
stop      49.998 avg 100.4109 calls  7 reconciled True: operator stop
budget    83.330 avg 100.5169 calls  4 reconciled True: schedule ended
rejects        0 avg none calls  3 reconciled True: too many rejects
```

- **Trouble.** The partial fill and the rejected slice roll into later slices, and the lost reply is found by client order ID, not resent. The last slice breaches the price limit, so 8.337 stays unfilled.
- **Budget.** At one request per 15 minutes, slices merge up to the 3-times cap, and 16.67 is left.

A lower average in a failing run is not a better outcome, because the unfilled quantity is not costed here. These figures describe the code, not any market.

## What should happen when a slice fails?

Write the answer down before the first slice, because the schedule alone cannot decide it.

**Decisions in the code above**

| Event | What it does, and why |
| --- | --- |
| Rejected slice | Keeps the quantity due and stops after a set number of rejects |
| Partial fill | Keeps the rest due, capped per slice, so catch-up cannot become one large order |
| Lost reply | Queries by [client order ID](https://fincodelabs.com/en/blog/client-order-id) first, because a blind resend can double the fill |
| Price limit breached | Skips the slice |
| Operator stop | Cancels anything working, then reconciles: a child can still fill, and [Kraken's cancel page](https://docs.kraken.com/api-reference/algo-trading/cancel-strategy) says those fills are kept |
| End of window | Reports what is left, because a final market sweep would be a different order |

State must be rebuilt from the venue's fills after a restart, as in [crypto order management system](https://fincodelabs.com/en/blog/crypto-order-management-system) and [position reconciliation](https://fincodelabs.com/en/blog/position-reconciliation); Kraken says its child fills cannot yet be linked to a `strategy_id`. The request budget must be shared across every parent order on the key or address, as [Binance API rate limit](https://fincodelabs.com/en/blog/binance-api-rate-limit) shows.

## Who may work orders, and what slicing must not be

Slicing your own order under your own rules is software; working other people's orders is a regulated service in many jurisdictions.

In the EU, MiCA lists execution of orders and reception and transmission of orders on behalf of clients as crypto-asset services (Article 3(1)(16)(e) and (g)). This is not legal advice, and rules depend on your jurisdiction and each platform's terms.

Slicing must never be used for wash trading, spoofing or other market abuse. MiCA Article 91(3)(b)(ii) counts as manipulation placing or canceling orders so that genuine orders are harder to identify, where this is likely to mislead or set an artificial price.

For readers in Turkey: Article 99/A of Capital Markets Law No. 6362 treats activity by foreign crypto-asset platforms directed at Turkish residents as unauthorized. The Capital Markets Board (SPK) says being on its [operating list](https://spk.gov.tr/kurumlar/kripto-varlik-hizmet-saglayicilar/faaliyette-bulunanlar-listesi) does not mean authorization.

Fincode builds software that follows rules the customer has written, on the customer's own account, and does not work client orders or recommend sizes, durations or venues. For integration work in general, see Fincode's [exchange API integration](https://fincodelabs.com/en/services/exchange-api-integration) page; naming a venue here does not mean Fincode integrates it or has built on it.

## Frequently asked questions

### What does TWAP mean?

Time-weighted average price. As an order type it splits one order into equal pieces over time; as a benchmark it is the average of prices sampled at equal time steps.

### Does Binance have a TWAP order API?

Yes, under Algo Trading: newOrderTwap for futures and for spot, as read on 5 November 2026. Availability depends on your jurisdiction and the platform's terms.

### Does Coinbase have a TWAP order?

Advanced Trade documents twap_limit_gtd inside order_configuration, with start and end times, a limit price and bucket fields, but states no numeric limit for the buckets.

### What happens if one TWAP slice fails?

It depends on the venue: Bitget's help page says the whole TWAP stops and Binance Futures ends it on a margin failure, while Hyperliquid and Kraken carry the shortfall into later slices. In your own slicer it is a written decision.

## Sources

- [Binance Algo Trading: Future Algo, TWAP new order (fields, limits, notes)](https://developers.binance.com/en/docs/catalog/advanced-trading-algo-trading/api/rest-api/future-algo#time-weighted-average-price-future-algo)
- [Binance Algo Trading: Spot Algo, TWAP new order (fields, limits, notes)](https://developers.binance.com/en/docs/catalog/advanced-trading-algo-trading/api/rest-api/spot-algo#time-weighted-average-price-spot-algo)
- [Coinbase Advanced Trade API: Create Order (twap_limit_gtd, failure reasons)](https://docs.cdp.coinbase.com/api-reference/advanced-trade-api/rest-api/orders/create-order)
- [Hyperliquid: Order types (TWAP details, randomize, catch-up)](https://hyperliquid.gitbook.io/hyperliquid-docs/trading/order-types)
- [Hyperliquid API: Exchange endpoint (twapOrder, twapCancel)](https://hyperliquid.gitbook.io/hyperliquid-docs/for-developers/api/exchange-endpoint)
- [Kraken API: Add Strategy (TWAP)](https://docs.kraken.com/api-reference/algo-trading/add-strategy)
- [Kraken: Algo trading guide, TWAP (execution, funds, cancelling)](https://docs.kraken.com/exchange/guides/algo-trading/twap)
- [Kraken Developers: Release notes (Algo Trading, 27 October 2026)](https://docs.kraken.com/exchange/changelog)
- [OKX API v5: Place algo order and Cancel algo order (TWAP parameters)](https://www.okx.com/docs-v5/en/)
- [Bitget Support: A complete guide to TWAP orders (dated 10 December 2025)](https://www.bitget.com/support/articles/12560603819691)
- [Bybit Help Center: Introduction to TWAP Strategy (updated 29 September 2026)](https://www.bybit.com/en/help-center/article/TWAP-Strategy)
- [KuCoin Help Center: TWAP Order (updated 31 December 2025)](https://www.kucoin.com/support/48142946141512)
- [ESMA interactive single rulebook: MiCA Article 3, definitions](https://www.esma.europa.eu/publications-and-data/interactive-single-rulebook/mica/article-3-definitions)
- [ESMA interactive single rulebook: MiCA Article 91, prohibition of market manipulation](https://www.esma.europa.eu/publications-and-data/interactive-single-rulebook/mica/article-91-prohibition-market-manipulation)
- [Capital Markets Law No. 6362, consolidated text, Article 99/A (Turkish)](https://www.mevzuat.gov.tr/mevzuatmetin/1.5.6362.pdf)

> This guide is general information about software and markets, not investment, legal or tax advice. Automated trading can lose money, past or backtested performance does not guarantee future results, and the rules that apply depend on your jurisdiction and your exchange's terms. Sources, checks and corrections: see the [editorial policy](https://fincodelabs.com/en/editorial-policy).

---

Published by Fincode (Fincode Yazılım ve Teknoloji A.Ş.), a software company in Istanbul, Turkey: https://fincodelabs.com/en/blog/twap-order

Cite as: Fincode, "TWAP order: how slicing works, API fields and tested code", updated November 6, 2026, https://fincodelabs.com/en/blog/twap-order