Order Acknowledgement Benchmark 2027: How Quickly Crypto Exchanges Confirm, Reject and Cancel Orders
An API response saying an order was accepted is not always proof that the order is already working in the matching engine. The DN Order Lifecycle framework separates request acknowledgement, exchange processing, confirmed order state, rejection and cancellation so algorithmic traders can measure the latency that actually determines execution risk.
Crypto exchanges use different meanings for “order accepted.” Bybit and Bitget explicitly describe their initial acknowledgements as asynchronous and require a later WebSocket update to confirm actual order state. OKX distinguishes an accepted cancellation request from a confirmed cancelled order. For automated traders, the meaningful benchmark is therefore not API round-trip time alone, but the complete lifecycle from send to authoritative state.
DN Evidence Block
-
OKX exposes microsecond gateway
inTimeandoutTimetimestamps and allows time-sensitive order requests to carry anexpTimedeadline. -
Gate exposes microsecond
x_in_timeandx_out_time, request and trace IDs, and selectable ACK, RESULT and FULL response modes. -
Kraken WebSocket v2 exposes wire-level
time_inandtime_outtimestamps and adeadlinethat prevents an order matching after a user-defined latency window. -
Bitget added microsecond
receiveTimeandpushTimeto WebSocket order, modify and cancel responses in August 2026. - Bybit explicitly states that create, amend and cancel acknowledgements only mean the request was accepted and that actual order state should be confirmed through the private WebSocket order stream.
- MEXC's Spot API returns an order ID and transaction time but its public order-entry documentation provides less internal gateway timing observability than several of the leading venues above.
Author: Decentralised News Research
Methodology: DN Order Lifecycle methodology
Primary evidence: Official exchange API documentation
ACK latency is not execution latency. A trading bot can receive an apparently successful API response while the economically important state transition is still pending. The hidden interval between acknowledgement and authoritative order state is the DN Post-ACK Uncertainty Window, and it can matter as much as network round-trip time.
The Five States Traders Often Confuse
A fifth state follows if the order trades: filled or partially filled.
These events can occur almost together in a quiet market, but they are logically separate.
Why ACK Is Not a Universal Metric
Different APIs attach different meaning to an acknowledgement.
An ACK can mean:
- the exchange gateway received the request,
- the request passed initial validation,
- an order ID was allocated,
- the matching engine processed the request,
- or simply that an asynchronous workflow has begun.
Comparing “API response time” without first defining which of these events is being timed creates a benchmark that looks precise but compares different things.
DN Order Lifecycle Observability Score
This first edition ranks how well an exchange lets a systematic trader observe and control the order lifecycle.
It does not claim that the highest-scoring exchange has the lowest measured P99 order latency. That requires controlled live measurement.
| Component | Weight | What DN Assesses |
|---|---|---|
| Gateway timing visibility | 25% | Receive/send timestamps and ability to separate network delay from exchange gateway processing. |
| ACK semantics clarity | 20% | Whether documentation clearly explains what a successful response actually proves. |
| Authoritative state confirmation | 15% | Private order streams, execution reports or queries that confirm working/cancelled/rejected state. |
| Cancel semantics | 15% | Ability to distinguish cancel request acknowledgement from confirmed cancellation. |
| Client identifiers & traceability | 15% | Client order IDs, request IDs and trace IDs for resolving uncertain outcomes. |
| Stale-request protection | 10% | Expiry/deadline mechanisms that stop delayed orders from becoming unexpectedly executable. |
2027 Order Lifecycle Observability Ranking
| Rank | Exchange | DN Score | Timing Visibility | ACK Model | Stale-Order Protection | Status |
|---|---|---|---|---|---|---|
| 1 | OKX | 98/100 | Microsecond gateway in/out | ACK + authoritative order channel | expTime |
LIVE |
| 2 | Gate | 97/100 | Microsecond x_in/x_out + trace IDs | ACK / RESULT / FULL | Timestamp validation | LIVE |
| 3 | Kraken | 96/100 | Microsecond wire time_in/time_out | Engine processing result | deadline |
LIVE |
| 4 | Bitget | 95/100 | Microsecond receiveTime/pushTime | Async ACK + order push | Client/request controls | LIVE |
| 5 | Binance | 93/100 | Order/transaction timestamps | Selectable ACK / RESULT / FULL | recvWindow | LIVE |
| 6 | Deribit | 92/100 | Strong professional stack; nanosecond Starbase state for eligible users | JSON-RPC / FIX / SBE pathways | FIX ValidUntilTime | LIVE |
| 7 | Bybit | 90/100 | Request time + TraceId | Explicit asynchronous ACK | recvWindow | LIVE |
| 8 | MEXC | 82/100 | transactTime / order-state timestamps | REST response + private order stream | recvWindow | LIVE |
Decision-Ready Comparison
| Venue | Best For | Avoid If | Confirmation Route | Cancel Behaviour | Main Engineering Risk |
|---|---|---|---|---|---|
| OKX | Latency instrumentation and expiry-sensitive automated trading | You do not implement the private order channel | ACK + WebSocket order state | Successful cancel response means accepted request, not necessarily cancelled order | Confusing ACK with final order state |
| Gate | Developers wanting detailed gateway and trace telemetry | You only consume the first ACK and ignore the result/order stream | ACK / RESULT / FULL + order notifications | Realtime order-state channels | Response mode changes the amount of information received |
| Kraken | Time-sensitive trading with deadline protection | Your clock synchronization is unreliable | WebSocket engine response + executions | Cancel response + execution stream | Deadline logic depends on accurate time |
| Bitget | Gateway-latency diagnostics and UTA automation | You interpret initial ACK as confirmed working state | ACK + private order push | Cancel ACK + order state | Asynchronous state must be reconciled correctly |
| Binance | Broad systematic stacks needing configurable response richness | You assume ACK, RESULT and FULL are equivalent | Response + user data stream | Matching-engine cancel endpoints | Different response modes can complicate benchmark comparability |
| Deribit | Professional derivatives and low-latency institutional infrastructure | You need Starbase features without qualifying professional access | JSON-RPC/FIX execution state; Starbase for eligible users | FIX / API execution reports | Standard and professional paths are not equivalent |
| Bybit | Unified API bots with straightforward async semantics | Your architecture assumes HTTP success equals final order state | ACK + private WebSocket order stream | Explicitly asynchronous | Failure to wait for authoritative state |
| MEXC | Spot automation where basic order-state APIs are sufficient | You require detailed internal gateway telemetry | REST response + private order updates/query | REST cancel returns cancelled state when confirmed | 5XX outcomes may be unknown and require reconciliation |
Operational Status Gate
All eight venues in this comparison were checked against current official API documentation during the 28 September 2026 review and treated as LIVE for the relevant trading API.
LIVE does not mean that every product, account tier or API interface is available in every jurisdiction.
1. OKX: Best Documented End-to-End Order Observability
OKX currently exposes one of the most useful timestamp sets for latency analysis.
Its trading responses include:
inTime: when the request reaches the REST or WebSocket gateway,outTime: when the gateway sends the response,cTime: order creation time after relevant risk checks,uTime: most recent order-state update,fillTime: matching time when the order trades.
This gives a trader multiple points along the lifecycle rather than one generic “response time.”
OKX also makes cancellation semantics explicit. An sCode=0 response means the
cancellation request was accepted by the server. It does not by itself prove that
the order has already reached canceled state.
The authoritative result comes from the order stream or a subsequent order-state query.
Stale-order protection
The expTime feature allows a bot to attach an expiry deadline to supported place or
amend requests.
If the request reaches the server after that deadline, it should not be processed.
Why this matters: For a latency-sensitive strategy, “do not execute this stale order” can be more valuable than “execute it eventually.”
Affiliate relationship disclosed. API and product availability varies by account and region.
Referral code: 2136301
2. Gate: Excellent Gateway and Trace Telemetry
Gate's WebSocket trading API exposes unusually detailed response metadata.
Current responses can include:
x_in_timein microseconds,x_out_timein microseconds,- connection ID,
- connection trace ID,
- order-operation trace ID,
- remaining rate-limit capacity.
Gate also gives developers three order response modes:
- ACK: asynchronous mode with key order fields,
- RESULT: expanded result without clearing information,
- FULL: full response mode.
That makes Gate particularly useful for studying the difference between first acknowledgement and complete order result.
The trader can separately compare that number with the local send-to-response time to estimate how much latency is occurring before and after the exchange gateway.
Affiliate relationship disclosed.
Referral code: UgUVAVoJ
3. Kraken: Strong Timing Plus Engine-Level Deadline Protection
Kraken WebSocket v2 provides an unusually clear set of timing and safety primitives.
The add_order response includes:
order_id,cl_ord_id,success,req_id,time_in,time_out.
The documentation describes time_in as the timestamp when the request is received on
the wire just before parsing, and time_out as the point just before the response is
transmitted.
Both examples use microsecond precision.
The deadline feature
Kraken also lets an order carry a deadline.
The allowed offset is currently 500 milliseconds to 60 seconds, with a five-second default. The matching engine will prevent the order from matching after the deadline.
This is a fundamentally different protection from merely measuring latency after the event.
DN interpretation: The strongest latency architecture not only measures delay. It limits the damage that delay can cause.
Affiliate relationship disclosed.
Referral code: QjZ0L3
4. Bitget: Microsecond Gateway Telemetry Added in 2026
Bitget materially improved its order-lifecycle observability in August 2026.
Its WebSocket place, modify, cancel and batch-order responses now expose:
receiveTime: gateway receive time in microseconds,pushTime: gateway push time in microseconds.
This allows the client to calculate exchange-side gateway handling separately from its own network round trip.
Bitget also makes the initial-response semantics explicit:
That distinction is exactly what an automated system needs to avoid treating an order ID as proof that the intended state transition has completed.
Affiliate relationship disclosed.
Referral code: nqef
5. Binance: Flexible ACK, RESULT and FULL Responses
Binance's Spot WebSocket API exposes trading directly through the WebSocket request-response interface and identifies matching-engine-backed trading endpoints in its documentation.
Binance also supports different new-order response formats, commonly including:
- ACK,
- RESULT,
- FULL.
That is useful, but it creates a benchmarking problem: two clients using different response modes are not necessarily timing the same amount of work.
A DN live benchmark should therefore standardize response type before comparing venues.
Binance also supports client order identifiers and private user-data streams, allowing the client to reconcile later order state with the original request.
Affiliate relationship disclosed. Product access varies by jurisdiction.
Referral code: CPA_00SXKU7IO9
6. Deribit: Specialist Professional Order Infrastructure
Deribit supports JSON-RPC over WebSocket, JSON-RPC over HTTP and FIX, with WebSocket recommended for general real-time integration.
For professional low-latency users, the 2026 Starbase rollout adds a substantially different infrastructure path.
Starbase includes:
- SBE Order Entry,
- hot-hot gateway pairs,
- FIX Drop Copy,
- colocation and cross-connect connectivity,
- AWS PrivateLink,
- nanosecond-precision Starbase match and order-update timestamps.
These features are designed for selected professional clients and should not be treated as equivalent to ordinary internet JSON-RPC access.
Deribit's FIX stack also supports ValidUntilTime on relevant order messages so delayed
orders can be rejected after a specified timestamp.
Benchmarking lesson: “Deribit latency” is not one number. Internet JSON-RPC and colocated Starbase SBE are different execution paths and should be measured separately.
Affiliate relationship disclosed. Specialist infrastructure can require professional onboarding.
Referral code: 5969.4030
7. Bybit: One of the Clearest Asynchronous ACK Definitions
Bybit does not blur the distinction between acknowledgement and actual order state.
Its order documentation explicitly says that a place-order acknowledgement only means the request was successfully accepted.
The request is asynchronous, and developers are instructed to use the WebSocket order stream to confirm status.
The same principle applies to cancellation.
A cancellation API response does not remove the need to observe the subsequent authoritative order-state event.
Bybit supports both exchange-generated orderId and user-supplied
orderLinkId, which helps a bot reconcile requests after uncertainty.
Affiliate relationship disclosed.
Referral code: 46164
8. MEXC: Basic Lifecycle Data With Less Internal Timing Visibility
MEXC Spot supports user-defined newClientOrderId values and returns an
orderId plus transactTime when a new order is submitted successfully.
It also exposes private order updates containing order status, creation time and remaining quantity.
The main observability gap is not that order state is unavailable.
It is that the public API documentation exposes less internal gateway timing detail than OKX, Gate, Kraken or Bitget.
There is another important engineering warning in MEXC's documentation: an HTTP 5XX response should not automatically be treated as proof that an operation failed. Its execution status can be unknown.
That means reconciliation is mandatory before retrying an uncertain request.
Affiliate relationship disclosed. Verify API access for the exact market before deployment.
Referral code: 16yJL
The Post-ACK Uncertainty Window
DN introduces a simple metric for an overlooked part of execution:
If a bot receives an ACK in 40 ms but does not know with certainty that the order is working until 120 ms, then the meaningful uncertainty window is 80 ms.
During that interval the strategy may not know whether it should:
- send another order,
- hedge,
- cancel,
- reserve more inventory,
- or assume the original request failed.
That ambiguity can be more dangerous than a slightly slower but deterministic API.
Cancellation Latency Is Often More Important Than Placement Latency
A strategy may tolerate a delayed new order.
It can be much less tolerant of a delayed cancel.
For a market maker, an order that should have been removed can remain exposed while the underlying market moves.
The correct cancel benchmark therefore has two timestamps:
Confirmed Cancel Latency = Authoritative Canceled State − Cancel Send
The second number is the economically important one.
Rejection Latency Also Matters
A fast rejection is often better than a slow ambiguous response.
Common causes include:
- invalid price increments,
- insufficient collateral,
- post-only orders that would cross,
- risk-limit breaches,
- expired requests,
- symbol or account restrictions.
A trading engine should know quickly that the intended position does not exist.
For live testing, DN should not spam production venues with intentionally invalid traffic. Validation and rejection behaviour should be tested primarily through documented validation or test environments and through naturally occurring production rejects.
DN Order Lifecycle Diagnostic
Use your own production or test measurements below to quantify how much latency exists after the first API acknowledgement.
Score Your Order Lifecycle
DN Lifecycle Score: —
Measure your own ACK-to-state gap
The exchange documentation tells you what an acknowledgement means. It does not tell you how long the lifecycle takes from your server, region and account.
Record local send time, first response, authoritative order-state event and confirmed cancellation. Then use the diagnostic above to calculate the uncertainty window your trading system is actually operating inside.
DN Live Benchmark Protocol
The next version should move from documented readiness to observed latency.
A defensible test should use identical infrastructure and record at least:
- send-to-ACK P50 / P95 / P99,
- send-to-confirmed-working-state P50 / P95 / P99,
- ACK-to-confirmed-state uncertainty window,
- cancel-send-to-ACK,
- cancel-send-to-confirmed-cancelled-state,
- gateway processing time where the exchange exposes internal timestamps,
- request rejection latency,
- timeouts and unknown outcomes,
- duplicate or reconciliation events.
Tests should be repeated from at least:
- London or Frankfurt,
- Virginia or New York,
- Singapore or Tokyo.
The same symbol, product, order type, account tier and safe non-disruptive order methodology should be used across venues.
DN should never create misleading live liquidity or generate manipulative order traffic merely to collect latency samples.
The Metric That Should Ultimately Matter
Once live testing exists, DN can publish the original DN Order Lifecycle Latency Score.
P50 latency would describe normal performance.
P95 and P99 would reveal whether performance deteriorates under less favourable conditions.
For real trading systems, tail latency may matter more than the median.
DN Alpha Thesis: Certainty Has a Latency Value
The fastest acknowledgement is not necessarily the best execution interface.
A slower response that proves the engine processed an order can be operationally more valuable than an extremely fast ACK followed by an extended period of uncertain state.
DN calls this the Certainty Premium.
In automated execution, certainty has economic value because it determines when the next safe decision can be made.
What Would Change the Ranking?
- DN publishes synchronized observed lifecycle-latency data.
- An exchange adds or removes gateway timing fields.
- ACK or cancel semantics change materially.
- Stale-order deadline functionality is added or removed.
- Private order-state streams materially change.
- A professional execution path becomes broadly available.
- A platform or relevant API product becomes restricted, migrating, winding down or inactive.
Methodology & Limitations
The DN Order Lifecycle Observability Score is a modelled assessment built from official exchange technical documentation and current public API behaviour descriptions.
This edition does not claim that DN has directly measured order-acknowledgement latency across all eight venues.
The six weighted dimensions are:
- gateway timing visibility,
- ACK semantics clarity,
- authoritative state confirmation,
- cancel semantics,
- request and order traceability,
- stale-request protection.
The model deliberately separates documentation readiness from live execution performance. A future observed benchmark will replace modelled timing assumptions with synchronized P50, P95 and P99 measurements.
Evidence Classification
| Classification | Meaning |
|---|---|
| Exchange-reported | Order behaviour, timestamps or API semantics documented by the exchange. |
| Modelled | DN readiness score or interpretation derived from documented infrastructure. |
| Calculated | A metric mathematically derived from documented or user-entered timestamps. |
| Observed | Direct DN live measurement. No cross-exchange live latency ranking is claimed in this edition. |
Related DN Research
FAQ
What is order acknowledgement latency?
Order acknowledgement latency is the time between sending an order request and receiving the exchange's initial response. Its meaning differs between APIs, so it should not automatically be treated as proof that the order is already live or working.
Does an order ID mean my crypto order is live?
Not always. Several exchanges describe order placement as asynchronous. A response or order ID may show that the request was accepted, while the actual state should be confirmed through a private WebSocket stream or subsequent order query.
Which crypto exchange has the fastest order acknowledgement?
DN does not claim a fastest venue in this edition because doing so requires controlled live measurement from identical locations and account conditions. The current ranking measures order-lifecycle observability and safety architecture instead.
Why is cancellation latency important?
An order can remain exposed to the market until cancellation is actually confirmed. For market-making and latency-sensitive strategies, confirmed cancellation time can therefore be more important than the initial cancel ACK.
What is the post-ACK uncertainty window?
It is the interval between the initial order acknowledgement and the first authoritative confirmation of actual order state. A shorter and more deterministic uncertainty window gives the trading system more confidence about when it can safely make its next decision.
Why do stale-order deadlines matter?
A delayed order can become economically dangerous if market conditions have already changed. Deadline or expiry controls can prevent sufficiently stale requests from entering the market after their original trading decision is no longer valid.
Primary Research Sources
- OKX API v5 - order placement, cancellation, gateway in/out timestamps, order timestamps and expTime.
- Gate API v4 WebSocket Trading - ACK/RESULT/FULL response modes, x_in_time, x_out_time and trace identifiers.
- Kraken WebSocket v2 Add Order - deadline, client order IDs, engine result, time_in and time_out.
- Bitget UTA WebSocket Place Order and August 2026 API changelog - asynchronous ACK semantics and microsecond receiveTime/pushTime.
- Binance Spot WebSocket API - order.place, Matching Engine trading endpoints and ACK/RESULT/FULL response architecture.
- Deribit API Guidance and 2026 Starbase releases - JSON-RPC, FIX, SBE Order Entry, Drop Copy and professional timing infrastructure.
- Bybit V5 Place/Cancel Order documentation - asynchronous acknowledgements and private WebSocket order-state confirmation.
- MEXC Spot API v3 - new order, client order IDs, transactTime, private order state and unknown execution status after certain server errors.
Limitations
This is currently an order-lifecycle observability benchmark, not a live cross-exchange order-latency race.
Actual acknowledgement and confirmation latency depends on:
- server location,
- network path,
- account/VIP tier,
- REST vs WebSocket vs FIX/SBE route,
- market conditions,
- order type,
- exchange load.
The first exchange in this model should therefore not be described as “the fastest exchange” until a controlled DN dataset supports that conclusion.
Change Log & Corrections
28 September 2026: First 2027 edition. Verified current order-lifecycle documentation for OKX, Gate, Kraken, Bitget, Binance, Deribit, Bybit and MEXC. Added the DN Order Lifecycle Observability Score, Post-ACK Uncertainty Window, live benchmark protocol and Order Lifecycle Diagnostic.
To report an API change or provide primary-source evidence for a correction, use the Decentralised News contact page .
Final Takeaway
A fast API response is useful.
A fast API response that clearly tells the trading system what actually happened is more useful.
Automated traders should therefore measure three separate events:
- initial acknowledgement,
- authoritative working/rejected state,
- authoritative cancellation state.
The DN principle: Do not optimise for the fastest ACK. Optimise for the shortest path from decision to certain exchange state.
Risk disclosure: Automated cryptocurrency and derivatives trading involves substantial risk. Network delays, ambiguous order state, stale requests, delayed cancellations and software errors can produce unintended exposure or losses. APIs and execution semantics can change. This research is educational and does not constitute financial or investment advice.
About the Author
