Skip to main content
Arcus runs a central limit order book (CLOB). You place orders against it with an order type and a time-in-force that together control how aggressively the order executes and how long it rests.
This page explains the concepts. For exact request fields, enums, and validation rules, see the order endpoints — POST /v1/placeOrder, cancelOrder, modifyOrder — and note that constraints are enforced server-side, so the spec is authoritative.

​
Order types

​
Time-in-force

Time-in-force (TIF) controls how long an order stays active: A few rules worth knowing at the concept level (the API enforces the exact constraints):
  • Every order carries a goodTilTime expiry — including IOC orders.
  • Market orders must use IOC.
  • Resting orders (GTT, ALO) require an expiry set sufficiently far in the future.

​
Modifying orders and queue priority

A modifyOrder replaces the resting order with a new one, which can cost you your place in the queue. The modify response echoes an originalSize field — the order’s size before the modify — so you can tell whether priority was kept:
  • If the price is unchanged and originalSize is less than the new size (you increased the order’s size), the order loses its queue priority — the added size can’t jump ahead of orders already resting behind you.
  • A same-price modify that leaves the size equal or smaller keeps the order’s place in the queue.
originalSize is only meaningful on the modifyOrder response; queue priority is a modify-specific concern.

​
Take-profit / stop-loss

Take-profit (TP) and stop-loss (SL) are trigger orders: they sit dormant until the market reaches a trigger price, then submit an order to close or reduce your position.
  • A stop-loss triggers when the price moves against you, to cap a loss.
  • A take-profit triggers when the price moves in your favor, to lock in a gain.
On Arcus, TP/SL legs are reduce-only (they can only shrink a position, never flip or grow it) and are submitted as grouped orders alongside the position. Each leg follows the TIF rules for its order type — a limit leg uses GTT, a market leg uses IOC. See POST /v1/placeOrder for the exact grouping and trigger fields.
Validation (required fields, allowed TIF per order type, trigger semantics) is enforced by the gateway and can evolve. Build against the API reference and the changelog rather than memorizing values here.