MTF & Repainting
Multi-timeframe indicators have a repainting problem that most people do not think about until it costs them something. The cost is usually not one dramatic trade. It is the slow erosion of trust in your own review pr...
Written By Axiom Admin
Last updated About 1 month ago
MTF & Repainting
Multi-timeframe indicators have a repainting problem that most people do not think about until it costs them something. The cost is usually not one dramatic trade. It is the slow erosion of trust in your own review process. You scroll through charts, see clean setups where the oscillator showed exactly the right read, and start building confidence in patterns that were never actually visible when the bar was live. Weeks later, when live results do not match what the historical chart promised, the disconnect feels personal rather than structural. But it is structural. The chart was revised after the fact, and nobody told you.
This page explains what that problem is, how this indicator handles it, how to make the tradeoff per slot, and how to verify the behavior yourself.
What the problem is
When your chart is set to a 5-minute timeframe and you ask for stochastic data from the 1-hour timeframe, you are requesting information from a bar that might not be finished yet. The 1-hour bar is still building. It has only 5 minutes of data, then 10, then 15, and so on. The stochastic value based on that incomplete bar keeps changing as new 5-minute bars arrive.
This is not a bug. It is a structural consequence of requesting higher-timeframe data from a lower-timeframe chart. But it creates a specific problem: what the indicator shows you during the live session may not match what the chart shows on that same bar after the fact. The 1-hour bar eventually closes, and the final value gets written to the historical record. When you scroll back later, you see the final value, not the intermediate values that were flickering on your screen while the bar was building.
This is what repainting means in the multi-timeframe context. The chart's history looks stable and clean. But the live experience was different. The reading was moving and uncertain during the bar's formation.
Why it matters: if you backtest or evaluate setups by scrolling through historical data, and your indicator was repainting during those historical bars, the readings you see now were never actually visible in real time. The historical chart flatters the tool. It looks more reliable than it was. And because the chart looks clean and correct, you have no way of knowing - from the chart alone - that the live experience was different. The only way to know is to understand the mechanic or to test it yourself.
How this indicator handles it
Each slot has an "On Bar Close?" toggle in its Power User settings. This is the repainting control. It defaults to on (enabled).
When "On Bar Close?" is enabled (default)
The slot uses the last confirmed slot-timeframe bar's K and D values. On a true higher-timeframe slot, that means the most recently closed HTF bar. If the slot timeframe matches the chart, it still means the previous completed slot bar, not the currently building one.
What this means in practice:
The reading is stable. Historical bars will show the same value whether you look at them during the live session or a week later.
The reading has a one-bar lag relative to the slot timeframe. If you are on a 5m chart watching a 1h slot, the slot shows the value from the previous completed hourly bar. It does not update until the next hourly bar closes.
On higher-timeframe slots, the values step instead of flow. The line stays flat during the HTF bar, then steps when the next HTF bar closes. If the slot timeframe matches the chart, you still get the one-bar lag, just without the staircase look.
When to use this mode: Whenever you want reliable historical data, whenever you are setting alerts, and whenever you want to trust that the reading you are seeing now is the reading that will still be there tomorrow when you scroll back to this bar. This is the default for a reason.
When "On Bar Close?" is disabled
The slot uses the currently building slot-timeframe bar's K and D values. On higher-timeframe slots, that means the reading updates in real time as new lower-timeframe bars arrive within the HTF bar.
What this means in practice:
The reading is responsive. You see the stochastic reaction to the latest price data without waiting for that slot's timeframe bar to close.
The reading can change retroactively. The value the slot shows you midway through an HTF bar may be different from the final value when that HTF bar closes. Historical bars on the chart show only the final value.
Looking back through chart history, you see a cleaner story than what actually happened during the live session. The intermediate values - the ones that may have influenced your real-time interpretation - are gone.
When to use this mode: When you want the fastest possible read on what that slot's stochastic is doing right now and you understand that the reading is provisional. Some traders run one slot in live mode for real-time sensitivity and keep the other slots in confirmed mode for stability. That is a reasonable hybrid approach, as long as you know which slot is provisional and which are confirmed.
The tradeoff in plain terms
Neither mode is right or wrong. They serve different purposes. The choice is about what you value more: stability and reviewability, or immediacy and responsiveness.
How to verify this yourself
You do not have to take anyone's word for how this works. You can verify the repainting behavior directly on your chart.
Confirming that On Bar Close mode is stable
Set your chart to a low timeframe (for example, 5m). Enable one slot on a higher timeframe (for example, 1h). Make sure "On Bar Close?" is enabled.
Watch the slot's K line during a live session. Notice that it stays flat during the twelve 5-minute bars inside each hour. When the hourly bar closes, the value steps to a new level.
Write down or screenshot the value at the moment the hourly bar closes and the step occurs. Note the bar's timestamp.
After several hourly bars have passed, scroll back to those timestamps. The values should match exactly what you recorded. They have not changed.
This confirms that confirmed mode produces stable historical readings. The value you saw live is the value that persists.
Confirming that live mode can repaint
On the same setup, toggle "On Bar Close?" to off for that slot.
Watch the slot's K line during the next hourly bar. Notice that it moves during the 5-minute bars because it is responding to the building hourly data. Write down the value at, say, minute 15 and minute 30 of the hour.
After the hourly bar closes, note the final value. Compare it to what you wrote down at minute 15 and minute 30. The final value may be different.
Now scroll back to the same bar. The chart shows only the final value. The intermediate values you observed are gone. If the final value was +40 but the value at minute 15 was +20, the chart now shows +40 for that bar, which is not what you saw at the time.
This confirms that live mode can repaint. The historical record diverges from the live experience.
Per-slot flexibility
One of the useful things about this indicator is that the repainting choice is per slot, not global. You do not have to choose confirmed mode for everything or live mode for everything.
A common and sensible approach: run your primary analysis slots - the ones you use for decisions, alerts, and historical review - in confirmed mode. Run one auxiliary slot in live mode for real-time monitoring of the fastest timeframe. You get stability where it matters and responsiveness where it helps, and you always know which slot is provisional. On higher-timeframe slots, the visual cue is the staircase: confirmed mode steps, live mode flows. If the slot timeframe matches the chart, the difference is still there, but it shows up as a one-bar lag versus a live-updating line instead of a staircase.
If you are using cross-ticker blending, keep all blended slots in confirmed mode so the composite reading is fully confirmed. Adding a live-mode slot to the blend mixes a provisional reading into a confirmed composite, which means the blend itself can shift retroactively - defeating the purpose of running the other slots in confirmed mode. If you want a live-mode slot alongside a cross-ticker blend, set its weight to zero so it observes without contaminating the composite.
A note on the chart timeframe and alerts
Alert conditions are bar-close gated on the chart timeframe. This is separate from the "On Bar Close?" setting.
What this means: even if "On Bar Close?" is disabled and the slot's K value is updating intrabar (live mode), the alert does not evaluate until the chart-timeframe bar closes. At that point, the slot value used for the alert is whatever the live slot-timeframe data shows at the moment of chart-bar confirmation. But the slot-timeframe bar itself may still be open, so the value could still change after the alert evaluates.
If you need alerts that fire on fully confirmed data - both chart-bar-confirmed and slot-timeframe-confirmed - keep "On Bar Close?" enabled for the relevant slots. That way, the slot value driving the alert is the confirmed slot-timeframe bar value, and it will not change.