https://api.velora.xyz.
It’s the Delta swap flow with one wrinkle that trips people up: you quote a single slice, not the whole order, and the server multiplies it across the schedule. For the conceptual model, see Product stack → TWAP. For a typed wrapper, see SDK → TWAP.
Sell vs buy
A TWAP is either a sell or a buy, and the field that fixes the total differs:- Sell TWAP (
orderType: "TWAPOrder") fixes the total source amount and splits it across slices. SettotalSrcAmount. - Buy TWAP (
orderType: "TWAPBuyOrder") fixes the total destination amount to receive and caps the total source spent. SettotalDestAmountandmaxSrcAmount.
The flow
Quote one slice
GET /v2/quote?mode=DELTA for the per-slice amount, floor(total / numSlices). The route’s amount must match that slice; the server applies it across the schedule.Approve the total
Approve the total source on-chain (
totalSrcAmount for sell, maxSrcAmount for buy), not one slice. A TWAP uses approval, not a permit; see Approvals and permit. Native source skips this.Build the schedule
POST /v2/delta/orders/build with the orderType, interval, numSlices, a deadline, and the totals. See POST /v2/delta/orders/build.Sign and submit
The user signs
toSign; POST /v2/delta/orders. See POST /v2/delta/orders.1. Quote one slice
Quote the per-slice amount, not the total. For a 4-slice sell of 10,000 USDC, quote10000000000 / 4 = 2500000000:
route.origin.input.amount must equal floor(totalSrcAmount / numSlices). For a buy TWAP, route.origin.output.amount must equal floor(totalDestAmount / numSlices). Each slice executes that floored amount, and the final slice picks up the rounding remainder, so the order settles the exact total. Then approve the total source amount, not the slice. Approve on-chain rather than with a permit, which can’t cover a multi-slice order (see Approvals and permit).
2. Build the schedule (sell TWAP)
numSlices is at least 2 and interval (seconds between slices) at least 60. The deadline must leave room for the whole schedule: at least numSlices × interval seconds from now, or the submit call rejects the order. The response is the same { toSign, orderHash } as any Delta order.
Buy TWAP
A buy TWAP fixes how much to receive and caps what’s spent. Quote a single slice by the per-slice destination amount, then build withtotalDestAmount and maxSrcAmount. Each slice may spend at most its proportional share of maxSrcAmount, so a single expensive slice can’t eat the whole budget:
3. Sign and submit
The user signstoSign (ERC-2098 compact signature), then you submit the order. There’s no TWAP-specific submit; it’s the same call as a market Delta order:
4. Poll, list, and cancel
PollGET /v2/delta/orders/{orderId} over the order’s lifetime; the input/output amounts carry expected and executed totals, so you can show fill progress without computing it yourself. For a human-readable view of slice-by-slice progress, open the order in the Velora explorer at https://explorer.velora.xyz/order/{orderId}. List a user’s TWAPs by filtering on onChainOrderType:
GET /v2/delta/orders and POST /v2/delta/orders/cancel.
Partner fee
Passpartner on the quote, build, and submit calls (plus optional partnerAddress, partnerFeeBps, partnerTakesSurplus), exactly as for a Delta swap. See Monetize.
Related pages
- Delta swap: the base flow a TWAP extends.
- Limit orders, the other scheduled Delta order type.
- Product stack → TWAP for the conceptual model.
- Delta API reference lists full parameters and response schemas.
- SDK → TWAP, a typed wrapper over this flow.