MTF and Repainting
This page exists because timing is one of the main trust boundaries in this indicator.
Written By AxiomCharts
Last updated About 2 hours ago
MTF and Repainting
This page exists because timing is one of the main trust boundaries in this indicator.
If you only remember one thing, remember this: the stack can be useful in both confirmed mode and live-forming mode, but they are not the same promise.
Why this matters: many MTF problems are not math problems. They are trust problems. A trader thinks they are reading settled higher-timeframe context when they are really reading something still in motion. This page is here to keep that mistake visible.
Start with the two clocks
This indicator always sits between at least two clocks:
- the chart timeframe clock
- the requested timeframe clock for each enabled slot
When those clocks differ, the script has to decide whether a higher-timeframe slot should show:
- the last settled value from that slot's requested timeframe, or
- the value from the requested bar while it is still forming
That is what On Bar Close? is controlling in this build.
The hard chart rule
An enabled slot TimeFrame: cannot be lower than the chart timeframe.
Examples:
5 / 15 / 60is legal on a1mchart5 / 15 / 60is legal on a5mchart5 / 15 / 60is not legal on a15mchart unless you raise or disable the5slot
This is a runtime rule, not a style suggestion.
If the script errors on load, start here before you assume anything is wrong with TradingView or the indicator.
What On Bar Close? really changes
This indicator uses one shared On Bar Close? switch for the whole stack.
That means one switch changes every slot together and therefore changes the blended summary too.
Treat that as a whole-stack decision, not a small speed preference.
The practical answer to "Does this repaint?"
The honest answer is not one slogan.
- In confirmed mode, higher-timeframe slot values wait for the requested bar to settle before they advance.
- In live-forming mode, higher-timeframe slot values can move while that requested bar is still forming.
That does not make the tool broken. It means you need to know which timing posture you are choosing.
The wrong question is:
- "Is this morally repainting or not?"
The better question is:
- "Am I reading confirmed higher-timeframe context, or am I choosing to watch it while it forms?"
That is a more useful question because it tells you what to verify next on the chart.
One more timing distinction that matters
Alert timing and slot timing are related, but they are not identical.
- alert conditions are checked on chart bar close
- higher-timeframe slot values may still be confirmed or still forming depending on
On Bar Close?
So a chart-bar-close alert can still reflect a live-forming higher-timeframe slot if you turned confirmed mode off.
A replay drill that teaches the difference fast
Use this on a 1m chart with the default 5 / 15 / 60 ladder.
- Leave every slot on the chart symbol.
- Keep weights at their defaults.
- Start with
On Bar Close?on. - Watch how the
15and60minute slots behave while their requested bars are still building. - Restart the same stretch with
On Bar Close?off. - Compare when those higher-timeframe slots begin to move and how the blend changes with them.
What you should notice:
- confirmed mode feels steadier
- live-forming mode reacts earlier
- the blend inherits the timing posture of the whole stack
That is the real tradeoff. Not faster versus slower in the abstract. Earlier versus more settled.
If the difference still feels academic, keep replaying until you can say which bars changed your trust in the move. That is usually when the distinction becomes practical.
When confirmed mode is usually the better choice
Stay with confirmed mode when:
- you are still learning the stack
- you care more about stable interpretation than early movement
- you want the manual examples to line up more closely with live use
- you are building alerts and want a calmer trust posture
When live-forming mode may still be useful
Live-forming mode can be useful when:
- you already understand the confirmed baseline
- you knowingly want earlier awareness of higher-timeframe shifts
- you accept that the slot and blend can change character before the requested bar settles
The keyword there is knowingly. Earlier is not automatically better. It is simply earlier.
What usually goes wrong
Common timing mistakes:
- turning confirmed mode off before learning what confirmed mode looks like
- assuming chart-bar-close alerts must mean higher-timeframe confirmation
- forgetting that the switch changes the whole stack, not one slot
- calling the confirmed mode "lag" and the live-forming mode "truth"
Those are interpretation mistakes, not software bugs.
A short verification checklist
Before trusting an MTF read, answer these:
- What is the chart timeframe?
- What are the enabled slot timeframes?
- Is
On Bar Close?on or off? - Would the same chart still tell the same story in the other timing mode?
If the fourth answer is "I do not know," that is the next thing to test.
The safest habit to keep
Whenever you change the timing mode, compare the same stretch of chart in replay before you start trusting the new behavior.
That small habit prevents one of the easiest mistakes in multi-timeframe tools: letting a different timing posture inherit the trust you built in the old one.
Visual placeholder: Side-by-side replay capture showing the same higher-timeframe slot behavior with
On Bar Close?on versus off, with callouts on "confirmed requested bar" and "still-forming requested bar."