A crypto order cancel-replace race occurs when execution changes while an old order is being canceled and a new order is being submitted. Resolve it by checking cancellation and replacement separately, then reconciling fills and open quantity for both orders. A cancel request does not freeze fills, and an accepted replacement does not prove the original stopped.
The practical question is whether the account can still acquire more than the approved quantity. A single “replace failed” label cannot answer it. This article uses official exchange documentation and an original hypothetical ledger, prepared with AI assistance. It describes an execution review method, not a claim that KLINEO implements every recovery control below.
Treat replacement as two operations
Call the existing order A and its proposed replacement B. Keep both identities: replacing a local row should not erase the exchange record for A.
Binance Spot exposes a combined cancel-replace endpoint with separate cancelResult and newOrderResult fields. Its STOP_ON_FAILURE mode skips the new order when cancellation fails; ALLOW_FAILURE permits attempting it anyway. The documented response matrix includes partial success, so the operation is not an all-or-nothing transaction. See Binance Spot cancel-replace rules.
Sending a separate cancellation followed by a separate create request also requires tracking both results. The exchange's exact ordering and acknowledgement contract matters. Bybit states that cancellation acknowledgement means the request was accepted for asynchronous processing and directs clients to the WebSocket for confirmation. See Bybit cancellation acknowledgement.
Before replacing, ask whether the intended change requires a new order at all. Some venues offer limited amendments with different rules. The order amendment and queue-priority guide covers that separate decision; an amendment and a cancel-replace should not share an assumed lifecycle.
The four confirmed outcome combinations
This table is an operator's interpretation worksheet for operations that were actually attempted and have known results. Venue policy can prevent some combinations. “Placement succeeded” means B was accepted; its subsequent fills and current status still need checking.
| Cancellation of A | Placement of B | What needs reconciliation | Next decision to resolve |
|---|---|---|---|
| Succeeded | Succeeded | A's final fills plus B's fills and remaining quantity | Does combined execution and outstanding capacity fit the target? |
| Succeeded | Failed | A's final fills; no accepted B from this attempt | Is the target still valid, and what quantity remains eligible for a new decision? |
| Failed | Succeeded | A may still be active or already terminal; B exists | Could both orders contribute fills, and is duplicate exposure possible? |
| Failed | Failed | A's actual state and earlier fills | Does A still work, or did its execution or another state change cause the cancellation failure? |
Cancellation failure does not mean A remains open. It might already have filled. Nor does cancellation success erase earlier executions. These distinctions are why the worksheet asks for quantities rather than inferring inventory from the success flags.
Keep NOT_ATTEMPTED separate from a failed placement: Binance uses it when the new order was skipped under applicable cancel-replace conditions. Do not turn a skipped operation into an exchange rejection or an accepted order.
Unknown is another state entirely. A lost response does not establish either success or failure. Binance documents timeouts with unknown execution status and calls for a status query when the user data stream has not resolved the request. Follow the order-timeout reconciliation process before assigning the attempt to a row. See Binance REST timeout semantics.
A successful replacement can still overshoot
Consider a hypothetical spot purchase with a target of 0.100 BTC. Assume no starting BTC, other trading, transfers or fees. Prices are omitted to isolate quantity accounting. This is not a live trade or a venue-specific execution sequence.
At the time of the replacement decision, order A has filled 0.030 BTC. The operator proposes B for the apparent remaining 0.070 BTC. While the cancellation is in flight, A fills another 0.020 BTC before its unfilled remainder is canceled. B is accepted for 0.070 BTC and then fills 0.010 BTC.
| Observation | Confirmed gross fills across A and B | Confirmed live buy remainder | Fills plus remaining capacity |
|---|---|---|---|
| Before replacement | 0.030 BTC | A: 0.070 BTC | 0.100 BTC |
| A canceled after its extra fill; B accepted | 0.050 BTC | B: 0.070 BTC | 0.120 BTC |
| B partially fills | 0.060 BTC | B: 0.060 BTC | 0.120 BTC |
Both operations succeeded. Nevertheless, the account can acquire 0.120 BTC if B's remainder fills: 20% above the original 0.100 BTC target. Cancellation did not freeze A at the earlier 0.030 BTC observation.
At the final row, owned gross quantity is 0.060 BTC. The difference between the target and current fills is 0.040 BTC, but B can already buy another 0.060 BTC. Creating an extra 0.040 BTC order would expand potential total acquisition to 0.160 BTC. A target-minus-balance calculation misses working commitments.
For this isolated, same-side example, use:
uncommitted quantity = target − confirmed gross fills − confirmed live buy remainders
The final row gives 0.100 − 0.060 − 0.060 = −0.020 BTC. The negative result identifies excess outstanding capacity. It is a review signal, not an instruction to immediately sell 0.020 BTC: that excess is not yet owned, and any cancellation or amendment itself needs confirmation.
Real spot inventory also needs fee assets and other account activity. Derivatives need the correct contract units, position side and reduction rules. The partial-fill inventory guide handles those accounting details. Do not mix an unfilled buy commitment with an already acquired asset.
Reconcile both identities before another change
Use one owner for the replacement decision so a bot and a manual operator do not both correct the same discrepancy. Preserve a replacement-group record linking A, B, their client identities, exchange IDs, account, environment, product, symbol and intended total quantity.
Then establish four pieces of evidence:
- A's latest authoritative state and final cumulative fills if terminal.
- B's acceptance or confirmed rejection, current fills and live remainder.
- Distinct execution records, with fees, reconciled against cumulative quantities.
- Other active orders and account activity that consume the same approved allocation.
Status messages are not individual trades. Bybit documents a concurrent fill-and-cancel case that can produce two Filled order messages. Counting both messages as separate execution would overstate inventory. See Bybit's simultaneous fill and cancellation warning.
If either order remains unresolved, preserve that uncertainty and block additional target-increasing replacements under the chosen operating policy. Repeatedly changing identifiers and resending a replacement makes the chain harder to reconstruct. The idempotency guide explains how a durable intent record helps separate recovery from a new trading decision.
Check the exposure boundary, then close the incident
A confirmation that B exists is only one part of closure. Record A's terminal outcome, all confirmed fills, B's current working quantity, and whether the combination fits the approved target. If B remains open, assign responsibility for its later fills. If its size changes again, preserve the link to the same inventory review.
For futures, available collateral is a different constraint from authorized position size. A margin addition or withdrawal can change the funds supporting a position; it does not resolve duplicate orders or subtract an already executed fill. Review collateral only after identifying the relevant orders and position scope.
Finally, verify protective orders against actual exposure. An entry replacement does not establish that its stop or take-profit quantity remains appropriate. When exchange evidence conflicts or history is incomplete, the useful incident result is a clearly recorded unresolved state with a responsible operator. A second successful submission is not evidence that the first order disappeared.