MTF & Repainting

This is the safety-critical page in the manual. If you take away one concept from the entire documentation pack, it should be this one: the On Bar Close toggle on each slot controls whether that slot uses the script's...

Written By Axiom Admin

Last updated About 1 month ago

MTF & Repainting

This is the safety-critical page in the manual. If you take away one concept from the entire documentation pack, it should be this one: the On Bar Close toggle on each slot controls whether that slot uses the script's confirmed request path or its live request path, and those two paths do not deserve the same level of trust.

Why this matters

Multi-timeframe indicators have a problem that most tools hide from you.

When you put a higher-timeframe reading on a lower-timeframe chart, the higher-timeframe bar is not finished yet. It is still building. So the indicator has a choice: show you the current, incomplete reading (which is fresh but will change), or show you the last completed reading (which is stable but lagged).

Both answers are valid. Neither is perfect. The problem is not the tradeoff β€” the problem is when a tool makes this choice for you silently, or makes it globally instead of letting you decide per component.

Here is what goes wrong when the choice is hidden: you look at your chart's history, see a clean oscillator reading on every past bar, and assume those readings were available in real time. In this script, that assumption is only justified when On Bar Close is enabled. The live path uses request.security(..., lookahead = barmerge.lookahead_on) without the [1] offset that Pine's own safety guidance uses to avoid future leak. On realtime bars that gives you the developing HTF value. On historical bars it can also make the chart look cleaner and earlier than the live experience really was.

This is how people get burned. They test a setup on historical data, see clean entries, assume those entries would have been just as clean in real time, and then discover the hard way that the oscillator was showing a rougher picture while the bar was building. The chart can absolutely mislead you about what you really had available at decision time if you treat live-mode history like confirmed-mode history.

This indicator makes the tradeoff visible and gives you control over it for each slot independently.

The two modes

On Bar Close: ON (default)

When On Bar Close is enabled, the slot uses a confirmed-data retrieval pattern:

  • The slot returns the values from the last completed higher-timeframe bar.

  • These values are locked. Once a higher-timeframe bar closes, the reading for that bar will never change.

  • When you scroll back through history, every bar shows the value that was available at that bar's time. This is the mode where "what you see is what you would have seen" is a fair claim.

  • The cost: there is a one-HTF-bar delay in responsiveness. If the slot is on a 60-minute timeframe and you are on a 5-minute chart, the slot's reading updates only once per hour β€” when the hourly bar completes. During the hour, it holds the previous hourly reading steady.

This is the safe default. The numbers are stable. The history is trustworthy. Alerts based on these values fire on genuinely confirmed data. The tradeoff is that you are always looking at the previous HTF bar's verdict, not the current one.

On Bar Close: OFF

When On Bar Close is disabled, the slot uses a live-data retrieval pattern:

  • The slot returns the values from the current building higher-timeframe bar.

  • These values update in real time as new lower-timeframe bars arrive within the HTF bar.

  • The live reading can change significantly between the start of an HTF bar and its close. A slot that reads +40 at the beginning of an hourly bar might read -10 by the time that bar closes.

  • The same request path also uses lookahead_on without a confirmed-bar offset, so you should not treat the historical chart in this mode as the same kind of trustworthy record you get in confirmed mode.

  • The advantage: faster feedback. You see the direction the HTF reading is heading before it confirms.

This is the responsive mode. The numbers are fresher. But the current reading is provisional, and the historical presentation can be cleaner than the live experience because of the lookahead behavior. Use it as a live heads-up view, not as backtest-grade evidence.

Per-slot independence

This is where the design gets deliberate. On Bar Close is a per-slot setting. You can configure each slot independently:

  • Slot 01 (5m) with On Bar Close ON

  • Slot 02 (15m) with On Bar Close ON

  • Slot 03 (60m) with On Bar Close OFF

In this configuration, slots 01 and 02 show confirmed data while slot 03 shows live data. This might make sense if you want your shorter-timeframe readings stable and are willing to watch the hourly reading build in real time.

The flexibility is the point. But it comes with a responsibility: you need to know which of your slots are confirmed and which are live. If you forget that slot 03 is running in live mode, you might mistake a draft reading for a confirmed regime state.

This matters even more for the blended composite. When the blend includes both confirmed and live slots, the blended output is a mix of both. The blended line does not mark which portion of its value comes from confirmed data and which comes from the live path. It just shows you the weighted average. You have to know, from your own slot configuration, what the blend is actually built from.

What "repainting" actually means here

The word "repainting" carries baggage. In many contexts, it means an indicator that secretly rewrites its history β€” showing signals that did not exist at the time, making the backtest look better than the live experience.

In this script, the honest answer is split by mode:

  • On Bar Close ON: this is the safe path. The request uses the prior confirmed bar in the requested context, so the slot is stable and does not depend on unfinished HTF values.

  • On Bar Close OFF: this is not just "the same history but faster on the live bar." The slot uses the live HTF request path, and because that path keeps lookahead_on without the confirmed-bar offset, it can present cleaner, earlier historical HTF values than a trader really had live.

So the practical rule is simple:

  • If you need a trustworthy historical reference, use On Bar Close ON.

  • If you choose On Bar Close OFF, accept that you are choosing responsiveness over historical trustworthiness.

That does not make live mode useless. It makes it a tool for discretionary monitoring rather than a mode you should sell to yourself as stable evidence.

How the mechanism works (user level)

You do not need to understand the Pine implementation to use this feature. Here is what you need to know:

  1. Each slot makes a data request to TradingView's security system for its configured timeframe and ticker.

  2. The On Bar Close toggle controls which version of that data the slot receives:

  • ON: the data from the last completed HTF bar (confirmed)

  • OFF: the data from the current HTF bar (building)

  1. The confirmed version is always one HTF bar behind the live version. That is the one-bar delay.

  2. In this script, only the confirmed version should be treated as a trustworthy historical reference. The live version is useful for seeing the HTF bar build, but its historical presentation is not equivalent to confirmed mode.

Verification walkthrough

You can prove this to yourself in about two minutes. Here is how:

Setup

  1. Apply the indicator to a 1-minute or 5-minute chart on an actively trading instrument.

  2. Make sure at least one slot has a higher timeframe (e.g., 15m or 60m).

  3. Start with all slots On Bar Close = true (the default).

Test 1: Confirm non-repainting behavior

  1. Watch the oscillator for a few bars. Note the Fast value for one of the higher-timeframe slots on the most recently completed bar.

  2. Wait for a few more bars to pass.

  3. Scroll back to the bar you noted. The value should be exactly the same as what you observed earlier.

  4. This confirms that confirmed-mode values do not change after the fact.

Test 2: Observe live-mode behavior

  1. Disable On Bar Close on one slot (choose a slot with a higher timeframe so the effect is visible).

  2. Watch that slot's Fast line on the current bar. It should move in real time β€” updating with each new lower-timeframe bar as the higher-timeframe bar builds.

  3. Note the reading at some point during the HTF bar.

  4. Wait for the HTF bar to complete (a new higher-timeframe bar starts).

  5. Check the value on the now-completed bar. It should be the final value β€” the one that was showing when the HTF bar closed, not necessarily the value you noted earlier.

  6. If the final value differs from what you noted mid-bar, you have seen the provisional-to-confirmed transition in action.

Test 3: Check what not to trust

  1. Leave that slot in live mode and study historical sections of the chart.

  2. Notice that the history will still look neat and stable once those bars are in the past.

  3. Do not read that neatness as proof that live mode was historically safe. In this script, live mode uses the same unoffset lookahead_on request path on historical bars, so the historical presentation can look better than the live decision context actually was.

Test 4: Confirm the difference

  1. Re-enable On Bar Close on the slot you just tested.

  2. The slot should now show the last confirmed HTF bar's value, which should match the final value from Test 2.

  3. The slot should stop updating intrabar β€” it holds steady until the next HTF bar closes.

This four-step test confirms the entire mechanism: confirmed mode is stable, live mode is provisional while the HTF bar builds, and the live request path should not be treated like confirmed-mode history.

The blend and repainting

When the blended composite includes slots with different On Bar Close settings, the blend mixes confirmed and live-path data. There is no visual indicator that distinguishes the two sources within the blended line.

This means:

  • If two of your three slots are confirmed and one is live, the blend is approximately two-thirds stable and one-third live-path data (weighted by the blend weights).

  • A blend regime flip that happens because the live slot is swinging could reverse when the HTF bar closes and the live slot's reading finalizes.

  • The blended alerts still fire only on chart-bar close (see Alerts), but the blended values that the alert evaluates may include unfinished HTF data from live slots.

Recommendation: If you care about the blend's reliability, either keep all contributing slots on confirmed data, or make sure you understand which slots are introducing provisional readings and how much weight they carry.

When to use each mode

Keep On Bar Close ON when:

  • You are making trading decisions based on the indicator's readings

  • You are using alerts and need them to lean on confirmed HTF data

  • You want to review your chart history and know that what you see is what was available at the time

  • You are comparing the indicator's behavior across multiple sessions and need consistent historical data

  • You do not have a specific reason to want faster updates

Consider On Bar Close OFF when:

  • You want to watch a higher-timeframe reading develop before it confirms β€” for example, seeing the 60-minute reading build over the course of the hour so you can prepare for what the confirmed value is likely to be

  • You are using the slot as a visual "heads up" tool, not as a decision input β€” the distinction matters, and you have to be honest with yourself about which role the slot actually plays in your process

  • You understand that the reading is provisional and that the historical chart in this mode is not something to grade the tool by

  • You have a hybrid setup where one slot provides fast visual feedback while others provide the confirmed readings you actually trust β€” this is a legitimate and useful configuration, but only if you remember which slot is which when the pressure is on

Avoid this combination:

  • All slots On Bar Close OFF while treating the blended reading as a confirmed score. If everything is live-path data, nothing is confirmed, and the entire composite can shift when the HTF bars close. This is the configuration that produces the most overconfidence β€” the blended line updates smoothly, the fill looks clean, and nothing about the visual tells you that every number on the current bar is a draft that could be revised.

Common questions about repainting

"Will the indicator repaint my historical chart?" Not in the same way under both modes. With On Bar Close enabled, the historical chart is the trustworthy one. With On Bar Close disabled, the slot uses the live HTF request path, so you should not treat the historical chart as confirmed-grade evidence even though the past bars look stable.

"If I disable On Bar Close, will my alerts fire on bad data?" They still wait for a confirmed chart bar, but a live-mode slot can feed unfinished HTF data into that chart-close check. So the alert is protected from mid-chart-bar noise, not from every unfinished higher-timeframe input.

"Can I mix On Bar Close on and off across slots?" Yes, and this is a deliberate design feature. But keep track of which slots are in which mode, especially if they contribute to the blend.

"Does On Bar Close matter when the slot timeframe equals the chart timeframe?" Yes. When the slot timeframe matches the chart timeframe, On Bar Close ON still uses the previous confirmed bar and OFF uses the current bar. The MTF complexity is lower because there is no higher timeframe involved, but the difference between confirmed and live values is still real.