MTF & Repainting

This page is the one to read before you tune this indicator beyond defaults. Multi-timeframe behavior is where a CVD tool most often lies to its reader — either by design or by neglect — and the whole reason this pane exists is that its author has been on the receiving end of both. The posture taken here is blunt and adjustable, but the default is the honest one and the knob that changes it is named, explicit, and guarded. Knowing the content of this page is what separates a reader who trusts the tool for the right reasons from a reader who trusts it for the wrong ones.

Why MTF is a trust problem, not just a convenience problem

A multi-timeframe indicator running on a lower-timeframe chart has two jobs that pull in opposite directions.

• It wants to react fast, so you see new information as early as possible.

• It wants to not lie, so the information you see now is the same information that will be there an hour later when the bar is finally closed.

A naive implementation reads the live higher-timeframe bar and plots its current value on every lower-timeframe bar. It is fast. It is also a machine for producing charts that look clean in hindsight and look nothing like what was on the screen at the moment of decision. The line on the chart yesterday was not the line that was actually there at the time; the tool was silently updating the past to match the present.

That class of failure has a name. This pane does not do it by default, and it does not pretend it never does it under any configuration. What it does is put the tradeoff on a switch named On Bar Close?, default it to the honest posture, and document both postures clearly enough that a reader choosing OFF knows exactly what they are choosing.

The timing posture, per slot

Every slot runs on its own timeframe, chosen by TimeFrame: in the slot's Inputs group, and is rendered onto the chart's lower timeframe by TradingView's request.security mechanism. Two controls inside this indicator govern how that rendering behaves.

On Bar Close? — the repaint switch

In every slot's Power User group, the first control is the toggle On Bar Close?. Its default is true.

When true (ON, the default):

• On every chart bar, the slot reports the previous closed value of its own higher-timeframe bar.

• Visually, the slot line steps and holds: it stays flat across the chart bars that fall inside a single slot-TF bar, then jumps to a new value at the start of the next slot-TF bar (when the previous one closes).

• The value you see at any moment is the confirmed value from the most recently closed slot-TF bar. That value will not change as the current slot-TF bar continues to form.

• Combined with TradingView's lookahead_on mode (used by the underlying request.security call), this posture is not a repainting configuration. The [1] offset on the prior value cancels the lookahead's forward bias. What you see now is what was there at the close of the last confirmed slot-TF bar.

When false (OFF):

• On every chart bar, the slot reports the live value of its current, in-progress higher-timeframe bar.

• Visually, the slot line drifts: it updates whenever the current slot-TF bar's OHLCV changes, which on a lower-timeframe chart is constantly.

• The value you see at any moment is provisional. It can, and often will, change direction multiple times before the slot-TF bar closes. The final value is only known when the bar closes.

• This posture does repaint within the current slot-TF bar, by design. The state you see now may not be the state you saw thirty seconds ago, and the chart you look at tomorrow will show the bar's final value, not its drifts along the way. That is the cost of the earlier read.

OFF is not hidden. It is not shameful. It has a legitimate use, documented below. The pane's job is to make the tradeoff choosable and named, not to pretend it does not exist.

lookahead_on plus [1] — why ON is safe under the hood

TradingView's request.security supports two lookahead modes. The default lookahead_off makes the security call behave like a regular historical read that does not know the future. The alternative lookahead_on lets the security call pull the value at the current moment on the higher timeframe, which can introduce look-ahead bias if used naively: a chart bar in the middle of the day "knows" what the higher-timeframe bar has closed at hours later.

This indicator uses lookahead_on, but it pairs it with a [1] offset inside the security call. The [1] says "give me the value one slot-TF bar ago." The combination is intentional: lookahead_on makes the read align cleanly on the slot-TF bar edges, and [1] prevents the read from seeing into the future. Together they produce the step-and-hold behavior described above.

You do not need to do anything with this information except know it exists. It is the detail a trust-checking reader will want, and the reason On Bar Close? = ON is a safe default rather than a lie.

Four behaviors to verify with your own eyes

Reading about repainting is cheaper than watching it. Watching it is the thing that makes the concepts stick. Four quick drills.

Drill 1 — Step-and-hold on ON

On a 5-minute chart with default settings, focus on the blue CVD 03 line (60-minute slot). Watch a full hour pass.

• For the twelve 5-minute bars inside a given hour, the blue line should sit completely still.

• At the top of the next hour (when the 60-minute bar closes), the blue line steps to a new value.

If instead the line wiggles on every 5-minute bar, either the chart timeframe or the slot's On Bar Close? setting is not what you think it is. Check both.

Drill 2 — Drift on OFF

Still on the 5-minute chart, open CVD 01's Power User group and set On Bar Close? to false. Save.

• The teal line now updates on every 5-minute intrabar refresh.

• At each 5-minute close, the line snaps to a final value.

Set it back to true when done. You have just watched the same slot produce two materially different pictures.

Drill 3 — Lookback-history edge

Scroll the chart back until you are looking at bars far in the past. On some chart plans, TradingView does not have intrabar history available beyond a certain depth; the slot is allowed to fall back to a cruder single-bar OHLCV delta read (described below). The line does not visually announce the fallback. What you are looking for is a stretch of bars where the line is visibly less responsive than a comparable recent stretch. If you see it, you have seen the fallback.

Drill 4 — Guardrail provocation

Open settings. Change a slot's TimeFrame: to a value below the chart's. Save. You should see the pane clear and a runtime error in TradingView's status row, naming the slot. Restore. This is the timeframe guardrail (see below) doing its job.

The three runtime guardrails

The indicator refuses to render three configurations that cannot be read honestly. Each is a hard runtime error, not a warning.

Slot timeframe below chart timeframe

Condition: A slot's TimeFrame: is lower than the chart's timeframe.

Why it is refused: A 1-minute CVD read cannot be folded into a 5-minute chart bar at chart resolution without losing everything that made the 1-minute read informative. The higher-resolution slot cannot be represented faithfully on the coarser chart.

Message: <slot label> timeframe cannot be lower than the chart timeframe.

Fix: Set the slot's TimeFrame: equal to or greater than the chart's, or move to a lower-timeframe chart.

Lower TF precision not strictly below slot timeframe

Condition: A slot's Lower TF Precision: is equal to or greater than its TimeFrame:.

Why it is refused: The precision value tells the estimator which lower timeframe to walk through to decompose each slot-TF bar into signed-volume contributions. A precision equal to or coarser than the slot timeframe leaves nothing to decompose.

Message: <slot label> lower TF precision must be lower than the slot timeframe.

Fix: Set Lower TF Precision: strictly below TimeFrame:. On a 15-minute slot, 1 and 5 are both legal; 15 and above are not.

Window below slot timeframe

Condition: A slot's Window: is lower than its TimeFrame:.

Why it is refused: The window is either the session-reset anchor (Session mode) or the sliding lookback size (Rolling mode). In both cases, a window finer than the slot itself has no interpretation.

Message: <slot label> window must be greater than or equal to the slot timeframe.

Fix: Raise Window: to at least the slot timeframe. On a 60-minute slot, D and 60 are legal; 15 is not.

Each guardrail is visible immediately in the status row when triggered. Having provoked at least one of them during the Quick Start drill (see Quick Start) is the cheapest way to know what the errors look like before they surprise you mid-session.

Session versus Rolling — the other MTF posture

Window Mode: is the second MTF-shaped choice a slot carries.

• Session mode — the slot's CVD resets to zero at the start of each Window: interval, and its normalization rescales against the high and low observed inside the current session. Session mode is how traders who think of CVD in daily terms read the tape: each new day gives a clean accounting cycle, and the dashed vertical reset markers show when each cycle starts.

• Rolling mode — the slot's CVD evolves continuously using a sliding lookback the size of Window:. There is no reset. Older bars drop out of the window as newer ones arrive.

Timing-wise, both modes are subject to the same On Bar Close? switch. A rolling-mode slot with On Bar Close? ON still steps and holds on its own timeframe. A session-mode slot with On Bar Close? OFF still drifts within its slot-TF bar.

The cases where rolling mode is the right posture tend to share a shape: the reader wants a continuous regime read, does not want the accounting artifact of a reset near a decision point, or is running an optional-ticker slot across different session calendars (SPY's daily and BTCUSDT's daily do not share an edge). The cases where session mode is the right posture tend to share a shape too: the reader is working inside a daily or weekly accounting cycle and wants the reset to be visible because its timing is part of the information.

Neither is universally better. Both are first-class. The choice is per-slot.

The intrabar fallback

The slot's participation estimator walks the lower timeframe precision window inside each slot-TF bar, classifying each intrabar's contribution and folding it into the slot's running state. On a bar where that lower-timeframe history is not available — typically because you have scrolled far enough back that TradingView's intrabar depth has run out — the estimator falls back to a single-bar OHLCV delta using only the slot-TF bar's own open, high, low, close, and volume.

Two things to know about the fallback.

• It is a cruder read. A single OHLCV bar carries less structure than several dozen intrabar samples of the same bar. The classifier's decisions are necessarily less informed, and the line will often look smoother or less responsive through the fallback stretch than it does where intrabars are available.

• The pane does not visually announce the fallback. There is no marker that says "intrabar history ended here." A reader studying old data is expected to be aware that some of what they see on deep historical bars is the fallback's output, not the full-precision estimator's output. Limitations & Trust Boundaries covers this as a named honest limit.

If your question is a live-market one on a liquid symbol, fallback is less likely to matter because recent intrabar history is usually available. It is not a promise. Thin symbols, unusual sessions, or plan limits can still make the estimator fall back sooner than you expect. If your question is a historical one (backtesting a setup across months or years), the fallback is the reason you should spot-check your backtest against the estimator's behavior on recent bars where it has full precision.

How the blend behaves across slots with mixed postures

The blended CVD is a weighted mean of the enabled, non-zero-weight slots at the chart-bar time. The slots each carry their own posture. That combination yields behavior a reader sometimes finds surprising.

• All slots ON. The blend itself steps and holds, changing only when one of its inputs steps — in practice, that means the blend shifts every time any slot's higher-timeframe bar closes. The blend's smoothness is the union of its inputs' steps.

• One slot OFF, rest ON. The blend drifts whenever the OFF slot drifts, and steps whenever any ON slot steps. The blend is partially live. A reader who has not internalized this will read the drifting blend as live information without realizing one slot is silently producing that drift.

• All slots OFF. The blend is fully live. The blended state on the current bar is provisional until every slot's bar closes. There is no single "confirmed" read; there are ten of them, on ten schedules.

The alert layer is more forgiving than the visual layer here: every alertcondition is gated on barstate.isconfirmed, so alerts fire only at chart-bar close regardless of individual slot postures. But the visual read during the bar's formation is whatever the posture mixture produces. If your workflow leans on the visuals, matching the postures across the slots that feed the blend is the right move for readability.

When OFF is the honest choice

Defaults exist because they are right for most readers most of the time. They are not right for all readers all of the time. Three cases where On Bar Close? OFF is a legitimate, documented choice:

• Intraday scalping with higher-timeframe context. A desk running on one-minute bars and using a 5-minute slot for context may accept the drift as the price of seeing the 5-minute read earlier than "at the next 5-minute close." If that drift is taken as provisional — and actions are not committed until the slot-TF bar closes — OFF can be the right posture.

• Research on historical data. When you are studying closed historical bars, both postures are stable after the fact, but they are not the same series. ON reads the previous slot-TF bar; OFF reads the current slot-TF bar after it has closed. Flipping OFF for a research session is fine only if the current-slot-bar posture is the one you mean to study.

• Deliberate study of the drift itself. A reader who wants to see how much a slot moves during the formation of its bar can learn a lot by watching an OFF slot drift on a quiet instrument. This is a teaching use, not a trading use, but it is honest.

Cases where OFF is not honest:

• Using OFF to shorten the perceived latency of a state while still trusting the state as if it were confirmed. The earlier read is provisional. Treating it as confirmed is the repainting failure mode the switch exists to prevent you from falling into unknowingly.

• Comparing two OFF slots' color-flip timestamps across a session and concluding one "led" the other. Both slots drift. The timestamps you read off are artifacts of which one happened to be drifting at which moment.

If in doubt, leave ON. If you do flip OFF, name the slot and the reason in whatever notes you keep for yourself. Future-you will not remember why a slot is OFF six weeks from now and will read it as if it were ON, which is the worst of both worlds.

Verification moves for MTF posture

Three cheap checks to confirm the pane is doing what you think it is doing.

Check 1 — Visual step-and-hold on every ON slot

Every slot with On Bar Close? ON should be visibly stepping at its own timeframe, not at the chart's. If a 60-minute ON slot looks like it is moving on every 5-minute bar, something is wrong — either the setting was flipped, or the slot's TimeFrame: is not what you think.

Check 2 — Confirmation lag on alerts

Wire a per-slot alert on the slot you care about. The alert should fire exactly at chart-bar close. If the alert fires mid-bar, check TradingView's alert-frequency setting (the indicator emits the condition at chart-bar close; repeat-fire within a bar is a TradingView-side setting).

Check 3 — Historical stability on ON

Screenshot the pane once. Wait an hour. Screenshot again, scrolling back so the historical region matches. The historical region of the chart should look identical in both screenshots. Any visible change in historical bars when the slot is ON is a bug — report it. Under OFF, the historical region will not change either (past bars are closed), but the current forming bar on the second screenshot will reflect whatever the slot looked like in that moment; that is expected OFF behavior, not a bug.

Three MTF traps

1. Flipping OFF "for speed" on a slot you then trust. OFF slots drift. Any read you take before the slot's own bar closes is provisional. Treating the earlier read as confirmed is exactly the failure that the ON default is built to prevent. The knob is not the trap; the trap is trusting an OFF read as if it were an ON read.

2. Running the chart at a timeframe very close to the slot's. A 5-minute slot on a 3-minute chart is legal, but the slot steps on its own 5-minute schedule and the chart's 3-minute bars will not line up cleanly with the steps. The visual rhythm looks stuttered. Either raise the chart timeframe to match the slot, or pick a slot timeframe that maps cleanly onto the chart's.

3. Treating "multi-timeframe" as a synonym for "repaint-safe." Multi-timeframe just means the indicator reads multiple timeframes. Whether it repaints is a separate question, answered per-slot by On Bar Close?. A tool that advertises "multi-timeframe, no repaint" is either using this posture explicitly — in which case it is committing to the step-and-hold behavior described above — or is quietly repainting and counting on the reader not to notice. The distinction is worth looking for on every MTF tool you read.

Where to go next

• For the state-by-state visual behavior at chart-bar close, Visuals & Logic.

• For how the per-slot alerts gate on confirmed bars, Alerts.

• For the estimator posture beneath the MTF layer, For the Geeks.

• For the honest-limits story, including the intrabar fallback, Limitations & Trust Boundaries.

• For documented workflows that pick a posture deliberately rather than accept defaults, Workflows.