Execution model

One pass over the bars

The engine compiles a script into bytecode once, then executes it for bar 0, bar 1, … up to the newest bar. On each bar:

1. plain variables start as na; persist / live variables start with the previous bar's value;
2. the statements run top to bottom;
3. outputs are written for this bar; orders placed are handed to the broker for the next bar.

Every builtin with history (ta.ema, stat.stdev, …) keeps its own state per call site and updates it in O(1) per bar, so the cost of a script does not grow with the length of the history.

Confirmed and forming bars

On a live chart the newest bar is forming: its prices change until it closes. The engine handles each update by rolling back to the state before the forming bar and executing that bar again with the new prices:

So a forming bar never "counts twice". bar.is_confirmed is false while a bar is forming; use it to act only on closed bars. Bars supplied when the chart opens are never live, even a forming last bar: bar.is_live starts with the first bar that arrives afterwards.

No lookahead

• x[n] only reads bars that already executed.
• feed.series only returns closed bars of the other interval.
• Orders fill from the next bar on.
• Pivots are reported on the bar that confirms them (right bars after the pivot); use offset = -right on a plot to draw them at the pivot bar.

Budgets

Determinism

The same script, parameters and bars always give bit-identical outputs, on any machine and any number of threads. math.random(seed) is a deterministic stream per call site.