The demo chart was immaculate. Every arrow sat on the perfect candle, every historical signal caught the turn.
Live, your entry arrow printed — then moved one bar left overnight. That discrepancy needs an explanation. Record what changed before deciding whether it came from the script, its settings or its data.
What does repainting actually mean?
Repainting means that a script's historical and real-time calculations or plots differ. A developing value can change legitimately. The practical question is whether a displayed decision was available at the time it claims to represent. TradingView distinguishes several kinds of repainting, including unavoidable data revisions.
The mechanics are mundane. On the developing bar, scripts recalculate on every tick, so a condition can be true at 14:32 and false again by the bar's close. When the chart reloads, history keeps only each bar's final result. Anything the script "said" mid-bar — the arrow you saw, maybe traded — has no place to live, and vanishes or moves. No villainy required; it's the default physics of the engine meeting a script that decided before the bar finished.
Four behaviors to investigate
Deciding on the unfinished bar. The script acts on the live bar without waiting for confirmation. Live you see signals flicker in and out; history shows only the survivors. This is the most common cause and the easiest to catch.
Higher-timeframe data requested with lookahead. On an intraday chart, requesting the unoffset daily close with barmerge.lookahead_on leaks the finished daily value into earlier historical bars. Requesting close[1] with that setting instead uses the previous completed daily bar. The requested timeframe must be strictly higher than the chart; inspect both the expression and the timeframe, not just the flag. TradingView documents this confirmed-data pattern.
Structures confirmed after the fact. Pivots, zigzags, and "market structure" points only become known several bars after they happen — then get drawn back at the original bar, offset into the past. The drawing is honest geometry; treating it as a signal you could have traded at that bar is the lie.
Alert-versus-chart mismatch. A discrepancy can come from developing values, different event rules or a saved alert context. Running alerts retain the script, inputs, symbol and timeframe from their creation; editing the chart does not update them. Check the alert's saved setup before attributing a mismatch to repainting. If an alert never fires at all, work through why a TradingView alert isn't triggering.
The 20-minute audit (no code required)
Minutes 0–5 — Freeze the evidence. Choose a standard candle chart and timeframe supported by the indicator. Record symbol/feed, script version, inputs and chart time; screenshot the right edge with signals and timestamps visible. Use a short timeframe only if the tool supports it.
Minutes 5–10 — The reload test. Let several bars close, then reload and compare the same window with your screenshot. Record changed or missing markers. Repeat under unchanged inputs and check for data or history-window changes. A clean short sample does not establish that a script never repaints.
Minutes 10–15 — Replay it. Open Replay (availability varies by plan and timeframe) and step through the recorded window. Record when a marker first becomes available separately from the candle where it is drawn. A pivot found later is not an entry that existed at its origin. Replay is historical evidence, not a reconstruction of every live tick. The SMC Basics lesson illustrates this detection delay.
Minutes 15–20 — Set up alert receipts. If the script exposes the event you need, create a matching alert and use once per bar close when that frequency is available and appropriate. Some scripts do not expose alerts, and indicator conditions, alert() calls and strategy fills are different event types. Keep the saved version and inputs aligned, then collect receipts over a live session and compare their times with the intended chart events. This follow-up extends beyond twenty minutes; a mismatch needs diagnosis, not an automatic verdict.
Three red flags if you can read the source
Open scripts make this faster — paste the code into our Pine Script repaint & v6 checker or grep for:
- Unoffset higher-timeframe values with
lookahead_on. Check for future leakage. An offset expression such asclose[1]withlookahead_onis a valid way to request completed higher-timeframe data; the flag alone is not a defect. - No close confirmation on live-bar decisions — logic that never checks the bar is confirmed before committing a signal it also plots into history.
- Markers plotted into the past. Negative offsets may describe a pivot's origin legitimately. Verify that the documentation and any alerts expose the later detection time rather than implying an earlier entry.
For a closed-source tool, behavioral observations and the author's documented event rules are the available evidence. Neither a short test nor source access alone guarantees correctness. Our indicator comparison checklist asks what can actually be verified before buying.
Where we sit
We sell the SMC toolkit, so this is a seller's explanation, not independent certification. Its documented zone rules and historical Resolved % should be checked against the loaded version and inputs. Record unexplained discrepancies and report them with the saved evidence. Confirmation rules do not establish a trading advantage or immunity to changes in the underlying data.
Use the installation walkthrough to load a candidate, then begin the reload, replay and alert checks. Twenty minutes starts an evidence log; longer observation and source review may be needed.
Record what appeared, when it became available and which settings produced it. Investigate differences before trusting a historical marker.
