> ## Documentation Index
> Fetch the complete documentation index at: https://docs.arcus.xyz/llms.txt
> Use this file to discover all available pages before exploring further.

# Order types

> Order types, time-in-force options, and take-profit / stop-loss on Arcus perps, at a conceptual level

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.

<Note>
  This page explains the concepts. For exact request fields, enums, and validation rules, see the order endpoints — [`POST /v1/placeOrder`](/api-reference/exchange/place-order), [`cancelOrder`](/api-reference/exchange/cancel-order), [`modifyOrder`](/api-reference/exchange/modify-order) — and note that constraints are enforced server-side, so the spec is authoritative.
</Note>

## Order types

| Type       | Behavior                                                                                                                                                               |
| ---------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Limit**  | Executes at your specified price or better. Rests on the book if it doesn't fully fill.                                                                                |
| **Market** | Executes immediately against the book. A protective price bound is required so a market order behaves like a marketable limit order and can't fill at a runaway price. |

## Time-in-force

Time-in-force (TIF) controls how long an order stays active:

| TIF                           | Meaning                                                            |
| ----------------------------- | ------------------------------------------------------------------ |
| **GTT** (good-til-time)       | Rests on the book until filled or until its expiry time.           |
| **IOC** (immediate-or-cancel) | Fills what it can immediately; cancels any remainder.              |
| **FOK** (fill-or-kill)        | Fills completely and immediately, or is canceled entirely.         |
| **ALO** (add-liquidity-only)  | Posts to the book as a maker; rejected if it would take liquidity. |

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`](/api-reference/exchange/modify-order) 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.

<Note>
  `originalSize` is only meaningful on the `modifyOrder` response; queue priority is a modify-specific concern.
</Note>

## 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`](/api-reference/exchange/place-order) for the exact grouping and trigger fields.

<Note>
  Validation (required fields, allowed TIF per order type, trigger semantics) is enforced by the gateway and can evolve. Build against the [API reference](/api-reference/introduction) and the [changelog](/changelog) rather than memorizing values here.
</Note>