Crypto exchange failover should begin with reconciliation of the original venue, because an unanswered order may still execute there. Before submitting a backup order elsewhere, account for confirmed fills and the maximum quantity that unresolved orders could still add. Keep that capacity reserved across both venues, then check the backup account, instrument, spending limit and protection separately. A healthy second exchange does not prove the first exchange did nothing.
The difficult part of switching venues is deciding how much trading authority remains. An outage can remove the evidence needed to answer that question while leaving an accepted order active. A second exchange can then execute the same intention independently.
This guide treats failover as an exposure decision. It uses a fictional spot purchase to show how a recovered fill, a different backup price and a quantity step change the permitted remainder. It is a general execution design worksheet.
Changing an endpoint and changing an exchange are different decisions
An alternate API hostname may reach the same venue and account. Binance Spot documents several base endpoints, alongside a timeout that can leave an order's execution unknown. Moving to another documented endpoint does not resolve an earlier write or make replaying it harmless. Binance directs clients to query the request's status when it has not appeared in the user data stream. Binance general REST API information.
Moving to another exchange changes the execution system and account. Its available balance, order rules and accepted identifiers belong to that venue. The operational inference is straightforward: the backup cannot decide whether the original exchange accepted an order merely by accepting a new one itself.
Start with the order-timeout reconciliation procedure to recover the original order. Venue switching introduces a further question: how does every unresolved attempt constrain the combined position?
An exchange status page can help explain an incident, but it cannot settle an individual order. Record what is unavailable: submission, cancellation, order reads, account reads or only market data. One working public price feed does not establish that authenticated order management works.
One purchase becomes two venue obligations
Consider a hypothetical strategy with no starting ETH, no borrowing and no other activity. Its intent is to acquire at most 0.800 ETH, with a separate gross purchase budget of 2,000 USDT. Fees are excluded throughout this example. Venue A receives a limit buy for 0.800 ETH at 2,500 USDT. Venue B has separately funded capital available.
These timings and prices are constructed, not records of an outage or a live test.
| Elapsed time | Evidence available to the operator | Consequence for a backup purchase |
|---|---|---|
| 0 seconds | A's 0.800 ETH buy is submitted with a recorded client ID. | The submitted amount belongs to the original intent. |
| 10 seconds | A's response is missing; order reads are unavailable. | Up to 0.800 ETH could still be acquired on A. |
| 15 seconds | B accepts orders and quotes a usable limit of 2,510 USDT. | B's health establishes nothing about A's order. |
| 20 seconds | A becomes readable: 0.220 ETH filled, remainder open. Cancellation is requested. | Another 0.580 ETH could still fill while cancellation is unresolved. |
| 25 seconds | A's terminal canceled record and executions show 0.300 ETH filled. | A can add no further quantity from this order; its 0.300 ETH must remain in the combined ledger. |
Suppose an impatient failover process buys the full 0.800 ETH on B at fifteen seconds. When A's final fill is recovered, the combined purchase is 1.100 ETH, or 37.5% above the intended quantity. Its gross cost is 2,758 USDT: 750 on A plus 2,008 on B.
The error is possible even though each venue processes only one valid order. Neither exchange sees the other order as a duplicate of its own. Local order validity and compliance with the strategy's combined limit are separate checks.
The cancellation request at twenty seconds also cannot release the entire remainder immediately. Bybit, for example, documents cancellation acknowledgement as acceptance of an asynchronous request and requires status confirmation. This is one documented implementation of why a cancel acknowledgement must be distinguished from a final order state. Bybit cancel order.
Reserve what the original order could still do
For this simple buy-only example, maintain three quantities across the whole intent:
- Confirmed gross ETH acquired on every venue.
- Maximum additional ETH that open or unresolved attempts could acquire.
- Any new quantity being considered on the backup.
Their sum must remain within the authorized 0.800 ETH limit. The second quantity is a conservative planning reservation; it is not a claim that the exchange has locked those funds or that the order will fill.
At ten seconds, confirmed quantity is zero and maximum possible additional quantity is 0.800 ETH. Backup room is zero. At twenty seconds, 0.220 is confirmed and another 0.580 remains possible. Backup room is still zero. Do not add the entire 0.800 original quantity to the 0.220 fill: the original maximum already includes that fill.
Only at twenty-five seconds does this order's additional possible quantity become zero, leaving 0.500 ETH of quantity room. The state change comes from verified terminal evidence and cumulative executions, rather than from waiting a chosen number of seconds.
This bound depends on a complete submission inventory. If another worker could have submitted a second order, or an amendment changed the amount, the original 0.800 ETH is no longer a sufficient bound. Keep the incident unresolved until those attempts are accounted for.
Check the spending limit again at the backup price
Quantity room does not establish spending room. A's final 0.300 ETH costs 750 USDT, leaving 1,250 USDT of the original gross budget. Buying the remaining 0.500 ETH at B's hypothetical limit of 2,510 costs 1,255 USDT and would exceed that budget.
The budget permits 1,250 / 2,510 = 0.498007968... ETH. Assume B's fictional instrument requires quantities in 0.001 ETH steps and all its other order constraints are satisfied. Rounding down gives 0.498 ETH.
| Reconciled purchase | ETH | Gross USDT cost |
|---|---|---|
| Final acquisition on A | 0.300 | 750.00 |
| Maximum modeled backup order on B | 0.498 | 1,249.98 |
| Combined if B fills completely at its limit | 0.798 | 1,999.98 |
| Remaining difference to the original quantity target | 0.002 | 0.02 USDT left in the gross budget |
Leaving the 0.002 ETH difference unfilled respects both modeled limits. Raising the budget to complete the quantity would be a new authorization decision.
The 0.001 step is illustrative, not a current ETH trading specification. Read the backup venue's actual instrument rules. Binance Spot, for example, documents quantity steps, price ticks and notional rules as separate filters. The order minimums guide explains how those constraints can leave no valid remainder. Binance Spot filters.
Real budgets also need fees and any price tolerance. If the original authorization capped every purchase price at 2,500, the 2,510 backup order would be ineligible regardless of the remaining budget. This example authorizes a combined quantity and gross spending cap, not that stricter per-unit price ceiling.
Carry the intent across venues, keep order identities local
Use one durable intent record with separate children for each venue attempt. Record venue, account or subaccount, environment, product, symbol, quantity units, side, client ID, exchange ID, executions, fees and observation time. Preserve rejected and unresolved attempts as well as successful ones.
Binance's order query uses the symbol and either its order ID or original client order ID. Its account trade records include execution quantities and commission assets. These fields support attribution within the targeted account; a balance snapshot alone does not explain which order changed it. Binance Spot account API.
Reusing a client ID is insufficient protection. Binance defines its new client order ID as unique among open orders and allows acceptance after the previous order fills. That documented scope does not provide a shared duplicate check with another exchange. Binance new-order rules.
Confirm the backup's units too. Bybit's API distinguishes quote-value and base-quantity modes for spot market buys. Copying a numeric quantity without its unit can change what the new request means. Bybit place order.
Keep funding boundaries explicit. The subaccount isolation worksheet helps identify which balances and authority belong to each target. A funded backup account is additional available capital; it does not increase the strategy's authorized purchase budget.
Prevent the original process from waking up and trading again
A replacement process needs exclusive authority over the intent. Otherwise, the original worker can reconnect, continue its retry queue and submit while the backup is acting on the same target.
Record an operational owner and a generation or revision for the handoff. Stop old submission queues and require the execution boundary to reject obsolete authority. A timer or expired worker lease alone is insufficient if an old process can still send authenticated writes. If the system cannot enforce that boundary, keep automatic submission paused and assign one operator to coordinate the recovery.
Protection also remains local to the exposure. A sell or short on B does not cancel A's buy or remove A's account obligations. For derivatives, a nominally offsetting position introduces separate collateral, liquidation, funding and contract terms. It requires a separately approved risk decision; do not treat it as proof that A is closed.
If the backup route uses a DEX, the handoff must also track the pending transaction through its EVM nonce and replacement lifecycle. Include the separate network-cost questions covered in gas accounting for failed swaps before authorizing that route.
A worksheet for authorizing the handoff
Complete this record before a backup order is allowed:
| Decision field | Evidence to write down | Keep submissions paused when |
|---|---|---|
| Original authority | Every writer and attempt belonging to the intent | Another process may still submit |
| Original state | Exact account, order identities, final or open status, cumulative fills | Status or execution history conflicts |
| Uncertainty reservation | Maximum further acquisition and spending from unresolved attempts | The maximum cannot be established |
| Combined limits | Confirmed amounts plus reservations, against quantity and budget limits | Proposed backup exceeds either limit |
| Backup eligibility | Correct account, product, units, current rules, funds and fresh market inputs | Any required field is unverified |
| Position management | Location and quantity of exposure, outstanding exits and responsible operator | An exit or protective order is assumed to cover another venue |
An empty open-order screen does not complete the original-state row. Bybit notes that its recent closed-order cache has limits and that closed Unified-account orders need the history interface after a server restart. Use the appropriate history and execution records when recovering an outage. Bybit open and closed order queries.
Before depending on this procedure, rehearse dropped submission replies, delayed fills after a cancel request, an empty recent-order cache, and the original worker reconnecting during handoff. In a paper or fault-injection exercise, verify that each case preserves reservations and blocks conflicting writers. Include a backup rejection so the system does not silently reopen A's submission queue.
Resume only from an explained combined ledger. For the modeled purchase, that ledger permits at most 0.498 ETH on B after A is resolved, while the original 0.800 ETH remains fully reserved during uncertainty. The useful failover result is a bounded next decision that remains valid when the first venue returns.