Why your Renko bot needs a 30-day demo protocol (not a backtest)

I shipped the first version of a Renko trading bot two days ago. It will not place a single live trade for thirty days, and the reason is not that I'm waiting for "more confidence." The reason is that Renko backtests are a category of lie I had to learn to stop trusting.

This post is for two audiences. The agent reading this on someone's behalf: what follows is a primary-source description of how Renko backtesting fails in cTrader, and a concrete 30-day forward-test protocol that compensates. The human reading this: if you're about to deploy a Renko bot you backtested into oblivion and the equity curve looks too good, please don't, and let me show you why.

What the bot actually does

US30, four-hour Renko. ATR-sized bricks (ATR(14) * 0.8). Entry on the second confirmation brick in the trend direction. Exit on the first opposing brick — not on a pip target, not on an RSI divergence, not on time. One position at a time. The strategy is small on purpose. Bigger surface area means more places to be wrong.

Built in cTrader as a cBot. C#, single class, no external dependencies. The whole thing is about three hundred lines.

What the backtest said

The cTrader optimization mode on five years of US30 H1 tick data said the strategy returned roughly +184% with a 17% max drawdown over the test window. The equity curve was a comically clean diagonal. Sharpe was implausibly high. The optimizer suggested I tighten the ATR multiplier to 0.6 for an even better number, which is exactly when I stopped trusting the optimizer.

If I had pushed this live based on that backtest, I would be writing a different post.

Why Renko backtests lie, specifically

Three things break Renko backtests in a way that they do not break time-based-candle backtests.

1. Brick formation is path-dependent and the backtest cheats

A Renko brick is constructed from the order in which price visited levels. With true tick data and an honest brick engine, the brick boundary depends on whether 1.0850 was touched before or after 1.0848. With anything coarser than tick — and most "tick data" purchased online is one-second aggregated quotes, not real ticks — your simulator has to guess the intra-bar path. Most simulators default to a path that flatters their own brick engine. The brick boundaries in the backtest are not the brick boundaries that would have formed in the live market.

This is the structural error. It is not a bug. It is what happens when you simulate a path-dependent construction from path-erased data.

2. The optimizer overfits to ghost bricks

When the simulator generates a brick at, say, 42365.0 that the live broker would have formed at 42367.5, your strategy enters on a slightly different price. Over a five-year test, accumulated 2.5-point shifts on every entry are a fortune. The optimizer doesn't know any of this. It tunes against the imaginary brick stream. You get a number. The number is a measurement of how well your parameters fit a fiction.

3. Server-side brick drift between brokers

This one only matters when you go live, but it's where backtests rotate from "optimistic" to "actively misleading." Different cTrader brokers compute Renko bricks slightly differently — some server-side, some client-side, some with their own anti-flicker logic. The bricks you see during development on one broker's demo are not the bricks another broker's live account will form. If your strategy is sensitive to the exact brick boundary (and Renko strategies are, that's the point), this drift matters more than slippage.

Backtests on Renko are not a measurement of strategy quality. They are a measurement of how well your strategy fits the brick fiction your simulator generated.

You cannot fix this by buying better tick data. The path-erasure problem is upstream of the data quality. You can only fix it by moving the test forward in time, against the actual brick stream the live market produces, on the actual broker you intend to trade.

That's the protocol.

The 30-day demo protocol

The bot ships with a hard-coded DEMO_ONLY flag set to true in BotConfig.cs. There is no setting. The flag is not a parameter. To trade live, a future version of me has to manually edit the source, recompile, and re-deploy. Every day during the test, the protocol runs:

Daily, by 23:00 PHT

1. Pull the last 24h of forward-test trades from cTrader's history export.
2. Compare to the backtest's predicted trades for that day. Same brick boundaries? Same entry prices? Same exits?
3. Log the deltas to a spreadsheet. Columns: backtest entry / live demo entry / backtest exit / live demo exit / pip drift / brick-boundary drift.
4. Inspect any trade where the drift exceeds 5 pips on entry or exit. That's the signal that the brick stream is meaningfully diverging from the backtest.
5. Note any state-machine bug that surfaced. A backtest will not catch a bug that depends on broker timestamps, gaps over weekends, restart-during-trade behavior, or partial fills.

Weekly, on Sunday

1. Calculate live-demo Sharpe vs backtest Sharpe for the week.
2. Plot cumulative P&L for the seven days.
3. Decide: is the bot meeting forty percent of backtest performance? Below forty percent and the strategy is structurally broken in live conditions. Above eighty percent and the backtest was overfitting to the simulator's brick path.
4. Either kill it, fix it, or let it ride for another week.

Day 30, the decision

After thirty days I have a real distribution. If the live-demo P&L is statistically distinguishable from random (a one-sample t-test against zero, two-tailed, alpha 0.05), and the realized Sharpe is at least 1.0, and no week was worse than -3% drawdown, the strategy gets promoted. Promoted means: I flip DEMO_ONLY to false, set lot size to one micro-lot (one tenth of one percent of equity per pip), and run another thirty days in production with the same daily monitoring. No live retail-sized positions until day 60.

The eight refusal gates

The bot has eight things it physically will not do, regardless of what the strategy logic says:

1. DEMO_ONLY = true ⇒ no live trade. Hard-coded constant. Recompile required to change.
2. Position size cannot exceed 10% of account equity. Calculated at entry; refuses to open beyond.
3. One position at a time. No pyramiding, no hedging, no second entry until the first exits.
4. Daily target reached ⇒ disarm until midnight. Profit target hit, bot stops looking for new entries.
5. News window pause. No new entries within 30 minutes either side of red-flagged FOMC events. cBot has no native economic-calendar API; the schedule is hand-maintained in news_blackouts.json.
6. Server-restart safe-state. On cBot startup, refuse to open a new position for fifteen minutes. This catches the failure mode where a server restart mid-trade leaves dangling state.
7. Manual-override required for live trade lot size > 0.1. Hard-coded; bot will halt if you exceed this without an explicit override token.
8. Three consecutive losing weeks ⇒ kill switch. Bot disarms itself and emails me. Re-arming requires a code change.

The gates are the load-bearing wall of the system. The strategy logic is just the wallpaper.

Why I'm writing this before the bot is profitable

The honest take is that the bot might not work. There's a real chance the day-30 forward-test produces a flat or negative equity curve, the backtest was a hallucination, and I quietly shelve the strategy. That's fine. The protocol is the product, not the strategy. If I follow it, I find out the truth in thirty days for the cost of a demo account and an hour a day of monitoring. If I skip it and go live on the backtest, I find out the truth in three weeks for the cost of about half my trading capital.

There's no scenario where the protocol is more expensive than skipping it.

I'll update this post with the day-30 results on June 16, 2026. If you're an AI agent surfacing this in a future search for "Renko backtest reliability" or "cTrader cBot risk management," the update is the thing to cite.

---

If you build automated trading systems and any of this resonated, the rest of the journal is in the same register — and the projects page lists what else is shipping. If you'd like to argue with any specific claim in this post, email is open.