Editing a DCA bot's settings does not necessarily change its open deals. First verify whether the change applies to future deals, selected existing deals, or both. Preserve each deal's original configuration, adopt any revision explicitly, and recalculate remaining purchase commitments from confirmed fills and active orders before releasing cash or starting more deals.
A saved form answers what the bot is configured to use. It may leave unanswered what a deal opened yesterday will use for its next averaging purchase. That distinction matters most when an edit increases order sizes, adds more purchases or changes an exit that is already working at the exchange.
This guide uses unleveraged spot buying and a hypothetical settings migration. It provides an evaluation method; it does not establish which editing controls KLINEO supports.
Check whether the edit reaches existing deals
Find the product's documented scope before interpreting its Save button. A bot can supply a template for new deals while each open deal keeps its own settings. Alternatively, a particular control may offer an explicit update to selected active deals. Scope can differ by field and interface.
For a concrete vendor example, Gainium's Telegram control documentation says edits made through its bot-settings card apply only to new deals; open deals retain their levels and are changed through their deal cards. Its documented Telegram editing limits also exclude several DCA ladder types. That describes Gainium's interface, rather than a rule for every DCA product.
Use the following questions to classify a proposed edit. The possible effects are things to verify, not universal platform behavior.
| Proposed change | Scope question | Evidence needed for an open deal |
|---|---|---|
| Entry condition or base size | Is this used only when creating a deal? | Existing acquired quantity and entry history remain reconciled |
| Averaging size, spacing or count | Does this revise remaining purchases, already placed orders, or neither? | New remaining schedule, revised reservation and confirmed order states |
| Take-profit percentage | Does the deal adopt it, and when is its exit updated? | Effective target plus confirmed exit price and quantity |
| Maximum active deals | Does it restrict future admissions or affect existing deals? | Explicit treatment of deals already above the new limit |
| A cash or notional cap | Is it shared, per deal, or only a creation constraint? | Current commitments measured against that exact cap |
A lower displayed maximum does not itself prove that an existing purchase was canceled or that inventory was sold. Similarly, changing the initial order size cannot rewrite the price or quantity of a purchase that already filled.
Give the template and every deal separate revision records
Call the old template R7 and the revised template R8. These are invented identifiers. A useful record can show that new deals use R8 while Deal A and Deal B still use R7. That mixed population is understandable when adoption is explicit.
Keep the original settings attached to the deal's history. For an existing deal that adopts R8, add a change record with the previous revision, changed fields, effective event or time, and revised remaining commitments. Do not replace its history with today's template and imply that the deal always followed those rules.
If only take profit changes, record a take-profit revision while retaining the unchanged purchase plan. A single “R8” badge can otherwise conceal which fields actually moved. Products without exposed revision identifiers still allow an operator to retain dated exports or screenshots, although those records cannot prove what a worker loaded internally.
Also establish the creation boundary. A deal submitted while the template changes needs a known rule: for example, use the revision captured when the deal was admitted. “It started around the same time” is insufficient to decide its purchase authority.
Recalculate the remaining reserve, not historical spending
Consider two hypothetical spot deals. Each has already spent 100 USDT on its base purchase and 100 USDT on its first averaging purchase. Each R7 deal still authorizes purchases of 200 and 400 USDT: 600 USDT remaining per deal.
The proposed R8 migration preserves those confirmed fills and changes each adopting deal's remaining purchases to 250, 500 and 500 USDT. This constructed controller permits an explicit remaining-schedule revision; no particular product is assumed to support it. The new remaining commitment is 1,250 USDT per adopting deal, an increase of 650 USDT.
After the historical purchases, the shared account has 2,000 USDT of total quote cash. There are no unrelated commitments. A separate, illustrative 100 USDT allowance is excluded from purchase funding. Fees and execution deviations are omitted; the allowance is a chosen input, not a calculated ceiling on costs. All values are USDT units without conversion to dollars or an assumption about its peg.
| Adoption decision | Deal A remaining | Deal B remaining | Total remaining buys | Separate allowance | Uncommitted cash or shortfall |
|---|---|---|---|---|---|
| Save R8 for future deals; both existing deals retain R7 | 600 | 600 | 1,200 | 100 | 700 available |
| Apply R8 to A; B retains R7 | 1,250 | 600 | 1,850 | 100 | 50 available |
| Apply R8 to both existing deals | 1,250 | 1,250 | 2,500 | 100 | 600 shortfall |
For both deals, the edit adds 2 × (1,250 − 600) = 1,300 USDT of buying authority. The old 700 USDT headroom covers only part of that increase. Applying R8 to one deal fits the stated purchase ledger; applying it to both does not. Neither result says that the resulting exposure is suitable or profitable.
Saving R8 for future deals also does not establish that another deal is affordable. Its complete new-deal budget must fit beside the old deals' continuing commitments.
The 400 USDT already spent across the two deals is excluded from today's quote cash. Subtracting it again would count historical spending twice. The DCA capital-requirements ledger explains that distinction between the full campaign budget and its remaining funding.
Separate exchange locks from unplaced commitments
Suppose each old 200 USDT next purchase is already resting at the exchange. Of the 2,000 USDT quote cash, 400 is locked and 1,600 is free. Another 800 is promised for the two later 400 USDT purchases. Headroom is therefore 1,600 − 800 − 100 = 700 USDT, matching the first row.
Do not subtract the 400 lock again from the observed free balance. Conversely, do not treat the entire free balance as available for another deal: it still supports purchases not yet placed.
The table describes reconciled outcomes. During order replacement, old locks and new funding requirements may overlap. Do not release an old reserve while its cancellation outcome is unknown, and check whether the supported update procedure needs temporary additional funding. A final-state budget can fit while the transition cannot complete.
Adding money is a separate decision from adopting settings. If a deposit funds the shortfall, record it as contributed principal; the external-deposits and DCA performance guide explains why that cash movement is not a trading gain. For another reporting currency, use the quote-currency valuation guide before interpreting the USDT commitment as a fixed reporting-currency amount.
Verify adoption separately from order replacement
An accepted settings change and a confirmed exchange amendment are different observations. Binance's Spot cancel-replace documentation lists outcomes in which cancellation succeeds but the new order fails; its ALLOW_FAILURE mode can also attempt the new order after a failed cancellation. A combined request therefore needs its individual results checked.
For each selected deal, keep a short adoption receipt:
- Capture the old settings, confirmed fills, active order identifiers and remaining commitments.
- Specify the new values and exactly which deals and fields will adopt them.
- Validate the proposed remaining schedule against current funds, caps and venue constraints.
- Follow the product's supported update procedure and preserve unresolved order holds.
- Confirm resulting orders and any intervening fills, then record which revision is effective for the next action.
If a purchase fills during the update, rebuild the remaining schedule from that fill before completing adoption. The filled portion is now historical spending and inventory; canceling the remainder cannot erase it. If a replacement fails, record the actual mixed state and its next permitted action instead of marking the migration complete.
An exit edit needs its own confirmation. The take-profit recalculation guide covers target and quantity changes after fills. Updating a percentage in a deal record is insufficient evidence that the intended sell is active.
Validate one adoption boundary before a bulk edit
In a supported simulation or execution-disabled review, preserve an old deal and create a candidate under the new template. Check that a future-only edit leaves the old deal's remaining plan unchanged. Then evaluate an explicit existing-deal migration and verify the 650 USDT increase from this example, including its reservations.
Include a deal with every averaging purchase completed, a proposed maximum below the number already filled, and a fill arriving during adoption. Expected outcomes should be a documented valid remaining plan or a clearly rejected change. Reapplying the same confirmed revision should not add another 650 USDT reservation.
Before saving a real edit, write one sentence naming its scope, then retain one before-and-after receipt for an affected deal. If you cannot identify its effective settings, remaining purchase authority and confirmed exchange orders, resolve that uncertainty before expanding the change to the rest of the open deals.