A DCA bot restart budget ledger should restore saved purchase reservations, reconcile offline fills and unresolved submissions, and recalculate spendable cash before admitting another deal. An exchange balance alone cannot reveal promises for safety orders that have not been placed. Keep each commitment in one bucket, retain uncertain amounts until their outcome is established, and verify both cash availability and the strategy's remaining authorization.
Restarting the process does not release its promises. The practical question is how much the bot may commit next after accounting for everything that can still spend money. This guide uses an illustrative unleveraged spot ledger; futures collateral, borrowing and funding need different accounting.
Recover commitments, not just open orders
An order already resting at an exchange can lock quote currency. A future safety purchase may reserve nothing at the venue while still being part of the bot's authorized ladder. A submission awaiting reconciliation may belong to either category—or may already have filled.
Binance's Spot account and order reference reports asset balances separately as free and locked, and exposes order status and executed quantity. Those observations help reconcile spending; they do not describe your bot's unsent purchase promises.
Use separate records for these states:
| Budget state | Recovery evidence | Admission treatment |
|---|---|---|
| Confirmed purchase cost | Booked executions and fees | Consumes the applicable purchase authorization; already absent from current cash |
| Known open purchase remainder | Reconciled order quantity and price | Count once as a remaining commitment; identify any corresponding venue lock |
| Authorized future purchase | Persisted ladder and reservation | Deduct from free cash available for other deals |
| Submission outcome unknown | Durable intent and unresolved request | Retain an uncertainty hold; reconcile before reuse |
| Released reservation | Verified terminal outcome and recorded policy decision | Reusable only after any fills and continuing promises are accounted for |
First establish which saved intentions the orders belong to using the startup order-adoption guide. That ownership question is separate from reconstructing how much budget those intentions still consume.
A restart ledger with an offline fill
Consider a fictional ABC/USDT spot bot. All quantities satisfy the assumed venue rules. There are no sales, transfers or fees in the observed executions. USDT amounts are units of quote currency, not a claim about their dollar value.
Before the interruption, the bot had booked 420 USDT of purchases. A known safety order had 280 USDT remaining. The saved plan also reserved 200 USDT for later buys, and another 100 USDT submission had no confirmed outcome.
During recovery, execution records establish that 80 USDT of the known safety order filled offline. Apply that missing execution once: booked purchases become 500 USDT, and the open remainder becomes 200 USDT. Do not add 80 to purchases while leaving the original 280 reservation unchanged.
| Commitment | Before outage | After reconciliation | Change |
|---|---|---|---|
| Booked purchase cost | 420 | 500 | +80 |
| Known open buy remainder | 280 | 200 | −80 |
| Authorized future buys | 200 | 200 | 0 |
| Unresolved submission hold | 100 | 100 | 0 |
| Total consumed or promised | 1,000 | 1,000 | 0 |
The fill moved 80 between buckets. It did not create a second 80 commitment or release 80 for a new deal. An account trade record can also identify the commission and its asset; reconcile those separately when fees exist rather than assuming gross purchase quantity equals net inventory.
Suppose the recovered account reports 1,300 USDT total quote cash: 1,100 free and 200 locked. The lock is fully attributed to the known open buy. The unresolved 100 remains a conservative hold with no verified overlap against that lock. The account owner excludes 300 USDT from this bot and sets aside a hypothetical 30 USDT operating allowance.
| Cash admission line | USDT |
|---|---|
| Observed free quote balance | 1,100 |
| Cash outside this bot's allocation | −300 |
| Operating allowance | −30 |
| Future buys not exchange-locked | −200 |
| Unresolved submission hold | −100 |
| Provisional headroom | 470 |
Starting instead from total quote cash gives the same result: 1,300 − 200 − 300 − 30 − 200 − 100 = 470. Starting from free cash and subtracting the known 200 lock again would incorrectly produce 270. Subtracting the 500 already spent from today's cash would double-count historical spending.
The capital-requirements guide explains the underlying free-versus-total distinction. The restart-specific task is proving which persisted amounts belong in each column now.
Cash headroom is only one admission test
Assume a separate written purchase cap of 1,500 USDT, with no authorization released by sales in this example. The restored 1,000 consumed-or-promised total leaves 500 under that cap. Cash permits at most 470 under the stated allowances. A proposed 480 USDT full ladder passes the purchase-cap test but fails the cash test by 10.
That 470 is provisional arithmetic, not permission to trade while the 100 submission remains unresolved. A conservative recovery policy can block new exposure in the affected quote pool until uncertainty is resolved. If the policy permits unaffected activity, it must define that scope and preserve the hold.
A free deal slot is another separate constraint. Once recovery permits admission, the deal-entry queue guide addresses which eligible request receives capacity. A queue should consume reconciled headroom; it should not reconstruct money from scratch each time a process starts.
A vanished order does not release its whole reservation
A purchase can disappear from open orders because it filled, was canceled, expired or falls outside the queried scope. A canceled order may already have partially filled. Reconcile its executions, terminal state and any replacement instruction before changing the reserve.
Binance's Spot REST API guidance explicitly says a timeout can leave execution status unknown and recommends a status query when the result has not appeared in the user stream. It also documents asynchronous data sources. A missing acknowledgment therefore does not justify releasing the money and submitting a fresh purchase. The order-timeout procedure covers that investigation.
If the uncertain 100 is confirmed fully filled, move it to purchase cost and reconcile the reduced cash. If it is confirmed unfilled and terminal, the written strategy may release it or retain it for an authorized replacement. If it remains unknown, preserve the hold and escalate the discrepancy. Elapsed downtime is not evidence of rejection.
Closure also needs care. A deal can leave units too small to sell under current filters. The dust-residual closure guide separates operational closure from residual holdings. Record that inventory and its treatment before allowing a deal-closure event to reset every budget field.
Make the recovery decision durable
Ask how the software saves an intent and its reservation together, and how it prevents two recovering workers from spending the same headroom. PostgreSQL's transaction documentation explains all-or-nothing local updates and durable commits. That principle supports recording a reservation with its intention; a local database transaction does not make a remote exchange order part of the same atomic operation. Uncertain remote effects still need reconciliation.
A useful restart receipt records the account and quote asset, saved checkpoint, queried scope, missing executions applied, outstanding holds, cash basis and next permitted action. Retain reservation changes as attributable transitions rather than overwriting a single “available” number. Replaying the same execution should not spend the budget twice; restarting again should recover the same commitments unless new evidence changes them.
Before relying on a recovery design, test an offline partial fill, a lost acknowledgment, a cancel racing with a fill, a stale snapshot and two simultaneous restarts. The expected outcome is a reconciled ledger or an explicit hold with an owner. This is an evaluation worksheet, not a claim that KLINEO or every exchange exposes these recovery controls. A correct ledger can prevent reuse of already-promised cash; it cannot prevent the acquired asset from losing value.
Editorial method: This AI-assisted article uses primary exchange and database documentation with checked hypothetical arithmetic. No live restart or trading outcome was tested.