For the Geeks
This page is for the reader who wants to understand how the non-obvious parts of the indicator actually work — not at the code level, but at the engineering-reasoning level. If you are the kind of person who wants to...
Written By Axiom Admin
Last updated About 1 month ago
For the Geeks
This page is for the reader who wants to understand how the non-obvious parts of the indicator actually work — not at the code level, but at the engineering-reasoning level. If you are the kind of person who wants to know why the cross-ticker bands behave the way they do, or what happens inside the blended-band calculation, this page is for you.
Nothing here is required to use the indicator. Everything here is useful if you want to trust the output at a deeper level, troubleshoot unexpected behavior with confidence, or understand the tradeoffs that went into the design.
This page explains three mechanics:
Cross-ticker price-space scaling
Weighted blended band normalization
In-context HTF computation
For each one, the explanation covers what it does, why it was built that way, what the tradeoff is, and how you can verify the behavior yourself.
1. Cross-ticker price-space scaling
The problem it solves
When you want to overlay SPY's Bollinger Bands onto an AAPL chart, you have an immediate problem: SPY trades around $450 and AAPL trades around $200 (hypothetical values). If you plotted SPY's raw BB values on the AAPL chart, the bands would be hundreds of dollars above the visible price range. You would see nothing useful.
You need a way to project SPY's BB structure into AAPL's price space — to preserve the proportional shape of the bands while making them visually meaningful on the chart you are actually looking at.
How it works
The indicator computes a ratio from the closing prices of both symbols. At each bar, it takes the chart symbol's close and divides it by the reference symbol's close (both fetched at the slot's configured timeframe, both respecting the On Bar Close setting). This ratio becomes the multiplier.
The reference symbol's BB values — upper, basis, and lower — are then multiplied by this ratio. The result is a set of bands that exist in the chart symbol's price space but reflect the reference symbol's volatility structure.
In plain terms: if the chart symbol's close is half the reference symbol's close, the ratio is 0.5, and the reference BB values are halved before being plotted. The proportional shape — how wide the bands are relative to the basis, how the basis moves — is preserved. The absolute price level changes to match the chart.
Why a close ratio and not something else
There were other ways to approach this. A fixed multiplier would be simpler but would drift immediately as prices change. A percentage-based or z-score overlay would be scale-independent but would lose the BB's absolute-price meaning — you could not visually compare band widths between the chart symbol and the reference symbol because they would be in different units.
The close ratio adapts on the slot's timing model and preserves the BB's native price-space interpretation. With On Bar Close off, it can keep shifting while the requested timeframe is still building. With On Bar Close on, it steps using the previous completed closes from that timeframe. A band that was 2% above the reference symbol's basis appears roughly 2% above the projected basis on the chart. This is the most intuitive mapping for a trader who thinks in price terms.
Where it gets less reliable
Ratio instability. The ratio is only as stable as the proportional relationship between the two symbols. If SPY rises 3% while AAPL drops 2%, the ratio changes by roughly 5% — and that shift moves the projected bands even if SPY's actual BB did not change. The user sees the cross-ticker bands shifting and might think the reference structure changed, when really the mapping changed.
Structural divergence. When two symbols are in fundamentally different regimes — one trending up while the other consolidates, or one in high volatility while the other is calm — the proportional mapping still works mathematically, but the projected structure becomes less meaningful. You are mapping a trending structure onto a consolidating price — the resulting visual does not correspond to any structural reality in the chart symbol.
Large absolute price differences. When the chart symbol is $10 and the reference symbol is $500, the ratio is 0.02. Small percentage changes in either symbol produce proportionally small absolute changes in the ratio — but those small changes apply to the large BB values being projected, which can create jumpiness in the projected bands that does not reflect actual structural change.
How to verify it
Set one slot to an Optional Ticker — for example, SPY on an AAPL chart — at the 60-minute timeframe with On Bar Close on.
Open a separate chart of SPY and apply a standard Bollinger Band with the same settings (length 20, multiplier 2.0, SMA, 60-minute timeframe).
Compare the shapes. The proportional structure should be similar — band expansions and contractions should roughly coincide, basis direction should match.
The absolute values will differ because one is in AAPL's price space and the other is in SPY's. That difference is the scaling at work.
If you want to verify the ratio, divide AAPL's close by SPY's close at a specific bar. Multiply SPY's basis by that ratio. The result should be close to what the cross-ticker basis shows on the AAPL chart.
2. Weighted blended band normalization
The problem it solves
When you run 3 BB slots at different timeframes, you see three sets of bands. The natural question is: "Where is the middle ground?" The blended band answers this by computing a weighted average across all contributing slots.
The challenge is making this average behave sensibly when slots have different weights, when some slots are disabled or set to zero weight, and when the user expects the blend to respond predictably to configuration changes.
How it works
The blended band computes three independent weighted averages:
Blended upper = (Slot1_upper × weight1 + Slot2_upper × weight2 + ... ) / total_weight
Blended basis = (Slot1_basis × weight1 + Slot2_basis × weight2 + ... ) / total_weight
Blended lower = (Slot1_lower × weight1 + Slot2_lower × weight2 + ... ) / total_weight
Only enabled slots with weight greater than zero contribute. The total weight is the sum of all contributing slots' weights, and each slot's contribution is proportional to its share of that total.
Key property: independent averaging. Upper, basis, and lower are averaged separately. This means the blended band can have a different width profile than any individual slot. If Slot 1 has tight bands and Slot 3 has wide bands, the blended upper is somewhere between the two uppers, and the blended lower is somewhere between the two lowers — but those "somewheres" are computed independently, so the blended width is not simply the average of the individual widths.
Weight normalization. Weights do not need to sum to 100. If three slots have weights of 60, 40, and 20, the total is 120, and the contributions are 50%, 33%, and 17% respectively. This normalization means you can set weights in whatever units feel natural — the math handles the proportioning.
What happens at the edges
All weights at zero. If every enabled slot has weight 0, the total weight is 0, and the blend produces 0 values. On most price charts that collapses the blended lines toward zero, which usually pushes them off-screen or makes them obviously wrong rather than truly removing them.
One slot contributing. If only one slot has weight > 0, the blend tracks it exactly. This is a useful sanity check: disable all but one slot, and the blend should be identical to that slot's bands.
Two slots at 50/50. The blend sits at the exact midpoint between the two slots. You can verify this visually — the blended lines should be equidistant from both contributing slots' lines.
Hidden slots. A slot with its plot hidden but still enabled with weight > 0 contributes to the blend normally. The blending logic does not know or care about plot visibility — it only looks at whether the slot is enabled and has non-zero weight. This is the most common source of confusion with the blend: the visible bands suggest one position, but a hidden contributor is pulling the blend elsewhere.
Why averaging can hide useful information
The blend smooths over the disagreements between slots. When the 5-minute BB says price is compressed and the 60-minute BB says price is extended, the blend gives you a value somewhere in between. That "in between" may look calm and centered — when the underlying reality is structural tension between timeframes.
Consider a concrete case. You are running three slots at equal weight: 5m, 15m, and 60m. The 5-minute bands are tight — price has been in a narrow range for the last hour. The 60-minute bands are wide — there was a strong directional move earlier in the session. The 15-minute bands sit in between. The blend produces a band that looks moderate: not tight, not wide. On the chart, it looks like "normal" volatility.
But the actual situation is a 5-minute compression inside a 60-minute expansion. That configuration — low short-term volatility inside high longer-term volatility — is often a setup for a sharp move. The compression is coiling inside the expansion. The blend, by averaging the two, shows neither the compression nor the expansion. It shows a calm middle ground that does not correspond to any structural reality at any timeframe.
If you are reading the blend, you see a moderate, unremarkable state. If you are reading the individual slots, you see tension between scales. The tension is the information. The blend hid it.
Practical takeaway: The blend is a convenience, not a replacement for reading the individual slots. When the blend and the individual slots tell a consistent story, the blend is a reliable summary. When they look inconsistent — when the blend sits in a position that does not match what any individual slot is doing — that is the blend averaging away a disagreement you should investigate rather than accept.
How to verify it
Enable exactly two slots at equal weights (e.g., both at 50).
The blended band should sit at the midpoint between the two slots' bands.
Change one slot's weight to 75 and the other to 25.
The blend should shift toward the higher-weighted slot — roughly 75% of the way from the lower-weighted slot to the higher-weighted one.
Set one slot's weight to 0. The blend should now track the remaining slot exactly.
Re-enable both and hide one slot's plot (but keep it enabled with weight > 0). The blend should not change — proving that visibility has no effect on blending.
3. In-context HTF computation
The problem it solves
Most multi-timeframe indicators on TradingView follow a pattern like this:
Request the higher-timeframe source series (e.g., the close) using
request.security()Compute the indicator (e.g., a BB) on the chart timeframe using the requested HTF data
This works, but it introduces a subtle problem. The HTF close is sampled onto chart-timeframe bars — one HTF value is replicated across many chart bars. When you compute a moving average and standard deviation on this replicated series, the calculations run on interpolated data rather than on the actual HTF bar series. The result is a BB that looks like an HTF BB but is computed differently from one you would see on an actual HTF chart.
The difference can be small or significant depending on the MA type, the length, and the timeframe ratio. But it is always there, and it makes comparison between the MTF overlay and a native HTF chart imprecise.
How Axiom BB Pro does it differently
Instead of requesting the HTF source and computing locally, Axiom BB Pro computes the full Bollinger Band — the basis moving average and the standard deviation — inside the request.security() expression itself. The calculation runs on actual higher-timeframe bars, not on chart-timeframe bars that have been filled with HTF values.
This means:
The basis MA is computed over real HTF candles with their actual opens, closes, highs, and lows
The standard deviation is computed over real HTF price movements, not over a sampled and replicated series
The resulting BB values line up with the requested timeframe's own BB calculation when you compare the same timing mode and the same bar state
Why this matters to you
If you compare Axiom BB Pro's 60-minute BB on a 1-minute chart to a standard Bollinger Band applied directly to a 60-minute chart, compare like with like. With On Bar Close = true, the slot is showing the last completed 60-minute bar, not the still-building 60-minute bar. With On Bar Close = false, it follows the building 60-minute bar and can repaint after the fact. If the values do not line up once you match the timing mode, you cannot trust the overlay.
This matters more than it might seem at first. If the MTF BB values were computed on interpolated chart-timeframe data, you would be looking at bands that look like the HTF BB but are subtly different. The standard deviation, in particular, would be computed on a series where the same HTF value is replicated across many chart bars. You might notice the bands look slightly "off" compared to the requested-timeframe chart, or you might not. Either way, you would be building structural reads on numbers that are close but not right.
The in-context approach eliminates the approximation gap. The bands you see on your 1-minute chart are coming from the actual requested-timeframe calculation, not a sampled imitation. The remaining job is timing the comparison correctly: confirmed slots should be checked against completed requested-timeframe bars, and live slots should be checked live while that requested-timeframe bar is still building. If you point a slot at the chart timeframe and leave On Bar Close on, expect a one-bar-lag confirmed view by design.
How to verify it
Apply Axiom BB Pro to a 1-minute chart. Set Slot 1 to the 60-minute timeframe, On Bar Close = true, SMA, length 20, multiplier 2.0.
Open a 60-minute chart of the same instrument. Apply a standard TradingView Bollinger Band with the same settings: SMA, length 20, multiplier 2.0, source close.
Compare the BB Pro slot to the last completed 60-minute candle on the standalone chart. Those values should match because both are using the confirmed 60-minute bar.
If you want to compare the still-building 60-minute candle instead, turn On Bar Close off on the slot and watch both charts live. Do not use historical bars for that comparison, because the live 60-minute path is not preserved after the fact.
The fact that they match confirms the in-context computation is doing its job. The MTF overlay is not an approximation of the HTF BB — it is the HTF BB, computed where it belongs and projected onto your chart.
What this page does not cover
This page explains the engineering reasoning behind three non-obvious mechanics. It does not cover:
The source code, internal function names, or specific implementation patterns
The exact formulas used by the Axiom MA Library for each MA type
The na-handling logic or edge-case branching in the scaling or blending functions
Performance considerations or TradingView-specific execution details
Those details are part of the implementation. This page is about the architecture — the choices that were made, why they were made, and how you can verify that they work. The implementation serves the architecture, and the architecture serves you.