Latency-focused release, with the introduction of our async-db pipeline.
This cuts latency on the core matching engine, but it changes how you get transaction hashes after posting an order.
What to expect:
Trading intermittent during maintenance, for up to 1.5h.
Brief post-only window after restart (2 min) before normal matching resumes. Cancels accepted.
There may be 503 errors during the maintenance, where trades would not be accepted
Post-only: only orders explicitly set with postOnly: true are accepted. Regular limit orders without the flag, market orders, and any taking liquidity will be rejected. Cancels for existing orders will still go through.
See POST /order API reference for the post-only flag.
What's changing for developers
Today, POST /order and POST /orders return transactionHashes inline on successful FAK/FOK matches. After this rollout, those endpoints won't return transactionHashes at all — you'll get tradeIDs instead.
tradeIDs behavior itself isn't changing: on a match you get tradeIDs back, on no match or failure you don't.
Websocket updates are unchanged. If you're already reading fills off the websocket, nothing to do here.
What you need to do On CLOB client (TS / Python / Rust): it handles this for you — resolves transactions after posting and returns hashes, successful trades, and any failures. Just bump to the latest version. Custom API integration: if you depend on transactionHashes from the REST response, you'll need to resolve them yourself off tradeIDs — poll trades until each has a hash or comes back FAILED. Reference PRs: