Are Renko Backtests Reliable? An Honest Look at Brick Mechanics

No. A backtest run on a Renko chart is not a reliable estimate of live performance, because Renko bricks are synthetic constructs on a fixed price grid: the strategy tester fills orders at brick prices the market frequently never traded in that sequence, the time axis has been discarded, and — on most platforms — the historical bricks you backtest on are not even built from the same data as the real-time bricks you would trade against.

That is the direct answer, and it matches the practical consensus you find scattered across Forex Factory threads, Quora answers, and the NinjaTrader forums, where the recurring story is a Renko system that looked immaculate in testing and diverged immediately when run live. What those threads rarely provide is the mechanics — which specific properties of brick construction produce the divergence. This article walks through them one by one: how bricks are anchored to a grid and what information gets thrown away, where your fills actually happen versus where the tester says they happen, and why ATR-sized bricks make the entire history non-reproducible.

None of this means Renko charts are useless. As a visualisation — a noise filter for reading structure — they are a legitimate tool. The problem is narrower and sharper: the strategy tester treats brick boundaries as executable prices and brick sequences as stable history, and neither assumption survives contact with a live feed. TradingView's own documentation warns that strategies on non-standard chart types produce unrealistic results for exactly this reason.

As always on ForexCodes: this is educational material, not financial advice. Even a methodologically clean backtest is a description of the past, and trading carries a real risk of loss.

A Renko chart discards time entirely and redraws price as fixed-size bricks on a grid. With a brick size of 10 points, a new up-brick prints only when price closes a full 10 points above the top of the previous brick; a reversal brick in the classic construction requires price to travel two full bricks in the opposite direction before anything appears. Between those events, the chart shows nothing — a quiet hour and a violent, stop-sweeping range both compress into the same absence of bricks.

Three pieces of information are destroyed in the process. First, time: you cannot tell from the chart whether a brick took four seconds or four hours to complete, yet live execution, spread behaviour, and session effects all depend on when things happened. Second, the intra-brick path: every excursion smaller than a brick is invisible, including moves that would have hit a live stop-loss. Third, the anchor: the grid is seeded from wherever the chart's data begins, so the same instrument with a different history start date produces a different grid, different bricks, and different signals from identical price action.

There is also a subtler data problem specific to backtesting. On TradingView, historical Renko bricks are constructed from the closes of a lower-timeframe series, while real-time bricks build tick by tick. Those are different data sources, so the brick sequence you backtested is not the brick sequence you would have experienced live — after a refresh, real-time bricks are themselves redrawn to match the historical construction. A chart whose history disagrees with its own live behaviour cannot anchor a trustworthy backtest, no matter how careful the strategy logic sitting on top of it is.

On a Renko chart, the strategy tester's world consists only of brick boundary prices. When your script signals on a completed brick, the emulator fills the order at a grid price — the brick's close or the next brick's open. Live trading offers no such courtesy, and the gap between the two is systematic, not random.

Consider the classic Renko entry: buy when a reversal brick prints. In the classic construction, that brick only exists after price has already travelled two full bricks off the extreme. The tester books your fill at the brick boundary — but the tick that completed the brick is simply the first trade at or beyond that boundary, and in a fast market it can gap well past it. Every fill the tester records at a clean grid price was, in reality, "at least this bad, possibly much worse." The error always points against you.

Stops and limits inside a brick are worse. Because the chart contains no prices between boundaries, a stop-loss placed mid-brick is evaluated against a price series in which mid-brick prices do not exist. The tester may show the stop untouched while the real market traded through it repeatedly. Combined with the hidden intra-brick path from the previous section, this means Renko backtests systematically understate adverse excursion — the exact quantity risk management depends on.

Finally, the time-compression flatters exits: a trend that took days of exposure, overnight gaps, and financing costs renders as a tidy staircase of bricks. The tester sees the staircase; your live account would have lived through the days. A backtest that cannot see time cannot price the risk of holding through it.

The problems so far apply even with a fixed brick size. The popular ATR-based brick sizing makes things categorically worse, because it makes the chart's entire history unstable.

With ATR sizing, the brick size is derived from an Average True Range calculation over recent data. As new bars arrive, the ATR value changes — and because every brick on the chart depends on the brick size, the platform recomputes the entire brick history from scratch. Bricks that existed yesterday vanish; boundaries shift; signals that your backtest traded on are no longer on the chart. Run the same backtest on Monday and again on Thursday and you can get materially different trade lists from the same underlying market history. A result that cannot be reproduced cannot be verified, and a result that cannot be verified should not be trusted — this is as close to a deterministic disqualification as backtesting offers.

Even fixed-size bricks inherit a milder form of the disease through the anchor dependence mentioned earlier: extend or trim the chart's history and the grid seeds from a different starting price, shifting every subsequent brick. Two traders testing the "same" fixed-brick strategy on the same instrument can see different signals purely because their charts loaded different amounts of history.

The honest mental model: a Renko backtest is a measurement taken with a ruler whose markings move. The strategy logic may be perfectly sound, but the substrate it is measured against — the bricks — is neither stable across time nor faithful to the prices that traded. Any performance number read off that substrate is a property of the chart configuration at that moment, not of the strategy.

If a brick-style idea genuinely interests you, the defensible way to test it is to recreate the brick logic on a standard chart. Signals then derive from your own explicit grid arithmetic, fills happen at real traded prices on a real timeline, stops are evaluated against genuine highs and lows, and the whole thing is reproducible. Here is a deliberately simplified single-brick-flip sketch showing the pattern:

//@version=6
// Educational only — validate before trading; not financial advice.
// Renko-style brick logic computed on a STANDARD chart, so every
// fill and every stop is evaluated against real traded prices.
strategy("Brick logic on standard chart", overlay = true)

brickSize  = input.float(1.0, "Brick size (price units)", minval = 0.0001)
stopBricks = input.int(2, "Stop distance (bricks)", minval = 1)

var float anchor = na
var int   dir    = 0
if na(anchor)
    anchor := close

// Advance the anchor only when price traverses a full brick.
if close >= anchor + brickSize
    anchor := anchor + brickSize * math.floor((close - anchor) / brickSize)
    dir    := 1
else if close <= anchor - brickSize
    anchor := anchor - brickSize * math.floor((anchor - close) / brickSize)
    dir    := -1

flipUp   = dir == 1  and dir[1] == -1
flipDown = dir == -1 and dir[1] == 1

if flipUp and barstate.isconfirmed and strategy.position_size == 0
    strategy.entry("Long", strategy.long)
if flipDown and barstate.isconfirmed and strategy.position_size > 0
    strategy.close("Long")

// Wire the declared stop input into the exit — no dead risk inputs.
if strategy.position_size > 0
    strategy.exit("Stop", "Long", stop = anchor - stopBricks * brickSize)

This is a teaching sketch, not a finished system — classic Renko uses a two-brick reversal, and bar closes are a coarser trigger than ticks — but every structural honesty problem from the previous sections is gone: the grid is explicit, the history is stable, and the stop input is genuinely wired into strategy.exit(). Whatever the results say, treat them as a hypothesis for forward testing, never a forecast. Educational only; trading carries a real risk of loss.