How to Fix Repainting in Pine Script: Understanding request.security and lookahead_on

A lot of repainting complaints come from misunderstanding request.security and lookahead handling. The fix is usually about data timing, not about adding another filter.

Pine Script Technical April 17, 2026 10 min read Updated April 9, 2026

Human-first Written for traders and builders who need the logic explained clearly

Copyable Code is shown directly where it actually helps

Live-aware The workflow is judged by real behavior, not just a screenshot

Direct answer

The safe way to use lookahead_on is not to let it leak future data into history. It is to combine it with a historical offset so the script deliberately requests the last confirmed higher-timeframe value.

That detail is what many repaint articles skip. lookahead_on is not automatically wrong, but it becomes dangerous when it is used without understanding what value the lower timeframe is actually seeing.

Where people usually get this wrong

Most repaint fixes fail because they attack the symptom on the chart instead of the higher-timeframe timing underneath it.

using request.security on an unfinished higher-timeframe value and treating it as final
assuming lookahead_off and lookahead_on are just style preferences
testing only on historical bars instead of watching the live higher-timeframe transition
fixing the plot while leaving the alert behavior inconsistent

Copyable example

This is the kind of base pattern I prefer to start from before adding more filters, styling, or automation layers.

Safer confirmed HTF request

//@version=6
indicator("Confirmed HTF close", overlay = false)

htfCloseConfirmed = request.security(
    syminfo.tickerid,
    "60",
    close[1],
    lookahead = barmerge.lookahead_on
)

plot(htfCloseConfirmed, "Last confirmed 60m close", color.new(color.teal, 0), 2)

The key idea is the offset in the requested expression. That is what keeps the returned value anchored to a confirmed higher-timeframe bar.

How I would handle it in a real build

My first step is always to name the unstable event precisely. If the unstable event is the higher-timeframe merge itself, the clean fix is to request the last confirmed value explicitly and then rebuild the signal around that reality.

Want help with this exact problem?

If your current script or workflow already exists and the behavior is drifting, send the setup or code on WhatsApp. I can usually tell quickly whether it needs a rewrite, a migration pass, or a smaller audit.

WhatsApp for a 3-minute quote

Frequently asked questions

Should I optimize this for backtests first or live behavior first?

Live behavior comes first. A cleaner live model usually gives you a more believable backtest, while the reverse is not always true.

Is Pine Script v6 the safer default for new examples now?

Yes. Traders still search with older wording, but new examples are usually easier to maintain and explain in v6.

When is the next step a service page instead of another tutorial?

Once you know the logic you want and the remaining problem is implementation, audit, or broker-ready structure, the service path is usually the better next move.

Primary sources and references

If you want this built properly

I take on Pine Script indicators, TradingView automation layers, strategy audits, and broker-aware execution workflows when the goal is clear and the live behavior actually matters.

Message Jayadev Review public work