Version Control and Change Logs for Deriv Bot Iterations

A disciplined version control workflow turns a Deriv bot from an undocumented sequence of edits into a reproducible research artifact. The core practice is simple: every strategy iteration gets a version identifier, a written hypothesis, a recorded configuration, and a change log entry that states what was tested and what happened. This article describes a concrete workflow for DBot strategies and Deriv API bots: how to structure the repository, what a change log entry must contain, how to link backtests to exact code states, and how to use that record to decide whether to roll back. The goal is not more process for its own sake; it is to make backtests reproducible and rollback decisions evidence-based rather than emotional.

Trading involves significant risk and you can lose your entire stake. Test every strategy on a demo account first.

The minimum viable repository structure

Treat each bot as a small software project with a research log attached. A working structure looks like this:

`strategies//` — one directory per strategy family.
`strategies//v001.xml` — exported DBot blocks, or the equivalent Deriv API script, one file per version. Never edit a released version file in place; create the next version.
`strategies//CHANGELOG.md` — the human-readable history.
`strategies//config/` — parameter files: stake, duration, market symbol, contract type, session limits.
`backtests//` — raw results, one file per run, named by version and run identifier.
`docs/rules.md` — the written strategy rules and risk limits, versioned alongside the code.

The exported DBot strategy file is the artifact of record. DBot allows you to save and load strategies, and the exported file is what you can diff, archive, and reload later. For bots built directly on the Deriv API, the script file plays the same role; the official Deriv API libraries are the reference for client code. Either way, the rule is that the file in the repository is the only version that is allowed to run. If you edit blocks inside Deriv Bot without exporting, you have an untracked change and no reproducible record.

A practical convention: version numbers are `vNNN`, monotonically increasing, and a version is “released” only when it has a change log entry and at least one recorded backtest run. Anything else is a draft and must be labelled as such in the file name, for example `v004-draft2.xml`.

What a change log entry must contain

A change log that only says “tweaked stake” is worthless for rollback decisions. Each entry should answer five questions in a fixed format.

Version and date. The version identifier and the date the change was made.
Hypothesis. One or two sentences stating what you expect to change and why, written before testing. For example: “Raising the take-profit threshold on Multipliers from 2x to 3x will reduce trade frequency and may reduce drawdown, at the cost of lower expectancy per session.”
Exact changes. A diff-level description: which blocks, parameters, or code lines changed, with old and new values. “Stake: 0.35 → 0.50” is a change log entry; “adjusted stake” is not.
Test record. Which backtests were run, on what data window, with what sample size, and how many configurations were tried in total. This last number matters because trying many variants and reporting only the best one inflates apparent performance.
Decision. Promoted to demo, held, or rejected, with the reason. A rejection is a result and should be recorded.

A short template:

## v007 — 2026-11-10
Hypothesis: switching from Rise/Fall to Digits Over 2 on R_100
  reduces variance per contract at equal stake.
Changes: contract_type RISE_FALL -> DIGITOVER; barrier 2;
  stake 0.35 -> 0.35 (unchanged); duration 5 ticks (unchanged).
Tests: 3 configurations tried; 2,000 simulated contracts each,
  in-sample window 2026-01-01..2026-06-30, out-of-sample 2026-07-01..2026-09-30.
Result: in-sample expectancy per contract +0.004 at payout 1.95x;
  out-of-sample expectancy negative. Rejected.
Decision: not promoted; v006 remains the demo candidate.

Note the honesty of the last two lines. A negative out-of-sample result recorded in the log is more valuable than ten undocumented “improvements,” because it prevents you from re-testing the same idea in three months and prevents you from promoting a version whose only evidence was in-sample.

Worked example: linking a backtest to a version and a rollback decision

Suppose a bot trades Rise/Fall on a synthetic index with a payout of 1.95x per successful contract, meaning a win returns 0.95 times the stake and a loss returns the full stake. The break-even win rate is the stake divided by the total return on a win, which is 1 / 1.95 ≈ 0.5128, or about 51.3%. This arithmetic is the only honest way to read a win rate: a 54% win rate sounds strong but is only about 2.7 percentage points above break-even before costs and variance, and a 50% win rate at this payout is a losing strategy by construction.

Now consider two versions, both with a fixed stake of 0.50 USD per contract, which under a fixed-stake contract is also the maximum loss per contract. Assume a demo balance of 200 USD, so the stake is 0.25% of balance, comfortably inside the 1% ceiling.

v005: recorded over 1,000 demo contracts, 540 wins and 460 losses. Gross result: 540 × (0.50 × 0.95) − 460 × 0.50 = 540 × 0.475 − 230 = 256.50 − 230 = +26.50 USD. Win rate 54.0%, expectancy per contract +0.0265 USD.
v006: same market and stake, but a narrower entry filter that halved trade frequency. Recorded over 500 contracts, 262 wins and 238 losses. Gross result: 262 × 0.475 − 238 × 0.50 = 124.45 − 119.00 = +5.45 USD. Win rate 52.4%, expectancy per contract +0.0109 USD.

Both versions are positive in this illustrative sample, but v005 has roughly 2.4 times the expectancy per contract of v006 (0.0265 / 0.0109 ≈ 2.43). The rollback question arises when a later version, v007, is promoted to demo and underperforms. Suppose v007 is stopped by its own daily loss limit after 300 contracts with 140 wins and 160 losses: 140 × 0.475 − 160 × 0.50 = 66.50 − 80.00 = −13.50 USD, a win rate of 46.7%, well below the 51.3% break-even. The change log shows v007’s only stated benefit was a higher theoretical win rate from a wider entry filter, and the out-of-sample test had already shown negative expectancy. The rollback decision is not a judgment call about “bad luck”; the record shows the hypothesis failed its pre-registered test and the live-demo sample confirmed it. Roll back to v005, archive v007 with its result, and write the next hypothesis.

Two cautions on this example. First, 500–1,000 contracts is a modest sample; the difference between 54.0% and 52.4% observed win rates is within the range that sampling noise can produce, so neither figure should be treated as an estimate of future performance. Second, the expectancy figures are computed from stated assumptions and are illustrative, not evidence about any real market. A backtest is a filter, not proof.

Rules, limits, and what the bot must enforce itself

Version control is only half of discipline; the other half is that risk limits live in the bot, not in your intentions. Before any version is promoted to demo, `docs/rules.md` must specify the maximum loss before the expected gain, the per-contract stake (at most 1% of balance, ceiling 2%), and hard automatic limits: daily loss, maximum drawdown, and consecutive losses, after which the bot stops by itself. For fixed-stake contracts such as Rise/Fall and Digits, the stake is the maximum loss on the contract; stop-loss and take-profit by price exist only for Multipliers. Session limits, not price stops, are how fixed-stake risk is bounded.

If a strategy uses any stake progression, the rules file must cap the number of steps and the maximum stake, and a ruin test must be run before demo promotion. ORSTAC recommends against martingale; many community bots still use it, and the reason to avoid it is arithmetic, not taste: doubling after losses grows stake geometrically while the payout per win stays linear, so a short losing run can exhaust a balance that a flat-stake version would survive. Any progression that is tested must be logged as its own version with its own ruin test, never slipped in as a parameter tweak.

A minimal promotion checklist, applied in order:

Rules written and committed in `docs/rules.md` before testing.
Version file exported and committed; change log entry written with hypothesis and exact changes.
Backtest run with a large sample, an out-of-sample window, and a count of configurations tried.
Demo run recorded with a stated sample size; results appended to the change log.
Limits verified in the bot: daily loss, drawdown, consecutive losses, and session stop all trigger automatically.
Promotion decision recorded, including rejections.

Limitations

This workflow does not make a strategy profitable, and it does not validate one. It cannot remove sampling noise from small demo samples, correct for a backtest engine that models fills or payouts differently from the live platform, or detect regime changes in synthetic indices or forex markets. It does not substitute for the platform’s own contract specifications: payout, duration, and barrier behaviour depend on settings you must verify in the Deriv API documentation and on the platform itself. A clean change log only guarantees that you know what you tested and what happened; it says nothing about what will happen next. Demo trading removes financial risk but not behavioural or execution differences, so a demo result is a filter on execution and discipline, not a forecast.

Frequently Asked Questions

Do I need Git, or is a folder of exported files enough?

A folder of exported files with a disciplined naming scheme is enough to start, but a version control system such as Git adds diffs, timestamps, and the ability to check out an exact past state, which is what makes rollback decisions cheap.

How large a demo sample is enough to promote a version?

There is no universal number; the honest answer is that the sample must be large enough that the result is not dominated by a handful of contracts, and the change log must state the sample size so the claim can be judged. Record the sample, report expectancy and drawdown alongside win rate, and treat small samples as inconclusive rather than as confirmation.

Should I change the strategy right after a losing session?

No. Rules are written before trading, and changes follow the process: hypothesis, test, version. A change made immediately after a loss is usually a reaction to variance, and the change log exists partly to make that visible.

Key Takeaways

Every strategy iteration gets a version file, a written hypothesis, and a change log entry with exact parameter changes and a test record.
Link each backtest result to the exact version and configuration that produced it; record how many configurations were tried.
Judge versions by expectancy, break-even rate, and drawdown, not win rate alone; at a 1.95x payout the break-even win rate is about 51.3%.
Rollback decisions should cite the failed pre-registered test, not the most recent losing session.
Risk limits — stake, daily loss, drawdown, consecutive losses — belong in the bot and are verified before demo promotion.

The workflow above is the one ORSTAC uses for its open-source bots; the ORSTAC repository contains the bot code and the structure to adapt. The bots run on Deriv, where a free demo account is available to test them, and the synthetic indices documentation describes the markets most community strategies target. Questions about versioning conventions and change log formats are welcome in the ORSTAC Telegram group.

Trading involves significant risk and you can lose your entire stake. Test every strategy on a demo account first.