Strike orders

Every endpoint here writes. Read strike-auth first: signing, the API wallet and the strike_request.py helper live there, and none of it is repeated below.

Who may run this: the Execution Trader, on a ticket carrying a Risk Manager PASS and the user's approval line by id. Nobody else, for any reason.

Symbols here are the same -USD symbols the Price Service uses. There is no translation on this desk.

1. Before any send

All of these must be true. Same pre-send checklist as desk-execution-protocol, in this API's terms.

1. The proposal file carries a Risk PASS and the user's approve <ticket id> line.
2. Live equity and positions read this minute: GET /v2/account, GET /v2/positions.
3. size respects the market's LOT_SIZE.stepSize; notional clears MIN_NOTIONAL.notional.
4. price respects PRICE_FILTER.tickSize.
5. Leverage on the symbol already equals the ticket's (strike-positions), set before the entry.
6. A fresh client_order_id is generated, written to the proposal file before the send.
7. The preview block has been posted to the floor and matches the ticket field for field (section 3).

2. Rounding

Constraints come from the market, not from memory: GET /v2/exchangeInfo on the Price Service gives tickSize, stepSize and MIN_NOTIONAL per symbol.

Round size down, never up: rounding up spends risk budget the ticket did not authorise. Round price to the tick in the direction that does not flatter your own fill assumption.

python3 -c "
from decimal import Decimal, ROUND_DOWN
qty, step = Decimal('1234.87'), Decimal('1')      # ADA-USD trades in whole tokens
print((qty / step).to_integral_value(rounding=ROUND_DOWN) * step)
"

A size that rounds to zero, or to a notional under the minimum, is a reject the Execution Trader reports. Never a size nudged up to clear the floor.

Sizes and prices are strings in this API. Send "4800", not 4800.

3. The preview block replaces a dry run

The API has no dry-run mode. Nothing stops a POST but the desk's own discipline, so that discipline is written down and mandatory.

Before every send, build the exact request body, save it to a file, and post its contents to the floor as a PREVIEW block beside the ticket. Send only after the user's approval line refers to that ticket id. The bytes sent must be the bytes previewed.

cat > /workspace/trading-desk/proposals/SG-20260910-01-entry.json <<'JSON'
{
  "strategy_id": "SG-20260910-01",
  "client_order_id": "SG-20260910-01-entry",
  "symbol": "ADA-USD",
  "side": "buy",
  "type": "limit",
  "size": "4800",
  "price": "0.2100",
  "time_in_force": "GTC",
  "sl_order": {
    "client_order_id": "SG-20260910-01-sl",
    "type": "stop",
    "size": "4800",
    "stop_price": "0.1995",
    "working_type": "mark_price"
  },
  "tp_order": {
    "client_order_id": "SG-20260910-01-tp",
    "type": "take_profit",
    "size": "4800",
    "stop_price": "0.2310",
    "working_type": "mark_price"
  }
}
JSON
cat /workspace/trading-desk/proposals/SG-20260910-01-entry.json   # this is the PREVIEW block

Because the file is the request, a preview that differs from the send is a bug the desk can see, not a story it tells.

4. Client order ids

Every order carries a client_order_id the desk chooses. Derive it from the ticket: SG-20260910-01-entry, -sl, -tp, -B-entry for a follow-up ticket. Unique, never reused.

This is the desk's most important reconciliation handle. GET /v2/order?client_order_id=... answers authoritatively whether an order exists, so a send whose response was lost is a lookup, not a guess. Write the id into the proposal file before the send, not after.

Brackets also take a strategy_id, which the desk sets to the ticket id, and a client_order_id per leg.

5. The order shapes

Bracket strategy - the desk's default for a new position

POST /v2/order/strategy. Entry plus take-profit plus stop-loss in one request; the exit legs arm after the entry fills, so they cannot be rejected for having no position to reduce.

python3 scripts/strike_request.py POST /v2/order/strategy \
  --body-file /workspace/trading-desk/proposals/SG-20260910-01-entry.json

• side is buy or sell for the entry; Strike sets the exit legs opposite and reduce-only.
• Leg type: stop / stop_limit for the SL, take_profit / take_profit_limit for the TP. The plain forms fill at market on trigger; the _limit forms rest at price after triggering and can fail to fill on a fast move. The desk's default for a stop is stop - a stop that might not fill is not protection, which is exactly why the Risk Manager sizes on a stressed stop.
• working_type decides what the trigger watches: mark_price (default, and what liquidation settles against) or contract_price. The desk uses mark_price and says so on the ticket.
• A ticket without a stop does not reach this skill.

Limit entry

POST /v2/order with type: "limit". Add post_only: true when the ticket calls for maker-only - the order is rejected rather than crossing. No attached protection, so prefer a bracket unless the ticket has a reason.

Market entry, with a bound

POST /v2/order with type: "market" and slippage set - a decimal fraction, e.g. "0.005" for 50 bps. Always set it. An unbounded market order on a thin book is how a desk loses more than its ticket said.

Protection on a position that already exists

POST /v2/order with type: "stop" or "take_profit", reduce_only: true, stop_price, and working_type: "mark_price". side is the side of the closing order: sell protects a long, buy protects a short.

close_position: true closes the whole position on trigger regardless of the size field, which keeps protection correct after a partial fill or an add. Prefer it for a stop that is meant to flatten.

Trailing stop

type: "trailing_stop_market" with callback_rate (a percentage, "0.1" to "5") and optionally activation_price. Available, and used only when the ticket says so - a trailing stop changes the risk the Risk Manager sized, so it is a ticket decision, never an execution flourish.

6. The send, and reading it back

Send once. No retry loop. A finite timeout.

python3 scripts/strike_request.py POST /v2/order/strategy --body-file <ticket>.json

Then confirm from the exchange, because the response is a claim and the record is the fact:

python3 scripts/strike_request.py GET /v2/order --query client_order_id=SG-20260910-01-entry
python3 scripts/strike_request.py GET /v2/openOrders
python3 scripts/strike_request.py GET /v2/positions
python3 scripts/strike_request.py GET /v2/history/fill --query symbol=ADA-USD --query limit=20

Report the exchange's numbers: status, filled price and size, order ids, fees, and whether protection is actually resting. Order status values are 2 open, 3 filled, 4 canceled, 5 untriggered, 6 rejected, 7 expired. A resting stop that has not fired is 5, not 2 - a check that counts only 2 will call a protected position unprotected.

A bracket whose entry filled but whose exit legs are not resting is an unprotected position. Incident, immediately, under desk-incident-response.

7. Replace and cancel

POST /v2/order/replace cancels and re-places atomically: cancel takes {order_id, symbol}, new_order is a full order object with a new client_order_id.

python3 scripts/strike_request.py POST /v2/order/replace --body-file amend.json

Use it for an unfilled entry the user has re-priced. For protection, prefer place-new, confirm-resting, then cancel-old, so the position is never unprotected even briefly - an atomic replace that fails leaves nothing behind.

DELETE /v2/order/cancel takes order_id (integer) and symbol. It does not accept a client order id, so look the numeric id up in GET /v2/openOrders or GET /v2/order?client_order_id=... first.

python3 scripts/strike_request.py GET /v2/openOrders
python3 scripts/strike_request.py DELETE /v2/order/cancel --body-file cancel.json

Cancelling protection on a position that stays open increases risk and needs approval like anything else.

DELETE /v2/order/cancel-all is in strike-advanced, and is not a reflex.

8. What this desk does not do

• No entry without a stop in the same strategy order.
• No market order without a slippage bound.
• No send whose body differs from the previewed block.
• No reused client_order_id.
• No resend on an unknown result - look it up by client order id first (desk-execution-protocol).
• No size rounded up to clear a minimum, and no leverage raised to make a ticket fit.
• No vault_id. The desk trades the user's own account only.