POST /v1/orders1234567891011121314{ "order": { "maker": "0x1111111111111111111111111111111111111111", "underlyingKey": 7, "optionSpecifier": 859008923130267914, "side": 0, "size": 25, "limitPrice": 20000, "nonce": 42, "expiresAt": 200003600000, "maxFeeBps": 100 }, "signature": "0x…" }
body order.makeraddressrequiredbody order.underlyingKeyuint64requiredbody order.optionSpecifieruint64requiredbody order.sideuint8required0 buy, 1 sell. There is no open or close flag.body order.sizeuint64requiredbody order.limitPriceuint64requiredbody order.nonceuint64required[1, 2^62) with
bits 54–61 zero. See Nonces.body order.expiresAtuint64requiredexpiryMs for good-till-expiry, or an
earlier instant. See Lifetime.body order.maxFeeBpsuint8requiredbody signaturestringrequiredr‖s‖v, as eth_signTypedData_v4 returns it.query waitintegerwait202 Accepted once the order is sequenced:1{ "status": "accepted", "clientId": 42, "fills": [] }
clientId is the order's nonce. Follow the order on the WebSocket's account:
channel, or at GET /v1/orders/{maker}/{nonce}.wait200 OK, whatever the engine decided:123456{ "status": "resting", "orderId": "1834:12", "clientId": 42, "fills": [{ "size": 10, "price": 20000, "fee": 100000 }] }
status | Meaning |
resting | In the book, after any fills it took on the way in. orderId names it. |
filled | Took liquidity and did not rest. The fills may sum to less than size if the engine was quiet for the rest of the window. |
expired | Its lifetime ended before it rested: what was left of a zero-lifetime order. |
refused | The engine refused it. code is the reason; see Refusals. |
unknown | No answer within the window. The order may still be live: ask for its status. |
fills[].fee is what this order paid on that fill.refused with code NONCE_USED, and an order field says where
the first one stands:1234567{ "status": "refused", "code": "NONCE_USED", "clientId": 42, "fills": [], "order": { "orderId": "1834:12", "state": "resting", "remaining": 15 } }