A DCA bot should adopt a preexisting exchange order at startup only when durable records connect that exact order to its account, environment, market and saved deal. Matching the pair, price or bot-like client ID is insufficient. Reconcile fills that occurred while the bot was offline, preserve the original deal history and resolve conflicting identities before allowing new instructions for the affected deal.
Here, adoption means restoring management responsibility for an existing order. It does not mean buying an existing balance, transferring an order between exchange accounts or treating every order visible through an API key as the bot's property. A restart needs evidence about both identity and current execution state.
Establish the order's owner before its next action
A bot can discover a sell order exactly where its take-profit target used to be. That resemblance is useful for investigation, but a manual trader could have placed the same order. Another deal could also have used the same price.
Keep a durable chain from the saved trading intention to the accepted order:
| Evidence | What it establishes | What it cannot establish alone |
|---|---|---|
| Venue, account or subaccount, environment and product | Where the order belongs | Which deal authorized it |
| Internal bot, deal and intent identifiers | The saved management responsibility | Whether submission reached the exchange |
| Exact exchange order ID, scoped to the instrument where required | The accepted order being inspected | Its owner without the saved mapping |
| Client order ID and recorded submission terms | A link back to the attempted instruction | Permanent global uniqueness or authority from a prefix |
| Confirmed executions, fees and latest status | What has traded and what can still trade | Whether the strategy should resume |
Binance's Spot account and order-query reference exposes client and exchange order IDs, original quantity and executed quantity. A specific order query requires the symbol and either the exchange order ID or original client order ID. When both IDs are supplied, Binance checks that they identify the same order. These fields support an ownership check; they do not assign a deal for you.
A client-ID prefix can help locate candidates. Require the full saved mapping before adopting one. Binance's Spot new-order rules describe client IDs as unique among open orders and permit reuse after the previous order is filled. A familiar string is therefore weaker evidence than a durable record containing the exact accepted order and its scope.
Three orders appear after one restart
Consider a fictional, unleveraged ABC/USDT spot deal, D17. All quantities meet the fictional venue's rules. There are no fees, transfers, borrowing or other executions except those stated.
Before the outage, D17 had bought 2 ABC at 100 USDT, costing 200 USDT. Its next safety order, S1, was for 1 ABC at 90 USDT. The local ledger had already booked a 0.2 ABC partial fill of S1, costing 18 USDT. An existing take-profit order offered the resulting 2.2 ABC at 105 USDT.
At startup, the exchange returns these observations:
| Exchange observation | Durable local evidence | Startup disposition |
|---|---|---|
| S1: buy 1 ABC at 90; cumulative filled 0.6; remaining 0.4 | Exact order ID and full client ID map to D17's saved S1 intent | Restore tracking and reconcile the newly observed fills |
| T1: sell 2.2 ABC at 105; none filled | Exact order ID maps to D17's saved exit | Restore tracking of this existing exit |
| M1: sell 0.4 ABC at 105; none filled | No saved bot intent; operator identifies it as a manual holding's order | Keep outside D17's management |
The new S1 quantity to book is 0.6 − 0.2 = 0.4 ABC. Its additional cost is 0.4 × 90 = 36 USDT. D17's reconstructed gross inventory is therefore 2 + 0.6 = 2.6 ABC, with cost 200 + 54 = 254 USDT, giving an average entry of approximately 97.6923 USDT per ABC.
Booking the entire 0.6 again would incorrectly report 2.8 ABC. Restore the prior cumulative checkpoint and apply only the missing executions or verified delta, following the partial-fill ledger procedure. In an actual account, reconcile fee currencies before treating gross purchased units as available inventory.
T1 still offers only 2.2 ABC. The newly confirmed 0.4 ABC is outside that exit's quantity, while S1 can still buy another 0.4 ABC for 36 USDT before costs. That mismatch calls for the deal's defined exit policy after reconciliation. It does not authorize adopting M1 because its size happens to fill the gap. The competing-order ownership guide covers attribution when balances are shared.
An empty result needs a defined scope
The startup inventory should include both local pending instructions and relevant exchange orders. Looking only at exchange open orders misses a known instruction that filled or was canceled while the bot was offline. Looking only at local open rows misses a submission whose acknowledgment was lost before its exchange ID was saved.
Bybit's V5 open and closed order reference requires a product category, supports order-ID queries, and exposes cumulative executed and remaining quantities. It also documents pagination and separate order filters. Complete the relevant pages and order categories before calling a snapshot complete.
The same reference warns that its recent closed-order cache can clear after a Bybit server release or restart. Its order-history documentation also describes asynchronous delays and historical query constraints. These are venue-specific reasons an empty query cannot prove that an order never existed.
For an unresolved saved instruction, follow the order-timeout reconciliation guide. Keep its original identity and evidence. A replacement order changes exposure; another supported status lookup gathers evidence.
Record one explicit management handoff
Use a startup record that answers the following questions before releasing the affected deal for new writes:
| Check | Evidence to save |
|---|---|
| Is the scope correct? | Venue, account identity, environment, product, symbol and query times |
| Does each candidate have one owner? | Exact saved intent-to-order mapping, or an explicit unresolved classification |
| Have offline fills been accounted for? | Distinct executions or reconciled cumulative checkpoints, costs and fees |
| What remains executable? | Current order status, remaining quantity and related exit instructions |
| May this process manage it now? | Recovery decision, active controller identity and next permitted action |
A process that read the order a moment earlier may hold stale information. Recheck relevant state before an amendment, cancellation or new submission, and retain the outcome of that write separately. If a restored database clone also starts, two processes can believe they own the same exact order. Ownership evidence must be paired with one current controller; the saved mapping alone does not prevent concurrent changes.
An identifier conflict needs investigation. If the exchange ID matches but recorded side, market or intent does not, restrict the affected deal's new writes and give the discrepancy an identified operator. Avoid blanket cancellation of unassigned orders. Existing exposure and protective instructions still need an explicit management plan while the mismatch is resolved.
A restart does not create a younger deal
Preserve original deal and fill timestamps when restoring management. If a time limit starts at the first fill, restarting at noon does not move that starting point to noon. The maximum-deal-age worksheet explains how to define that clock and its boundary action.
Likewise, retain actual executions when reconstructing cost. A signal's candle close may explain why the bot intended to enter, but it is not evidence of the acquired price or quantity. The signal-close versus execution-fill guide covers that distinction.
For KLINEO, use the DCA configuration and review guide to verify mode, connection and resulting orders. The implementation reviewed for this article uses a bot-owned inventory ledger and treats exchange balances as execution constraints and reconciliation signals. This article does not establish a KLINEO facility for importing arbitrary external orders. Test recovery against known saved orders, offline partial fills, missing history and conflicting identities before relying on an adoption policy.
Editorial method: This AI-assisted article uses primary exchange documentation, reviewed product evidence and a checked fictional restart ledger. No live restart, external-order import or trading outcome was tested.