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

# Execution

> Three order types, one flag, no hidden state.

SORY sends orders and reports what the venue said back. Nothing more.

```python theme={"dark"}
order = await sory.place(
    symbol="BTC/USDT",
    side="buy",
    qty=Decimal("0.5"),
    type="limit",
    price=Decimal("95000"),
    post_only=True,
    venues=["binance"],       # omit to route across all healthy venues
    margin=False,
    max_slippage_bps=15,      # market orders only
)
```

## Order types

| Type     | Behaviour                                         |
| -------- | ------------------------------------------------- |
| `limit`  | GTC. Rests at your price. Partial fills expected. |
| `market` | Immediate. Requires `max_slippage_bps`.           |
| cancel   | Pull a resting order.                             |

Plus one flag: **`post_only`**, which stops a resting quote from crossing and paying taker.

<Warning>
  If a venue does not support `post_only`, the order is **refused** rather than sent without it. A quote that silently pays taker is worse than one that fails loudly. Use `venues=[...]` to route only where it is supported — the [venues table](/venues) says which.
</Warning>

No `reduce_only`, no stop or trigger orders, no IOC/FOK, no icebergs, no algos. Build them on top.

## The order model

One `Order` fans out to one or more `VenueOrder`s. That is inherent to routing.

```text theme={"dark"}
Order       (id, symbol, side, qty, type, price, post_only, margin)
  ├── VenueOrder  (venue=binance, client_order_id, venue_order_id, qty, price)
  └── VenueOrder  (venue=okx,     client_order_id, venue_order_id, qty, price)
```

```python theme={"dark"}
order.filled       # sum over children
order.remaining    # qty - filled
order.plan         # why it was routed this way
```

The parent sums its children and computes nothing else — except `expected_price` / `achieved_price`, because routing has to be measurable.

## What a venue tells you

```python theme={"dark"}
async for update in sory.order_updates():
    update.venue, update.status, update.filled, update.average, update.raw
```

`OrderUpdate` is the venue's own report, normalised: numbers as `Decimal`, the venue tagged on. No derived fields, no invented all-in price. `raw` holds the untouched payload.

Status is the venue's own — `open`, `closed`, `canceled`, `rejected`, `expired`. SORY builds no state machine on top of it.

## Cancelling

```python theme={"dark"}
await sory.cancel(order.id)              # returns once every venue has confirmed
await sory.cancel_all()                  # kill switch: everything, everywhere
await sory.cancel_all(symbol="BTC/USDT")
```

<Note>
  **Wait for confirmation before reposting.** A cancel that races a fill is how you end up double-filled, so `cancel` returns when the venues have answered, not when the requests were sent.
</Note>

## State

**In memory only.** No file, no database, no persistence of any kind. On restart, the venues tell you what is resting — that is the whole recovery story.

## Safety

| Control               | Behaviour                                                                 |
| --------------------- | ------------------------------------------------------------------------- |
| Capability validation | An order needing something a venue does not declare dies before dispatch. |
| Price bound           | Required on every order.                                                  |
| Venue health          | `Stale` or `Offline` is not routable.                                     |
| `max_order_notional`  | Optional cap. Off by default.                                             |
| `max_open_orders`     | Optional cap. Off by default.                                             |
| `dry_run`             | Every path runs end to end without sending.                               |

The caps are yours to set. SORY does not invent a risk policy for you.