Venue Performance
| Venue | Scenario | Submission | Order | Metric | Measurements | OK | Cancel p50 | Cancel p95 | Cancel p99 | Cost/run | Speed bump | Errors | |||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Post-only Confirmation
How quickly a resting order is confirmed as placed.
Batch Post-only Confirmation
Five post-only orders per sample. Native batch venues are labeled separately from manual fanout venues that send concurrent single-order requests.
Cancel Confirmation
Post-only cleanup cancel latency, measured when the cancel is confirmed through the account feed.
Taker Confirmation
How quickly a marketable order is confirmed, adjusted for published venue delays.
Benchmark Box
Methodology
Post-only BTC order. Confirm latency is measured from completed order-submit write to the matching private account-feed order update. The synchronous exchange response is shown on hover.
Post-only BTC order using the maker-only API key. Confirm latency is measured from completed sendTx write to the matching private account order/trade WebSocket event for the client order index. The sendTx queue ack is shown on hover.
Post-only BTC order. Confirm latency is measured from completed order-submit write to the matching private account order/trade WebSocket event for the external order ID. Batch view labels documented native batch separately from manual fanout.
Post-only BTC-PERP order. Single-order submit uses Gateway WebSocket and private subscription confirmation. Batch view uses manual fanout over concurrent place_order executes because no native multi-place endpoint is documented.
Post-only BTCUSDT order using GTX time-in-force. Confirm latency is measured from completed order-submit write to the matching user data stream ORDER_TRADE_UPDATE event for the client order ID. The HTTP submit response is shown on hover.