Under the Hood

For the Geeks

This page is for the reader who wants to understand why the mechanics work the way they do - not just what the settings do, but what is happening underneath and why it was built that way.

The goal is trust through comprehension. If you understand the principles behind the confirmed-bar HTF pattern, the cross-ticker scaling, and the weighted blending, you can make better configuration decisions, predict the indicator's behavior in new situations, and know when to trust its output versus when to double-check.

This page does not reproduce the implementation. It explains the concepts at the mental-model level - enough to build real understanding, not enough to clone the code.

Mechanic 1: The confirmed-bar HTF pattern

The MTF & Repainting page explains what this mechanism does for you - why it matters, what the tradeoff is, and how to verify it. This section explains how it actually works, at the level where you can reason about its behavior in situations the manual has not covered.

The problem at the platform level

When a TradingView indicator asks for data from a higher timeframe, the platform has to decide which bar to deliver. If the indicator is running on a 1-minute chart and requests 60-minute data, TradingView needs to resolve which 60-minute bar to use for each 1-minute bar.

The default behavior in many indicators is to deliver the current (forming) 60-minute bar. This gives real-time updates but creates a timing problem: the 60-minute bar is not finished. Its high, low, and close are still changing. The values the indicator draws on the chart at minute 15 of the hour are different from the values at minute 45, which are different from the final values at minute 60. But after the bar closes, TradingView stores only the final values. History records the finished version, not the versions that were visible during formation. The historical picture and the live picture disagree. That is the repainting problem at the platform level.

How the two components work together

The pattern has two components, and both are necessary. Either one alone does not solve the problem.

Component 1: Request the previous bar, not the current bar. Instead of asking for the current 60-minute bar's Donchian values, the indicator asks for the previous 60-minute bar's values. The previous bar is already closed. Its values are final. They will not change. This eliminates the source of the repainting - the data being displayed was already confirmed before it was delivered.

Component 2: Use a specific request mode that aligns delivery timing. TradingView's data request system has a mode that controls when the returned data becomes available to the chart-timeframe bars. Without this mode, requesting the previous bar's data would introduce a different problem: the data would not appear until the current bar closes, creating an additional bar of delay on top of the one-bar offset. The mode the indicator uses makes the previous bar's confirmed values available immediately - as soon as the HTF bar closes, the confirmed values appear on the very next chart-timeframe bar, with no extra wait.

The combination means: at any point during the current hour, the indicator displays the Donchian Channel values from the previous completed hour. Those values were finalized when that hour closed. They are the same values that will show up in history tomorrow, next week, and next year. And they appeared on the chart at the earliest possible moment after being confirmed - no sooner (which would require seeing the future) and no later (which would waste the data by delaying it).

The tradeoff

The cost is one bar of lag. The indicator is always showing you the previous higher-timeframe bar's structure. On a 60-minute slot, the channel reflects the range from the last completed hour, not the current one.

When On Bar Close is turned off, the indicator switches to requesting the current bar's values directly. This eliminates the lag but reintroduces the repainting problem described above.

Why this is not proprietary

This confirmed-bar pattern is a well-documented technique in TradingView's Pine Script ecosystem. Experienced script authors have been using variations of it for years, and TradingView's own documentation describes the underlying mechanics. What Axiom DC Lite does is apply this pattern consistently across all three slots and make the choice between confirmed and fast an explicit, labeled toggle rather than a hidden implementation detail.

How to verify it

The verification is straightforward and you can do it right now:

1. Apply the indicator to a 1-minute chart with On Bar Close ON.

2. Watch a 5-minute bar form. The DC 01 channel (teal, 5-minute timeframe) should be flat during the entire 5-minute period.

3. When the 5-minute bar closes, the channel may step to new values.

4. Scroll back and confirm: the values on completed bars match what you observed live.

5. Toggle On Bar Close OFF and repeat. The channel will now update mid-bar, and when you scroll back afterward, the historical values will show the final version, not the mid-bar version you saw.

Mechanic 2: Cross-ticker price-space scaling

The problem it solves

Sometimes a trader wants to see another instrument's structural range on their chart. For example: you are trading an individual stock and you want to see where SPY's Donchian Channel sits relative to your stock's price action. But SPY trades at a completely different price level - $550 versus your stock at $45. If the indicator just plotted SPY's raw Donchian values on your chart, the channel would appear far off-screen.

The scaling mechanism maps the other instrument's Donchian Channel into the chart symbol's price space so it visually overlays on the current chart.

How it works (the mental model)

The indicator computes a ratio between your chart symbol's price and the other instrument's price at the same higher-timeframe point. Think of it as asking: "For every dollar of the other instrument, how many dollars of my chart symbol does that correspond to right now?"

It then multiplies the other instrument's Donchian values (upper, basis, lower) by that ratio. The result is a channel that carries the shape of the other instrument's structural range - its expansions, contractions, relative position - but expressed in the chart symbol's price coordinates.

A concrete example:

Suppose your chart shows a stock at $50. You set a slot's Optional Ticker to SPY, which is at $500. The ratio is 50/500 = 0.1. If SPY's Donchian upper is $520, the scaled upper appears at $520 x 0.1 = $52 on your chart. If SPY's Donchian lower is $490, the scaled lower appears at $49.

The scaled channel on your chart shows: the stock equivalent of SPY's range. When SPY's range expands, the scaled channel widens. When it contracts, the scaled channel narrows.

Where it works well

For instruments that are reasonably correlated - a stock and its sector ETF, an index and its primary futures contract, two forex pairs with a known relationship - the scaling produces a useful structural overlay. The shapes correspond. When SPY's range expands, your stock's range is likely expanding too, and the scaled channel gives you a visual reference for whether the cross-market context supports what you are seeing on your chart.

Where it breaks down

The scaling assumes a stable linear relationship between the two prices. That assumption holds well enough for correlated instruments over short to medium periods. It degrades in two important ways:

Uncorrelated instruments: If you set the Optional Ticker to gold while charting a tech stock, the ratio between their prices has no stable structural meaning. The scaled channel will move in ways that reflect gold's structural range mapped into your stock's price space - but that mapping does not correspond to any real structural boundary for your stock. The channel looks like data but carries no actionable information about the instrument you are trading.

Divergent moves: Even for correlated instruments, the scaling becomes less trustworthy during periods when the correlation breaks down. If your stock rallies 5% while SPY drops 2%, the ratio shifts significantly and the scaled channel can move in the opposite direction from your stock's own structure. In that moment, the scaled channel is telling you about SPY's behavior, not about your stock's structural levels.

Ratio failure: The code has a rougher edge than the idealized explanation suggests. If it cannot compute a valid ratio, it does not force the slot to na. It leaves the alternate symbol's raw Donchian values in place. On a differently priced instrument, that can throw the slot far off-scale instead of producing a neat gap.

How to calibrate your trust

The verification is simple:

1. Set a slot's Optional Ticker to an instrument you know is correlated with your chart symbol.

2. Watch the scaled channel for a few sessions. Does it move roughly in sync with your chart's own DC? Do the expansions and contractions make sense relative to what the cross-market instrument is doing?

3. Now try an instrument you know is uncorrelated. Watch the scaled channel behave erratically relative to your chart's price action. That erratic behavior is what the scaling looks like when the underlying assumption fails.

If the scaled channel adds useful context - showing you that the related market's structure is expanding or contracting in ways that align with your chart - it is doing its job. If it moves independently and unpredictably, the instruments are not correlated enough for the scaling to mean anything.

The ratio also respects On Bar Close

The price ratio used for scaling follows the same confirmed/building logic as the Donchian values. When On Bar Close is ON, both the chart symbol's close and the other instrument's close are taken from the previous confirmed bar. When it is OFF, both use the current forming bar. The scaling stays internally consistent with the repainting setting.

Mechanic 3: Weighted channel blending

The problem it solves

Three independent Donchian Channels on the same chart create visual complexity. The blended channel provides a single structural summary that reflects enabled slots in proportion to their assigned importance when the inputs are meaningful.

How it works

The blending is straightforward arithmetic - a normalized weighted average. Upper, basis, and lower are each blended independently using the same process:

1. For each enabled slot that has a non-zero weight, multiply the slot's value (upper, basis, or lower) by its weight.

2. Sum all the weighted values.

3. Divide by the total weight.

That is it. No adaptive logic, no lookback-dependent weighting, no proprietary algorithm. It is the same operation as computing a weighted average of three numbers.

Weight normalization explained:

The weights are proportional, not absolute. What matters is the ratio between them. Consider these three weight configurations:

All three produce the exact same blended channel because the proportions are identical. The indicator divides by the total weight, so doubling all weights changes nothing.

This also means setting a weight to 0 excludes the slot from the blend entirely. The slot's values are not included in the weighted sum, and its weight is not included in the total. The slot still plots on the chart if it is enabled and visible - only its blend contribution is removed.

One ugly implementation detail matters here: before values are pushed into the blend arrays, the script runs them through nz(). So when an enabled slot does not have usable values yet, the blend receives 0 rather than na. In practice that means the blended channel can collapse toward zero instead of politely waiting for all inputs to become valid.

What the blend can and cannot tell you

What it can tell you: A weighted structural summary across your chosen timeframes. When the slots are reasonably aligned, the blend gives you a quick visual reference for the combined picture without having to read three channels separately.

What it cannot tell you: Anything that the individual slots do not already contain. The blend is a weighted compression of existing information, not a derived insight. It does not reveal hidden structure or calculate anything the slots have not already computed.

Where it actively misleads: When the timeframes disagree. If the 5-minute upper is at 100 and the 60-minute upper is at 95, the blended upper (with default weights) is approximately 98. That 98 does not correspond to any structural boundary on any timeframe. It is an arithmetic midpoint of conflicting information. Reading it as "the real structural level is at 98" is a mistake - neither timeframe has a structural boundary there.

Verification moves

• Set two slots to equal weights, disable the third. The blended channel should sit exactly midway between the two remaining slots.

• Change one of the two remaining slots' weight to 0. The blend should snap to the other slot's values.

• Enable all three slots with default weights (40/35/25). Then change DC 01's weight to 0. Watch the blend shift toward DC 02 and DC 03.

These checks confirm the blending is doing what you expect and help you build an intuitive feel for how weight changes affect the result.

Putting it together

The three mechanics interact, and understanding their interaction is what separates a user who configures the tool from a user who can reason about its output in unfamiliar situations.

• The confirmed-bar pattern determines whether the Donchian values going into the blend are trustworthy (confirmed) or provisional (building). This is the foundation layer. If the data is not confirmed, nothing downstream of it is reliable - including the blend, the alerts, and any analysis built on top.

• The cross-ticker scaling determines whether a slot's values represent the chart symbol's own structure or a translated view of another instrument's structure. The blend treats both the same way - it does not distinguish between native and scaled slots. A blend that includes a cross-ticker slot is mixing two kinds of structural information without labeling the difference. If the ratio fails and the slot falls back to raw alternate-symbol values, the blend still averages them as if nothing unusual happened.

• The blending compresses whatever values the slots produce into a weighted summary. It is the last step in the chain, and it is as trustworthy as the least trustworthy input.

Where this matters in practice: Suppose you are running DC 01 and DC 02 on the chart's own symbol with On Bar Close ON, and DC 03 on a cross-ticker with On Bar Close ON. The confirmed-bar pattern is working for all three slots. But DC 03's values are ratio-scaled from a different instrument. The blend mixes DC 01 and DC 02 (which represent the chart's own confirmed structural range) with DC 03 (which represents another instrument's confirmed structural range, scaled). The blend does not know the difference. If the cross-ticker instrument diverges from your chart symbol, the blend drifts toward a weighted position that reflects a mix of two different markets - and there is nothing in the blended channel's visual appearance that tells you this is happening.

If you want to trust the blended channel, you need to trust each of the inputs going into it. That means: On Bar Close on, reasonable timeframe separation between slots, and cross-ticker slots limited to correlated instruments. If any of those inputs are unreliable, the blend faithfully averages that unreliability into its output.

The blend does not filter. It does not validate. It averages. Your job is to make sure what it is averaging is worth averaging. The mechanics on this page give you the understanding to make that judgment.