For the Geeks

This page is for the reader who wants to know what the estimator is doing before they put weight on it. It walks through the participation model at mental-model altitude — enough to decide whether to trust the line, n...

Written By Axiom Admin

Last updated 22 days ago

For the Geeks

This page is for the reader who wants to know what the estimator is doing before they put weight on it. It walks through the participation model at mental-model altitude — enough to decide whether to trust the line, not enough to rebuild it. The formulas, thresholds, coefficients, and internal mappings stay in the source file. What lives here is the reasoning that connects the page you see on screen to the decisions made underneath it.

If you came here looking for pseudocode, you will not find it. Not because we are being coy. Because the honest job of this page is to earn trust by explaining the thinking, not to hand over a blueprint. If the explanation below does not earn your trust, the right answer is probably to use a different tool rather than to extract more implementation detail.

That last sentence is not a negotiating position. A reader who decides, at any point in this page, that the estimator's approach does not fit their process is doing the work this page is built to enable. There is no penalty for walking away. What the page refuses to do is let a reader stake real money on a tool whose reasoning they have not inspected, which is why the depth is here and why the protected details are not.

Why this page exists at all

Most CVD tools show you a line and move on. The reader is left to either accept the line on faith or reject the line on vibes. Both are bad options. This page is the alternative: a structured walkthrough that a serious reader can use to form a defensible opinion about whether the estimator's approach fits their process. The goal is not to convince you the estimator is right. The goal is to give you enough material to decide.

If at any point in the reading below you think "that is not how I would do it" or "I do not believe that approach," that is fine — and it is the kind of disagreement we want to surface now, at the desk, rather than at the moment when real money is on the pane. Limitations and Trust Boundaries is the companion page for readers who decide the estimator is not where they want to lean.

The problem the estimator is solving

Every cumulative-volume-delta tool that runs inside TradingView has the same underlying problem: the platform does not hand the indicator tick-resolution bid/ask delta. What it hands the indicator is OHLCV — open, high, low, close, volume — at whatever timeframe resolution the script requests. Turning that into a defensible estimate of signed volume requires answering one awkward question:

For each bar, how much of that bar's volume should be attributed to buying participation versus selling participation?

The naive answer is "look at the close relative to the open." Green bar is buying; red bar is selling; volume splits on that basis. That is correct on decisive bars. It is misleading on balanced bars and on wick-led rejection bars, and it is actively wrong on the bars where understanding participation is most useful.

This estimator does not take the naive route. It reads three pieces of evidence from each bar and combines them into a bar intent score; it classifies that score into one of several participation buckets; and it carries forward the previous state on bars that do not have enough to say. Each of those three moves has a reason.

The three pieces of evidence

For each bar the estimator is scoring — whether that bar is a lower-timeframe intrabar or the slot bar itself in fallback mode — it reads:

  • Body direction. The close-minus-open distance, normalized against the bar's full high-low range. A strong close above the open reads as buying; a strong close below reads as selling; a balanced body reads as ambiguous.

  • Close location. Where the close sits inside the bar's range, on a -1 to +1 scale. A close near the bar's high reads as buying even if the body was small; a close near the bar's low reads as selling. This captures the distinction between "bar closed in the upper third" and "bar closed in the middle."

  • Wick asymmetry. The imbalance between the upper and lower wicks. Long lower wicks relative to upper wicks suggest rejected downside — the buyers came in; long upper wicks relative to lower wicks suggest rejected upside — the sellers came in.

Each of these is a separate piece of information. A bar with a small body but a close near the high and a long lower wick is a different bar from a bar with the same small body but a close near the middle and symmetric wicks. A body-direction-only model treats them identically. This estimator does not.

What we do not publish: the coefficients that combine these three pieces into the intent score. The reason is simple — publishing the coefficients hands over a clone of the estimator, which is not what this page is here for. The claims register inside the planning artifacts codifies this boundary; the page you are reading on the live product does not.

Verification moves for the three pieces

  • Load a strong-body decisive bar with aligned wicks. Confirm the slot line moves in the expected direction with visible conviction.

  • Load a balanced doji. Confirm the line does not spike. The estimator should treat it as ambiguous.

  • Load a bar with a small body but a long lower wick. Confirm the line moves up more than you would expect from body direction alone. Push Wick Weight higher on that slot and confirm the same bar now moves the line more.

  • Load a bar with a big body but a close against the body direction (for example, a bar with a strong upper body but a close that pulled back to near the open). Confirm the line's response is more muted than on a similarly-sized bar that closed on its highs.

Each of these is a concrete test you can run on any chart with a readable example. The point is not to "prove" the estimator; the point is to put your eye on what the three-piece evidence looks like in practice.

The buckets

Once each bar has its intent score, the estimator classifies the bar into one of several participation buckets. Five branches exist:

  • Strong up. Intent score is clearly positive and commits the bar to full bullish participation at the bar's volume.

  • Weak up. Intent score is moderately positive. Commits the bar to partial bullish participation.

  • Strong down. Intent score is clearly negative. Commits to full bearish participation.

  • Weak down. Intent score is moderately negative. Commits to partial bearish participation.

  • Indecisive (carry). Intent score does not clearly fall into any of the above. The bar does not generate fresh participation on its own; instead, it carries the prior bar's state forward at a partial magnitude.

Why five buckets instead of a continuous scale? Because participation is, in practice, a discrete concept. A bar either has buyers leaning on it, or sellers leaning on it, or neither clearly. A continuous scale would assign meaningful participation to every balanced bar the market produces, which in aggregate overstates how much participation is happening. The discrete bucket approach is more honest about the cases where the answer really is "this bar does not strongly indicate anything."

What we do not publish: the threshold values that separate the buckets, or the exact magnitude of "full" versus "partial" participation. These are protected details for the same reason the coefficients are.

Why the indecisive branch carries state

This is the design choice most worth explaining, because it is also the one most likely to feel counterintuitive.

On an indecisive bar, the estimator could do one of three things: zero out the bar (contribute no participation), flip to the opposite direction (let the bar's slight disagreement reverse state), or carry the prior bar's lean forward at a reduced magnitude. This estimator does the third.

The reasoning is a hypothesis about how participation actually behaves. When a market is under buying pressure for a stretch and then prints an ambiguous bar, the underlying participation did not vanish on that bar — it usually thinned, while the prior-direction pressure was still present. A zero-out model would erase that presence; a flip-on-weakness model would invent an opposite pressure that probably is not there. A carry-forward-at-reduced-magnitude model respects the continuity of the prior state while also admitting that the current bar is not contributing fresh evidence.

The carry is at a partial magnitude, not the full prior state. It does not reset the prior state by itself; it keeps contributing partial volume in that prior direction until a later bar is decisive enough to update the state. That is useful when the tape is pausing inside a real move, and it is costly when chop keeps borrowing stale context. The specific magnitude of "partial" is a protected detail, but the behavior is the important part: continuity when the bar has nothing to say, and a known drift risk when too many bars keep having nothing to say.

Verification moves for the buckets

  • Watch a quiet range. During extended indecision, the slot line can keep leaning in the prior direction because carry is still contributing partial volume. That drift is the tradeoff. It is not proof of fresh pressure; it is the model preserving prior state until a decisive bar changes it.

  • Watch a decisive counter-move after a long one-sided run. The line should flip relatively quickly. The bucket model commits on decisive bars; the carry does not override real signal.

  • Compare a mild pullback against a small reversal bar. A mild pullback inside a continuing run will show the line easing but not flipping (carry is holding). A small but genuinely decisive reversal bar against a longer-running move will show the line starting to turn.

Pressure Sensitivity, at model depth

Pressure Sensitivity is the user-facing knob that controls how quickly the bucket classifier commits a bar to a strong bucket versus a weak bucket versus the indecisive branch.

At higher values, the thresholds that separate the buckets narrow. More bars can classify as weak or strong instead of staying in the carry branch. The carry magnitude also shifts upward, so the bars that still remain indecisive carry the prior state more strongly. The net effect on the pane is a more assertive classifier: smaller evidence can commit, while true indecision can preserve prior-state bias more forcefully.

At lower values, the thresholds widen. More borderline bars land in the carry branch, but the carried contribution is smaller. The net effect on the pane is a more cautious classifier: it needs clearer evidence to commit, and it assigns less volume to bars that do not earn a bucket.

The knob changes the classifier, not the data. A higher Pressure Sensitivity does not let the estimator see more participation; it just makes the estimator speak more confidently about what it already sees. A reader who assumes "more sensitive" means "more accurate" will mis-tune this knob. Settings names this as a misuse warning; this page is the reasoning behind it.

What we do not publish: the mapping from Pressure Sensitivity to the internal thresholds and carry magnitude. That mapping is a protected detail.

Why you do not get to pick the buckets directly

It would be possible to expose the bucket thresholds themselves as separate inputs and let the user tune them independently. We did not, for two reasons:

  • The three parameters (strong threshold, weak threshold, carry magnitude) are not independent. Changing one in isolation while holding the others fixed produces behavior that is not internally consistent. A user who tuned the strong threshold down without adjusting the weak threshold would get a classifier that rarely commits weak and frequently commits strong, which is a less defensible shape than any of the coordinated configurations along the Pressure Sensitivity axis.

  • Three independent knobs triples the tuning surface for the user. Pressure Sensitivity ties them together on a single defensible axis. The cost is that a specific reader cannot decouple them; the benefit is that the user-facing knob always produces an internally coherent classifier.

The CTX trim does not expose them either, for the same reason.

Wick Weight, at model depth

Wick Weight is the user-facing knob that controls how much the wick-asymmetry piece of evidence contributes to the intent score.

At higher values, wick asymmetry carries more weight in the score. A bar with a long lower wick and a small body will produce a more bullish intent score than the same body-and-close on a symmetric-wick bar. On instruments where wicks genuinely carry information — liquid spot markets where wicks reflect real rejections — this is usually the honest posture.

At lower values, wick asymmetry carries less weight. The estimator leans harder on body direction and close location. On instruments where wicks are mostly thin-book noise — illiquid products, overnight stretches, low-volume sessions — this can be the more defensible posture.

The tradeoff sits in a specific kind of error each posture makes. High Wick Weight makes the estimator responsive to wicks that happen to be real rejection; it also makes it responsive to wicks that are thin-book artefacts. Low Wick Weight ignores thin-book artefacts; it also ignores real rejections. Neither is universally correct. Which error you would rather tolerate depends on the instrument.

What we do not publish: the coefficients on body, close location, and wick bias inside the intent score.

Bounded normalization

After each slot's accumulation runs (Session-reset or Rolling), the raw cumulative value is mapped to a 0-to-100 range using the window's observed high and low. That is the _normalizeCvd step.

The consequences of bounding the output this way are worth naming explicitly.

  • Every slot on every instrument is drawn on the same scale. Cross-symbol visual comparison is possible; cross-symbol cumulative comparison is not. Two slots at 80 on different instruments are at the same relative position in their own windows, not at the same absolute cumulative delta.

  • The pane is portable. The same indicator on a liquid futures contract and on a thinly-traded stock will both show lines inside 0-to-100. That is not a statement about participation magnitude; it is a statement about normalized position.

  • Bounded does not mean meaningful. A slot pinned at 100 can be reporting a genuinely one-sided accumulation or a quiet window that normalization is amplifying. Visuals and Logic and Limitations both carry this.

  • The bounding does not fake conviction. Clamping the line to 0 and 100 prevents the raw cumulative from drifting forever, but it does not invent meaning on windows that have not produced variation. A quiet window produces a quiet normalization range, which in turn produces a pane that is easy to mis-read as decisive when it is actually describing thin evidence.

Why bounded instead of Z-score or percentile

Two common alternatives to simple high-low normalization are Z-score (subtract the window mean, divide by the window standard deviation) and percentile-rank (map the current value to its percentile against the window's observed values). Both are legitimate approaches for different purposes.

Simple high-low normalization wins here for three reasons:

  • Visually stable across instruments. The line's position on the pane corresponds directly to where the cumulative sits in its range. A reader's eye can trust the guides.

  • Fast to compute incrementally. The estimator is doing a lot of work per bar; keeping the normalization simple leaves budget for the more expensive pieces.

  • Does not assume distribution. Z-score assumes a roughly Gaussian distribution of cumulative values; cumulative deltas are not Gaussian. Percentile-rank requires the full window history each bar, which is expensive. Simple high-low is agnostic and cheap.

The tradeoff is that simple high-low is sensitive to outliers at the window edges. That is a real cost, and it shows up as the quiet-window pinning described above. The tradeoff is one we chose deliberately and one the reader can see on the pane rather than be hidden from.

The smoothing pair (CVD and signal lines)

After the normalized 0-to-100 value is produced, two MA passes happen per slot.

  • First pass: the CVD line. The normalized value is smoothed by the slot's configured CVD Length and CVD Type. This is the line you see plotted.

  • Second pass: the signal line. The already-smoothed CVD value is smoothed again by the slot's configured Signal Length and Signal Type. This is the line the CVD is compared to for color flips and alerts.

The signal is computed off the already-smoothed CVD, not off the raw normalized value. This is why a CVD Length of 10 and a Signal Length of 10 with the same MA family produce very few crossings — both lines are built off the same smoothed base, and the second pass just lags the first. Asymmetric configurations (shorter CVD Length than Signal Length) produce more crossings because the CVD leads the signal more.

The MA families themselves come from the lite Axiom MA library used by this trim: SMA, EMA, RMA, WMA, VWMA, and SWMA. Each family has its own temperament, and the library manual covers the family-level behavior. This pack does not reteach those distinctions because they apply across every Axiom indicator that uses the library.

The blend

After each enabled slot produces its CVD and signal values, the three feed into _calcBlendedLines, which computes a weighted mean.

Two properties are worth noting:

  • Weights are normalized internally. A configuration of weights (1, 1, 1), (33.3, 33.3, 33.3), and (100, 100, 100) all produce the same blend. Only the relative weights matter.

  • Slots returning na are excluded. Slots that are enabled but currently have no value (warm-up bars, failed data, etc.) are skipped rather than treated as zero. This prevents a warming-up slot from dragging the blend toward the middle.

If master smoothing is on, the blended CVD and blended signal go through one more MA pass using the Master MA Type and Master Length before they are plotted and evaluated for alerts. Master smoothing applies only to the blend; it does not touch the individual slot lines.

The fallback mode, at model depth

When lower-timeframe intrabars are unavailable, the slot falls back to computing the intent score on the slot bar's own OHLCV. The same participation model runs; it just has one bar of evidence instead of many.

The consequence is that the bucket classifier has only one intent score to work with, rather than an intrabar-by-intrabar sum of scores. The slot bar's delta is computed from that single classification multiplied by the slot bar's volume. The line moves according to the same rules, but with less resolution.

The fallback is deliberately silent on the visual. A flag or a warning marker on the line would be loud and would introduce a separate class of reading mistake (people interpreting the flag as a market event). The price of silence is that the reader has to notice the fallback by the line's character; the benefit is that the pane keeps its visual language consistent.

What this page does not and will not publish

Codified once, so there is no ambiguity on any future polish pass.

  • The weight coefficients on body direction, close location, and wick bias inside the intent score.

  • The specific threshold values that separate strong, weak, and indecisive buckets.

  • The carry magnitude for indecisive bars.

  • The mapping from Pressure Sensitivity to the internal thresholds and carry.

  • The normalization range used to map Pressure Sensitivity onto its internal axis.

  • Any pseudocode that reconstructs the classifier.

These are protected details. They live in the source file; they do not live on any reader-facing page. If a future reader asks for them on a support channel, the honest answer is the same as the answer here: the page is the explanation, and the boundary is where the page ends.

Deciding whether to lean on the estimator

The whole point of this page is to put the reader in a position to decide. If the logic above reads as defensible to you — the three pieces of evidence, the bucket structure, the carry-forward on indecision, the bounded normalization — the estimator probably deserves real weight in your reading, within the limits covered on Limitations and Trust Boundaries. If the logic reads as one too many design choices for you to trust, or if the lack of specific numbers is itself a problem, that is legitimate information about fit.

Different readers will land in different places. That is as it should be. A tool that does not earn everyone's trust is a tool that is honest about whose process it fits.

A small exercise for the undecided

If you finish this page uncertain whether to put weight on the estimator, here is a cheaper experiment than committing real capital.

  • Pick a two-week stretch of bars on an instrument you know well, with known regime transitions inside it (a breakout, a range, a reversal).

  • Scroll through it with the pane on and a notebook open. For each regime, write down what the pane was showing right before the transition, what it showed through the transition, and what it showed after.

  • Then decide: does the pane's account of those transitions fit the way you already thought about them? Does it add information you did not see? Does it mislead in ways your eye already catches?

Two hours of that exercise on an instrument you know will tell you more about whether the estimator fits your process than any amount of additional page-reading. The estimator is not trying to convince you. It is trying to show up honestly so you can decide.