Walk-Forward Testing for Crypto Bots: A Worked Example
Choose settings on earlier data, freeze them for a later window, and preserve the equity path. Work through the date split, selection rule, compounding, and open-inventory decisions.
You test twenty bot configurations on the same chart and choose the one with the highest return. Its settings now reflect information from that entire period. Running it on the same dates again gives you no fresh evidence.
Walk-forward testing repeatedly chooses settings on an earlier training window, freezes them for a later test window, and combines the results from those later windows. It helps you examine a selection process across changing conditions while keeping future prices out of each selection decision.
For GRID and DCA strategies, there is an extra accounting problem: coins and open positions can survive the window boundary. A useful test needs a rule for those holdings before the first result appears.
Training, testing, and forward demo mean different things
| Term | What you do | What it can show |
|---|---|---|
| In-sample training | Compare permitted settings on an earlier historical window | Which candidate your selection rule would choose |
| Out-of-sample historical test | Run the chosen settings on the next window without retuning | How that selection behaves on later historical data |
| Walk-forward sequence | Repeat training and testing as time advances | The combined behavior of the selection process |
| Forward demo | Freeze a setup and observe new market data with virtual funds | Whether the workflow and behavior match your plan in a new period |
The general backtesting guide covers the wider limitations of historical simulation. Walk-forward adds a repeated time split; it does not remove execution assumptions, data errors, or the temptation to revise rules after seeing results.
QuantConnect's walk-forward documentation describes parameter selection over trailing windows and the trade-off in optimization frequency. Re-optimizing more often creates more decisions and more opportunities to fit recent noise.
Write the protocol before comparing results
Choose the market, data interval, time zone, and exact candidate settings. Keep the candidate list small enough to inspect. A test of three declared configurations is easier to explain than a search through thousands of undocumented combinations.
Also specify:
- The training length and test length, including exact boundary timestamps.
- The selection metric, minimum evidence requirement, and tie-break rule.
- Fees, slippage, minimum sizes, rounding, and the fill model.
- The treatment of holdings and open orders at each boundary.
- The benchmark's starting assets and rebalancing rules.
For example, a hypothetical protocol could choose the highest training return among three candidates whose training drawdown stays below a stated limit. If none qualifies, the strategy holds cash for the next test month. Define the drawdown limit and fallback before looking at the test months.
The limit is a selection constraint, not a promise about future drawdown. A strategy that passes it in training can exceed it in testing.
Split the dates without counting a test month twice
Use three months for training and one month for testing in this illustrative rolling schedule. Every timestamp below is in UTC, and each interval includes its start and excludes its end.
| Round | Training window | Untouched test window |
|---|---|---|
| 1 | Jan 1 to Apr 1 | Apr 1 to May 1 |
| 2 | Feb 1 to May 1 | May 1 to Jun 1 |
| 3 | Mar 1 to Jun 1 | Jun 1 to Jul 1 |
| 4 | Apr 1 to Jul 1 | Jul 1 to Aug 1 |
Training windows overlap. The four test windows do not. April can become historical training data for the next round after it has finished; you cannot use April's price path to choose the settings tested on April itself.
Save the selection made at each boundary. A complete record includes rejected candidates and their training metrics, so another reviewer can reconstruct why the winner was chosen.
A complete first round
The following table contains invented teaching values. They are not measured backtest results or market observations. Assume the written selection rule requires training drawdown of no more than 10%, then picks the highest net training return. All returns are after the model's stated costs.
| Candidate | Training return | Training maximum drawdown | Eligible? |
|---|---|---|---|
| A | +5.0% | 8.0% | Yes |
| B | +8.0% | 15.0% | No |
| C | +4.0% | 6.0% | Yes |
The protocol selects A. Candidate B's higher return does not override the declared drawdown constraint. Candidate C remains in the record even though it loses the comparison.
Freeze A for April. Suppose the teaching example assigns it an April net return of −2%. That value enters the out-of-sample record. Switching to C because it would have handled April better would reuse the test month in the decision.
At the May boundary, the original protocol compares all candidates again using February through April. It can select C for May if C wins that new training comparison. This is a planned update using information available at that time.
Join the later test windows into one equity path
Assume the next selections and test returns are as follows. These values continue the same fictional accounting example and do not come from a real strategy simulation.
| Test month | Selected configuration | Net test return | Starting equity | Ending equity |
|---|---|---|---|---|
| April | A | −2.0% | $1,000.00 | $980.00 |
| May | C | +1.0% | $980.00 | $989.80 |
| June | A | −3.0% | $989.80 | $960.11 |
| July | C | +2.0% | $960.11 | $979.31 |
The underlying unrounded ending values are 980, 989.8, 960.106, and 979.30812. The combined return is:
(1 − 0.02) × (1 + 0.01) × (1 − 0.03) × (1 + 0.02) − 1 = −2.069188%.
Adding the four percentages gives −2%, which differs from the compounded result. Carry the previous window's ending equity into the next one and round only for display.
The month-end observations show a deepest decline of about 3.99% from the initial $1,000. Intramonth equity could have fallen further, so monthly observations cannot establish the true maximum drawdown.
For this accounting example, assume every boundary reset is included in the stated net monthly returns. A real backtest must calculate those resets from its holdings and execution model.
Decide what happens to open GRID or DCA inventory
Suppose a bot finishes April holding 0.01 BTC and 400 USDT. At a hypothetical $50,000 BTC mark, its equity is 900 USDT. A new month does not restore it to the original 1,000 USDT.
Choose one consistent boundary policy:
Carry the holdings. Transfer the actual coins, cash, and position state into the next test window. Define what a settings change does to existing orders and inventory. The simulator must support that transition; a fresh backtest started with default assets may not represent it.
Close and reset. Cancel outstanding orders, sell or close remaining exposure using the declared execution model, deduct costs, and begin the next window with the resulting equity. If the next setup needs starting coin inventory, model that acquisition and its costs too.
Either policy can describe a real operating process. Mixing them after seeing results can hide losses. Keep the same policy in the benchmark where relevant and show the effect of a different policy as a separately labeled sensitivity check.
Check the fill model and benchmark
A candle touching a limit price does not prove your order could have filled in full. Candle data may also hide whether a buy level or a sell level was reached first. Dense grid settings can look attractive in a simulation that assumes favorable intrabar ordering.
Document the model's treatment of partial fills, queue priority, spread, and gaps. Repeat the analysis with less favorable costs or fills where the tool supports it. A conclusion that disappears after a small cost change deserves investigation.
Use the same dates, starting equity, and initial assets for the comparison. A bot starting half in coins and half in cash is not directly comparable with a benchmark starting fully invested unless you explain that allocation difference.
The backtest-results checklist is useful for reviewing the resulting report. Keep the monthly path, trading activity, exposure, and costs alongside the total return.
Keep the final evaluation separate from protocol design
Repeated walk-forward tests can themselves become training. If you inspect all four test months, change the candidate list, and rerun the same period, the updated method has used information from those months.
Log that revision and reserve later untouched history or new forward data for the next evaluation. A new label on the same dates does not make them unseen again.
The downloadable record can be simple: one row per round with training dates, candidate version, selection metrics, chosen configuration, test dates, cost model, boundary policy, and net test result. Retain the raw reports and data references beside it. The example below includes the fictional table as an exportable CSV for practicing the accounting.
Follow historical checks with a fixed demo run
Practice the example's accounting
Download the four fictional test-month rows, including start and end equity. These are invented teaching values, not a backtest report.
Observe your setup in Bitsgap demo
After completing your historical analysis in a tool that supports the required windows and accounting, freeze a supported bot configuration in Bitsgap demo. Record its starting assets and settings, then observe it with virtual funds and current market prices. Demo is a separate forward exercise; this workflow does not assume a built-in walk-forward optimizer.
Frequently asked questions
Does walk-forward testing prevent overfitting?
It reduces one source of in-sample bias by separating each selection window from its later test. Repeated protocol changes, data leakage, unrealistic fills, and selective reporting can still produce misleading results.
How long should the windows be?
There is no universal length. The trading frequency, available history, and selection method determine how much evidence each window contains. The three-month and one-month split here is a teaching example.
Can I add the returns from separate test windows?
Compound sequential returns when each window starts with the previous window's ending equity. Also preserve the underlying equity path, costs, and exposure; a final percentage alone hides important differences.
Is forward demo the same as an out-of-sample backtest?
A historical out-of-sample test uses later historical data under a simulator. Forward demo observes new data with virtual funds. Both have limits, and neither guarantees live fills or future returns.
