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, set at least one month ahead — including IOC and FOK orders, where it acts as a replay-protection timestamp. See POST /v1/placeOrder for the exact rule.
  • Market orders must use IOC.
  • Order reads report a resting GTT order’s time-in-force as GTC, the legacy name for the same bucket; treat the two as equivalent.

Modifying orders and queue priority

A modifyOrder changes a resting order’s price or size. The order keeps its orderId, its createdAt and its fill state (filledSize, avgFillPrice).
  • Size (quantity) is the new total, including any amount already filled. A total at or below the filled amount is rejected with MODIFY_SIZE_ALREADY_FILLED.
  • Same price, smaller size — the order keeps its queue priority.
  • Any price change, or a size increase — the order loses its queue priority and rejoins at the back of the queue at its (new) price.
  • If the engine rejects the modified order (for example, an ALO modify that would cross, or MODIFY_SIZE_ALREADY_FILLED), the original order is removed too. A request that fails validation with HTTP 400 leaves the original order untouched.
On the orders channel, a modify arrives as two consecutive updates for the same orderId: CANCELED with cancelReason: "MODIFY_CANCELED", carrying the pre-modify price and size, then the order’s new state (OPEN, a fill, or REJECTED). Use these orders channel updates, not the HTTP response, for the outcome of a modify.

Take-profit / stop-loss

Take-profit and stop-loss (TP/SL) orders protect a position. They only close or reduce it, so they are always reduce-only (reduceOnly: true). A reduce-only order can only shrink a position, never flip or grow it. A TP/SL is a trigger order. It sets tpslType (STOP_LOSS or TAKE_PROFIT) and a trigger price, stopPrice. It sits dormant off the order book, reported with status UNTRIGGERED, until the mark price reaches stopPrice. Then it submits a regular order: a market leg (IOC) or a limit leg (GTT). A trigger price on the wrong side of the current mark price, one that would fire at once, is rejected.
  • A stop-loss caps a loss. It sits below a long or above a short.
  • A take-profit locks in a gain. It sits on the other side. A TAKE_PROFIT fires in the limit direction: a sell take-profit when the mark price rises to stopPrice, a buy take-profit when it falls to it. Unlike a limit order it stays off the book until it fires. A TAKE_PROFIT is always reduce-only.
You set TP/SL on an open position, or attach it to a new entry order. In the Arcus app, you set it on a position or add it when you place an order. A single POST /v1/placeOrder with tpslType set places one standalone TP/SL order. To bundle legs or bind them to an entry, use POST /v1/batchPlaceOrders with a TPSL grouping:
  • positionTpsl closes the full open position. Each leg is resized to the whole position when it fires, so it still fits after you add to or trim the position.
  • partialTpsl closes a specific quantity.
  • entryTpsl is an entry order plus its bound TP/SL child legs. The legs arm on the entry’s first fill, including a fill against a liquidation, so they cannot fire while the entry is still unfilled. If the position closes while the entry still rests on the book, the legs stay attached and re-arm on the entry’s next fill. Canceling the entry cancels its legs.
Every TP/SL leg in a batch grouping sets reduceOnly: true.

Stop market and stop limit (advanced orders)

Stop market and stop limit orders are advanced orders. They are entry stops: they open a position, or add to one, rather than protect it. In the Arcus app they are under Advanced in the trade form. An entry stop is a STOP_LOSS order with reduceOnly: false, placed on its own with POST /v1/placeOrder. It uses the same trigger mechanism as TP/SL: it stays off the book as UNTRIGGERED until the mark price reaches stopPrice, then submits its order. Unlike TP/SL it is not reduce-only, so once triggered it opens or adds to a position in the trigger direction. Use it for a breakout or breakdown entry, for example to buy once the price rises through a resistance level. Only a STOP_LOSS can set reduceOnly: false. The reduce-only TP/SL above is unchanged. The order a stop submits is either a market or a limit order, and it follows the TIF rules for that type:
  • Stop market (a market leg, IOC) fills at whatever the book offers once triggered. Its price is still a protective bound, checked against stopPrice under the 10% rule above.
  • Stop limit (a limit leg, GTT) caps the price you accept. In a fast move the price can pass your limit, and the order then rests unfilled or partly filled.
Choose a market leg when getting in matters more than the price. Choose a limit leg when the price matters more than the fill.

Stops versus limit orders

A limit order and a stop wait for opposite moves: A limit order waits for a better price. A stop waits for the market to move through a level, then acts. A buy limit placed above the market is not a stop: it is marketable and fills at once. To buy only after the price rises through a level, you need a stop.
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.