MTF and Repainting

This page exists because the indicator is only as trustworthy as your understanding of its timing behavior.

Written By AxiomCharts

Last updated About 2 hours ago

MTF and Repainting

This page exists because the indicator is only as trustworthy as your understanding of its timing behavior.

Multi-timeframe tools often get misused in one of two ways:

  • the trader assumes every historical reading behaved exactly the same way live
  • the trader treats any live-forming movement as scandal instead of a timing choice

Neither reaction helps. The useful question is simpler:

"Am I reading confirmed higher-timeframe values, or am I choosing to watch the higher-timeframe bar while it is still forming?"

The first hard rule

Every enabled slot timeframe must stay at or above the chart timeframe.

That means:

  • a 5m slot is legal on a 1m or 5m chart
  • a 5m slot is not legal on a 15m chart

If you violate that rule, the script throws a runtime error. That is not a bug. It is the guardrail telling you the stack no longer makes sense in the current chart context.

What On Bar Close? actually changes

This lite build uses one shared timing switch for every slot.

ModeWhat the stack readsWhat you gainWhat you must not forget
OnConfirmed higher-timeframe valuesA calmer trust posture and a live view that stays closer to the historical pictureThe stack will react later
OffStill-forming higher-timeframe valuesEarlier movement from the requested contextEarlier does not mean final, and alerts still wait for confirmed chart bars

When On Bar Close? is on

Each slot uses the last confirmed value from its requested symbol and timeframe context.

Practical meaning:

  • the higher-timeframe slot waits for the requested bar to finish
  • the historical view and the live experience stay closer together
  • the slot is slower to react, but easier to trust

When On Bar Close? is off

Each slot can use the current still-forming value from its requested symbol and timeframe context.

Practical meaning:

  • the higher-timeframe slot can move sooner
  • the slot can change before the requested bar is final
  • the live experience is more responsive, but less settled

Neither mode is fake. They answer different timing questions.

Why this is called a trust boundary

The indicator does not become more honest simply because it updates earlier. It also does not become more useful simply because it waits longer.

You are choosing between:

  • earlier information with less finality
  • later information with more stability

That is why this switch belongs in your method, not just in your settings.

What "repainting" means here

In this manual, repainting is not a moral label. It is a behavior difference between still-forming and confirmed values.

For this tool, the most important version of that difference is:

  • confirmed higher-timeframe slot behavior versus
  • still-forming higher-timeframe slot behavior

If you keep that sentence in mind, the whole topic gets calmer.

Alerts are still chart-bar-close gated

This is the nuance that catches people.

Even when On Bar Close? is off and a slot can update sooner, the alert conditions are still checked on confirmed chart bars.

That means two things can both be true:

  • the slot value can move during the requested higher-timeframe bar
  • the alert still waits for the chart bar to close before it fires

So "live-forming timing" and "instant alerts" are not the same thing.

A clean replay test

If you want to verify the timing behavior without guessing, use this drill:

  1. Open a chart at 1m or 5m.
  2. Leave one slot on a clearly higher timeframe such as 15 or 60.
  3. Keep the other settings simple.
  4. Turn On Bar Close? on.
  5. Watch that higher-timeframe slot through an unfinished requested bar.
  6. Note how the slot holds the last confirmed read.
  7. Turn On Bar Close? off.
  8. Watch the same slot through another unfinished requested bar.
  9. Note how the slot can now change before that requested bar is complete.

What you are verifying is not whether one mode is morally better. You are verifying what kind of object you are reading.

What usually gets misread

"The indicator repainted, so it must be deceptive"

Not necessarily. If you chose live-forming higher-timeframe behavior, you chose a value that was allowed to keep evolving.

"Confirmed mode is always better"

Not necessarily. Confirmed mode is safer for trust and review. It can also be later than your workflow wants.

"Turning the switch off only changes one slot"

It does not. In this lite build, the timing switch is global across the whole stack.

"If the alert fired late, the MTF logic must be broken"

Often the real answer is simpler: the slot was allowed to move earlier, but the alert still waited for the chart bar to confirm.

A sensible first-use posture

If the indicator is still new to you:

  • keep On Bar Close? on
  • learn the stack in confirmed mode first
  • add alerts only after that mode feels predictable
  • test live-forming behavior later, on purpose

That order protects comprehension. It also reduces the chance that you start trusting speed more than you trust process.

What to verify before you leave this page

You should be able to answer these without guessing:

  • Which slot timeframes are above the chart timeframe right now?
  • Is the whole stack currently confirmed or live-forming?
  • Would a blended shift and an alert always happen at the same instant?

If the answer to the last question is still "yes," read the alerts page next.

Where to go next

  • Go to Alerts if you need the notification timing explained cleanly.
  • Go to Quick Start if you want to rerun the first sanity checks.
  • Go to Limitations and Trust Boundaries if this page made the indicator feel a little more complex than you expected.

Visual placeholder: Replay sequence showing the same higher-timeframe slot with On Bar Close? on versus off, plus one callout noting that chart alerts are still checked on confirmed chart bars.