Look-ahead bias: why most browser backtesters lie, and how Backticks prevents it by construction

If a strategy shows a glorious 800% backtest return and then goes flat the moment it hits real money, the most likely diagnosis isn’t a bad strategy. It’s a time machine: the backtest was quietly letting “past” code see “future” data.

This is look-ahead bias, and it’s the single most under-appreciated source of failure in retail systematic trading. It hides in a single line of code, sometimes a single property accessor. The strategy passes review. The equity curve looks beautiful. Production hits, and the curve is flat (or worse).

Backticks is built around making this class of bug impossible. Not “discouraged”. Not “checked at runtime”. Structurally impossible.

What look-ahead bias looks like in code

Here’s a textbook backtest pattern. Spot the bug:

// Common pattern in browser-based JS backtesters
const candles = loadCandles("BTCUSDT", "1m", "2024-01-01", "2024-12-31");

for (let i = 0; i < candles.length; i++) {
  const current = candles[i];
  const sma20 = average(candles.slice(i - 20, i + 1).map(c => c.close));

  if (current.close > sma20) {
    buy(current.close);
  }
}

Looks innocent. Run it. SMA crosses are profitable. Ship it.

The bug: current.close is the closing price of a bar that hasn’t closed yet at the moment the strategy decides to buy. In a live tape, when price is at current.close, the bar isn’t done — you can’t take that price. By the time the bar closes and the SMA condition is “true”, the next tick is already at a different price. Your fill in production won’t be current.close. Your backtest fill is.

This pattern is in dozens of tutorials, boilerplate repos, and YouTube videos. It quietly inflates returns by 10–40% on most mean-reversion strategies. Strategies that “work” lose money.

The four flavours of leakage

Once you start looking, leakage is everywhere:

1. Same-bar fills. As above. The strategy sees a bar’s close and trades at that close, in the same step. Real life: you’d trade on the next bar’s open.
2. Indicator pre-computation. A common optimisation: pre-compute every indicator value for the whole series, then loop. Fast — but if the indicator code accidentally references future bars (e.g., a series.shift(-1) somewhere), the leak is invisible from the strategy code itself.
3. Survivorship and revision leakage. Using a current symbol list to backtest five years ago. Using fundamentals revised after the fact. Using economic data with the modern release date instead of the original release date.
4. Parameter leakage in optimisation. Optimising parameters on the same data window you then “test” on, with no held-out portion. Equally dangerous, equally common.

The first two are engine-level problems. The last two are workflow-level. A correct platform fixes the first two by construction and makes the last two hard to do by accident.

How the Backticks engine prevents each one

The Backticks engine is built around a single non-negotiable: strategy code physically cannot see future bars.

That’s not a runtime check. It’s a property of the API surface itself.

Forward-only event stream

Strategies in Backticks are not for loops over a candles array. They’re a graph of nodes that the engine drives one bar at a time, in event-time order. When a node fires, it sees only data with timestamps ≤ the current bar.

There is no random-access array of candles to slice into. Indicators are stateful — they accumulate as bars arrive — so even if a node wanted to peek forward, the indicator literally hasn’t computed that value yet.

Order semantics enforced by the simulator, not the strategy

When an entry node fires inside the bar, the order is not filled at that bar’s close. The simulator queues it and fills at the next bar’s open (with whatever realistic execution model is configured — slippage, partial fills, latency).

The strategy never gets to claim a price it couldn’t have actually traded at. This isn’t a setting — it’s how the order types are defined.

Indicator updates are stateful and incremental

Every indicator in Backticks (SMA, EMA, RSI, MACD, Bollinger, ATR, Stochastic, SuperTrend, Aroon, PSAR, etc.) is a stateful object that accepts one bar at a time and emits one value at a time. There is no series.shift(-1). There is no precomputed array indexable by bar number. The shape of the API forecloses entire bug classes.

Deterministic, reproducible runs

The same engine runs in a Web Worker in the browser and on Node servers. Same inputs, same outputs, byte-for-byte. That property compounds:

• Iteration in the browser stays trustworthy — running 10 backtests a minute and comparing them isn’t subject to the whims of a global library version.
• Distributed parameter search verifies itself. Workers cross-check each other’s results because deterministic backtests make this cheap.
• A backtest result is reproducible six months later, after libraries have moved on.

A backtest you can’t reproduce is a backtest you can’t trust.

What about performance?

The reason most “safe” backtesters are slow is that they enforce safety at the cost of vectorisation. Bar-by-bar iteration is the safe model; vectorised array operations are the fast model. Engines that pick safety usually pick it at the cost of speed, and at scale they give up.

The Backticks engine doesn’t make that trade. A representative workload from the in-product genetic optimiser:

• 2,000 strategy instances per generation
• 40 generations
• Each instance backtests 1 year of 1-minute bars (525,600 bars/year)
• Total: ~42 billion bar-evaluations per full run
• Wall clock: single-digit minutes on a laptop, single process

That’s roughly ~100 million bar-evaluations per second, in a deterministic forward-only model with all the safety properties above held intact.

What makes this possible:

• Indicator state is reused incrementally — windowed averages aren’t recomputed from scratch every bar.
• The hot path is monomorphic. Candle objects don’t shape-shift, so the JIT inlines aggressively.
• The optimiser is async-aware, so candidate evaluation fans out across cores without losing determinism.

This is enough throughput that a strategy is something you iterate on while having coffee, not something you start before lunch and hope looks good when you come back.

What this means for the user

You don’t need to remember any of this. You don’t need to add a “look-ahead audit” pass. You don’t need to skim a strategy for candles[i+1] accidents.

You write a graph. Backticks runs it. The engine is the part that promises:

• Every indicator value the strategy reads was computable at that exact moment in real time.
• Every order is filled at a price the market would actually have given you.
• The same backtest, run later, returns the same numbers.

Look-ahead bias is solved at the layer it should be solved: under the strategy, not on top of it.

---

Open the demo — drop a few indicators on the canvas, run a backtest, then open the replay. Every signal you see fired on data that was actually visible at the time. That’s the contract.