Cari skrip untuk "bar"
MACD Aspray Hybrid Bars (teal/red) = raw momentum (Aspray Histogram).
Teal line = smooth curve of the histogram (Aspray Line).
Orange line = 9-EMA of that line (new signal).
Zero line for reference.
Bar numberAdds a number above the last 50 candles. Candle 1 is always the most recent.
Can be useful when teaching people onlinet. Now they can just ask « what’s candle number 20 » instead of « what’s with that narrow range candle next to the big one to the left… no not that one, the other one »
Bars pattern MLThis script implements a K-Nearest Neighbors (KNN)-based machine learning model to predict future price movements in financial markets. It analyzes past price action using Euclidean distance and selects the most similar historical patterns to estimate future price changes. Unlike traditional KNN implementations, this approach optimizes distance calculations by maintaining a dynamically updated list of the closest neighbors, ensuring efficient selection without the need for sorting. The model generates a forecasted price trajectory based on incremental predictions, which are visualized on the chart using polylines for better interpretability.
Volume HighlightBar colouring: this indicator is simple but effective, it repaints higher than normal candles a certain colour (by default gold/yellow) it helps to know what are valuable areas to trade around for longs and shorts.
Changing the volume multiplier manually helps you to screen volume relevant to the timeframe you are trading on.
For example, some charts 1min the best filter/setting would be 12-35 multiplier where others like btc 1-4 hourly, the filter/setting might be 8-12.
The key is having only the highest/most relevant 3-4 volume candles showing as they often represent supports and resistances.
Pivot Points And Breakout Price Action With LuckyNickVaBar Color Candle Aligned with pivot points swing high and swing lows For Those Who Are Familiar with Trading The Breakouts Of Highs & Lows Of Structure. Pivots are said to be key areas in the market where price shows heavy reaction to where reversals make occur. At these points there are swing Highs & swing lows that traders may be able to find opportunity in the market. This Script is a combination of pivot points and Barcolor signals for the breakout.
Koalafied Volume Extension Bar colours based on extensions from volume Z-Score. Large volume candles can often signal exhaustion or show market strength in reversals or breakouts. Candles not supported by rising volume are coloured black while those that are retain their colouring.
Bars CharacteristicsThis code is for defining or explaining market conditions via micro trend and the characterized bars.
lines 5,6: show the conditions for a normal trend, means market can go in the direction that it has in the past.
lines 11,12: show the conditions for kind of the trend having cumulative energy itself, mean market can go in the same direction.
lines 18,19: show the conditions for kind of the trend having overbought/sold concept, means it's better exit from the market or to look for the other clues.
lines 24,25: show some kind of noise not a stable trend, it's better not to enter the market.
WhenWasThePriceAction
Bars of largest range (volatility)
* see moments of strongest price action immediately
* colored & upDown by candle color
* amplifier: you see only the bull runs, and subsequent dumps
Very nice on the 5 years scale of BITSTAMP:BTCUSD - nothing comparable to 2013 has happened yet.
Internals:
squared_range = pow(high-low, 2)
That is essentially it already. The rest are details:
* gauge with (in case of Bitcoin exponentially rising) price
* show in red for negative candles
* take even higher polynomial (than 2) to show only the very largest values
* allow some user input (but there is not much more that can be chosen here.)
Sorry for such a simple formula - but sometimes the easiest things are powerful.
Please give feedback. www.tradingview.com and/or in the cryptocurrency chat. Thanks.
Bars Since the last RSI ExtremeThis is something Jamie Saettele pointed out. Gold has been in 'neutral' RSI territory for its longest stretch in four years. It's coiling up for its next major move.
Expected Move BandsExpected move is the amount that an asset is predicted to increase or decrease from its current price, based on the current levels of volatility.
In this model, we assume asset price follows a log-normal distribution and the log return follows a normal distribution.
Note: Normal distribution is just an assumption, it's not the real distribution of return
Settings:
"Estimation Period Selection" is for selecting the period we want to construct the prediction interval.
For "Current Bar", the interval is calculated based on the data of the previous bar close. Therefore changes in the current price will have little effect on the range. What current bar means is that the estimated range is for when this bar close. E.g., If the Timeframe on 4 hours and 1 hour has passed, the interval is for how much time this bar has left, in this case, 3 hours.
For "Future Bars", the interval is calculated based on the current close. Therefore the range will be very much affected by the change in the current price. If the current price moves up, the range will also move up, vice versa. Future Bars is estimating the range for the period at least one bar ahead.
There are also other source selections based on high low.
Time setting is used when "Future Bars" is chosen for the period. The value in time means how many bars ahead of the current bar the range is estimating. When time = 1, it means the interval is constructing for 1 bar head. E.g., If the timeframe is on 4 hours, then it's estimating the next 4 hours range no matter how much time has passed in the current bar.
Note: It's probably better to use "probability cone" for visual presentation when time > 1
Volatility Models :
Sample SD: traditional sample standard deviation, most commonly used, use (n-1) period to adjust the bias
Parkinson: Uses High/ Low to estimate volatility, assumes continuous no gap, zero mean no drift, 5 times more efficient than Close to Close
Garman Klass: Uses OHLC volatility, zero drift, no jumps, about 7 times more efficient
Yangzhang Garman Klass Extension: Added jump calculation in Garman Klass, has the same value as Garman Klass on markets with no gaps.
about 8 x efficient
Rogers: Uses OHLC, Assume non-zero mean volatility, handles drift, does not handle jump 8 x efficient
EWMA: Exponentially Weighted Volatility. Weight recently volatility more, more reactive volatility better in taking account of volatility autocorrelation and cluster.
YangZhang: Uses OHLC, combines Rogers and Garmand Klass, handles both drift and jump, 14 times efficient, alpha is the constant to weight rogers volatility to minimize variance.
Median absolute deviation: It's a more direct way of measuring volatility. It measures volatility without using Standard deviation. The MAD used here is adjusted to be an unbiased estimator.
Volatility Period is the sample size for variance estimation. A longer period makes the estimation range more stable less reactive to recent price. Distribution is more significant on a larger sample size. A short period makes the range more responsive to recent price. Might be better for high volatility clusters.
Standard deviations:
Standard Deviation One shows the estimated range where the closing price will be about 68% of the time.
Standard Deviation two shows the estimated range where the closing price will be about 95% of the time.
Standard Deviation three shows the estimated range where the closing price will be about 99.7% of the time.
Note: All these probabilities are based on the normal distribution assumption for returns. It's the estimated probability, not the actual probability.
Manually Entered Standard Deviation shows the range of any entered standard deviation. The probability of that range will be presented on the panel.
People usually assume the mean of returns to be zero. To be more accurate, we can consider the drift in price from calculating the geometric mean of returns. Drift happens in the long run, so short lookback periods are not recommended. Assuming zero mean is recommended when time is not greater than 1.
When we are estimating the future range for time > 1, we typically assume constant volatility and the returns to be independent and identically distributed. We scale the volatility in term of time to get future range. However, when there's autocorrelation in returns( when returns are not independent), the assumption fails to take account of this effect. Volatility scaled with autocorrelation is required when returns are not iid. We use an AR(1) model to scale the first-order autocorrelation to adjust the effect. Returns typically don't have significant autocorrelation. Adjustment for autocorrelation is not usually needed. A long length is recommended in Autocorrelation calculation.
Note: The significance of autocorrelation can be checked on an ACF indicator.
ACF
The multimeframe option enables people to use higher period expected move on the lower time frame. People should only use time frame higher than the current time frame for the input. An error warning will appear when input Tf is lower. The input format is multiplier * time unit. E.g. : 1D
Unit: M for months, W for Weeks, D for Days, integers with no unit for minutes (E.g. 240 = 240 minutes). S for Seconds.
Smoothing option is using a filter to smooth out the range. The filter used here is John Ehler's supersmoother. It's an advance smoothing technique that gets rid of aliasing noise. It affects is similar to a simple moving average with half the lookback length but smoother and has less lag.
Note: The range here after smooth no long represent the probability
Panel positions can be adjusted in the settings.
X position adjusts the horizontal position of the panel. Higher X moves panel to the right and lower X moves panel to the left.
Y position adjusts the vertical position of the panel. Higher Y moves panel up and lower Y moves panel down.
Step line display changes the style of the bands from line to step line. Step line is recommended because it gets rid of the directional bias of slope of expected move when displaying the bands.
Warnings:
People should not blindly trust the probability. They should be aware of the risk evolves by using the normal distribution assumption. The real return has skewness and high kurtosis. While skewness is not very significant, the high kurtosis should be noticed. The Real returns have much fatter tails than the normal distribution, which also makes the peak higher. This property makes the tail ranges such as range more than 2SD highly underestimate the actual range and the body such as 1 SD slightly overestimate the actual range. For ranges more than 2SD, people shouldn't trust them. They should beware of extreme events in the tails.
Different volatility models provide different properties if people are interested in the accuracy and the fit of expected move, they can try expected move occurrence indicator. (The result also demonstrate the previous point about the drawback of using normal distribution assumption).
Expected move Occurrence Test
The prediction interval is only for the closing price, not wicks. It only estimates the probability of the price closing at this level, not in between. E.g., If 1 SD range is 100 - 200, the price can go to 80 or 230 intrabar, but if the bar close within 100 - 200 in the end. It's still considered a 68% one standard deviation move.
Prime-Time × Vortex (3/6/9) — Ace (clean v3)1️⃣ Prime-Time Index (PT)
A bar becomes Prime-Time when the count satisfies the formula:
4·n − 3 is a perfect square
This generates the sequence:
1, 3, 7, 13, 21, 31, 43, 57, 73, 91, …
These are time windows where price is more likely to form:
Shifts in market structure
Impulses
Reversals
Liquidity expansions
These PT bars are drawn as small circles above the candle.
If labels are enabled, the counter value (n) is also shown.
2️⃣ Vortex 3/6/9 Digital-Root Timing
Every bar also has a digital root, calculated from the counter:
If n → digitalRoot(n) = 3, 6, or 9,
the bar is considered a Vortex bar.
These moments often align with:
Swing highs / swing lows
Micro shifts
Mini-reversals
Minor liquidity grabs
When a Prime-Time bar is also a 3/6/9 bar → high-probability timing.
These bars are highlighted in green by default.
3️⃣ Filters & Display
You can customize:
Anchor time → when counting begins
Reset daily → restart counter each new trading day
Show only 3/6/9 → hides normal PT hits
Label offset → distance above the candle
Color themes
This makes the indicator usable on:
1Min
5Min
15Min
1H
Any timeframe you want
4️⃣ How To Apply It in Trading
Use it as a time confluence tool, not a signal generator.
✔ Best ways to use:
Look for MSS, sweeps, OB retests, FVG reactions when
they occur on or near a Prime-Time or 3/6/9 bar
Expect volatility increases after PT bars
Use 3/6/9 hits to anticipate internal turning points
Combine with:
Session High/Low
Killzones (London, NYO, PM)
Purge Protocol
MMXM Execution
✔ Example:
If price sweeps a level and prints a 3/6/9 vortex bar inside a PT window →
you have a very strong timing alignment for reversal.
5️⃣ Simple Summary
Feature Meaning
Prime-Time Hit (PT) Major time window where price often shifts
3/6/9 Vortex Bar Micro-timing for internal swings
PT + 3/6/9 together High-probability timing for entries
Reset Daily Perfect for intraday models like NYO & London
Anchor Time Defines the entire cycle structure
Grok/Claude Turtle Soup Strategy # 🥣 Turtle Soup Strategy (Enhanced)
## A Mean-Reversion Strategy Based on Failed Breakouts
---
## Historical Origins
### The Original Turtle Traders (1983-1988)
The Turtle Trading system is one of the most famous experiments in trading history. In 1983, legendary commodities trader **Richard Dennis** made a bet with his partner **William Eckhardt** about whether great traders were born or made. Dennis believed trading could be taught; Eckhardt believed it was innate.
To settle the debate, Dennis recruited 23 ordinary people through newspaper ads—including a professional blackjack player, a fantasy game designer, and an accountant—and taught them his trading system in just two weeks. He called them "Turtles" after turtle farms he had visited in Singapore, saying *"We are going to grow traders just like they grow turtles in Singapore."*
The results were extraordinary. Over the next five years, the Turtles reportedly earned over **$175 million in profits**. The experiment proved Dennis right: trading could indeed be taught.
#### The Original Turtle Rules:
- **Entry:** Buy when price breaks above the 20-day high (System 1) or 55-day high (System 2)
- **Exit:** Sell when price breaks below the 10-day low (System 1) or 20-day low (System 2)
- **Stop Loss:** 2x ATR (Average True Range) from entry
- **Position Sizing:** Based on volatility (ATR)
- **Philosophy:** Pure trend-following—catch big moves by riding breakouts
The Turtle system was a **trend-following** strategy that assumed breakouts would lead to sustained trends. It worked brilliantly in trending markets but suffered during choppy, range-bound conditions.
---
### The Turtle Soup Strategy (1990s)
In the 1990s, renowned trader **Linda Bradford Raschke** (along with Larry Connors) observed something interesting: many of the breakouts that the Turtle system traded actually *failed*. Price would spike above the 20-day high, trigger Turtle buy orders, then immediately reverse—trapping the breakout traders.
Raschke realized these failed breakouts were predictable and tradeable. She developed the **Turtle Soup** strategy, which does the *exact opposite* of the original Turtle system:
> *"Instead of buying the breakout, we wait for it to fail—then fade it."*
The name "Turtle Soup" is a clever play on words: the strategy essentially "eats" the Turtles by trading against them when their breakouts fail.
#### Original Turtle Soup Rules:
- **Setup:** Price makes a new 20-day high (or low)
- **Qualifier:** The previous 20-day high must be at least 3-4 days old (not a fresh breakout)
- **Entry Trigger:** Price reverses back inside the channel (failed breakout)
- **Entry:** Go SHORT (against the failed breakout above), or LONG (against the failed breakdown below)
- **Philosophy:** Mean-reversion—fade false breakouts and profit from trapped traders
#### Turtle Soup Plus One Variant:
Raschke also developed a more conservative variant called "Turtle Soup Plus One" which waits for the *next bar* after the breakout to confirm the failure before entering. This reduces false signals but may miss some opportunities.
---
## Our Enhanced Turtle Soup Strategy
We have taken the classic Turtle Soup concept and enhanced it with modern technical indicators and filters to improve signal quality and adapt to today's markets.
### Core Logic Preserved
The fundamental strategy remains true to Raschke's original concept:
| Turtle (Original) | Turtle Soup (Our Strategy) |
|-------------------|---------------------------|
| BUY breakout above 20-day high | SHORT when that breakout FAILS |
| SELL breakout below 20-day low | LONG when that breakdown FAILS |
| Trend-following | Mean-reversion |
| "The trend is your friend" | "Failed breakouts trap traders" |
---
### Enhancements & Improvements
#### 1. RSI Exhaustion Filter
**Addition:** RSI must confirm exhaustion before entry
- **For SHORT entries:** RSI > 60 (buyers exhausted)
- **For LONG entries:** RSI < 40 (sellers exhausted)
**Why:** The original Turtle Soup had no momentum filter. Adding RSI ensures we only fade breakouts when the market is showing signs of exhaustion, significantly reducing false signals. This enhancement was inspired by later traders who found RSI extremes (originally 90/10, softened to 60/40) dramatically improved win rates.
#### 2. ADX Trending Filter
**Addition:** ADX must be > 20 for trades to execute
**Why:** While the original Turtle Soup was designed for ranging markets, we found that requiring *some* trend strength (ADX > 20) actually improves results. This ensures we're trading in markets with enough directional movement to create meaningful failed breakouts, rather than random noise in dead markets.
#### 3. Heikin Ashi Smoothing
**Addition:** Optional Heikin Ashi calculations for breakout detection
**Why:** Heikin Ashi candles smooth out price noise and make trend reversals more visible. When enabled, the strategy uses HA values to detect breakouts and failures, reducing whipsaws from erratic price spikes.
#### 4. Dynamic Donchian Channels with Regime Detection
**Addition:** Color-coded channels based on market regime
- 🟢 **Green:** Bullish regime (uptrend + DI+ > DI- + OBV bullish)
- 🔴 **Red:** Bearish regime (downtrend + DI- > DI+ + OBV bearish)
- 🟡 **Yellow:** Neutral regime
**Why:** Visual regime detection helps traders understand the broader market context. The original Turtle Soup had no regime awareness—our enhancement lets traders see at a glance whether conditions favor the strategy.
#### 5. Volume Spike Detection (Optional)
**Addition:** Optional filter requiring volume surge on the breakout bar
**Why:** Failed breakouts are more significant when they occur on high volume. A volume spike on the breakout bar (default 1.2x average) indicates more traders got trapped, creating stronger reversal potential.
#### 6. ATR-Based Stops and Targets
**Addition:** Configurable ATR-based stop losses and profit targets
- **Stop Loss:** 1.5x ATR (default)
- **Profit Target:** 2.0x ATR (default)
**Why:** The original Turtle Soup used fixed stop placement. ATR-based stops adapt to current volatility, providing tighter stops in calm markets and wider stops in volatile conditions.
#### 7. Signal Cooldown
**Addition:** Minimum bars between trades (default 5)
**Why:** Prevents overtrading during choppy conditions where multiple failed breakouts might occur in quick succession.
#### 8. Real-Time Info Panel
**Addition:** Comprehensive dashboard showing:
- Current regime (Bullish/Bearish/Neutral)
- RSI value and zone
- ADX value and trending status
- Breakout status
- Bars since last high/low
- Current setup status
- Position status
**Why:** Gives traders instant visibility into all strategy conditions without needing to check multiple indicators.
---
## Entry Rules Summary
### SHORT Entry (Fading Failed Breakout Above)
1. ✅ Price breaks ABOVE the 20-period Donchian high
2. ✅ Previous 20-period high was at least 1 bar ago
3. ✅ Price closes back BELOW the Donchian high (failed breakout)
4. ✅ RSI > 60 (exhausted buyers)
5. ✅ ADX > 20 (trending market)
6. ✅ Cooldown period met
→ **Enter SHORT**, betting the breakout will fail
### LONG Entry (Fading Failed Breakdown Below)
1. ✅ Price breaks BELOW the 20-period Donchian low
2. ✅ Previous 20-period low was at least 1 bar ago
3. ✅ Price closes back ABOVE the Donchian low (failed breakdown)
4. ✅ RSI < 40 (exhausted sellers)
5. ✅ ADX > 20 (trending market)
6. ✅ Cooldown period met
→ **Enter LONG**, betting the breakdown will fail
---
## Exit Rules
1. **ATR Stop Loss:** Position closed if price moves 1.5x ATR against entry
2. **ATR Profit Target:** Position closed if price moves 2.0x ATR in favor
3. **Channel Exit:** Position closed if price breaks the exit channel in the opposite direction
4. **Mid-Channel Exit:** Position closed if price returns to channel midpoint
---
## Best Market Conditions
The Turtle Soup strategy performs best when:
- ✅ Markets are prone to false breakouts
- ✅ Volatility is moderate (not too low, not extreme)
- ✅ Price is oscillating within a broader range
- ✅ There are clear support/resistance levels
The strategy may struggle when:
- ❌ Strong trends persist (breakouts follow through)
- ❌ Volatility is extremely low (no meaningful breakouts)
- ❌ Markets are in news-driven directional moves
---
## Default Settings
| Parameter | Default | Description |
|-----------|---------|-------------|
| Lookback Period | 20 | Donchian channel period |
| Min Bars Since Extreme | 1 | Bars since last high/low |
| RSI Length | 14 | RSI calculation period |
| RSI Short Level | 60 | RSI must be above this for shorts |
| RSI Long Level | 40 | RSI must be below this for longs |
| ADX Length | 14 | ADX calculation period |
| ADX Threshold | 20 | Minimum ADX for trades |
| ATR Period | 20 | ATR calculation period |
| ATR Stop Multiplier | 1.5 | Stop loss distance in ATR |
| ATR Target Multiplier | 2.0 | Profit target distance in ATR |
| Cooldown Period | 5 | Minimum bars between trades |
| Volume Multiplier | 1.2 | Volume spike threshold |
---
## Philosophy
> *"The Turtle system made millions by following breakouts. The Turtle Soup strategy makes money when those breakouts fail. In trading, there's always someone on the other side of the trade—this strategy profits by being the smart money that fades the trapped breakout traders."*
The beauty of the Turtle Soup strategy is its elegant simplicity: it exploits a known, repeatable pattern (failed breakouts) while using modern filters (RSI, ADX) to improve timing and reduce false signals.
---
## Credits
- **Original Turtle System:** Richard Dennis & William Eckhardt (1983)
- **Turtle Soup Strategy:** Linda Bradford Raschke & Larry Connors (1990s)
- **RSI Enhancement:** Various traders who discovered RSI extremes improve reversal detection
- **This Implementation:** Enhanced with Heikin Ashi smoothing, regime detection, ADX filtering, and comprehensive visualization
---
*"We're not following the turtles—we're making soup out of them."* 🥣
Hurst Exponent - Detrended Fluctuation AnalysisIn stochastic processes, chaos theory and time series analysis, detrended fluctuation analysis (DFA) is a method for determining the statistical self-affinity of a signal. It is useful for analyzing time series that appear to be long-memory processes and noise.
█ OVERVIEW
We have introduced the concept of Hurst Exponent in our previous open indicator Hurst Exponent (Simple). It is an indicator that measures market state from autocorrelation. However, we apply a more advanced and accurate way to calculate Hurst Exponent rather than simple approximation. Therefore, we recommend using this version of Hurst Exponent over our previous publication going forward. The method we used here is called detrended fluctuation analysis. (For folks that are not interested in the math behind the calculation, feel free to skip to "features" and "how to use" section. However, it is recommended that you read it all to gain a better understanding of the mathematical reasoning).
█ Detrend Fluctuation Analysis
Detrended Fluctuation Analysis was first introduced by by Peng, C.K. (Original Paper) in order to measure the long-range power-law correlations in DNA sequences . DFA measures the scaling-behavior of the second moment-fluctuations, the scaling exponent is a generalization of Hurst exponent.
The traditional way of measuring Hurst exponent is the rescaled range method. However DFA provides the following benefits over the traditional rescaled range method (RS) method:
• Can be applied to non-stationary time series. While asset returns are generally stationary, DFA can measure Hurst more accurately in the instances where they are non-stationary.
• According the the asymptotic distribution value of DFA and RS, the latter usually overestimates Hurst exponent (even after Anis- Llyod correction) resulting in the expected value of RS Hurst being close to 0.54, instead of the 0.5 that it should be. Therefore it's harder to determine the autocorrelation based on the expected value. The expected value is significantly closer to 0.5 making that threshold much more useful, using the DFA method on the Hurst Exponent (HE).
• Lastly, DFA requires lower sample size relative to the RS method. While the RS method generally requires thousands of observations to reduce the variance of HE, DFA only needs a sample size greater than a hundred to accomplish the above mentioned.
█ Calculation
DFA is a modified root-mean-squares (RMS) analysis of a random walk. In short, DFA computes the RMS error of linear fits over progressively larger bins (non-overlapped “boxes” of similar size) of an integrated time series.
Our signal time series is the log returns. First we subtract the mean from the log return to calculate the demeaned returns. Then, we calculate the cumulative sum of demeaned returns resulting in the cumulative sum being mean centered and we can use the DFA method on this. The subtraction of the mean eliminates the “global trend” of the signal. The advantage of applying scaling analysis to the signal profile instead of the signal, allows the original signal to be non-stationary when needed. (For example, this process converts an i.i.d. white noise process into a random walk.)
We slice the cumulative sum into windows of equal space and run linear regression on each window to measure the linear trend. After we conduct each linear regression. We detrend the series by deducting the linear regression line from the cumulative sum in each windows. The fluctuation is the difference between cumulative sum and regression.
We use different windows sizes on the same cumulative sum series. The window sizes scales are log spaced. Eg: powers of 2, 2,4,8,16... This is where the scale free measurements come in, how we measure the fractal nature and self similarity of the time series, as well as how the well smaller scale represent the larger scale.
As the window size decreases, we uses more regression lines to measure the trend. Therefore, the fitness of regression should be better with smaller fluctuation. It allows one to zoom into the “picture” to see the details. The linear regression is like rulers. If you use more rulers to measure the smaller scale details you will get a more precise measurement.
The exponent we are measuring here is to determine the relationship between the window size and fitness of regression (the rate of change). The more complex the time series are the more it will depend on decreasing window sizes (using more linear regression lines to measure). The less complex or the more trend in the time series, it will depend less. The fitness is calculated by the average of root mean square errors (RMS) of regression from each window.
Root mean Square error is calculated by square root of the sum of the difference between cumulative sum and regression. The following chart displays average RMS of different window sizes. As the chart shows, values for smaller window sizes shows more details due to higher complexity of measurements.
The last step is to measure the exponent. In order to measure the power law exponent. We measure the slope on the log-log plot chart. The x axis is the log of the size of windows, the y axis is the log of the average RMS. We run a linear regression through the plotted points. The slope of regression is the exponent. It's easy to see the relationship between RMS and window size on the chart. Larger RMS equals less fitness of the regression. We know the RMS will increase (fitness will decrease) as we increases window size (use less regressions to measure), we focus on the rate of RMS increasing (how fast) as window size increases.
If the slope is < 0.5, It means the rate of of increase in RMS is small when window size increases. Therefore the fit is much better when it's measured by a large number of linear regression lines. So the series is more complex. (Mean reversion, negative autocorrelation).
If the slope is > 0.5, It means the rate of increase in RMS is larger when window sizes increases. Therefore even when window size is large, the larger trend can be measured well by a small number of regression lines. Therefore the series has a trend with positive autocorrelation.
If the slope = 0.5, It means the series follows a random walk.
█ FEATURES
• Sample Size is the lookback period for calculation. Even though DFA requires a lower sample size than RS, a sample size larger > 50 is recommended for accurate measurement.
• When a larger sample size is used (for example = 1000 lookback length), the loading speed may be slower due to a longer calculation. Date Range is used to limit numbers of historical calculation bars. When loading speed is too slow, change the data range "all" into numbers of weeks/days/hours to reduce loading time. (Credit to allanster)
• “show filter” option applies a smoothing moving average to smooth the exponent.
• Log scale is my work around for dynamic log space scaling. Traditionally the smallest log space for bars is power of 2. It requires at least 10 points for an accurate regression, resulting in the minimum lookback to be 1024. I made some changes to round the fractional log space into integer bars requiring the said log space to be less than 2.
• For a more accurate calculation a larger "Base Scale" and "Max Scale" should be selected. However, when the sample size is small, a larger value would cause issues. Therefore, a general rule to be followed is: A larger "Base Scale" and "Max Scale" should be selected for a larger the sample size. It is recommended for the user to try and choose a larger scale if increasing the value doesn't cause issues.
The following chart shows the change in value using various scales. As shown, sometimes increasing the value makes the value itself messy and overshoot.
When using the lowest scale (4,2), the value seems stable. When we increase the scale to (8,2), the value is still alright. However, when we increase it to (8,4), it begins to look messy. And when we increase it to (16,4), it starts overshooting. Therefore, (8,2) seems to be optimal for our use.
█ How to Use
Similar to Hurst Exponent (Simple). 0.5 is a level for determine long term memory.
• In the efficient market hypothesis, market follows a random walk and Hurst exponent should be 0.5. When Hurst Exponent is significantly different from 0.5, the market is inefficient.
• When Hurst Exponent is > 0.5. Positive Autocorrelation. Market is Trending. Positive returns tend to be followed by positive returns and vice versa.
• Hurst Exponent is < 0.5. Negative Autocorrelation. Market is Mean reverting. Positive returns trends to follow by negative return and vice versa.
However, we can't really tell if the Hurst exponent value is generated by random chance by only looking at the 0.5 level. Even if we measure a pure random walk, the Hurst Exponent will never be exactly 0.5, it will be close like 0.506 but not equal to 0.5. That's why we need a level to tell us if Hurst Exponent is significant.
So we also computed the 95% confidence interval according to Monte Carlo simulation. The confidence level adjusts itself by sample size. When Hurst Exponent is above the top or below the bottom confidence level, the value of Hurst exponent has statistical significance. The efficient market hypothesis is rejected and market has significant inefficiency.
The state of market is painted in different color as the following chart shows. The users can also tell the state from the table displayed on the right.
An important point is that Hurst Value only represents the market state according to the past value measurement. Which means it only tells you the market state now and in the past. If Hurst Exponent on sample size 100 shows significant trend, it means according to the past 100 bars, the market is trending significantly. It doesn't mean the market will continue to trend. It's not forecasting market state in the future.
However, this is also another way to use it. The market is not always random and it is not always inefficient, the state switches around from time to time. But there's one pattern, when the market stays inefficient for too long, the market participants see this and will try to take advantage of it. Therefore, the inefficiency will be traded away. That's why Hurst exponent won't stay in significant trend or mean reversion too long. When it's significant the market participants see that as well and the market adjusts itself back to normal.
The Hurst Exponent can be used as a mean reverting oscillator itself. In a liquid market, the value tends to return back inside the confidence interval after significant moves(In smaller markets, it could stay inefficient for a long time). So when Hurst Exponent shows significant values, the market has just entered significant trend or mean reversion state. However, when it stays outside of confidence interval for too long, it would suggest the market might be closer to the end of trend or mean reversion instead.
Larger sample size makes the Hurst Exponent Statistics more reliable. Therefore, if the user want to know if long term memory exist in general on the selected ticker, they can use a large sample size and maximize the log scale. Eg: 1024 sample size, scale (16,4).
Following Chart is Bitcoin on Daily timeframe with 1024 lookback. It suggests the market for bitcoin tends to have long term memory in general. It generally has significant trend and is more inefficient at it's early stage.
Bifurcation Zone - CAEBifurcation Zone — Cognitive Adversarial Engine (BZ-CAE)
Bifurcation Zone — CAE (BZ-CAE) is a next-generation divergence detection system enhanced by a Cognitive Adversarial Engine that evaluates both sides of every potential trade before presenting signals. Unlike traditional divergence indicators that show every price-oscillator disagreement regardless of context, BZ-CAE applies comprehensive market-state intelligence to identify only the divergences that occur in favorable conditions with genuine probability edges.
The system identifies structural bifurcation points — critical junctures where price and momentum disagree, signaling potential reversals or continuations — then validates these opportunities through five interconnected intelligence layers: Trend Conviction Scoring , Directional Momentum Alignment , Multi-Factor Exhaustion Modeling , Adversarial Validation , and Confidence Scoring . The result is a selective, context-aware signal system that filters noise and highlights high-probability setups.
This is not a "buy the arrow" indicator. It's a decision support framework that teaches you how to read market state, evaluate divergence quality, and make informed trading decisions based on quantified intelligence rather than hope.
What Sets BZ-CAE Apart: Technical Architecture
The Problem With Traditional Divergence Indicators
Most divergence indicators operate on a simple rule: if price makes a higher high and RSI makes a lower high, show a bearish signal. If price makes a lower low and RSI makes a higher low, show a bullish signal. This creates several critical problems:
Context Blindness : They show counter-trend signals in powerful trends that rarely reverse, leading to repeated losses as you fade momentum.
Signal Spam : Every minor price-oscillator disagreement generates an alert, overwhelming you with low-quality setups and creating analysis paralysis.
No Quality Ranking : All signals are treated identically. A marginal divergence in choppy conditions receives the same visual treatment as a high-conviction setup at a major exhaustion point.
Single-Sided Evaluation : They ask "Is this a good long?" without checking if the short case is overwhelmingly stronger, leading you into obvious bad trades.
Static Configuration : You manually choose RSI 14 or Stochastic 14 and hope it works, with no systematic way to validate if that's optimal for your instrument.
BZ-CAE's Solution: Cognitive Adversarial Intelligence
BZ-CAE solves these problems through an integrated five-layer intelligence architecture:
1. Trend Conviction Score (TCS) — 0 to 1 Scale
Most indicators check if ADX is above 25 to determine "trending" conditions. This binary approach misses nuance. TCS is a weighted composite metric:
Formula : 0.35 × normalize(ADX, 10, 35) + 0.35 × structural_strength + 0.30 × htf_alignment
Structural Strength : 10-bar SMA of consecutive directional bars. Captures persistence — are bulls or bears consistently winning?
HTF Alignment : Multi-timeframe EMA stacking (20/50/100/200). When all EMAs align in the same direction, you're in institutional trend territory.
Purpose : Quantifies how "locked in" the trend is. When TCS exceeds your threshold (default 0.80), the system knows to avoid counter-trend trades unless other factors override.
Interpretation :
TCS > 0.85: Very strong trend — counter-trading is extremely high risk
TCS 0.70-0.85: Strong trend — favor continuation, require exhaustion for reversals
TCS 0.50-0.70: Moderate trend — context matters, both directions viable
TCS < 0.50: Weak/choppy — reversals more viable, range-bound conditions
2. Directional Momentum Alignment (DMA) — ATR-Normalized
Formula : (EMA21 - EMA55) / ATR14
This isn't just "price above EMA" — it's a regime-aware momentum gauge. The same $100 price movement reads completely differently in high-volatility crypto versus low-volatility forex. By normalizing with ATR, DMA adapts its interpretation to current market conditions.
Purpose : Quantifies the directional "force" behind current price action. Positive = bullish push, negative = bearish push. Magnitude = strength.
Interpretation :
DMA > 0.7: Strong bullish momentum — bearish divergences risky
DMA 0.3 to 0.7: Moderate bullish bias
DMA -0.3 to 0.3: Balanced/choppy conditions
DMA -0.7 to -0.3: Moderate bearish bias
DMA < -0.7: Strong bearish momentum — bullish divergences risky
3. Multi-Factor Exhaustion Modeling — 0 to 1 Probability
Single-metric exhaustion detection (like "RSI > 80") misses complex market states. BZ-CAE aggregates five independent exhaustion signals:
Volume Spikes : Current volume versus 50-bar average
2.5x average: 0.25 weight
2.0x average: 0.15 weight
1.5x average: 0.10 weight
Divergence Present : The fact that a divergence exists contributes 0.30 weight — structural momentum disagreement is itself an exhaustion signal.
RSI Extremes : Captures oscillator climax zones
RSI > 80 or < 20: 0.25 weight
RSI > 75 or < 25: 0.15 weight
Pin Bar Detection : Identifies rejection candles (2:1 wick-to-body ratio, indicating failed breakout attempts): 0.15 weight
Extended Runs : Consecutive bars above/below EMA20 without pullback
30+ bars: 0.15 weight (market hasn't paused to consolidate)
Total exhaustion score is the sum of all applicable weights, capped at 1.0.
Purpose : Detects when strong trends become vulnerable to reversal. High exhaustion can override trend filters, allowing counter-trend trades at genuine turning points that basic indicators would miss.
Interpretation :
Exhaustion > 0.75: High probability of climax — yellow background shading alerts you visually
Exhaustion 0.50-0.75: Moderate overextension — watch for confirmation
Exhaustion < 0.50: Fresh move — trend can continue, counter-trend trades higher risk
4. Adversarial Validation — Game Theory Applied to Trading
This is BZ-CAE's signature innovation. Before approving any signal, the engine quantifies BOTH sides of the trade simultaneously:
For Bullish Divergences , it calculates:
Bull Case Score (0-1+) :
Distance below EMA20 (pullback quality): up to 0.25
Bullish EMA alignment (close > EMA20 > EMA50): 0.25
Oversold RSI (< 40): 0.25
Volume confirmation (> 1.2x average): 0.25
Bear Case Score (0-1+) :
Price below EMA50 (structural weakness): 0.30
Very oversold RSI (< 30, indicating knife-catching): 0.20
Differential = Bull Case - Bear Case
If differential < -0.10 (default threshold), the bear case is dominating — signal is BLOCKED or ANNOTATED.
For Bearish Divergences , the logic inverts (Bear Case vs Bull Case).
Purpose : Prevents trades where you're fighting obvious strength in the opposite direction. This is institutional-grade risk management — don't just evaluate your trade, evaluate the counter-trade simultaneously.
Why This Matters : You might see a bullish divergence at a local low, but if price is deeply below major support EMAs with strong bearish momentum, you're catching a falling knife. The adversarial check catches this and blocks the signal.
5. Confidence Scoring — 0 to 1 Quality Assessment
Every signal that passes initial filters receives a comprehensive quality score:
Formula :
0.30 × normalize(TCS) // Trend context
+ 0.25 × normalize(|DMA|) // Momentum magnitude
+ 0.20 × pullback_quality // Entry distance from EMA20
+ 0.15 × state_quality // ADX + alignment + structure
+ 0.10 × divergence_strength // Slope separation magnitude
+ adversarial_bonus (0-0.30) // Your side's advantage
Purpose : Ranks setup quality for filtering and position sizing decisions. You can set a minimum confidence threshold (default 0.35) to ensure only quality setups reach your chart.
Interpretation :
Confidence > 0.70: Premium setup — consider increased position size
Confidence 0.50-0.70: Good quality — standard size
Confidence 0.35-0.50: Acceptable — reduced size or skip if conservative
Confidence < 0.35: Marginal — blocked in Filtering mode, annotated in Advisory mode
CAE Operating Modes: Learning vs Enforcement
Off : Disables all CAE logic. Raw divergence pipeline only. Use for baseline comparison.
Advisory : Shows ALL signals regardless of CAE evaluation, but annotates signals that WOULD be blocked with specific warnings (e.g., "Bull: strong downtrend (TCS=0.87)" or "Adversarial bearish"). This is your learning mode — see CAE's decision logic in action without missing educational opportunities.
Filtering : Actively blocks low-quality signals. Only setups that pass all enabled gates (Trend Filter, Adversarial Validation, Confidence Gating) reach your chart. This is your live trading mode — trust the system to enforce discipline.
CAE Filter Gates: Three-Layer Protection
When CAE is enabled, signals must pass through three independent gates (each can be toggled on/off):
Gate 1: Strong Trend Filter
If TCS ≥ tcs_threshold (default 0.80)
And signal is counter-trend (bullish in downtrend or bearish in uptrend)
And exhaustion < exhaustion_required (default 0.50)
Then: BLOCK signal
Logic: Don't fade strong trends unless the move is clearly overextended
Gate 2: Adversarial Validation
Calculate both bull case and bear case scores
If opposing case dominates by more than adv_threshold (default 0.10)
Then: BLOCK signal
Logic: Avoid trades where you're fighting obvious strength in the opposite direction
Gate 3: Confidence Gating
Calculate composite confidence score (0-1)
If confidence < min_confidence (default 0.35)
Then: In Filtering mode, BLOCK signal; in Advisory mode, ANNOTATE with warning
Logic: Only take setups with minimum quality threshold
All three gates work together. A signal must pass ALL enabled gates to fire.
Visual Intelligence System
Bifurcation Zones (Supply/Demand Blocks)
When a divergence signal fires, BZ-CAE draws a semi-transparent box extending 15 bars forward from the signal pivot:
Demand Zones (Bullish) : Theme-colored box (cyan in Cyberpunk, blue in Professional, etc.) labeled "Demand" — marks where smart money likely placed buy orders as price diverged at the low.
Supply Zones (Bearish) : Theme-colored box (magenta in Cyberpunk, orange in Professional) labeled "Supply" — marks where smart money likely placed sell orders as price diverged at the high.
Theory : Divergences represent institutional disagreement with the crowd. The crowd pushed price to an extreme (new high or low), but momentum (oscillator) is waning, indicating smart money is taking the opposite side. These zones mark order placement areas that become future support/resistance.
Use Cases :
Exit targets: Take profit when price returns to opposite-side zone
Re-entry levels: If price returns to your entry zone, consider adding
Stop placement: Place stops just beyond your zone (below demand, above supply)
Auto-Cleanup : System keeps the last 20 zones to prevent chart clutter.
Adversarial Bar Coloring — Real-Time Market Debate Heatmap
Each bar is colored based on the Bull Case vs Bear Case differential:
Strong Bull Advantage (diff > 0.3): Full theme bull color (e.g., cyan)
Moderate Bull Advantage (diff > 0.1): 50% transparency bull
Neutral (diff -0.1 to 0.1): Gray/neutral theme
Moderate Bear Advantage (diff < -0.1): 50% transparency bear
Strong Bear Advantage (diff < -0.3): Full theme bear color (e.g., magenta)
This creates a real-time visual heatmap showing which side is "winning" the market debate. When bars flip from cyan to magenta (or vice versa), you're witnessing a shift in adversarial advantage — a leading indicator of potential momentum changes.
Exhaustion Shading
When exhaustion score exceeds 0.75, the chart background displays a semi-transparent yellow highlight. This immediate visual warning alerts you that the current move is at high risk of reversal, even if trend indicators remain strong.
Visual Themes — Six Aesthetic Options
Cyberpunk : Cyan/Magenta/Yellow — High contrast, neon aesthetic, excellent for dark-themed trading environments
Professional : Blue/Orange/Green — Corporate color palette, suitable for presentations and professional documentation
Ocean : Teal/Red/Cyan — Aquatic palette, calming for extended monitoring sessions
Fire : Orange/Red/Coral — Warm aggressive colors, high energy
Matrix : Green/Red/Lime — Code aesthetic, homage to classic hacker visuals
Monochrome : White/Gray — Minimal distraction, maximum focus on price action
All visual elements (signal markers, zones, bar colors, dashboard) adapt to your selected theme.
Divergence Engine — Core Detection System
What Are Divergences?
Divergences occur when price action and momentum indicators disagree, creating structural tension that often resolves in a change of direction:
Regular Divergence (Reversal Signal) :
Bearish Regular : Price makes higher high, oscillator makes lower high → Potential trend reversal down
Bullish Regular : Price makes lower low, oscillator makes higher low → Potential trend reversal up
Hidden Divergence (Continuation Signal) :
Bearish Hidden : Price makes lower high, oscillator makes higher high → Downtrend continuation
Bullish Hidden : Price makes higher low, oscillator makes lower low → Uptrend continuation
Both types can be enabled/disabled independently in settings.
Pivot Detection Methods
BZ-CAE uses symmetric pivot detection with separate lookback and lookforward periods (default 5/5):
Pivot High : Bar where high > all highs within lookback range AND high > all highs within lookforward range
Pivot Low : Bar where low < all lows within lookback range AND low < all lows within lookforward range
This ensures structural validity — the pivot must be a clear local extreme, not just a minor wiggle.
Divergence Validation Requirements
For a divergence to be confirmed, it must satisfy:
Slope Disagreement : Price slope and oscillator slope must move in opposite directions (for regular divs) or same direction with inverted highs/lows (for hidden divs)
Minimum Slope Change : |osc_slope| > min_slope_change / 100 (default 1.0) — filters weak, marginal divergences
Maximum Lookback Range : Pivots must be within max_lookback bars (default 60) — prevents ancient, irrelevant divergences
ATR-Normalized Strength : Divergence strength = min(|price_slope| × |osc_slope| × 10, 1.0) — quantifies the magnitude of disagreement in volatility context
Regular divergences receive 1.0× weight; hidden divergences receive 0.8× weight (slightly less reliable historically).
Oscillator Options — Five Professional Indicators
RSI (Relative Strength Index) : Classic overbought/oversold momentum indicator. Best for: General purpose divergence detection across all instruments.
Stochastic : Range-bound %K momentum comparing close to high-low range. Best for: Mean reversion strategies and range-bound markets.
CCI (Commodity Channel Index) : Measures deviation from statistical mean, auto-normalized to 0-100 scale. Best for: Cyclical instruments and commodities.
MFI (Money Flow Index) : Volume-weighted RSI incorporating money flow. Best for: Volume-driven markets like stocks and crypto.
Williams %R : Inverse stochastic looking back over period, auto-adjusted to 0-100. Best for: Reversal detection at extremes.
Each oscillator has adjustable length (2-200, default 14) and smoothing (1-20, default 1). You also set overbought (50-100, default 70) and oversold (0-50, default 30) thresholds.
Signal Timing Modes — Understanding Repainting
BZ-CAE offers two timing policies with complete transparency about repainting behavior:
Realtime (1-bar, peak-anchored)
How It Works :
Detects peaks 1 bar ago using pattern: high > high AND high > high
Signal prints on the NEXT bar after peak detection (bar_index)
Visual marker anchors to the actual PEAK bar (bar_index - 1, offset -1)
Signal locks in when bar CONFIRMS (closes)
Repainting Behavior :
On the FORMING bar (before close), the peak condition may change as new prices arrive
Once bar CLOSES (barstate.isconfirmed), signal is locked permanently
This is preview/early warning behavior by design
Best For :
Active monitoring and immediate alerts
Learning the system (seeing signals develop in real-time)
Responsive entry if you're watching the chart live
Confirmed (lookforward)
How It Works :
Uses Pine Script's built-in ta.pivothigh() and ta.pivotlow() functions
Requires full pivot validation period (lookback + lookforward bars)
Signal prints pivot_lookforward bars after the actual peak (default 5-bar delay)
Visual marker anchors to the actual peak bar (offset -pivot_lookforward)
No Repainting Behavior
Best For :
Backtesting and historical analysis
Conservative entries requiring full confirmation
Automated trading systems
Swing trading with larger timeframes
Tradeoff :
Delayed entry by pivot_lookforward bars (typically 5 bars)
On a 5-minute chart, this is a 25-minute delay
On a 4-hour chart, this is a 20-hour delay
Recommendation : Use Confirmed for backtesting to verify system performance honestly. Use Realtime for live monitoring only if you're actively watching the chart and understand pre-confirmation repainting behavior.
Signal Spacing System — Anti-Spam Architecture
Even after CAE filtering, raw divergences can cluster. The spacing system enforces separation:
Three Independent Filters
1. Min Bars Between ANY Signals (default 12):
Prevents rapid-fire clustering across both directions
If last signal (bull or bear) was within N bars, block new signal
Ensures breathing room between all setups
2. Min Bars Between SAME-SIDE Signals (default 24, optional enforcement):
Prevents bull-bull or bear-bear spam
Separate tracking for bullish and bearish signal timelines
Toggle enforcement on/off
3. Min ATR Distance From Last Signal (default 0, optional):
Requires price to move N × ATR from last signal location
Ensures meaningful price movement between setups
0 = disabled, 0.5-2.0 = typical range for enabled
All three filters work independently. A signal must pass ALL enabled filters to proceed.
Practical Guidance :
Scalping (1-5m) : Any 6-10, Same-side 12-20, ATR 0-0.5
Day Trading (15m-1H) : Any 12, Same-side 24, ATR 0-1.0
Swing Trading (4H-D) : Any 20-30, Same-side 40-60, ATR 1.0-2.0
Dashboard — Real-Time Control Center
The dashboard (toggleable, four corner positions, three sizes) provides comprehensive system intelligence:
Oscillator Section
Current oscillator type and value
State: OVERBOUGHT / OVERSOLD / NEUTRAL (color-coded)
Length parameter
Cognitive Engine Section
TCS (Trend Conviction Score) :
Current value with emoji state indicator
🔥 = Strong trend (>0.75)
📊 = Moderate trend (0.50-0.75)
〰️ = Weak/choppy (<0.50)
Color: Red if above threshold (trend filter active), yellow if moderate, green if weak
DMA (Directional Momentum Alignment) :
Current value with emoji direction indicator
🐂 = Bullish momentum (>0.5)
⚖️ = Balanced (-0.5 to 0.5)
🐻 = Bearish momentum (<-0.5)
Color: Green if bullish, red if bearish
Exhaustion :
Current value with emoji warning indicator
⚠️ = High exhaustion (>0.75)
🟡 = Moderate (0.50-0.75)
✓ = Low (<0.50)
Color: Red if high, yellow if moderate, green if low
Pullback :
Quality of current distance from EMA20
Values >0.6 are ideal entry zones (not too close, not too far)
Bull Case / Bear Case (if Adversarial enabled):
Current scores for both sides of the market debate
Differential with emoji indicator:
📈 = Bull advantage (>0.2)
➡️ = Balanced (-0.2 to 0.2)
📉 = Bear advantage (<-0.2)
Last Signal Metrics Section (New Feature)
When a signal fires, this section captures and displays:
Signal type (BULL or BEAR)
Bars elapsed since signal
Confidence % at time of signal
TCS value at signal time
DMA value at signal time
Purpose : Provides a historical reference for learning. You can see what the market state looked like when the last signal fired, helping you correlate outcomes with conditions.
Statistics Section
Total Signals : Lifetime count across session
Blocked Signals : Count and percentage (filter effectiveness metric)
Bull Signals : Total bullish divergences
Bear Signals : Total bearish divergences
Purpose : System health monitoring. If blocked % is very high (>60%), filters may be too strict. If very low (<10%), filters may be too loose.
Advisory Annotations
When CAE Mode = Advisory, this section displays warnings for signals that would be blocked in Filtering mode:
Examples:
"Bull spacing: wait 8 bars"
"Bear: strong uptrend (TCS=0.87)"
"Adversarial bearish"
"Low confidence 32%"
Multiple warnings can stack, separated by " | ". This teaches you CAE's decision logic transparently.
How to Use BZ-CAE — Complete Workflow
Phase 1: Initial Setup (First Session)
Apply BZ-CAE to your chart
Select your preferred Visual Theme (Cyberpunk recommended for visibility)
Set Signal Timing to "Confirmed (lookforward)" for learning
Choose your Oscillator Type (RSI recommended for general use, length 14)
Set Overbought/Oversold to 70/30 (standard)
Enable both Regular Divergence and Hidden Divergence
Set Pivot Lookback/Lookforward to 5/5 (balanced structure)
Enable CAE Intelligence
Set CAE Mode to "Advisory" (learning mode)
Enable all three CAE filters: Strong Trend Filter , Adversarial Validation , Confidence Gating
Enable Show Dashboard , position Top Right, size Normal
Enable Draw Bifurcation Zones and Adversarial Bar Coloring
Phase 2: Learning Period (Weeks 1-2)
Goal : Understand how CAE evaluates market state and filters signals.
Activities :
Watch the dashboard during signals :
Note TCS values when counter-trend signals fail — this teaches you the trend strength threshold for your instrument
Observe exhaustion patterns at actual turning points — learn when overextension truly matters
Study adversarial differential at signal times — see when opposing cases dominate
Review blocked signals (orange X-crosses):
In Advisory mode, you see everything — signals that would pass AND signals that would be blocked
Check the advisory annotations to understand why CAE would block
Track outcomes: Were the blocks correct? Did those signals fail?
Use Last Signal Metrics :
After each signal, check the dashboard capture of confidence, TCS, and DMA
Journal these values alongside trade outcomes
Identify patterns: Do confidence >0.70 signals work better? Does your instrument respect TCS >0.85?
Understand your instrument's "personality" :
Trending instruments (indices, major forex) may need TCS threshold 0.85-0.90
Choppy instruments (low-cap stocks, exotic pairs) may work best with TCS 0.70-0.75
High-volatility instruments (crypto) may need wider spacing
Low-volatility instruments may need tighter spacing
Phase 3: Calibration (Weeks 3-4)
Goal : Optimize settings for your specific instrument, timeframe, and style.
Calibration Checklist :
Min Confidence Threshold :
Review confidence distribution in your signal journal
Identify the confidence level below which signals consistently fail
Set min_confidence slightly above that level
Day trading : 0.35-0.45
Swing trading : 0.40-0.55
Scalping : 0.30-0.40
TCS Threshold :
Find the TCS level where counter-trend signals consistently get stopped out
Set tcs_threshold at or slightly below that level
Trending instruments : 0.85-0.90
Mixed instruments : 0.80-0.85
Choppy instruments : 0.75-0.80
Exhaustion Override Level :
Identify exhaustion readings that marked genuine reversals
Set exhaustion_required just below the average
Typical range : 0.45-0.55
Adversarial Threshold :
Default 0.10 works for most instruments
If you find CAE is too conservative (blocking good trades), raise to 0.15-0.20
If signals are still getting caught in opposing momentum, lower to 0.07-0.09
Spacing Parameters :
Count bars between quality signals in your journal
Set min bars ANY to ~60% of that average
Set min bars SAME-SIDE to ~120% of that average
Scalping : Any 6-10, Same 12-20
Day trading : Any 12, Same 24
Swing : Any 20-30, Same 40-60
Oscillator Selection :
Try different oscillators for 1-2 weeks each
Track win rate and average winner/loser by oscillator type
RSI : Best for general use, clear OB/OS
Stochastic : Best for range-bound, mean reversion
MFI : Best for volume-driven markets
CCI : Best for cyclical instruments
Williams %R : Best for reversal detection
Phase 4: Live Deployment
Goal : Disciplined execution with proven, calibrated system.
Settings Changes :
Switch CAE Mode from Advisory to Filtering
System now actively blocks low-quality signals
Only setups passing all gates reach your chart
Keep Signal Timing on Confirmed for conservative entries
OR switch to Realtime if you're actively monitoring and want faster entries (accept pre-confirmation repaint risk)
Use your calibrated thresholds from Phase 3
Enable high-confidence alerts: "⭐ High Confidence Bullish/Bearish" (>0.70)
Trading Discipline Rules :
Respect Blocked Signals :
If CAE blocks a trade you wanted to take, TRUST THE SYSTEM
Don't manually override — if you consistently disagree, return to Phase 2/3 calibration
The block exists because market state failed intelligence checks
Confidence-Based Position Sizing :
Confidence >0.70: Standard or increased size (e.g., 1.5-2.0% risk)
Confidence 0.50-0.70: Standard size (e.g., 1.0% risk)
Confidence 0.35-0.50: Reduced size (e.g., 0.5% risk) or skip if conservative
TCS-Based Management :
High TCS + counter-trend signal: Use tight stops, quick exits (you're fading momentum)
Low TCS + reversal signal: Use wider stops, trail aggressively (genuine reversal potential)
Exhaustion Awareness :
Exhaustion >0.75 (yellow shading): Market is overextended, reversal risk is elevated — consider early exit or tighter trailing stops even on winning trades
Exhaustion <0.30: Continuation bias — hold for larger move, wide trailing stops
Adversarial Context :
Strong differential against you (e.g., bullish signal with bear diff <-0.2): Use very tight stops, consider skipping
Strong differential with you (e.g., bullish signal with bull diff >0.2): Trail aggressively, this is your tailwind
Practical Settings by Timeframe & Style
Scalping (1-5 Minute Charts)
Objective : High frequency, tight stops, quick reversals in fast-moving markets.
Oscillator :
Type: RSI or Stochastic (fast response to quick moves)
Length: 9-11 (more responsive than standard 14)
Smoothing: 1 (no lag)
OB/OS: 65/35 (looser thresholds ensure frequent crossings in fast conditions)
Divergence :
Pivot Lookback/Lookforward: 3/3 (tight structure, catch small swings)
Max Lookback: 40-50 bars (recent structure only)
Min Slope Change: 0.8-1.0 (don't be overly strict)
CAE :
Mode: Advisory first (learn), then Filtering
Min Confidence: 0.30-0.35 (lower bar for speed, accept more signals)
TCS Threshold: 0.70-0.75 (allow more counter-trend opportunities)
Exhaustion Required: 0.45-0.50 (moderate override)
Strong Trend Filter: ON (still respect major intraday trends)
Adversarial: ON (critical for scalping protection — catches bad entries quickly)
Spacing :
Min Bars ANY: 6-10 (fast pace, many setups)
Min Bars SAME-SIDE: 12-20 (prevent clustering)
Min ATR Distance: 0 or 0.5 (loose)
Timing : Realtime (speed over precision, but understand repaint risk)
Visuals :
Signal Size: Tiny (chart clarity in busy conditions)
Show Zones: Optional (can clutter on low timeframes)
Bar Coloring: ON (helps read momentum shifts quickly)
Dashboard: Small size (corner reference, not main focus)
Key Consideration : Scalping generates noise. Even with CAE, expect lower win rate (45-55%) but aim for favorable R:R (2:1 or better). Size conservatively.
Day Trading (15-Minute to 1-Hour Charts)
Objective : Balance quality and frequency. Standard divergence trading approach.
Oscillator :
Type: RSI or MFI (proven reliability, volume confirmation with MFI)
Length: 14 (industry standard, well-studied)
Smoothing: 1-2
OB/OS: 70/30 (classic levels)
Divergence :
Pivot Lookback/Lookforward: 5/5 (balanced structure)
Max Lookback: 60 bars
Min Slope Change: 1.0 (standard strictness)
CAE :
Mode: Filtering (enforce discipline from the start after brief Advisory learning)
Min Confidence: 0.35-0.45 (quality filter without being too restrictive)
TCS Threshold: 0.80-0.85 (respect strong trends)
Exhaustion Required: 0.50 (balanced override threshold)
Strong Trend Filter: ON
Adversarial: ON
Confidence Gating: ON (all three filters active)
Spacing :
Min Bars ANY: 12 (breathing room between all setups)
Min Bars SAME-SIDE: 24 (prevent bull/bear clusters)
Min ATR Distance: 0-1.0 (optional refinement, typically 0.5-1.0)
Timing : Confirmed (1-bar delay for reliability, no repainting)
Visuals :
Signal Size: Tiny or Small
Show Zones: ON (useful reference for exits/re-entries)
Bar Coloring: ON (context awareness)
Dashboard: Normal size (full visibility)
Key Consideration : This is the "sweet spot" timeframe for BZ-CAE. Market structure is clear, CAE has sufficient data, and signal frequency is manageable. Expect 55-65% win rate with proper execution.
Swing Trading (4-Hour to Daily Charts)
Objective : Quality over quantity. High conviction only. Larger stops and targets.
Oscillator :
Type: RSI or CCI (robust on higher timeframes, smooth longer waves)
Length: 14-21 (capture larger momentum swings)
Smoothing: 1-3
OB/OS: 70/30 or 75/25 (strict extremes)
Divergence :
Pivot Lookback/Lookforward: 5/5 or 7/7 (structural purity, major swings only)
Max Lookback: 80-100 bars (broader historical context)
Min Slope Change: 1.2-1.5 (require strong, undeniable divergence)
CAE :
Mode: Filtering (strict enforcement, premium setups only)
Min Confidence: 0.40-0.55 (high bar for entry)
TCS Threshold: 0.85-0.95 (very strong trend protection — don't fade established HTF trends)
Exhaustion Required: 0.50-0.60 (higher bar for override — only extreme exhaustion justifies counter-trend)
Strong Trend Filter: ON (critical on HTF)
Adversarial: ON (avoid obvious bad trades)
Confidence Gating: ON (quality gate essential)
Spacing :
Min Bars ANY: 20-30 (substantial separation)
Min Bars SAME-SIDE: 40-60 (significant breathing room)
Min ATR Distance: 1.0-2.0 (require meaningful price movement)
Timing : Confirmed (purity over speed, zero repaint for swing accuracy)
Visuals :
Signal Size: Small or Normal (clear markers on zoomed-out view)
Show Zones: ON (important HTF levels)
Bar Coloring: ON (long-term trend awareness)
Dashboard: Normal or Large (comprehensive analysis)
Key Consideration : Swing signals are rare but powerful. Expect 2-5 signals per month per instrument. Win rate should be 60-70%+ due to stringent filtering. Position size can be larger given confidence.
Dashboard Interpretation Reference
TCS (Trend Conviction Score) States
0.00-0.50: Weak/Choppy
Emoji: 〰️
Color: Green/cyan
Meaning: No established trend. Range-bound or consolidating. Both reversal and continuation signals viable.
Action: Reversals (regular divs) are safer. Use wider profit targets (market has room to move). Consider mean reversion strategies.
0.50-0.75: Moderate Trend
Emoji: 📊
Color: Yellow/neutral
Meaning: Developing trend but not locked in. Context matters significantly.
Action: Check DMA and exhaustion. If DMA confirms trend and exhaustion is low, favor continuation (hidden divs). If exhaustion is high, reversals are viable.
0.75-0.85: Strong Trend
Emoji: 🔥
Color: Orange/warning
Meaning: Well-established trend with persistence. Counter-trend is high risk.
Action: Require exhaustion >0.50 for counter-trend entries. Favor continuation signals. Use tight stops on counter-trend attempts.
0.85-1.00: Very Strong Trend
Emoji: 🔥🔥
Color: Red/danger (if counter-trading)
Meaning: Locked-in institutional trend. Extremely high risk to fade.
Action: Avoid counter-trend unless exhaustion >0.75 (yellow shading). Focus exclusively on continuation opportunities. Momentum is king here.
DMA (Directional Momentum Alignment) Zones
-2.0 to -1.0: Strong Bearish Momentum
Emoji: 🐻🐻
Color: Dark red
Meaning: Powerful downside force. Sellers are in control.
Action: Bullish divergences are counter-momentum (high risk). Bearish divergences are with-momentum (lower risk). Size down on longs.
-0.5 to 0.5: Neutral/Balanced
Emoji: ⚖️
Color: Gray/neutral
Meaning: No strong directional bias. Choppy or consolidating.
Action: Both directions have similar probability. Focus on confidence score and adversarial differential for edge.
1.0 to 2.0: Strong Bullish Momentum
Emoji: 🐂🐂
Color: Bright green/cyan
Meaning: Powerful upside force. Buyers are in control.
Action: Bearish divergences are counter-momentum (high risk). Bullish divergences are with-momentum (lower risk). Size down on shorts.
Exhaustion States
0.00-0.50: Fresh Move
Emoji: ✓
Color: Green
Meaning: Trend is healthy, not overextended. Room to run.
Action: Counter-trend trades are premature. Favor continuation. Hold winners for larger moves. Avoid early exits.
0.50-0.75: Mature Move
Emoji: 🟡
Color: Yellow
Meaning: Move is aging. Watch for signs of climax.
Action: Tighten trailing stops on winning trades. Be ready for reversals. Don't add to positions aggressively.
0.75-0.85: High Exhaustion
Emoji: ⚠️
Color: Orange
Background: Yellow shading appears
Meaning: Move is overextended. Reversal risk elevated significantly.
Action: Counter-trend reversals are higher probability. Consider early exits on with-trend positions. Size up on reversal divergences (if CAE allows).
0.85-1.00: Critical Exhaustion
Emoji: ⚠️⚠️
Color: Red
Background: Yellow shading intensifies
Meaning: Climax conditions. Reversal imminent or underway.
Action: Aggressive reversal trades justified. Exit all with-trend positions. This is where major turns occur.
Confidence Score Tiers
0.00-0.30: Low Quality
Color: Red
Status: Blocked in Filtering mode
Action: Skip entirely. Setup lacks fundamental quality across multiple factors.
0.30-0.50: Moderate Quality
Color: Yellow/orange
Status: Marginal — passes in Filtering only if >min_confidence
Action: Reduced position size (0.5-0.75% risk). Tight stops. Conservative profit targets. Skip if you're selective.
0.50-0.70: High Quality
Color: Green/cyan
Status: Good setup across most quality factors
Action: Standard position size (1.0-1.5% risk). Normal stops and targets. This is your bread-and-butter trade.
0.70-1.00: Premium Quality
Color: Bright green/gold
Status: Exceptional setup — all factors aligned
Visual: Double confidence ring appears
Action: Consider increased position size (1.5-2.0% risk, maximum). Wider stops. Larger targets. High probability of success. These are rare — capitalize when they appear.
Adversarial Differential Interpretation
Bull Differential > 0.3 :
Visual: Strong cyan/green bar colors
Meaning: Bull case strongly dominates. Buyers have clear advantage.
Action: Bullish divergences favored (with-advantage). Bearish divergences face headwind (reduce size or skip). Momentum is bullish.
Bull Differential 0.1 to 0.3 :
Visual: Moderate cyan/green transparency
Meaning: Moderate bull advantage. Buyers have edge but not overwhelming.
Action: Both directions viable. Slight bias toward longs.
Differential -0.1 to 0.1 :
Visual: Gray/neutral bars
Meaning: Balanced debate. No clear advantage either side.
Action: Rely on other factors (confidence, TCS, exhaustion) for direction. Adversarial is neutral.
Bear Differential -0.3 to -0.1 :
Visual: Moderate red/magenta transparency
Meaning: Moderate bear advantage. Sellers have edge but not overwhelming.
Action: Both directions viable. Slight bias toward shorts.
Bear Differential < -0.3 :
Visual: Strong red/magenta bar colors
Meaning: Bear case strongly dominates. Sellers have clear advantage.
Action: Bearish divergences favored (with-advantage). Bullish divergences face headwind (reduce size or skip). Momentum is bearish.
Last Signal Metrics — Post-Trade Analysis
After a signal fires, dashboard captures:
Type : BULL or BEAR
Bars Ago : How long since signal (updates every bar)
Confidence : What was the quality score at signal time
TCS : What was trend conviction at signal time
DMA : What was momentum alignment at signal time
Use Case : Post-trade journaling and learning.
Example: "BULL signal 12 bars ago. Confidence: 68%, TCS: 0.42, DMA: -0.85"
Analysis : This was a bullish reversal (regular div) with good confidence, weak trend (TCS), but strong bearish momentum (DMA). The bet was that momentum would reverse — a counter-momentum play requiring exhaustion confirmation. Check if exhaustion was high at that time to justify the entry.
Track patterns:
Do your best trades have confidence >0.65?
Do low-TCS signals (<0.50) work better for you?
Are you more successful with-momentum (DMA aligned with signal) or counter-momentum?
Troubleshooting Guide
Problem: No Signals Appearing
Symptoms : Chart loads, dashboard shows metrics, but no divergence signals fire.
Diagnosis Checklist :
Check dashboard oscillator value : Is it crossing OB/OS levels (70/30)? If oscillator stays in 40-60 range constantly, it can't reach extremes needed for divergence detection.
Are pivots forming? : Look for local swing highs/lows on your chart. If price is in tight consolidation, pivots may not meet lookback/lookforward requirements.
Is spacing too tight? : Check "Last Signal" metrics — how many bars since last signal? If <12 and your min_bars_ANY is 12, spacing filter is blocking.
Is CAE blocking everything? : Check dashboard Statistics section — what's the blocked signal count? High blocks indicate overly strict filters.
Solutions :
Loosen OB/OS Temporarily :
Try 65/35 to verify divergence detection works
If signals appear, the issue was threshold strictness
Gradually tighten back to 67/33, then 70/30 as appropriate
Lower Min Confidence :
Try 0.25-0.30 (diagnostic level)
If signals appear, filter was too strict
Raise gradually to find sweet spot (0.35-0.45 typical)
Disable Strong Trend Filter Temporarily :
Turn off in CAE settings
If signals appear, TCS threshold was blocking everything
Re-enable and lower TCS_threshold to 0.70-0.75
Reduce Min Slope Change :
Try 0.7-0.8 (from default 1.0)
Allows weaker divergences through
Helpful on low-volatility instruments
Widen Spacing :
Set min_bars_ANY to 6-8
Set min_bars_SAME_SIDE to 12-16
Reduces time between allowed signals
Check Timing Mode :
If using Confirmed, remember there's a pivot_lookforward delay (5+ bars)
Switch to Realtime temporarily to verify system is working
Realtime has no delay but repaints
Verify Oscillator Settings :
Length 14 is standard but might not fit all instruments
Try length 9-11 for faster response
Try length 18-21 for slower, smoother response
Problem: Too Many Signals (Signal Spam)
Symptoms : Dashboard shows 50+ signals in Statistics, confidence scores mostly <0.40, signals clustering close together.
Solutions :
Raise Min Confidence :
Try 0.40-0.50 (quality filter)
Blocks bottom-tier setups
Targets top 50-60% of divergences only
Tighten OB/OS :
Use 70/30 or 75/25
Requires more extreme oscillator readings
Reduces false divergences in mid-range
Increase Min Slope Change :
Try 1.2-1.5 (from default 1.0)
Requires stronger, more obvious divergences
Filters marginal slope disagreements
Raise TCS Threshold :
Try 0.85-0.90 (from default 0.80)
Stricter trend filter blocks more counter-trend attempts
Favors only strongest trend alignment
Enable ALL CAE Gates :
Turn on Trend Filter + Adversarial + Confidence
Triple-layer protection
Blocks aggressively — expect 20-40% reduction in signals
Widen Spacing :
min_bars_ANY: 15-20 (from 12)
min_bars_SAME_SIDE: 30-40 (from 24)
Creates substantial breathing room
Switch to Confirmed Timing :
Removes realtime preview noise
Ensures full pivot validation
5-bar delay filters many false starts
Problem: Signals in Strong Trends Get Stopped Out
Symptoms : You take a bullish divergence in a downtrend (or bearish in uptrend), and it immediately fails. Dashboard showed high TCS at the time.
Analysis : This is INTENDED behavior — CAE is protecting you from low-probability counter-trend trades.
Understanding :
Check Last Signal Metrics in dashboard — what was TCS when signal fired?
If TCS was >0.85 and signal was counter-trend, CAE correctly identified it as high risk
Strong trends rarely reverse cleanly without major exhaustion
Your losses here are the system working as designed (blocking bad odds)
If You Want to Override (Not Recommended) :
Lower TCS_threshold to 0.70-0.75 (allows more counter-trend)
Lower exhaustion_required to 0.40 (easier override)
Disable Strong Trend Filter entirely (very risky)
Better Approach :
TRUST THE FILTER — it's preventing costly mistakes
Wait for exhaustion >0.75 (yellow shading) before counter-trending strong TCS
Focus on continuation signals (hidden divs) in high-TCS environments
Use Advisory mode to see what CAE is blocking and learn from outcomes
Problem: Adversarial Blocking Seems Wrong
Symptoms : You see a divergence that "looks good" visually, but CAE blocks with "Adversarial bearish/bullish" warning.
Diagnosis :
Check dashboard Bull Case and Bear Case scores at that moment
Look at Differential value
Check adversarial bar colors — was there strong coloring against your intended direction?
Understanding :
Adversarial catches "obvious" opposing momentum that's easy to miss
Example: Bullish divergence at a local low, BUT price is deeply below EMA50, bearish momentum is strong, and RSI shows knife-catching conditions
Bull Case might be 0.20 while Bear Case is 0.55
Differential = -0.35, far beyond threshold
Block is CORRECT — you'd be fighting overwhelming opposing flow
If You Disagree Consistently
Review blocked signals on chart — scroll back and check outcomes
Did those blocked signals actually work, or did they fail as adversarial predicted?
Raise adv_threshold to 0.15-0.20 (more permissive, allows closer battles)
Disable Adversarial Validation temporarily (diagnostic) to isolate its effect
Use Advisory mode to learn adversarial patterns over 50-100 signals
Remember : Adversarial is conservative BY DESIGN. It prevents "obvious" bad trades where you're fighting strong strength the other way.
Problem: Dashboard Not Showing or Incomplete
Solutions :
Toggle "Show Dashboard" to ON in settings
Try different dashboard sizes (Small/Normal/Large)
Try different positions (Top Left/Right, Bottom Left/Right) — might be off-screen
Some sections require CAE Enable = ON (Cognitive Engine section won't appear if CAE is disabled)
Statistics section requires at least 1 lifetime signal to populate
Check that visual theme is set (dashboard colors adapt to theme)
Problem: Performance Lag, Chart Freezing
Symptoms : Chart loading is slow, indicator calculations cause delays, pinch-to-zoom lags.
Diagnosis : Visual features are computationally expensive, especially adversarial bar coloring (recalculates every bar).
Solutions (In Order of Impact) :
Disable Adversarial Bar Coloring (MOST EXPENSIVE):
Turn OFF "Adversarial Bar Coloring" in settings
This is the single biggest performance drain
Immediate improvement
Reduce Vertical Lines :
Lower "Keep last N vertical lines" to 20-30
Or set to 0 to disable entirely
Moderate improvement
Disable Bifurcation Zones :
Turn OFF "Draw Bifurcation Zones"
Reduces box drawing calculations
Moderate improvement
Set Dashboard Size to Small :
Smaller dashboard = fewer cells = less rendering
Minor improvement
Use Shorter Max Lookback :
Reduce max_lookback to 40-50 (from 60+)
Fewer bars to scan for divergences
Minor improvement
Disable Exhaustion Shading :
Turn OFF "Show Market State"
Removes background coloring calculations
Minor improvement
Extreme Performance Mode :
Disable ALL visual enhancements
Keep only triangle markers
Dashboard Small or OFF
Use Minimal theme if available
Problem: Realtime Signals Repainting
Symptoms : You see a signal appear, but on next bar it disappears or moves.
Explanation :
Realtime mode detects peaks 1 bar ago: high > high AND high > high
On the FORMING bar (before close), this condition can change as new prices arrive
Example: At 10:05, high (10:04 bar) was 100, current high is 99 → peak detected
At 10:05:30, new high of 101 arrives → peak condition breaks → signal disappears
At 10:06 (bar close), final high is 101 → no peak at 10:04 anymore → signal gone permanently
This is expected behavior for realtime responsiveness. You get preview/early warning, but it's not locked until bar confirms.
Solutions :
Use Confirmed Timing :
Switch to "Confirmed (lookforward)" mode
ZERO repainting — pivot must be fully validated
5-bar delay (pivot_lookforward)
What you see in history is exactly what would have appeared live
Accept Realtime Repaint as Tradeoff :
Keep Realtime mode for speed and alerts
Understand that pre-confirmation signals may vanish
Only trade signals that CONFIRM at bar close (check barstate.isconfirmed)
Use for live monitoring, NOT for backtesting
Trade Only After Confirmation :
In Realtime mode, wait 1 full bar after signal appears before entering
If signal survives that bar close, it's locked
This adds 1-bar delay but removes repaint risk
Recommendation : Use Confirmed for backtesting and conservative trading. Use Realtime only for active monitoring with full understanding of preview behavior.
Risk Management Integration
BZ-CAE is a signal generation system, not a complete trading strategy. You must integrate proper risk management:
Position Sizing by Confidence
Confidence 0.70-1.00 (Premium) :
Risk: 1.5-2.0% of account (MAXIMUM)
Reasoning: High-quality setup across all factors
Still cap at 2% — even premium setups can fail
Confidence 0.50-0.70 (High Quality) :
Risk: 1.0-1.5% of account
Reasoning: Standard good setup
Your bread-and-butter risk level
Confidence 0.35-0.50 (Moderate Quality) :
Risk: 0.5-1.0% of account
Reasoning: Marginal setup, passes minimum threshold
Reduce size or skip if you're selective
Confidence <0.35 (Low Quality) :
Risk: 0% (blocked in Filtering mode)
Reasoning: Insufficient quality factors
System protects you by not showing these
Stop Placement Strategies
For Reversal Signals (Regular Divergences) :
Place stop beyond the divergence pivot plus buffer
Bullish : Stop below the divergence low - 1.0-1.5 × ATR
Bearish : Stop above the divergence high + 1.0-1.5 × ATR
Reasoning: If price breaks the pivot, divergence structure is invalidated
For Continuation Signals (Hidden Divergences) :
Place stop beyond recent swing in opposite direction
Bullish continuation : Stop below recent swing low (not the divergence pivot itself)
Bearish continuation : Stop above recent swing high
Reasoning: You're trading with trend, allow more breathing room
ATR-Based Stops :
1.5-2.0 × ATR is standard
Scale by timeframe:
Scalping (1-5m): 1.0-1.5 × ATR (tight)
Day trading (15m-1H): 1.5-2.0 × ATR (balanced)
Swing (4H-D): 2.0-3.0 × ATR (wide)
Never Use Fixed Dollar/Pip Stops :
Markets have different volatility
50-pip stop on EUR/USD ≠ 50-pip stop on GBP/JPY
Always normalize by ATR or pivot structure
Profit Targets and Scaling
Primary Target :
2-3 × ATR from entry (minimum 2:1 reward-risk)
Example : Entry at 100, ATR = 2, stop at 97 (1.5 × ATR) → target at 106 (3 × ATR) = 2:1 R:R
Scaling Out Strategy :
Take 50% off at 1.5 × ATR (secure partial profit)
Move stop to breakeven
Trail remaining 50% with 1.0 × ATR trailing stop
Let winners run if trend persists
Targets by Confidence :
High Confidence (>0.70) : Aggressive targets (3-4 × ATR), trail wider (1.5 × ATR)
Standard Confidence (0.50-0.70) : Normal targets (2-3 × ATR), standard trail (1.0 × ATR)
Low Confidence (0.35-0.50) : Conservative targets (1.5-2 × ATR), tight trail (0.75 × ATR)
Use Bifurcation Zones :
If opposite-side zone is visible on chart (from previous signal), use it as target
Example : Bullish signal at 100, prior supply zone at 110 → use 110 as target
Zones mark institutional resistance/support
Exhaustion-Based Exits :
If you're in a trade and exhaustion >0.75 develops (yellow shading), consider early exit
Market is overextended — reversal risk is high
Take profit even if target not reached
Trade Management by TCS
High TCS + Counter-Trend Trade (Risky) :
Use very tight stops (1.0-1.5 × ATR)
Conservative targets (1.5-2 × ATR)
Quick exit if trade doesn't work immediately
You're fading momentum — respect it
Low TCS + Reversal Trade (Safer) :
Use wider stops (2.0-2.5 × ATR)
Aggressive targets (3-4 × ATR)
Trail with patience
Genuine reversal potential in weak trend
High TCS + Continuation Trade (Safest) :
Standard stops (1.5-2.0 × ATR)
Very aggressive targets (4-5 × ATR)
Trail wide (1.5-2.0 × ATR)
You're with institutional momentum — let it run
Educational Value — Learning Machine Intelligence
BZ-CAE is designed as a learning platform, not just a tool:
Advisory Mode as Teacher
Most indicators are binary: signal or no signal. You don't learn WHY certain setups are better.
BZ-CAE's Advisory mode shows you EVERY potential divergence, then annotates the ones that would be blocked in Filtering mode with specific reasons:
"Bull: strong downtrend (TCS=0.87)" teaches you that TCS >0.85 makes counter-trend very risky
"Adversarial bearish" teaches you that the opposing case was dominating
"Low confidence 32%" teaches you that the setup lacked quality across multiple factors
"Bull spacing: wait 8 bars" teaches you that signals need breathing room
After 50-100 signals in Advisory mode, you internalize the CAE's decision logic. You start seeing these factors yourself BEFORE the indicator does.
Dashboard Transparency
Most "intelligent" indicators are black boxes — you don't know how they make decisions.
BZ-CAE shows you ALL metrics in real-time:
TCS tells you trend strength
DMA tells you momentum alignment
Exhaustion tells you overextension
Adversarial shows both sides of the debate
Confidence shows composite quality
You learn to interpret market state holistically, a skill applicable to ANY trading system beyond this indicator.
Divergence Quality Education
Not all divergences are equal. BZ-CAE teaches you which conditions produce high-probability setups:
Quality divergence : Regular bullish div at a low, TCS <0.50 (weak trend), exhaustion >0.75 (overextended), positive adversarial differential, confidence >0.70
Low-quality divergence : Regular bearish div at a high, TCS >0.85 (strong uptrend), exhaustion <0.30 (not overextended), negative adversarial differential, confidence <0.40
After using the system, you can evaluate divergences manually with similar intelligence.
Risk Management Discipline
Confidence-based position sizing teaches you to adjust risk based on setup quality, not emotions:
Beginners often size all trades identically
Or worse, size UP on marginal setups to "make up" for losses
BZ-CAE forces systematic sizing: premium setups get larger size, marginal setups get smaller size
This creates a probabilistic approach where your edge compounds over time.
What This Indicator Is NOT
Complete transparency about limitations and positioning:
Not a Prediction System
BZ-CAE does not predict future prices. It identifies structural divergences (price-momentum disagreements) and assesses current market state (trend, exhaustion, adversarial conditions). It tells you WHEN conditions favor a potential reversal or continuation, not WHAT WILL HAPPEN.
Markets are probabilistic. Even premium-confidence setups fail ~30-40% of the time. The system improves your probability distribution over many trades — it doesn't eliminate risk.
Not Fully Automated
This is a decision support tool, not a trading robot. You must:
Execute trades manually based on signals
Manage positions (stops, targets, trailing)
Apply discretionary judgment (news events, liquidity, context)
Integrate with your broader strategy and risk rules
The confidence scores guide position sizing, but YOU determine final risk allocation based on your account size, risk tolerance, and portfolio context.
Not Beginner-Friendly
BZ-CAE requires understanding of:
Divergence trading concepts (regular vs hidden, reversal vs continuation)
Market state interpretation (trend vs range, momentum, exhaustion)
Basic technical analysis (pivots, support/resistance, EMAs)
Risk management fundamentals (position sizing, stops, R:R)
This is designed for intermediate to advanced traders willing to invest time learning the system. If you want "buy the arrow" simplicity, this isn't the tool.
Not a Holy Grail
There is no perfect indicator. BZ-CAE filters noise and improves signal quality significantly, but:
Losing trades are inevitable (even at 70% win rate, 30% still fail)
Market conditions change rapidly (yesterday's strong trend becomes today's chop)
Black swan events occur (fundamentals override technicals)
Execution matters (slippage, fees, emotional discipline)
The system provides an EDGE, not a guarantee. Your job is to execute that edge consistently with proper risk management over hundreds of trades.
Not Financial Advice
BZ-CAE is an educational and analytical tool. All trading decisions are your responsibility. Past performance (backtested or live) does not guarantee future results. Only risk capital you can afford to lose. Consult a licensed financial advisor for investment advice specific to your situation.
Ideal Market Conditions
Best Performance Characteristics
Liquid Instruments :
Major forex pairs (EUR/USD, GBP/USD, USD/JPY)
Large-cap stocks and index ETFs (SPY, QQQ, AAPL, MSFT)
High-volume crypto (BTC, ETH)
Major commodities (Gold, Oil, Natural Gas)
Reasoning: Clean price structure, clear pivots, meaningful oscillator behavior
Trending with Consolidations :
Markets that trend for 20-40 bars, then consolidate 10-20 bars, repeat
Creates divergences at consolidation boundaries (reversals) and within trends (continuations)
Both regular and hidden divs find opportunities
5-Minute to Daily Timeframes :
Below 5m: too much noise, false pivots, CAE metrics unstable
Above daily: too few signals, edge diminishes (fundamentals dominate)
Sweet spot: 15m to 4H for most traders
Consistent Volume and Participation :
Regular trading sessions (not holidays or thin markets)
Predictable volatility patterns
Avoid instruments with sudden gaps or circuit breakers
Challenging Conditions
Extremely Low Liquidity :
Penny stocks, exotic forex pairs, low-volume crypto
Erratic pivots, unreliable oscillator readings
CAE metrics can't assess market state properly
Very Low Timeframes (1-Minute or Below) :
Dominated by market microstructure noise
Divergences are everywhere but meaningless
CAE filtering helps but still unreliable
Extended Sideways Consolidation :
100+ bars of tight range with no clear pivots
Oscillator hugs midpoint (45-55 range)
No divergences to detect
Fundamentally-Driven Gap Markets :
Earnings releases, economic data, geopolitical events
Price gaps over stops and targets
Technical structure breaks down
Recommendation: Disable trading around known events
Calculation Methodology — Technical Depth
For users who want to understand the math:
Oscillator Computation
Each oscillator type calculates differently, but all normalize to 0-100:
RSI : ta.rsi(close, length) — Standard Relative Strength Index
Stochastic : ta.stoch(high, low, close, length) — %K calculation
CCI : (ta.cci(hlc3, length) + 100) / 2 — Normalized from -100/+100 to 0-100
MFI : ta.mfi(hlc3, length) — Volume-weighted RSI equivalent
Williams %R : ta.wpr(length) + 100 — Inverted stochastic adjusted to 0-100
Smoothing: If smoothing > 1, apply ta.sma(oscillator, smoothing)
Divergence Detection Algorithm
Identify Pivots :
Price high pivot: ta.pivothigh(high, lookback, lookforward)
Price low pivot: ta.pivotlow(low, lookback, lookforward)
Oscillator high pivot: ta.pivothigh(osc, lookback, lookforward)
Oscillator low pivot: ta.pivotlow(osc, lookback, lookforward)
Store Recent Pivots :
Maintain arrays of last 10 pivots with bar indices
When new pivot confirmed, unshift to array, pop oldest if >10
Scan for Slope Disagreements :
Loop through last 5 pivots
For each pair (current pivot, historical pivot):
Check if within max_lookback bars
Calculate slopes: (current - historical) / bars_between
Regular bearish: price_slope > 0, osc_slope < 0, |osc_slope| > min_threshold
Regular bullish: price_slope < 0, osc_slope > 0, |osc_slope| > min_threshold
Hidden bearish: price_slope < 0, osc_slope > 0, osc_slope > min_threshold
Hidden bullish: price_slope > 0, osc_slope < 0, |osc_slope| > min_threshold
Important Disclaimers and Terms
Performance Disclosure
Past performance, whether backtested or live-traded, does not guarantee future results. Markets change. What works today may not work tomorrow. Hypothetical or simulated performance results have inherent limitations and do not represent actual trading.
Risk of Loss
Trading involves substantial risk of loss. Only trade with risk capital you can afford to lose entirely. The high degree of leverage often available in trading can work against you as well as for you. Leveraged trading may result in losses exceeding your initial deposit.
Not Financial Advice
BZ-CAE is an educational and analytical tool for technical analysis. It is not financial advice, investment advice, or a recommendation to buy or sell any security or instrument. All trading decisions are your sole responsibility. Consult a licensed financial advisor for advice specific to your circumstances.
Technical Indicator Limitations
BZ-CAE is a technical analysis tool based on price and volume data. It does not account for:
Fundamental analysis (earnings, economic data, financial health)
Market sentiment and positioning
Geopolitical events and news
Liquidity conditions and market microstructure changes
Regulatory changes or exchange rules
Integrate with broader analysis and strategy. Do not rely solely on technical indicators for trading decisions.
Repainting Acknowledgment
As disclosed throughout this documentation:
Realtime mode may repaint on forming bars before confirmation (by design for preview functionality)
Confirmed mode has zero repainting (fully validated pivots only)
Choose timing mode appropriate for your use case. Understand the tradeoffs.
Testing Recommendation
ALWAYS test on demo/paper accounts before committing real capital. Validate the indicator's behavior on your specific instruments and timeframes. Learn the system thoroughly in Advisory mode before using Filtering mode.
Learning Resources :
In-indicator tooltips (hover over setting names for detailed explanations)
This comprehensive publishing statement (save for reference)
User guide in script comments (top of code)
Final Word — Philosophy of BZ-CAE
BZ-CAE is not designed to replace your judgment — it's designed to enhance it.
The indicator identifies structural inflection points (bifurcations) where price and momentum disagree. The Cognitive Engine evaluates market state to determine if this disagreement is meaningful or noise. The Adversarial model debates both sides of the trade to catch obvious bad setups. The Confidence system ranks quality so you can choose your risk appetite.
But YOU still execute. YOU still manage risk. YOU still learn from outcomes.
This is intelligence amplification, not intelligence replacement.
Use Advisory mode to learn how expert traders evaluate market state. Use Filtering mode to enforce discipline when emotions run high. Use the dashboard to develop a systematic approach to reading markets. Use confidence scores to size positions probabilistically.
The system provides an edge. Your job is to execute that edge with discipline, patience, and proper risk management over hundreds of trades.
Markets are probabilistic. No system wins every trade. But a systematic edge + disciplined execution + proper risk management compounds over time. That's the path to consistent profitability. BZ-CAE gives you the edge. The discipline and risk management are on you.
Taking you to school. — Dskyz, Trade with insight. Trade with anticipation.
ATAI Volume analysis with price action V 1.00ATAI Volume Analysis with Price Action
1. Introduction
1.1 Overview
ATAI Volume Analysis with Price Action is a composite indicator designed for TradingView. It combines per‑side volume data —that is, how much buying and selling occurs during each bar—with standard price‑structure elements such as swings, trend lines and support/resistance. By blending these elements the script aims to help a trader understand which side is in control, whether a breakout is genuine, when markets are potentially exhausted and where liquidity providers might be active.
The indicator is built around TradingView’s up/down volume feed accessed via the TradingView/ta/10 library. The following excerpt from the script illustrates how this feed is configured:
import TradingView/ta/10 as tvta
// Determine lower timeframe string based on user choice and chart resolution
string lower_tf_breakout = use_custom_tf_input ? custom_tf_input :
timeframe.isseconds ? "1S" :
timeframe.isintraday ? "1" :
timeframe.isdaily ? "5" : "60"
// Request up/down volume (both positive)
= tvta.requestUpAndDownVolume(lower_tf_breakout)
Lower‑timeframe selection. If you do not specify a custom lower timeframe, the script chooses a default based on your chart resolution: 1 second for second charts, 1 minute for intraday charts, 5 minutes for daily charts and 60 minutes for anything longer. Smaller intervals provide a more precise view of buyer and seller flow but cover fewer bars. Larger intervals cover more history at the cost of granularity.
Tick vs. time bars. Many trading platforms offer a tick / intrabar calculation mode that updates an indicator on every trade rather than only on bar close. Turning on one‑tick calculation will give the most accurate split between buy and sell volume on the current bar, but it typically reduces the amount of historical data available. For the highest fidelity in live trading you can enable this mode; for studying longer histories you might prefer to disable it. When volume data is completely unavailable (some instruments and crypto pairs), all modules that rely on it will remain silent and only the price‑structure backbone will operate.
Figure caption, Each panel shows the indicator’s info table for a different volume sampling interval. In the left chart, the parentheses “(5)” beside the buy‑volume figure denote that the script is aggregating volume over five‑minute bars; the center chart uses “(1)” for one‑minute bars; and the right chart uses “(1T)” for a one‑tick interval. These notations tell you which lower timeframe is driving the volume calculations. Shorter intervals such as 1 minute or 1 tick provide finer detail on buyer and seller flow, but they cover fewer bars; longer intervals like five‑minute bars smooth the data and give more history.
Figure caption, The values in parentheses inside the info table come directly from the Breakout — Settings. The first row shows the custom lower-timeframe used for volume calculations (e.g., “(1)”, “(5)”, or “(1T)”)
2. Price‑Structure Backbone
Even without volume, the indicator draws structural features that underpin all other modules. These features are always on and serve as the reference levels for subsequent calculations.
2.1 What it draws
• Pivots: Swing highs and lows are detected using the pivot_left_input and pivot_right_input settings. A pivot high is identified when the high recorded pivot_right_input bars ago exceeds the highs of the preceding pivot_left_input bars and is also higher than (or equal to) the highs of the subsequent pivot_right_input bars; pivot lows follow the inverse logic. The indicator retains only a fixed number of such pivot points per side, as defined by point_count_input, discarding the oldest ones when the limit is exceeded.
• Trend lines: For each side, the indicator connects the earliest stored pivot and the most recent pivot (oldest high to newest high, and oldest low to newest low). When a new pivot is added or an old one drops out of the lookback window, the line’s endpoints—and therefore its slope—are recalculated accordingly.
• Horizontal support/resistance: The highest high and lowest low within the lookback window defined by length_input are plotted as horizontal dashed lines. These serve as short‑term support and resistance levels.
• Ranked labels: If showPivotLabels is enabled the indicator prints labels such as “HH1”, “HH2”, “LL1” and “LL2” near each pivot. The ranking is determined by comparing the price of each stored pivot: HH1 is the highest high, HH2 is the second highest, and so on; LL1 is the lowest low, LL2 is the second lowest. In the case of equal prices the newer pivot gets the better rank. Labels are offset from price using ½ × ATR × label_atr_multiplier, with the ATR length defined by label_atr_len_input. A dotted connector links each label to the candle’s wick.
2.2 Key settings
• length_input: Window length for finding the highest and lowest values and for determining trend line endpoints. A larger value considers more history and will generate longer trend lines and S/R levels.
• pivot_left_input, pivot_right_input: Strictness of swing confirmation. Higher values require more bars on either side to form a pivot; lower values create more pivots but may include minor swings.
• point_count_input: How many pivots are kept in memory on each side. When new pivots exceed this number the oldest ones are discarded.
• label_atr_len_input and label_atr_multiplier: Determine how far pivot labels are offset from the bar using ATR. Increasing the multiplier moves labels further away from price.
• Styling inputs for trend lines, horizontal lines and labels (color, width and line style).
Figure caption, The chart illustrates how the indicator’s price‑structure backbone operates. In this daily example, the script scans for bars where the high (or low) pivot_right_input bars back is higher (or lower) than the preceding pivot_left_input bars and higher or lower than the subsequent pivot_right_input bars; only those bars are marked as pivots.
These pivot points are stored and ranked: the highest high is labelled “HH1”, the second‑highest “HH2”, and so on, while lows are marked “LL1”, “LL2”, etc. Each label is offset from the price by half of an ATR‑based distance to keep the chart clear, and a dotted connector links the label to the actual candle.
The red diagonal line connects the earliest and latest stored high pivots, and the green line does the same for low pivots; when a new pivot is added or an old one drops out of the lookback window, the end‑points and slopes adjust accordingly. Dashed horizontal lines mark the highest high and lowest low within the current lookback window, providing visual support and resistance levels. Together, these elements form the structural backbone that other modules reference, even when volume data is unavailable.
3. Breakout Module
3.1 Concept
This module confirms that a price break beyond a recent high or low is supported by a genuine shift in buying or selling pressure. It requires price to clear the highest high (“HH1”) or lowest low (“LL1”) and, simultaneously, that the winning side shows a significant volume spike, dominance and ranking. Only when all volume and price conditions pass is a breakout labelled.
3.2 Inputs
• lookback_break_input : This controls the number of bars used to compute moving averages and percentiles for volume. A larger value smooths the averages and percentiles but makes the indicator respond more slowly.
• vol_mult_input : The “spike” multiplier; the current buy or sell volume must be at least this multiple of its moving average over the lookback window to qualify as a breakout.
• rank_threshold_input (0–100) : Defines a volume percentile cutoff: the current buyer/seller volume must be in the top (100−threshold)%(100−threshold)% of all volumes within the lookback window. For example, if set to 80, the current volume must be in the top 20 % of the lookback distribution.
• ratio_threshold_input (0–1) : Specifies the minimum share of total volume that the buyer (for a bullish breakout) or seller (for bearish) must hold on the current bar; the code also requires that the cumulative buyer volume over the lookback window exceeds the seller volume (and vice versa for bearish cases).
• use_custom_tf_input / custom_tf_input : When enabled, these inputs override the automatic choice of lower timeframe for up/down volume; otherwise the script selects a sensible default based on the chart’s timeframe.
• Label appearance settings : Separate options control the ATR-based offset length, offset multiplier, label size and colors for bullish and bearish breakout labels, as well as the connector style and width.
3.3 Detection logic
1. Data preparation : Retrieve per‑side volume from the lower timeframe and take absolute values. Build rolling arrays of the last lookback_break_input values to compute simple moving averages (SMAs), cumulative sums and percentile ranks for buy and sell volume.
2. Volume spike: A spike is flagged when the current buy (or, in the bearish case, sell) volume is at least vol_mult_input times its SMA over the lookback window.
3. Dominance test: The buyer’s (or seller’s) share of total volume on the current bar must meet or exceed ratio_threshold_input. In addition, the cumulative sum of buyer volume over the window must exceed the cumulative sum of seller volume for a bullish breakout (and vice versa for bearish). A separate requirement checks the sign of delta: for bullish breakouts delta_breakout must be non‑negative; for bearish breakouts it must be non‑positive.
4. Percentile rank: The current volume must fall within the top (100 – rank_threshold_input) percent of the lookback distribution—ensuring that the spike is unusually large relative to recent history.
5. Price test: For a bullish signal, the closing price must close above the highest pivot (HH1); for a bearish signal, the close must be below the lowest pivot (LL1).
6. Labeling: When all conditions above are satisfied, the indicator prints “Breakout ↑” above the bar (bullish) or “Breakout ↓” below the bar (bearish). Labels are offset using half of an ATR‑based distance and linked to the candle with a dotted connector.
Figure caption, (Breakout ↑ example) , On this daily chart, price pushes above the red trendline and the highest prior pivot (HH1). The indicator recognizes this as a valid breakout because the buyer‑side volume on the lower timeframe spikes above its recent moving average and buyers dominate the volume statistics over the lookback period; when combined with a close above HH1, this satisfies the breakout conditions. The “Breakout ↑” label appears above the candle, and the info table highlights that up‑volume is elevated relative to its 11‑bar average, buyer share exceeds the dominance threshold and money‑flow metrics support the move.
Figure caption, In this daily example, price breaks below the lowest pivot (LL1) and the lower green trendline. The indicator identifies this as a bearish breakout because sell‑side volume is sharply elevated—about twice its 11‑bar average—and sellers dominate both the bar and the lookback window. With the close falling below LL1, the script triggers a Breakout ↓ label and marks the corresponding row in the info table, which shows strong down volume, negative delta and a seller share comfortably above the dominance threshold.
4. Market Phase Module (Volume Only)
4.1 Concept
Not all markets trend; many cycle between periods of accumulation (buying pressure building up), distribution (selling pressure dominating) and neutral behavior. This module classifies the current bar into one of these phases without using ATR , relying solely on buyer and seller volume statistics. It looks at net flows, ratio changes and an OBV‑like cumulative line with dual‑reference (1‑ and 2‑bar) trends. The result is displayed both as on‑chart labels and in a dedicated row of the info table.
4.2 Inputs
• phase_period_len: Number of bars over which to compute sums and ratios for phase detection.
• phase_ratio_thresh : Minimum buyer share (for accumulation) or minimum seller share (for distribution, derived as 1 − phase_ratio_thresh) of the total volume.
• strict_mode: When enabled, both the 1‑bar and 2‑bar changes in each statistic must agree on the direction (strict confirmation); when disabled, only one of the two references needs to agree (looser confirmation).
• Color customisation for info table cells and label styling for accumulation and distribution phases, including ATR length, multiplier, label size, colors and connector styles.
• show_phase_module: Toggles the entire phase detection subsystem.
• show_phase_labels: Controls whether on‑chart labels are drawn when accumulation or distribution is detected.
4.3 Detection logic
The module computes three families of statistics over the volume window defined by phase_period_len:
1. Net sum (buyers minus sellers): net_sum_phase = Σ(buy) − Σ(sell). A positive value indicates a predominance of buyers. The code also computes the differences between the current value and the values 1 and 2 bars ago (d_net_1, d_net_2) to derive up/down trends.
2. Buyer ratio: The instantaneous ratio TF_buy_breakout / TF_tot_breakout and the window ratio Σ(buy) / Σ(total). The current ratio must exceed phase_ratio_thresh for accumulation or fall below 1 − phase_ratio_thresh for distribution. The first and second differences of the window ratio (d_ratio_1, d_ratio_2) determine trend direction.
3. OBV‑like cumulative net flow: An on‑balance volume analogue obv_net_phase increments by TF_buy_breakout − TF_sell_breakout each bar. Its differences over the last 1 and 2 bars (d_obv_1, d_obv_2) provide trend clues.
The algorithm then combines these signals:
• For strict mode , accumulation requires: (a) current ratio ≥ threshold, (b) cumulative ratio ≥ threshold, (c) both ratio differences ≥ 0, (d) net sum differences ≥ 0, and (e) OBV differences ≥ 0. Distribution is the mirror case.
• For loose mode , it relaxes the directional tests: either the 1‑ or the 2‑bar difference needs to agree in each category.
If all conditions for accumulation are satisfied, the phase is labelled “Accumulation” ; if all conditions for distribution are satisfied, it’s labelled “Distribution” ; otherwise the phase is “Neutral” .
4.4 Outputs
• Info table row : Row 8 displays “Market Phase (Vol)” on the left and the detected phase (Accumulation, Distribution or Neutral) on the right. The text colour of both cells matches a user‑selectable palette (typically green for accumulation, red for distribution and grey for neutral).
• On‑chart labels : When show_phase_labels is enabled and a phase persists for at least one bar, the module prints a label above the bar ( “Accum” ) or below the bar ( “Dist” ) with a dashed or dotted connector. The label is offset using ATR based on phase_label_atr_len_input and phase_label_multiplier and is styled according to user preferences.
Figure caption, The chart displays a red “Dist” label above a particular bar, indicating that the accumulation/distribution module identified a distribution phase at that point. The detection is based on seller dominance: during that bar, the net buyer-minus-seller flow and the OBV‑style cumulative flow were trending down, and the buyer ratio had dropped below the preset threshold. These conditions satisfy the distribution criteria in strict mode. The label is placed above the bar using an ATR‑based offset and a dashed connector. By the time of the current bar in the screenshot, the phase indicator shows “Neutral” in the info table—signaling that neither accumulation nor distribution conditions are currently met—yet the historical “Dist” label remains to mark where the prior distribution phase began.
Figure caption, In this example the market phase module has signaled an Accumulation phase. Three bars before the current candle, the algorithm detected a shift toward buyers: up‑volume exceeded its moving average, down‑volume was below average, and the buyer share of total volume climbed above the threshold while the on‑balance net flow and cumulative ratios were trending upwards. The blue “Accum” label anchored below that bar marks the start of the phase; it remains on the chart because successive bars continue to satisfy the accumulation conditions. The info table confirms this: the “Market Phase (Vol)” row still reads Accumulation, and the ratio and sum rows show buyers dominating both on the current bar and across the lookback window.
5. OB/OS Spike Module
5.1 What overbought/oversold means here
In many markets, a rapid extension up or down is often followed by a period of consolidation or reversal. The indicator interprets overbought (OB) conditions as abnormally strong selling risk at or after a price rally and oversold (OS) conditions as unusually strong buying risk after a decline. Importantly, these are not direct trade signals; rather they flag areas where caution or contrarian setups may be appropriate.
5.2 Inputs
• minHits_obos (1–7): Minimum number of oscillators that must agree on an overbought or oversold condition for a label to print.
• syncWin_obos: Length of a small sliding window over which oscillator votes are smoothed by taking the maximum count observed. This helps filter out choppy signals.
• Volume spike criteria: kVolRatio_obos (ratio of current volume to its SMA) and zVolThr_obos (Z‑score threshold) across volLen_obos. Either threshold can trigger a spike.
• Oscillator toggles and periods: Each of RSI, Stochastic (K and D), Williams %R, CCI, MFI, DeMarker and Stochastic RSI can be independently enabled; their periods are adjustable.
• Label appearance: ATR‑based offset, size, colors for OB and OS labels, plus connector style and width.
5.3 Detection logic
1. Directional volume spikes: Volume spikes are computed separately for buyer and seller volumes. A sell volume spike (sellVolSpike) flags a potential OverBought bar, while a buy volume spike (buyVolSpike) flags a potential OverSold bar. A spike occurs when the respective volume exceeds kVolRatio_obos times its simple moving average over the window or when its Z‑score exceeds zVolThr_obos.
2. Oscillator votes: For each enabled oscillator, calculate its overbought and oversold state using standard thresholds (e.g., RSI ≥ 70 for OB and ≤ 30 for OS; Stochastic %K/%D ≥ 80 for OB and ≤ 20 for OS; etc.). Count how many oscillators vote for OB and how many vote for OS.
3. Minimum hits: Apply the smoothing window syncWin_obos to the vote counts using a maximum‑of‑last‑N approach. A candidate bar is only considered if the smoothed OB hit count ≥ minHits_obos (for OverBought) or the smoothed OS hit count ≥ minHits_obos (for OverSold).
4. Tie‑breaking: If both OverBought and OverSold spike conditions are present on the same bar, compare the smoothed hit counts: the side with the higher count is selected; ties default to OverBought.
5. Label printing: When conditions are met, the bar is labelled as “OverBought X/7” above the candle or “OverSold X/7” below it. “X” is the number of oscillators confirming, and the bracket lists the abbreviations of contributing oscillators. Labels are offset from price using half of an ATR‑scaled distance and can optionally include a dotted or dashed connector line.
Figure caption, In this chart the overbought/oversold module has flagged an OverSold signal. A sell‑off from the prior highs brought price down to the lower trend‑line, where the bar marked “OverSold 3/7 DeM” appears. This label indicates that on that bar the module detected a buy‑side volume spike and that at least three of the seven enabled oscillators—in this case including the DeMarker—were in oversold territory. The label is printed below the candle with a dotted connector, signaling that the market may be temporarily exhausted on the downside. After this oversold print, price begins to rebound towards the upper red trend‑line and higher pivot levels.
Figure caption, This example shows the overbought/oversold module in action. In the left‑hand panel you can see the OB/OS settings where each oscillator (RSI, Stochastic, Williams %R, CCI, MFI, DeMarker and Stochastic RSI) can be enabled or disabled, and the ATR length and label offset multiplier adjusted. On the chart itself, price has pushed up to the descending red trendline and triggered an “OverBought 3/7” label. That means the sell‑side volume spiked relative to its average and three out of the seven enabled oscillators were in overbought territory. The label is offset above the candle by half of an ATR and connected with a dashed line, signaling that upside momentum may be overextended and a pause or pullback could follow.
6. Buyer/Seller Trap Module
6.1 Concept
A bull trap occurs when price appears to break above resistance, attracting buyers, but fails to sustain the move and quickly reverses, leaving a long upper wick and trapping late entrants. A bear trap is the opposite: price breaks below support, lures in sellers, then snaps back, leaving a long lower wick and trapping shorts. This module detects such traps by looking for price structure sweeps, order‑flow mismatches and dominance reversals. It uses a scoring system to differentiate risk from confirmed traps.
6.2 Inputs
• trap_lookback_len: Window length used to rank extremes and detect sweeps.
• trap_wick_threshold: Minimum proportion of a bar’s range that must be wick (upper for bull traps, lower for bear traps) to qualify as a sweep.
• trap_score_risk: Minimum aggregated score required to flag a trap risk. (The code defines a trap_score_confirm input, but confirmation is actually based on price reversal rather than a separate score threshold.)
• trap_confirm_bars: Maximum number of bars allowed for price to reverse and confirm the trap. If price does not reverse in this window, the risk label will expire or remain unconfirmed.
• Label settings: ATR length and multiplier for offsetting, size, colours for risk and confirmed labels, and connector style and width. Separate settings exist for bull and bear traps.
• Toggle inputs: show_trap_module and show_trap_labels enable the module and control whether labels are drawn on the chart.
6.3 Scoring logic
The module assigns points to several conditions and sums them to determine whether a trap risk is present. For bull traps, the score is built from the following (bear traps mirror the logic with highs and lows swapped):
1. Sweep (2 points): Price trades above the high pivot (HH1) but fails to close above it and leaves a long upper wick at least trap_wick_threshold × range. For bear traps, price dips below the low pivot (LL1), fails to close below and leaves a long lower wick.
2. Close break (1 point): Price closes beyond HH1 or LL1 without leaving a long wick.
3. Candle/delta mismatch (2 points): The candle closes bullish yet the order flow delta is negative or the seller ratio exceeds 50%, indicating hidden supply. Conversely, a bearish close with positive delta or buyer dominance suggests hidden demand.
4. Dominance inversion (2 points): The current bar’s buyer volume has the highest rank in the lookback window while cumulative sums favor sellers, or vice versa.
5. Low‑volume break (1 point): Price crosses the pivot but total volume is below its moving average.
The total score for each side is compared to trap_score_risk. If the score is high enough, a “Bull Trap Risk” or “Bear Trap Risk” label is drawn, offset from the candle by half of an ATR‑scaled distance using a dashed outline. If, within trap_confirm_bars, price reverses beyond the opposite level—drops back below the high pivot for bull traps or rises above the low pivot for bear traps—the label is upgraded to a solid “Bull Trap” or “Bear Trap” . In this version of the code, there is no separate score threshold for confirmation: the variable trap_score_confirm is unused; confirmation depends solely on a successful price reversal within the specified number of bars.
Figure caption, In this example the trap module has flagged a Bear Trap Risk. Price initially breaks below the most recent low pivot (LL1), but the bar closes back above that level and leaves a long lower wick, suggesting a failed push lower. Combined with a mismatch between the candle direction and the order flow (buyers regain control) and a reversal in volume dominance, the aggregate score exceeds the risk threshold, so a dashed “Bear Trap Risk” label prints beneath the bar. The green and red trend lines mark the current low and high pivot trajectories, while the horizontal dashed lines show the highest and lowest values in the lookback window. If, within the next few bars, price closes decisively above the support, the risk label would upgrade to a solid “Bear Trap” label.
Figure caption, In this example the trap module has identified both ends of a price range. Near the highs, price briefly pushes above the descending red trendline and the recent pivot high, but fails to close there and leaves a noticeable upper wick. That combination of a sweep above resistance and order‑flow mismatch generates a Bull Trap Risk label with a dashed outline, warning that the upside break may not hold. At the opposite extreme, price later dips below the green trendline and the labelled low pivot, then quickly snaps back and closes higher. The long lower wick and subsequent price reversal upgrade the previous bear‑trap risk into a confirmed Bear Trap (solid label), indicating that sellers were caught on a false breakdown. Horizontal dashed lines mark the highest high and lowest low of the lookback window, while the red and green diagonals connect the earliest and latest pivot highs and lows to visualize the range.
7. Sharp Move Module
7.1 Concept
Markets sometimes display absorption or climax behavior—periods when one side steadily gains the upper hand before price breaks out with a sharp move. This module evaluates several order‑flow and volume conditions to anticipate such moves. Users can choose how many conditions must be met to flag a risk and how many (plus a price break) are required for confirmation.
7.2 Inputs
• sharp Lookback: Number of bars in the window used to compute moving averages, sums, percentile ranks and reference levels.
• sharpPercentile: Minimum percentile rank for the current side’s volume; the current buy (or sell) volume must be greater than or equal to this percentile of historical volumes over the lookback window.
• sharpVolMult: Multiplier used in the volume climax check. The current side’s volume must exceed this multiple of its average to count as a climax.
• sharpRatioThr: Minimum dominance ratio (current side’s volume relative to the opposite side) used in both the instant and cumulative dominance checks.
• sharpChurnThr: Maximum ratio of a bar’s range to its ATR for absorption/churn detection; lower values indicate more absorption (large volume in a small range).
• sharpScoreRisk: Minimum number of conditions that must be true to print a risk label.
• sharpScoreConfirm: Minimum number of conditions plus a price break required for confirmation.
• sharpCvdThr: Threshold for cumulative delta divergence versus price change (positive for bullish accumulation, negative for bearish distribution).
• Label settings: ATR length (sharpATRlen) and multiplier (sharpLabelMult) for positioning labels, label size, colors and connector styles for bullish and bearish sharp moves.
• Toggles: enableSharp activates the module; show_sharp_labels controls whether labels are drawn.
7.3 Conditions (six per side)
For each side, the indicator computes six boolean conditions and sums them to form a score:
1. Dominance (instant and cumulative):
– Instant dominance: current buy volume ≥ sharpRatioThr × current sell volume.
– Cumulative dominance: sum of buy volumes over the window ≥ sharpRatioThr × sum of sell volumes (and vice versa for bearish checks).
2. Accumulation/Distribution divergence: Over the lookback window, cumulative delta rises by at least sharpCvdThr while price fails to rise (bullish), or cumulative delta falls by at least sharpCvdThr while price fails to fall (bearish).
3. Volume climax: The current side’s volume is ≥ sharpVolMult × its average and the product of volume and bar range is the highest in the lookback window.
4. Absorption/Churn: The current side’s volume divided by the bar’s range equals the highest value in the window and the bar’s range divided by ATR ≤ sharpChurnThr (indicating large volume within a small range).
5. Percentile rank: The current side’s volume percentile rank is ≥ sharp Percentile.
6. Mirror logic for sellers: The above checks are repeated with buyer and seller roles swapped and the price break levels reversed.
Each condition that passes contributes one point to the corresponding side’s score (0 or 1). Risk and confirmation thresholds are then applied to these scores.
7.4 Scoring and labels
• Risk: If scoreBull ≥ sharpScoreRisk, a “Sharp ↑ Risk” label is drawn above the bar. If scoreBear ≥ sharpScoreRisk, a “Sharp ↓ Risk” label is drawn below the bar.
• Confirmation: A risk label is upgraded to “Sharp ↑” when scoreBull ≥ sharpScoreConfirm and the bar closes above the highest recent pivot (HH1); for bearish cases, confirmation requires scoreBear ≥ sharpScoreConfirm and a close below the lowest pivot (LL1).
• Label positioning: Labels are offset from the candle by ATR × sharpLabelMult (full ATR times multiplier), not half, and may include a dashed or dotted connector line if enabled.
Figure caption, In this chart both bullish and bearish sharp‑move setups have been flagged. Earlier in the range, a “Sharp ↓ Risk” label appears beneath a candle: the sell‑side score met the risk threshold, signaling that the combination of strong sell volume, dominance and absorption within a narrow range suggested a potential sharp decline. The price did not close below the lower pivot, so this label remains a “risk” and no confirmation occurred. Later, as the market recovered and volume shifted back to the buy side, a “Sharp ↑ Risk” label prints above a candle near the top of the channel. Here, buy‑side dominance, cumulative delta divergence and a volume climax aligned, but price has not yet closed above the upper pivot (HH1), so the alert is still a risk rather than a confirmed sharp‑up move.
Figure caption, In this chart a Sharp ↑ label is displayed above a candle, indicating that the sharp move module has confirmed a bullish breakout. Prior bars satisfied the risk threshold — showing buy‑side dominance, positive cumulative delta divergence, a volume climax and strong absorption in a narrow range — and this candle closes above the highest recent pivot, upgrading the earlier “Sharp ↑ Risk” alert to a full Sharp ↑ signal. The green label is offset from the candle with a dashed connector, while the red and green trend lines trace the high and low pivot trajectories and the dashed horizontals mark the highest and lowest values of the lookback window.
8. Market‑Maker / Spread‑Capture Module
8.1 Concept
Liquidity providers often “capture the spread” by buying and selling in almost equal amounts within a very narrow price range. These bars can signal temporary congestion before a move or reflect algorithmic activity. This module flags bars where both buyer and seller volumes are high, the price range is only a few ticks and the buy/sell split remains close to 50%. It helps traders spot potential liquidity pockets.
8.2 Inputs
• scalpLookback: Window length used to compute volume averages.
• scalpVolMult: Multiplier applied to each side’s average volume; both buy and sell volumes must exceed this multiple.
• scalpTickCount: Maximum allowed number of ticks in a bar’s range (calculated as (high − low) / minTick). A value of 1 or 2 captures ultra‑small bars; increasing it relaxes the range requirement.
• scalpDeltaRatio: Maximum deviation from a perfect 50/50 split. For example, 0.05 means the buyer share must be between 45% and 55%.
• Label settings: ATR length, multiplier, size, colors, connector style and width.
• Toggles : show_scalp_module and show_scalp_labels to enable the module and its labels.
8.3 Signal
When, on the current bar, both TF_buy_breakout and TF_sell_breakout exceed scalpVolMult times their respective averages and (high − low)/minTick ≤ scalpTickCount and the buyer share is within scalpDeltaRatio of 50%, the module prints a “Spread ↔” label above the bar. The label uses the same ATR offset logic as other modules and draws a connector if enabled.
Figure caption, In this chart the spread‑capture module has identified a potential liquidity pocket. Buyer and seller volumes both spiked above their recent averages, yet the candle’s range measured only a couple of ticks and the buy/sell split stayed close to 50 %. This combination met the module’s criteria, so it printed a grey “Spread ↔” label above the bar. The red and green trend lines link the earliest and latest high and low pivots, and the dashed horizontals mark the highest high and lowest low within the current lookback window.
9. Money Flow Module
9.1 Concept
To translate volume into a monetary measure, this module multiplies each side’s volume by the closing price. It tracks buying and selling system money default currency on a per-bar basis and sums them over a chosen period. The difference between buy and sell currencies (Δ$) shows net inflow or outflow.
9.2 Inputs
• mf_period_len_mf: Number of bars used for summing buy and sell dollars.
• Label appearance settings: ATR length, multiplier, size, colors for up/down labels, and connector style and width.
• Toggles: Use enableMoneyFlowLabel_mf and showMFLabels to control whether the module and its labels are displayed.
9.3 Calculations
• Per-bar money: Buy $ = TF_buy_breakout × close; Sell $ = TF_sell_breakout × close. Their difference is Δ$ = Buy $ − Sell $.
• Summations: Over mf_period_len_mf bars, compute Σ Buy $, Σ Sell $ and ΣΔ$ using math.sum().
• Info table entries: Rows 9–13 display these values as texts like “↑ USD 1234 (1M)” or “ΣΔ USD −5678 (14)”, with colors reflecting whether buyers or sellers dominate.
• Money flow status: If Δ$ is positive the bar is marked “Money flow in” ; if negative, “Money flow out” ; if zero, “Neutral”. The cumulative status is similarly derived from ΣΔ.Labels print at the bar that changes the sign of ΣΔ, offset using ATR × label multiplier and styled per user preferences.
Figure caption, The chart illustrates a steady rise toward the highest recent pivot (HH1) with price riding between a rising green trend‑line and a red trend‑line drawn through earlier pivot highs. A green Money flow in label appears above the bar near the top of the channel, signaling that net dollar flow turned positive on this bar: buy‑side dollar volume exceeded sell‑side dollar volume, pushing the cumulative sum ΣΔ$ above zero. In the info table, the “Money flow (bar)” and “Money flow Σ” rows both read In, confirming that the indicator’s money‑flow module has detected an inflow at both bar and aggregate levels, while other modules (pivots, trend lines and support/resistance) remain active to provide structural context.
In this example the Money Flow module signals a net outflow. Price has been trending downward: successive high pivots form a falling red trend‑line and the low pivots form a descending green support line. When the latest bar broke below the previous low pivot (LL1), both the bar‑level and cumulative net dollar flow turned negative—selling volume at the close exceeded buying volume and pushed the cumulative Δ$ below zero. The module reacts by printing a red “Money flow out” label beneath the candle; the info table confirms that the “Money flow (bar)” and “Money flow Σ” rows both show Out, indicating sustained dominance of sellers in this period.
10. Info Table
10.1 Purpose
When enabled, the Info Table appears in the lower right of your chart. It summarises key values computed by the indicator—such as buy and sell volume, delta, total volume, breakout status, market phase, and money flow—so you can see at a glance which side is dominant and which signals are active.
10.2 Symbols
• ↑ / ↓ — Up (↑) denotes buy volume or money; down (↓) denotes sell volume or money.
• MA — Moving average. In the table it shows the average value of a series over the lookback period.
• Σ (Sigma) — Cumulative sum over the chosen lookback period.
• Δ (Delta) — Difference between buy and sell values.
• B / S — Buyer and seller share of total volume, expressed as percentages.
• Ref. Price — Reference price for breakout calculations, based on the latest pivot.
• Status — Indicates whether a breakout condition is currently active (True) or has failed.
10.3 Row definitions
1. Up volume / MA up volume – Displays current buy volume on the lower timeframe and its moving average over the lookback period.
2. Down volume / MA down volume – Shows current sell volume and its moving average; sell values are formatted in red for clarity.
3. Δ / ΣΔ – Lists the difference between buy and sell volume for the current bar and the cumulative delta volume over the lookback period.
4. Σ / MA Σ (Vol/MA) – Total volume (buy + sell) for the bar, with the ratio of this volume to its moving average; the right cell shows the average total volume.
5. B/S ratio – Buy and sell share of the total volume: current bar percentages and the average percentages across the lookback period.
6. Buyer Rank / Seller Rank – Ranks the bar’s buy and sell volumes among the last (n) bars; lower rank numbers indicate higher relative volume.
7. Σ Buy / Σ Sell – Sum of buy and sell volumes over the lookback window, indicating which side has traded more.
8. Breakout UP / DOWN – Shows the breakout thresholds (Ref. Price) and whether the breakout condition is active (True) or has failed.
9. Market Phase (Vol) – Reports the current volume‑only phase: Accumulation, Distribution or Neutral.
10. Money Flow – The final rows display dollar amounts and status:
– ↑ USD / Σ↑ USD – Buy dollars for the current bar and the cumulative sum over the money‑flow period.
– ↓ USD / Σ↓ USD – Sell dollars and their cumulative sum.
– Δ USD / ΣΔ USD – Net dollar difference (buy minus sell) for the bar and cumulatively.
– Money flow (bar) – Indicates whether the bar’s net dollar flow is positive (In), negative (Out) or neutral.
– Money flow Σ – Shows whether the cumulative net dollar flow across the chosen period is positive, negative or neutral.
The chart above shows a sequence of different signals from the indicator. A Bull Trap Risk appears after price briefly pushes above resistance but fails to hold, then a green Accum label identifies an accumulation phase. An upward breakout follows, confirmed by a Money flow in print. Later, a Sharp ↓ Risk warns of a possible sharp downturn; after price dips below support but quickly recovers, a Bear Trap label marks a false breakdown. The highlighted info table in the center summarizes key metrics at that moment, including current and average buy/sell volumes, net delta, total volume versus its moving average, breakout status (up and down), market phase (volume), and bar‑level and cumulative money flow (In/Out).
11. Conclusion & Final Remarks
This indicator was developed as a holistic study of market structure and order flow. It brings together several well‑known concepts from technical analysis—breakouts, accumulation and distribution phases, overbought and oversold extremes, bull and bear traps, sharp directional moves, market‑maker spread bars and money flow—into a single Pine Script tool. Each module is based on widely recognized trading ideas and was implemented after consulting reference materials and example strategies, so you can see in real time how these concepts interact on your chart.
A distinctive feature of this indicator is its reliance on per‑side volume: instead of tallying only total volume, it separately measures buy and sell transactions on a lower time frame. This approach gives a clearer view of who is in control—buyers or sellers—and helps filter breakouts, detect phases of accumulation or distribution, recognize potential traps, anticipate sharp moves and gauge whether liquidity providers are active. The money‑flow module extends this analysis by converting volume into currency values and tracking net inflow or outflow across a chosen window.
Although comprehensive, this indicator is intended solely as a guide. It highlights conditions and statistics that many traders find useful, but it does not generate trading signals or guarantee results. Ultimately, you remain responsible for your positions. Use the information presented here to inform your analysis, combine it with other tools and risk‑management techniques, and always make your own decisions when trading.
ValueAtTime█ OVERVIEW
This library is a Pine Script® programming tool for accessing historical values in a time series using UNIX timestamps . Its data structure and functions index values by time, allowing scripts to retrieve past values based on absolute timestamps or relative time offsets instead of relying on bar index offsets.
█ CONCEPTS
UNIX timestamps
In Pine Script®, a UNIX timestamp is an integer representing the number of milliseconds elapsed since January 1, 1970, at 00:00:00 UTC (the UNIX Epoch ). The timestamp is a unique, absolute representation of a specific point in time. Unlike a calendar date and time, a UNIX timestamp's meaning does not change relative to any time zone .
This library's functions process series values and corresponding UNIX timestamps in pairs , offering a simplified way to identify values that occur at or near distinct points in time instead of on specific bars.
Storing and retrieving time-value pairs
This library's `Data` type defines the structure for collecting time and value information in pairs. Objects of the `Data` type contain the following two fields:
• `times` – An array of "int" UNIX timestamps for each recorded value.
• `values` – An array of "float" values for each saved timestamp.
Each index in both arrays refers to a specific time-value pair. For instance, the `times` and `values` elements at index 0 represent the first saved timestamp and corresponding value. The library functions that maintain `Data` objects queue up to one time-value pair per bar into the object's arrays, where the saved timestamp represents the bar's opening time .
Because the `times` array contains a distinct UNIX timestamp for each item in the `values` array, it serves as a custom mapping for retrieving saved values. All the library functions that return information from a `Data` object use this simple two-step process to identify a value based on time:
1. Perform a binary search on the `times` array to find the earliest saved timestamp closest to the specified time or offset and get the element's index.
2. Access the element from the `values` array at the retrieved index, returning the stored value corresponding to the found timestamp.
Value search methods
There are several techniques programmers can use to identify historical values from corresponding timestamps. This library's functions include three different search methods to locate and retrieve values based on absolute times or relative time offsets:
Timestamp search
Find the value with the earliest saved timestamp closest to a specified timestamp.
Millisecond offset search
Find the value with the earliest saved timestamp closest to a specified number of milliseconds behind the current bar's opening time. This search method provides a time-based alternative to retrieving historical values at specific bar offsets.
Period offset search
Locate the value with the earliest saved timestamp closest to a defined period offset behind the current bar's opening time. The function calculates the span of the offset based on a period string . The "string" must contain one of the following unit tokens:
• "D" for days
• "W" for weeks
• "M" for months
• "Y" for years
• "YTD" for year-to-date, meaning the time elapsed since the beginning of the bar's opening year in the exchange time zone.
The period string can include a multiplier prefix for all supported units except "YTD" (e.g., "2W" for two weeks).
Note that the precise span covered by the "M", "Y", and "YTD" units varies across time. The "1M" period can cover 28, 29, 30, or 31 days, depending on the bar's opening month and year in the exchange time zone. The "1Y" period covers 365 or 366 days, depending on leap years. The "YTD" period's span changes with each new bar, because it always measures the time from the start of the current bar's opening year.
█ CALCULATIONS AND USE
This library's functions offer a flexible, structured approach to retrieving historical values at or near specific timestamps, millisecond offsets, or period offsets for different analytical needs.
See below for explanations of the exported functions and how to use them.
Retrieving single values
The library includes three functions that retrieve a single stored value using timestamp, millisecond offset, or period offset search methods:
• `valueAtTime()` – Locates the saved value with the earliest timestamp closest to a specified timestamp.
• `valueAtTimeOffset()` – Finds the saved value with the earliest timestamp closest to the specified number of milliseconds behind the current bar's opening time.
• `valueAtPeriodOffset()` – Finds the saved value with the earliest timestamp closest to the period-based offset behind the current bar's opening time.
Each function has two overloads for advanced and simple use cases. The first overload searches for a value in a user-specified `Data` object created by the `collectData()` function (see below). It returns a tuple containing the found value and the corresponding timestamp.
The second overload maintains a `Data` object internally to store and retrieve values for a specified `source` series. This overload returns a tuple containing the historical `source` value, the corresponding timestamp, and the current bar's `source` value, making it helpful for comparing past and present values from requested contexts.
Retrieving multiple values
The library includes the following functions to retrieve values from multiple historical points in time, facilitating calculations and comparisons with values retrieved across several intervals:
• `getDataAtTimes()` – Locates a past `source` value for each item in a `timestamps` array. Each retrieved value's timestamp represents the earliest time closest to one of the specified timestamps.
• `getDataAtTimeOffsets()` – Finds a past `source` value for each item in a `timeOffsets` array. Each retrieved value's timestamp represents the earliest time closest to one of the specified millisecond offsets behind the current bar's opening time.
• `getDataAtPeriodOffsets()` – Finds a past value for each item in a `periods` array. Each retrieved value's timestamp represents the earliest time closest to one of the specified period offsets behind the current bar's opening time.
Each function returns a tuple with arrays containing the found `source` values and their corresponding timestamps. In addition, the tuple includes the current `source` value and the symbol's description, which also makes these functions helpful for multi-interval comparisons using data from requested contexts.
Processing period inputs
When writing scripts that retrieve historical values based on several user-specified period offsets, the most concise approach is to create a single text input that allows users to list each period, then process the "string" list into an array for use in the `getDataAtPeriodOffsets()` function.
This library includes a `getArrayFromString()` function to provide a simple way to process strings containing comma-separated lists of periods. The function splits the specified `str` by its commas and returns an array containing every non-empty item in the list with surrounding whitespaces removed. View the example code to see how we use this function to process the value of a text area input .
Calculating period offset times
Because the exact amount of time covered by a specified period offset can vary, it is often helpful to verify the resulting times when using the `valueAtPeriodOffset()` or `getDataAtPeriodOffsets()` functions to ensure the calculations work as intended for your use case.
The library's `periodToTimestamp()` function calculates an offset timestamp from a given period and reference time. With this function, programmers can verify the time offsets in a period-based data search and use the calculated offset times in additional operations.
For periods with "D" or "W" units, the function calculates the time offset based on the absolute number of milliseconds the period covers (e.g., `86400000` for "1D"). For periods with "M", "Y", or "YTD" units, the function calculates an offset time based on the reference time's calendar date in the exchange time zone.
Collecting data
All the `getDataAt*()` functions, and the second overloads of the `valueAt*()` functions, collect and maintain data internally, meaning scripts do not require a separate `Data` object when using them. However, the first overloads of the `valueAt*()` functions do not collect data, because they retrieve values from a user-specified `Data` object.
For cases where a script requires a separate `Data` object for use with these overloads or other custom routines, this library exports the `collectData()` function. This function queues each bar's `source` value and opening timestamp into a `Data` object and returns the object's ID.
This function is particularly useful when searching for values from a specific series more than once. For instance, instead of using multiple calls to the second overloads of `valueAt*()` functions with the same `source` argument, programmers can call `collectData()` to store each bar's `source` and opening timestamp, then use the returned `Data` object's ID in calls to the first `valueAt*()` overloads to reduce memory usage.
The `collectData()` function and all the functions that collect data internally include two optional parameters for limiting the saved time-value pairs to a sliding window: `timeOffsetLimit` and `timeframeLimit`. When either has a non-na argument, the function restricts the collected data to the maximum number of recent bars covered by the specified millisecond- and timeframe-based intervals.
NOTE : All calls to the functions that collect data for a `source` series can execute up to once per bar or realtime tick, because each stored value requires a unique corresponding timestamp. Therefore, scripts cannot call these functions iteratively within a loop . If a call to these functions executes more than once inside a loop's scope, it causes a runtime error.
█ EXAMPLE CODE
The example code at the end of the script demonstrates one possible use case for this library's functions. The code retrieves historical price data at user-specified period offsets, calculates price returns for each period from the retrieved data, and then populates a table with the results.
The example code's process is as follows:
1. Input a list of periods – The user specifies a comma-separated list of period strings in the script's "Period list" input (e.g., "1W, 1M, 3M, 1Y, YTD"). Each item in the input list represents a period offset from the latest bar's opening time.
2. Process the period list – The example calls `getArrayFromString()` on the first bar to split the input list by its commas and construct an array of period strings.
3. Request historical data – The code uses a call to `getDataAtPeriodOffsets()` as the `expression` argument in a request.security() call to retrieve the closing prices of "1D" bars for each period included in the processed `periods` array.
4. Display information in a table – On the latest bar, the code uses the retrieved data to calculate price returns over each specified period, then populates a two-row table with the results. The cells for each return percentage are color-coded based on the magnitude and direction of the price change. The cells also include tooltips showing the compared daily bar's opening date in the exchange time zone.
█ NOTES
• This library's architecture relies on a user-defined type (UDT) for its data storage format. UDTs are blueprints from which scripts create objects , i.e., composite structures with fields containing independent values or references of any supported type.
• The library functions search through a `Data` object's `times` array using the array.binary_search_leftmost() function, which is more efficient than looping through collected data to identify matching timestamps. Note that this built-in works only for arrays with elements sorted in ascending order .
• Each function that collects data from a `source` series updates the values and times stored in a local `Data` object's arrays. If a single call to these functions were to execute in a loop , it would store multiple values with an identical timestamp, which can cause erroneous search behavior. To prevent looped calls to these functions, the library uses the `checkCall()` helper function in their scopes. This function maintains a counter that increases by one each time it executes on a confirmed bar. If the count exceeds the total number of bars, indicating the call executes more than once in a loop, it raises a runtime error .
• Typically, when requesting higher-timeframe data with request.security() while using barmerge.lookahead_on as the `lookahead` argument, the `expression` argument should be offset with the history-referencing operator to prevent lookahead bias on historical bars. However, the call in this script's example code enables lookahead without offsetting the `expression` because the script displays results only on the last historical bar and all realtime bars, where there is no future data to leak into the past. This call ensures the displayed results use the latest data available from the context on realtime bars.
Look first. Then leap.
█ EXPORTED TYPES
Data
A structure for storing successive timestamps and corresponding values from a dataset.
Fields:
times (array) : An "int" array containing a UNIX timestamp for each value in the `values` array.
values (array) : A "float" array containing values corresponding to the timestamps in the `times` array.
█ EXPORTED FUNCTIONS
getArrayFromString(str)
Splits a "string" into an array of substrings using the comma (`,`) as the delimiter. The function trims surrounding whitespace characters from each substring, and it excludes empty substrings from the result.
Parameters:
str (series string) : The "string" to split into an array based on its commas.
Returns: (array) An array of trimmed substrings from the specified `str`.
periodToTimestamp(period, referenceTime)
Calculates a UNIX timestamp representing the point offset behind a reference time by the amount of time within the specified `period`.
Parameters:
period (series string) : The period string, which determines the time offset of the returned timestamp. The specified argument must contain a unit and an optional multiplier (e.g., "1Y", "3M", "2W", "YTD"). Supported units are:
- "Y" for years.
- "M" for months.
- "W" for weeks.
- "D" for days.
- "YTD" (Year-to-date) for the span from the start of the `referenceTime` value's year in the exchange time zone. An argument with this unit cannot contain a multiplier.
referenceTime (series int) : The millisecond UNIX timestamp from which to calculate the offset time.
Returns: (int) A millisecond UNIX timestamp representing the offset time point behind the `referenceTime`.
collectData(source, timeOffsetLimit, timeframeLimit)
Collects `source` and `time` data successively across bars. The function stores the information within a `Data` object for use in other exported functions/methods, such as `valueAtTimeOffset()` and `valueAtPeriodOffset()`. Any call to this function cannot execute more than once per bar or realtime tick.
Parameters:
source (series float) : The source series to collect. The function stores each value in the series with an associated timestamp representing its corresponding bar's opening time.
timeOffsetLimit (simple int) : Optional. A time offset (range) in milliseconds. If specified, the function limits the collected data to the maximum number of bars covered by the range, with a minimum of one bar. If the call includes a non-empty `timeframeLimit` value, the function limits the data using the largest number of bars covered by the two ranges. The default is `na`.
timeframeLimit (simple string) : Optional. A valid timeframe string. If specified and not empty, the function limits the collected data to the maximum number of bars covered by the timeframe, with a minimum of one bar. If the call includes a non-na `timeOffsetLimit` value, the function limits the data using the largest number of bars covered by the two ranges. The default is `na`.
Returns: (Data) A `Data` object containing collected `source` values and corresponding timestamps over the allowed time range.
method valueAtTime(data, timestamp)
(Overload 1 of 2) Retrieves value and time data from a `Data` object's fields at the index of the earliest timestamp closest to the specified `timestamp`. Callable as a method or a function.
Parameters:
data (series Data) : The `Data` object containing the collected time and value data.
timestamp (series int) : The millisecond UNIX timestamp to search. The function returns data for the earliest saved timestamp that is closest to the value.
Returns: ( ) A tuple containing the following data from the `Data` object:
- The stored value corresponding to the identified timestamp ("float").
- The earliest saved timestamp that is closest to the specified `timestamp` ("int").
valueAtTime(source, timestamp, timeOffsetLimit, timeframeLimit)
(Overload 2 of 2) Retrieves `source` and time information for the earliest bar whose opening timestamp is closest to the specified `timestamp`. Any call to this function cannot execute more than once per bar or realtime tick.
Parameters:
source (series float) : The source series to analyze. The function stores each value in the series with an associated timestamp representing its corresponding bar's opening time.
timestamp (series int) : The millisecond UNIX timestamp to search. The function returns data for the earliest bar whose timestamp is closest to the value.
timeOffsetLimit (simple int) : Optional. A time offset (range) in milliseconds. If specified, the function limits the collected data to the maximum number of bars covered by the range, with a minimum of one bar. If the call includes a non-empty `timeframeLimit` value, the function limits the data using the largest number of bars covered by the two ranges. The default is `na`.
timeframeLimit (simple string) : (simple string) Optional. A valid timeframe string. If specified and not empty, the function limits the collected data to the maximum number of bars covered by the timeframe, with a minimum of one bar. If the call includes a non-na `timeOffsetLimit` value, the function limits the data using the largest number of bars covered by the two ranges. The default is `na`.
Returns: ( ) A tuple containing the following data:
- The `source` value corresponding to the identified timestamp ("float").
- The earliest bar's timestamp that is closest to the specified `timestamp` ("int").
- The current bar's `source` value ("float").
method valueAtTimeOffset(data, timeOffset)
(Overload 1 of 2) Retrieves value and time data from a `Data` object's fields at the index of the earliest saved timestamp closest to `timeOffset` milliseconds behind the current bar's opening time. Callable as a method or a function.
Parameters:
data (series Data) : The `Data` object containing the collected time and value data.
timeOffset (series int) : The millisecond offset behind the bar's opening time. The function returns data for the earliest saved timestamp that is closest to the calculated offset time.
Returns: ( ) A tuple containing the following data from the `Data` object:
- The stored value corresponding to the identified timestamp ("float").
- The earliest saved timestamp that is closest to `timeOffset` milliseconds before the current bar's opening time ("int").
valueAtTimeOffset(source, timeOffset, timeOffsetLimit, timeframeLimit)
(Overload 2 of 2) Retrieves `source` and time information for the earliest bar whose opening timestamp is closest to `timeOffset` milliseconds behind the current bar's opening time. Any call to this function cannot execute more than once per bar or realtime tick.
Parameters:
source (series float) : The source series to analyze. The function stores each value in the series with an associated timestamp representing its corresponding bar's opening time.
timeOffset (series int) : The millisecond offset behind the bar's opening time. The function returns data for the earliest bar's timestamp that is closest to the calculated offset time.
timeOffsetLimit (simple int) : Optional. A time offset (range) in milliseconds. If specified, the function limits the collected data to the maximum number of bars covered by the range, with a minimum of one bar. If the call includes a non-empty `timeframeLimit` value, the function limits the data using the largest number of bars covered by the two ranges. The default is `na`.
timeframeLimit (simple string) : Optional. A valid timeframe string. If specified and not empty, the function limits the collected data to the maximum number of bars covered by the timeframe, with a minimum of one bar. If the call includes a non-na `timeOffsetLimit` value, the function limits the data using the largest number of bars covered by the two ranges. The default is `na`.
Returns: ( ) A tuple containing the following data:
- The `source` value corresponding to the identified timestamp ("float").
- The earliest bar's timestamp that is closest to `timeOffset` milliseconds before the current bar's opening time ("int").
- The current bar's `source` value ("float").
method valueAtPeriodOffset(data, period)
(Overload 1 of 2) Retrieves value and time data from a `Data` object's fields at the index of the earliest timestamp closest to a calculated offset behind the current bar's opening time. The calculated offset represents the amount of time covered by the specified `period`. Callable as a method or a function.
Parameters:
data (series Data) : The `Data` object containing the collected time and value data.
period (series string) : The period string, which determines the calculated time offset. The specified argument must contain a unit and an optional multiplier (e.g., "1Y", "3M", "2W", "YTD"). Supported units are:
- "Y" for years.
- "M" for months.
- "W" for weeks.
- "D" for days.
- "YTD" (Year-to-date) for the span from the start of the current bar's year in the exchange time zone. An argument with this unit cannot contain a multiplier.
Returns: ( ) A tuple containing the following data from the `Data` object:
- The stored value corresponding to the identified timestamp ("float").
- The earliest saved timestamp that is closest to the calculated offset behind the bar's opening time ("int").
valueAtPeriodOffset(source, period, timeOffsetLimit, timeframeLimit)
(Overload 2 of 2) Retrieves `source` and time information for the earliest bar whose opening timestamp is closest to a calculated offset behind the current bar's opening time. The calculated offset represents the amount of time covered by the specified `period`. Any call to this function cannot execute more than once per bar or realtime tick.
Parameters:
source (series float) : The source series to analyze. The function stores each value in the series with an associated timestamp representing its corresponding bar's opening time.
period (series string) : The period string, which determines the calculated time offset. The specified argument must contain a unit and an optional multiplier (e.g., "1Y", "3M", "2W", "YTD"). Supported units are:
- "Y" for years.
- "M" for months.
- "W" for weeks.
- "D" for days.
- "YTD" (Year-to-date) for the span from the start of the current bar's year in the exchange time zone. An argument with this unit cannot contain a multiplier.
timeOffsetLimit (simple int) : Optional. A time offset (range) in milliseconds. If specified, the function limits the collected data to the maximum number of bars covered by the range, with a minimum of one bar. If the call includes a non-empty `timeframeLimit` value, the function limits the data using the largest number of bars covered by the two ranges. The default is `na`.
timeframeLimit (simple string) : Optional. A valid timeframe string. If specified and not empty, the function limits the collected data to the maximum number of bars covered by the timeframe, with a minimum of one bar. If the call includes a non-na `timeOffsetLimit` value, the function limits the data using the largest number of bars covered by the two ranges. The default is `na`.
Returns: ( ) A tuple containing the following data:
- The `source` value corresponding to the identified timestamp ("float").
- The earliest bar's timestamp that is closest to the calculated offset behind the current bar's opening time ("int").
- The current bar's `source` value ("float").
getDataAtTimes(timestamps, source, timeOffsetLimit, timeframeLimit)
Retrieves `source` and time information for each bar whose opening timestamp is the earliest one closest to one of the UNIX timestamps specified in the `timestamps` array. Any call to this function cannot execute more than once per bar or realtime tick.
Parameters:
timestamps (array) : An array of "int" values representing UNIX timestamps. The function retrieves `source` and time data for each element in this array.
source (series float) : The source series to analyze. The function stores each value in the series with an associated timestamp representing its corresponding bar's opening time.
timeOffsetLimit (simple int) : Optional. A time offset (range) in milliseconds. If specified, the function limits the collected data to the maximum number of bars covered by the range, with a minimum of one bar. If the call includes a non-empty `timeframeLimit` value, the function limits the data using the largest number of bars covered by the two ranges. The default is `na`.
timeframeLimit (simple string) : Optional. A valid timeframe string. If specified and not empty, the function limits the collected data to the maximum number of bars covered by the timeframe, with a minimum of one bar. If the call includes a non-na `timeOffsetLimit` value, the function limits the data using the largest number of bars covered by the two ranges. The default is `na`.
Returns: ( ) A tuple of the following data:
- An array containing a `source` value for each identified timestamp (array).
- An array containing an identified timestamp for each item in the `timestamps` array (array).
- The current bar's `source` value ("float").
- The symbol's description from `syminfo.description` ("string").
getDataAtTimeOffsets(timeOffsets, source, timeOffsetLimit, timeframeLimit)
Retrieves `source` and time information for each bar whose opening timestamp is the earliest one closest to one of the time offsets specified in the `timeOffsets` array. Each offset in the array represents the absolute number of milliseconds behind the current bar's opening time. Any call to this function cannot execute more than once per bar or realtime tick.
Parameters:
timeOffsets (array) : An array of "int" values representing the millisecond time offsets used in the search. The function retrieves `source` and time data for each element in this array. For example, the array ` ` specifies that the function returns data for the timestamps closest to one day and one week behind the current bar's opening time.
source (float) : (series float) The source series to analyze. The function stores each value in the series with an associated timestamp representing its corresponding bar's opening time.
timeOffsetLimit (simple int) : Optional. A time offset (range) in milliseconds. If specified, the function limits the collected data to the maximum number of bars covered by the range, with a minimum of one bar. If the call includes a non-empty `timeframeLimit` value, the function limits the data using the largest number of bars covered by the two ranges. The default is `na`.
timeframeLimit (simple string) : Optional. A valid timeframe string. If specified and not empty, the function limits the collected data to the maximum number of bars covered by the timeframe, with a minimum of one bar. If the call includes a non-na `timeOffsetLimit` value, the function limits the data using the largest number of bars covered by the two ranges. The default is `na`.
Returns: ( ) A tuple of the following data:
- An array containing a `source` value for each identified timestamp (array).
- An array containing an identified timestamp for each offset specified in the `timeOffsets` array (array).
- The current bar's `source` value ("float").
- The symbol's description from `syminfo.description` ("string").
getDataAtPeriodOffsets(periods, source, timeOffsetLimit, timeframeLimit)
Retrieves `source` and time information for each bar whose opening timestamp is the earliest one closest to a calculated offset behind the current bar's opening time. Each calculated offset represents the amount of time covered by a period specified in the `periods` array. Any call to this function cannot execute more than once per bar or realtime tick.
Parameters:
periods (array) : An array of period strings, which determines the time offsets used in the search. The function retrieves `source` and time data for each element in this array. For example, the array ` ` specifies that the function returns data for the timestamps closest to one day, week, and month behind the current bar's opening time. Each "string" in the array must contain a unit and an optional multiplier. Supported units are:
- "Y" for years.
- "M" for months.
- "W" for weeks.
- "D" for days.
- "YTD" (Year-to-date) for the span from the start of the current bar's year in the exchange time zone. An argument with this unit cannot contain a multiplier.
source (float) : (series float) The source series to analyze. The function stores each value in the series with an associated timestamp representing its corresponding bar's opening time.
timeOffsetLimit (simple int) : Optional. A time offset (range) in milliseconds. If specified, the function limits the collected data to the maximum number of bars covered by the range, with a minimum of one bar. If the call includes a non-empty `timeframeLimit` value, the function limits the data using the largest number of bars covered by the two ranges. The default is `na`.
timeframeLimit (simple string) : Optional. A valid timeframe string. If specified and not empty, the function limits the collected data to the maximum number of bars covered by the timeframe, with a minimum of one bar. If the call includes a non-na `timeOffsetLimit` value, the function limits the data using the largest number of bars covered by the two ranges. The default is `na`.
Returns: ( ) A tuple of the following data:
- An array containing a `source` value for each identified timestamp (array).
- An array containing an identified timestamp for each period specified in the `periods` array (array).
- The current bar's `source` value ("float").
- The symbol's description from `syminfo.description` ("string").
`security()` revisited [PineCoders]NOTE
The non-repainting technique in this publication that relies on bar states is now deprecated, as we have identified inconsistencies that undermine its credibility as a universal solution. The outputs that use the technique are still available for reference in this publication. However, we do not endorse its usage. See this publication for more information about the current best practices for requesting HTF data and why they work.
█ OVERVIEW
This script presents a new function to help coders use security() in both repainting and non-repainting modes. We revisit this often misunderstood and misused function, and explain its behavior in different contexts, in the hope of dispelling some of the coder lure surrounding it. The function is incredibly powerful, yet misused, it can become a dangerous WMD and an instrument of deception, for both coders and traders.
We will discuss:
• How to use our new `f_security()` function.
• The behavior of Pine code and security() on the three very different types of bars that make up any chart.
• Why what you see on a chart is a simulation, and should be taken with a grain of salt.
• Why we are presenting a new version of a function handling security() calls.
• Other topics of interest to coders using higher timeframe (HTF) data.
█ WARNING
We have tried to deliver a function that is simple to use and will, in non-repainting mode, produce reliable results for both experienced and novice coders. If you are a novice coder, stick to our recommendations to avoid getting into trouble, and DO NOT change our `f_security()` function when using it. Use `false` as the function's last argument and refrain from using your script at smaller timeframes than the chart's. To call our function to fetch a non-repainting value of close from the 1D timeframe, use:
f_security(_sym, _res, _src, _rep) => security(_sym, _res, _src )
previousDayClose = f_security(syminfo.tickerid, "D", close, false)
If that's all you're interested in, you are done.
If you choose to ignore our recommendation and use the function in repainting mode by changing the `false` in there for `true`, we sincerely hope you read the rest of our ramblings before you do so, to understand the consequences of your choice.
Let's now have a look at what security() is showing you. There is a lot to cover, so buckle up! But before we dig in, one last thing.
What is a chart?
A chart is a graphic representation of events that occur in markets. As any representation, it is not reality, but rather a model of reality. As Scott Page eloquently states in The Model Thinker : "All models are wrong; many are useful". Having in mind that both chart bars and plots on our charts are imperfect and incomplete renderings of what actually occurred in realtime markets puts us coders in a place from where we can better understand the nature of, and the causes underlying the inevitable compromises necessary to build the data series our code uses, and print chart bars.
Traders or coders complaining that charts do not reflect reality act like someone who would complain that the word "dog" is not a real dog. Let's recognize that we are dealing with models here, and try to understand them the best we can. Sure, models can be improved; TradingView is constantly improving the quality of the information displayed on charts, but charts nevertheless remain mere translations. Plots of data fetched through security() being modelized renderings of what occurs at higher timeframes, coders will build more useful and reliable tools for both themselves and traders if they endeavor to perfect their understanding of the abstractions they are working with. We hope this publication helps you in this pursuit.
█ FEATURES
This script's "Inputs" tab has four settings:
• Repaint : Determines whether the functions will use their repainting or non-repainting mode.
Note that the setting will not affect the behavior of the yellow plot, as it always repaints.
• Source : The source fetched by the security() calls.
• Timeframe : The timeframe used for the security() calls. If it is lower than the chart's timeframe, a warning appears.
• Show timeframe reminder : Displays a reminder of the timeframe after the last bar.
█ THE CHART
The chart shows two different pieces of information and we want to discuss other topics in this section, so we will be covering:
A — The type of chart bars we are looking at, indicated by the colored band at the top.
B — The plots resulting of calling security() with the close price in different ways.
C — Points of interest on the chart.
A — Chart bars
The colored band at the top shows the three types of bars that any chart on a live market will print. It is critical for coders to understand the important distinctions between each type of bar:
1 — Gray : Historical bars, which are bars that were already closed when the script was run on them.
2 — Red : Elapsed realtime bars, i.e., realtime bars that have run their course and closed.
The state of script calculations showing on those bars is that of the last time they were made, when the realtime bar closed.
3 — Green : The realtime bar. Only the rightmost bar on the chart can be the realtime bar at any given time, and only when the chart's market is active.
Refer to the Pine User Manual's Execution model page for a more detailed explanation of these types of bars.
B — Plots
The chart shows the result of letting our 5sec chart run for a few minutes with the following settings: "Repaint" = "On" (the default is "Off"), "Source" = `close` and "Timeframe" = 1min. The five lines plotted are the following. They have progressively thinner widths:
1 — Yellow : A normal, repainting security() call.
2 — Silver : Our recommended security() function.
3 — Fuchsia : Our recommended way of achieving the same result as our security() function, for cases when the source used is a function returning a tuple.
4 — White : The method we previously recommended in our MTF Selection Framework , which uses two distinct security() calls.
5 — Black : A lame attempt at fooling traders that MUST be avoided.
All lines except the first one in yellow will vary depending on the "Repaint" setting in the script's inputs. The first plot does not change because, contrary to all other plots, it contains no conditional code to adapt to repainting/no-repainting modes; it is a simple security() call showing its default behavior.
C — Points of interest on the chart
Historical bars do not show actual repainting behavior
To appreciate what a repainting security() call will plot in realtime, one must look at the realtime bar and at elapsed realtime bars, the bars where the top line is green or red on the chart at the top of this page. There you can see how the plots go up and down, following the close value of each successive chart bar making up a single bar of the higher timeframe. You would see the same behavior in "Replay" mode. In the realtime bar, the movement of repainting plots will vary with the source you are fetching: open will not move after a new timeframe opens, low and high will change when a new low or high are found, close will follow the last feed update. If you are fetching a value calculated by a function, it may also change on each update.
Now notice how different the plots are on historical bars. There, the plot shows the close of the previously completed timeframe for the whole duration of the current timeframe, until on its last bar the price updates to the current timeframe's close when it is confirmed (if the timeframe's last bar is missing, the plot will only update on the next timeframe's first bar). That last bar is the only one showing where the plot would end if that timeframe's bars had elapsed in realtime. If one doesn't understand this, one cannot properly visualize how his script will calculate in realtime when using repainting. Additionally, as published scripts typically show charts where the script has only run on historical bars, they are, in fact, misleading traders who will naturally assume the script will behave the same way on realtime bars.
Non-repainting plots are more accurate on historical bars
Now consider this chart, where we are using the same settings as on the chart used to publish this script, except that we have turned "Repainting" off this time:
The yellow line here is our reference, repainting line, so although repainting is turned off, it is still repainting, as expected. Because repainting is now off, however, plots on historical bars show the previous timeframe's close until the first bar of a new timeframe, at which point the plot updates. This correctly reflects the behavior of the script in the realtime bar, where because we are offsetting the series by one, we are always showing the previously calculated—and thus confirmed—higher timeframe value. This means that in realtime, we will only get the previous timeframe's values one bar after the timeframe's last bar has elapsed, at the open of the first bar of a new timeframe. Historical and elapsed realtime bars will not actually show this nuance because they reflect the state of calculations made on their close , but we can see the plot update on that bar nonetheless.
► This more accurate representation on historical bars of what will happen in the realtime bar is one of the two key reasons why using non-repainting data is preferable.
The other is that in realtime, your script will be using more reliable data and behave more consistently.
Misleading plots
Valiant attempts by coders to show non-repainting, higher timeframe data updating earlier than on our chart are futile. If updates occur one bar earlier because coders use the repainting version of the function, then so be it, but they must then also accept that their historical bars are not displaying information that is as accurate. Not informing script users of this is to mislead them. Coders should also be aware that if they choose to use repainting data in realtime, they are sacrificing reliability to speed and may be running a strategy that behaves very differently from the one they backtested, thus invalidating their tests.
When, however, coders make what are supposed to be non-repainting plots plot artificially early on historical bars, as in examples "c4" and "c5" of our script, they would want us to believe they have achieved the miracle of time travel. Our understanding of the current state of science dictates that for now, this is impossible. Using such techniques in scripts is plainly misleading, and public scripts using them will be moderated. We are coding trading tools here—not video games. Elementary ethics prescribe that we should not mislead traders, even if it means not being able to show sexy plots. As the great Feynman said: You should not fool the layman when you're talking as a scientist.
You can readily appreciate the fantasy plot of "c4", the thinnest line in black, by comparing its supposedly non-repainting behavior between historical bars and realtime bars. After updating—by miracle—as early as the wide yellow line that is repainting, it suddenly moves in a more realistic place when the script is running in realtime, in synch with our non-repainting lines. The "c5" version does not plot on the chart, but it displays in the Data Window. It is even worse than "c4" in that it also updates magically early on historical bars, but goes on to evaluate like the repainting yellow line in realtime, except one bar late.
Data Window
The Data Window shows the values of the chart's plots, then the values of both the inside and outside offsets used in our calculations, so you can see them change bar by bar. Notice their differences between historical and elapsed realtime bars, and the realtime bar itself. If you do not know about the Data Window, have a look at this essential tool for Pine coders in the Pine User Manual's page on Debugging . The conditional expressions used to calculate the offsets may seem tortuous but their objective is quite simple. When repainting is on, we use this form, so with no offset on all bars:
security(ticker, i_timeframe, i_source )
// which is equivalent to:
security(ticker, i_timeframe, i_source)
When repainting is off, we use two different and inverted offsets on historical bars and the realtime bar:
// Historical bars:
security(ticker, i_timeframe, i_source )
// Realtime bar (and thus, elapsed realtime bars):
security(ticker, i_timeframe, i_source )
The offsets in the first line show how we prevent repainting on historical bars without the need for the `lookahead` parameter. We use the value of the function call on the chart's previous bar. Since values between the repainting and non-repainting versions only differ on the timeframe's last bar, we can use the previous value so that the update only occurs on the timeframe's first bar, as it will in realtime when not repainting.
In the realtime bar, we use the second call, where the offsets are inverted. This is because if we used the first call in realtime, we would be fetching the value of the repainting function on the previous bar, so the close of the last bar. What we want, instead, is the data from the previous, higher timeframe bar , which has elapsed and is confirmed, and thus will not change throughout realtime bars, except on the first constituent chart bar belonging to a new higher timeframe.
After the offsets, the Data Window shows values for the `barstate.*` variables we use in our calculations.
█ NOTES
Why are we revisiting security() ?
For four reasons:
1 — We were seeing coders misuse our `f_secureSecurity()` function presented in How to avoid repainting when using security() .
Some novice coders were modifying the offset used with the history-referencing operator in the function, making it zero instead of one,
which to our horror, caused look-ahead bias when used with `lookahead = barmerge.lookahead_on`.
We wanted to present a safer function which avoids introducing the dreaded "lookahead" in the scripts of unsuspecting coders.
2 — The popularity of security() in screener-type scripts where coders need to use the full 40 calls allowed per script made us want to propose
a solid method of allowing coders to offer a repainting/no-repainting choice to their script users with only one security() call.
3 — We wanted to explain why some alternatives we see circulating are inadequate and produce misleading behavior.
4 — Our previous publication on security() focused on how to avoid repainting, yet many other considerations worthy of attention are not related to repainting.
Handling tuples
When sending function calls that return tuples with security() , our `f_security()` function will not work because Pine does not allow us to use the history-referencing operator with tuple return values. The solution is to integrate the inside offset to your function's arguments, use it to offset the results the function is returning, and then add the outside offset in a reassignment of the tuple variables, after security() returns its values to the script, as we do in our "c2" example.
Does it repaint?
We're pretty sure Wilder was not asked very often if RSI repainted. Why? Because it wasn't in fashion—and largely unnecessary—to ask that sort of question in the 80's. Many traders back then used daily charts only, and indicator values were calculated at the day's close, so everybody knew what they were getting. Additionally, indicator values were calculated by generally reputable outfits or traders themselves, so data was pretty reliable. Today, almost anybody can write a simple indicator, and the programming languages used to write them are complex enough for some coders lacking the caution, know-how or ethics of the best professional coders, to get in over their heads and produce code that does not work the way they think it does.
As we hope to have clearly demonstrated, traders do have legitimate cause to ask if MTF scripts repaint or not when authors do not specify it in their script's description.
► We recommend that authors always use our `f_security()` with `false` as the last argument to avoid repainting when fetching data dependent on OHLCV information. This is the only way to obtain reliable HTF data. If you want to offer users a choice, make non-repainting mode the default, so that if users choose repainting, it will be their responsibility. Non-repainting security() calls are also the only way for scripts to show historical behavior that matches the script's realtime behavior, so you are not misleading traders. Additionally, non-repainting HTF data is the only way that non-repainting alerts can be configured on MTF scripts, as users of MTF scripts cannot prevent their alerts from repainting by simply configuring them to trigger on the bar's close.
Data feeds
A chart at one timeframe is made up of multiple feeds that mesh seamlessly to form one chart. Historical bars can use one feed, and the realtime bar another, which brokers/exchanges can sometimes update retroactively so that elapsed realtime bars will reappear with very slight modifications when the browser's tab is refreshed. Intraday and daily chart prices also very often originate from different feeds supplied by brokers/exchanges. That is why security() calls at higher timeframes may be using a completely different feed than the chart, and explains why the daily high value, for example, can vary between timeframes. Volume information can also vary considerably between intraday and daily feeds in markets like stocks, because more volume information becomes available at the end of day. It is thus expected behavior—and not a bug—to see data variations between timeframes.
Another point to keep in mind concerning feeds it that when you are using a repainting security() plot in realtime, you will sometimes see discrepancies between its plot and the realtime bars. An artefact revealing these inconsistencies can be seen when security() plots sometimes skip a realtime chart bar during periods of high market activity. This occurs because of races between the chart and the security() feeds, which are being monitored by independent, concurrent processes. A blue arrow on the chart indicates such an occurrence. This is another cause of repainting, where realtime bar-building logic can produce different outcomes on one closing price. It is also another argument supporting our recommendation to use non-repainting data.
Alternatives
There is an alternative to using security() in some conditions. If all you need are OHLC prices of a higher timeframe, you can use a technique like the one Duyck demonstrates in his security free MTF example - JD script. It has the great advantage of displaying actual repainting values on historical bars, which mimic the code's behavior in the realtime bar—or at least on elapsed realtime bars, contrary to a repainting security() plot. It has the disadvantage of using the current chart's TF data feed prices, whereas higher timeframe data feeds may contain different and more reliable prices when they are compiled at the end of the day. In its current state, it also does not allow for a repainting/no-repainting choice.
When `lookahead` is useful
When retrieving non-price data, or in special cases, for experiments, it can be useful to use `lookahead`. One example is our Backtesting on Non-Standard Charts: Caution! script where we are fetching prices of standard chart bars from non-standard charts.
Warning users
Normal use of security() dictates that it only be used at timeframes equal to or higher than the chart's. To prevent users from inadvertently using your script in contexts where it will not produce expected behavior, it is good practice to warn them when their chart is on a higher timeframe than the one in the script's "Timeframe" field. Our `f_tfReminderAndErrorCheck()` function in this script does that. It can also print a reminder of the higher timeframe. It uses one security() call.
Intrabar timeframes
security() is not supported by TradingView when used with timeframes lower than the chart's. While it is still possible to use security() at intrabar timeframes, it then behaves differently. If no care is taken to send a function specifically written to handle the successive intrabars, security() will return the value of the last intrabar in the chart's timeframe, so the last 1H bar in the current 1D bar, if called at "60" from a "D" chart timeframe. If you are an advanced coder, see our FAQ entry on the techniques involved in processing intrabar timeframes. Using intrabar timeframes comes with important limitations, which you must understand and explain to traders if you choose to make scripts using the technique available to others. Special care should also be taken to thoroughly test this type of script. Novice coders should refrain from getting involved in this.
█ TERMINOLOGY
Timeframe
Timeframe , interval and resolution are all being used to name the concept of timeframe. We have, in the past, used "timeframe" and "resolution" more or less interchangeably. Recently, members from the Pine and PineCoders team have decided to settle on "timeframe", so from hereon we will be sticking to that term.
Multi-timeframe (MTF)
Some coders use "multi-timeframe" or "MTF" to name what are in fact "multi-period" calculations, as when they use MAs of progressively longer periods. We consider that a misleading use of "multi-timeframe", which should be reserved for code using calculations actually made from another timeframe's context and using security() , safe for scripts like Duyck's one mentioned earlier, or TradingView's Relative Volume at Time , which use a user-selected timeframe as an anchor to reset calculations. Calculations made at the chart's timeframe by varying the period of MAs or other rolling window calculations should be called "multi-period", and "MTF-anchored" could be used for scripts that reset calculations on timeframe boundaries.
Colophon
Our script was written using the PineCoders Coding Conventions for Pine .
The description was formatted using the techniques explained in the How We Write and Format Script Descriptions PineCoders publication.
Snippets were lifted from our MTF Selection Framework , then massaged to create the `f_tfReminderAndErrorCheck()` function.
█ THANKS
Thanks to apozdnyakov for his help with the innards of security() .
Thanks to bmistiaen for proofreading our description.
Look first. Then leap.
Volume Based Sampling [BackQuant]Volume Based Sampling
What this does
This indicator converts the usual time-based stream of candles into an event-based stream of “synthetic” bars that are created only when enough trading activity has occurred . You choose the activity definition:
Volume bars : create a new synthetic bar whenever the cumulative number of shares/contracts traded reaches a threshold.
Dollar bars : create a new synthetic bar whenever the cumulative traded dollar value (price × volume) reaches a threshold.
The script then keeps an internal ledger of these synthetic opens, highs, lows, closes, and volumes, and can display them as candles, plot a moving average calculated over the synthetic closes, mark each time a new sample is formed, and optionally overlay the native time-bars for comparison.
Why event-based sampling matters
Markets do not release information on a clock: activity clusters during news, opens/closes, and liquidity shocks. Event-based bars normalize for that heteroskedastic arrival of information: during active periods you get more bars (finer resolution); during quiet periods you get fewer bars (coarser resolution). Research shows this can reduce microstructure pathologies and produce series that are closer to i.i.d. and more suitable for statistical modeling and ML. In particular:
Volume and dollar bars are a common event-time alternative to time bars in quantitative research and are discussed extensively in Advances in Financial Machine Learning (AFML). These bars aim to homogenize information flow by sampling on traded size or value rather than elapsed seconds.
The Volume Clock perspective models market activity in “volume time,” showing that many intraday phenomena (volatility, liquidity shocks) are better explained when time is measured by traded volume instead of seconds.
Related market microstructure work on flow toxicity and liquidity highlights that the risk dealers face is tied to information intensity of order flow, again arguing for activity-based clocks.
How the indicator works (plain English)
Choose your bucket type
Volume : accumulate volume until it meets a threshold.
Dollar Bars : accumulate close × volume until it meets a dollar threshold.
Pick the threshold rule
Dynamic threshold : by default, the script computes a rolling statistic (mean or median) of recent activity to set the next bucket size. This adapts bar size to changing conditions (e.g., busier sessions produce more frequent synthetic bars).
Fixed threshold : optionally override with a constant target (e.g., exactly 100,000 contracts per synthetic bar, or $5,000,000 per dollar bar).
Build the synthetic bar
While a bucket fills, the script tracks:
o_s: first price of the bucket (synthetic open)
h_s: running maximum price (synthetic high)
l_s: running minimum price (synthetic low)
c_s: last price seen (synthetic close)
v_s: cumulative native volume inside the bucket
d_samples: number of native bars consumed to complete the bucket (a proxy for “how fast” the threshold filled)
Emit a new sample
Once the bucket meets/exceeds the threshold, a new synthetic bar is finalized and stored. If overflow occurs (e.g., a single native bar pushes you past the threshold by a lot), the code will emit multiple synthetic samples to account for the extra activity.
Maintain a rolling history efficiently
A ring buffer can overwrite the oldest samples when you hit your Max Stored Samples cap, keeping memory usage stable.
Compute synthetic-space statistics
The script computes an SMA over the last N synthetic closes and basic descriptors like average bars per synthetic sample, mean and standard deviation of synthetic returns, and more. These are all in event time , not clock time.
Inputs and options you will actually use
Data Settings
Sampling Method : Volume or Dollar Bars.
Rolling Lookback : window used to estimate the dynamic threshold from recent activity.
Filter : Mean or Median for the dynamic threshold. Median is more robust to spikes.
Use Fixed? / Fixed Threshold : override dynamic sizing with a constant target.
Max Stored Samples : cap on synthetic history to keep performance snappy.
Use Ring Buffer : turn on to recycle storage when at capacity.
Indicator Settings
SMA over last N samples : moving average in synthetic space . Because its index is sample count, not minutes, it adapts naturally: more updates in busy regimes, fewer in quiet regimes.
Visuals
Show Synthetic Bars : plot the synthetic OHLC candles.
Candle Color Mode :
Green/Red: directional close vs open
Volume Intensity: opacity scales with synthetic size
Neutral: single color
Adaptive: graded by how large the bucket was relative to threshold
Mark new samples : drop a small marker whenever a new synthetic bar prints.
Comparison & Research
Show Time Bars : overlay the native time-based candles to visually compare how the two sampling schemes differ.
How to read it, step by step
Turn on “Synthetic Bars” and optionally overlay “Time Bars.” You will see that during high-activity bursts, synthetic bars print much faster than time bars.
Watch the synthetic SMA . Crosses in synthetic space can be more meaningful because each update represents a roughly comparable amount of traded information.
Use the “Avg Bars per Sample” in the info table as a regime signal. Falling average bars per sample means activity is clustering, often coincident with higher realized volatility.
Try Dollar Bars when price varies a lot but share count does not; they normalize by dollar risk taken in each sample. Volume Bars are ideal when share count is a better proxy for information flow in your instrument.
Quant finance background and citations
Event time vs. clock time : Easley, López de Prado, and O’Hara advocate measuring intraday phenomena on a volume clock to better align sampling with information arrival. This framing helps explain volatility bursts and liquidity droughts and motivates volume-based bars.
Flow toxicity and dealer risk : The same authors show how adverse selection risk changes with the intensity and informativeness of order flow, further supporting activity-based clocks for modeling and risk management.
AFML framework : In Advances in Financial Machine Learning , event-driven bars such as volume, dollar, and imbalance bars are presented as superior sampling units for many ML tasks, yielding more stationary features and fewer microstructure distortions than fixed time bars. ( Alpaca )
Practical use cases
1) Regime-aware moving averages
The synthetic SMA in event time is not fooled by quiet periods: if nothing of consequence trades, it barely updates. This can make trend filters less sensitive to calendar drift and more sensitive to true participation.
2) Breakout logic on “equal-information” samples
The script exposes simple alerts such as breakout above/below the synthetic SMA . Because each bar approximates a constant amount of activity, breakouts are conditioned on comparable informational mass, not arbitrary time buckets.
3) Volatility-adaptive backtests
If you use synthetic bars as your base data stream, most signal rules become self-paced : entry and exit opportunities accelerate in fast markets and slow down in quiet regimes, which often improves the realism of slippage and fill modeling in research pipelines (pair this indicator with strategy code downstream).
4) Regime diagnostics
Avg Bars per Sample trending down: activity is dense; expect larger realized ranges.
Return StdDev (synthetic) rising: noise or trend acceleration in event time; re-tune risk.
Interpreting the info panel
Method : your sampling choice and current threshold.
Total Samples : how many synthetic bars have been formed.
Current Vol/Dollar : how much of the next bucket is already filled.
Bars in Bucket : native bars consumed so far in the current bucket.
Avg Bars/Sample : lower means higher trading intensity.
Avg Return / Return StdDev : return stats computed over synthetic closes .
Research directions you can build from here
Imbalance and run bars
Extend beyond pure volume or dollar thresholds to imbalance bars that trigger on directional order flow imbalance (e.g., buy volume minus sell volume), as discussed in the AFML ecosystem. These often further homogenize distributional properties used in ML. alpaca.markets
Volume-time indicators
Re-compute classical indicators (RSI, MACD, Bollinger) on the synthetic stream. The premise is that signals are updated by traded information , not seconds, which may stabilize indicator behavior in heteroskedastic regimes.
Liquidity and toxicity overlays
Combine synthetic bars with proxies of flow toxicity to anticipate spread widening or volatility clustering. For instance, tag synthetic bars that surpass multiples of the threshold and test whether subsequent realized volatility is elevated.
Dollar-risk parity sampling for portfolios
Use dollar bars to align samples across assets by notional risk, enabling cleaner cross-asset features and comparability in multi-asset models (e.g., correlation studies, regime clustering). AFML discusses the benefits of event-driven sampling for cross-sectional ML feature engineering.
Microstructure feature set
Compute duration in native bars per synthetic sample , range per sample , and volume multiple of threshold as inputs to state classifiers or regime HMMs . These features are inherently activity-aware and often predictive of short-horizon volatility and trend persistence per the event-time literature. ( Alpaca )
Tips for clean usage
Start with dynamic thresholds using Median over a sensible lookback to avoid outlier distortion, then move to Fixed thresholds when you know your instrument’s typical activity scale.
Compare time bars vs synthetic bars side by side to develop intuition for how your market “breathes” in activity time.
Keep Max Stored Samples reasonable for performance; the ring buffer avoids memory creep while preserving a rolling window of research-grade data.
Screener based on Profitunity strategy for multiple timeframes
Screener based on Profitunity strategy by Bill Williams for multiple timeframes (max 5, including chart timeframe) and customizable symbol list. The screener analyzes the Alligator and Awesome Oscillator indicators, Divergent bars and high volume bars.
The maximum allowed number of requests (symbols and timeframes) is limited to 40 requests, for example, for 10 symbols by 4 requests of different timeframes. Therefore, the indicator automatically limits the number of displayed symbols depending on the number of timeframes for each symbol, if there are more symbols than are displayed in the screener table, then the ordinal numbers are displayed to the left of the symbols, in this case you can display the next group of symbols by increasing the value by 1 in the "Show tickers from" field, if the "Group" field is enabled, or specify the symbol number by 1 more than the last symbol in the screener table. 👀 When timeframe filtering is applied, the screener table displays only the columns of those timeframes for which the filtering value is selected, which allows displaying more symbols.
For each timeframe, in the "TIMEFRAMES > Prev" field, you can enable the display of data for the previous bar relative to the last (current) one, if the market is open for the requested symbol. In the "TIMEFRAMES > Y" field, you can enable filtering depending on the location of the last five bars relative to the Alligator indicator lines, which are designated by special symbols in the screener table:
⬆️ — if the Alligator is open upwards (Lips > Teeth > Jaw) and none of the bars is closed below the Lips line;
↗️ — if one of the bars, except for the penultimate one, is closed below Lips, or two bars, except for the last one, are closed below Lips, or the Alligator is open upwards only below four bars, but none of the bars is closed below Lips;
⬇️ — if the Alligator is open downwards (Lips < Teeth < Jaw), but none of the bars is closed above Lips;
↘️ — if one of the bars, except the penultimate one, is closed above the Lips, or two bars, except the last one, are closed above the Lips, or the Alligator is open down only above four bars, but none of the bars are closed above the Lips;
➡️ — in other cases, including when the Alligator lines intersect and one of the bars is closed behind the Lips line or two bars intersect one of the Alligator lines.
In the "TIMEFRAMES > Show bar change value for TF" field, you can add a column to the right of the selected timeframe column with the percentage change between the closing price of the last bar (current) and the closing price of the previous bar ((close – previous close) / previous close * 100). Depending on the percentage value, the background color of the screener table cell will change: dark red if <= -3%; red if <= -2%, light red if <= -0.5%; dark green if >= 3%; green if >= 2%; light green if >= 0.5%.
For each timeframe, the screener table displays the symbol of the latest (current) bar, depending on the closing price relative to the bar's midpoint ((high + low) / 2) and its location relative to the Alligator indicator lines: ⎾ — the bar's closing price is above its midpoint; ⎿ — the bar's closing price is below its midpoint; ├ — the bar's closing price is equal to its midpoint; 🟢 — Bullish Divergent bar, i.e. the bar's closing price is above its midpoint, the bar's high is below all Alligator lines, the bar's low is below the previous bar's low; 🔴 — Bearish Divergent bar, i.e. the bar's closing price is below its midpoint, the bar's low is above all Alligator lines, the bar's high is above the previous bar's high. When filtering is enabled in the "TIMEFRAMES > Filtering by Divergent bar" field, the data in the screener table cells will be displayed only for those timeframes that have a Divergent bar. A high bar volume signal is also displayed — 📶/📶² if the bar volume is greater than 40%/70% of the average volume value calculated using a simple moving average (SMA) in the 140 bar interval from the last bar.
In the indicator settings in the "SYMBOL LIST" field, each ticker (for example: OANDA:SPX500USD) must be on a separate line. If the market is closed, then the data for requested symbols will be limited to the time of the last (current) bar on the chart, for example, if the current symbol was traded yesterday, and the requested symbol is traded today, when requesting data for an hourly timeframe, the last bar will be for yesterday, if the timeframe of the current chart is not higher than 1 day. Therefore, by default, a warning will be displayed on the chart instead of the screener table that if the market is open, you must wait for the screener to load (after the first price change on the current chart), or if the highest timeframe in the screener is 1 day, you will be prompted to change the timeframe on the current chart to 1 week, if the screener requests data for the timeframe of 1 week, you will be prompted to change the timeframe on the current chart to 1 month, or switch to another symbol on the current chart for which the market is open (for example: BINANCE:BTCUSDT), or disable the warning in the field "SYMBOL LIST > Do not display screener if market is close".
The number of the last columns with the color of the AO indicator that will be displayed in the screener table for each timeframe is specified in the indicator settings in the "AWESOME OSCILLATOR > Number of columns" field.
For each timeframe, the direction of the trend between the price of the highest and lowest bars in the specified range of bars from the last bar is displayed — ↑ if the trend is up (the highest bar is to the right of the lowest), or ↓ if the trend is down (the lowest bar is to the right of the highest). If there is a divergence on the AO indicator in the specified interval, the symbol ∇ is also displayed. The average volume value is also calculated in the specified interval using a simple moving average (SMA). The number of bars is set in the indicator settings in the "INTERVAL FOR HIGHEST AND LOWEST BARS > Bars count" field.
In the indicator settings in the "STYLE" field you can change the position of the screener table relative to the chart window, the background color, the color and size of the text.
***
Скринер на основе стратегии Profitunity Билла Вильямса для нескольких таймфреймов (максимум 5, включая таймфрейм графика) и настраиваемого списка символов. Скринер анализирует индикаторы Alligator и Awesome Oscillator, Дивергентные бары и бары с высоким объемом.
Максимально допустимое количество запросов (символы и таймфреймы) ограничено 40 запросами, например, для 10 символов по 4 запроса разных таймфреймов. Поэтому в индикаторе автоматически ограничивается количество отображаемых символов в зависимости от количества таймфреймов для каждого символа, если символов больше чем отображено в таблице скринера, то слева от символов отображаются порядковые номера, в таком случае можно отобразить следующую группу символов, увеличив значение на 1 в настройках индикатора поле "Show tickers from", если включено поле "Group", или указать номер символа на 1 больше, чем последний символ в таблице скринера. 👀 Когда применяется фильтрация по таймфрейму, в таблице скринера отображаются только столбцы тех таймфреймов, для которых выбрано значение фильтрации, что позволяет отображать большее количество символов.
Для каждого таймфрейма в настройках индикатора в поле "TIMEFRAMES > Prev" можно включить отображение данных для предыдущего бара относительно последнего (текущего), если для запрашиваемого символа рынок открыт. В поле "TIMEFRAMES > Y" можно включить фильтрацию, в зависимости от расположения последних пяти баров относительно линий индикатора Alligator, которые обозначаются специальными символами в таблице скринера:
⬆️ — если Alligator открыт вверх (Lips > Teeth > Jaw) и ни один из баров не закрыт ниже линии Lips;
↗️ — если один из баров, кроме предпоследнего, закрыт ниже Lips, или два бара, кроме последнего, закрыты ниже Lips, или Alligator открыт вверх только ниже четырех баров, но ни один из баров не закрыт ниже Lips;
⬇️ — если Alligator открыт вниз (Lips < Teeth < Jaw), но ни один из баров не закрыт выше Lips;
↘️ — если один из баров, кроме предпоследнего, закрыт выше Lips, или два бара, кроме последнего, закрыты выше Lips, или Alligator открыт вниз только выше четырех баров, но ни один из баров не закрыт выше Lips;
➡️ — в остальных случаях, в то числе когда линии Alligator пересекаются и один из баров закрыт за линией Lips или два бара пересекают одну из линий Alligator.
В поле "TIMEFRAMES > Show bar change value for TF" можно добавить справа от выбранного столбца таймфрейма столбец с процентным изменением между ценой закрытия последнего бара (текущего) и ценой закрытия предыдущего бара ((close – previous close) / previous close * 100). В зависимости от величины процента будет меняться цвет фона ячейки таблицы скринера: темно-красный, если <= -3%; красный, если <= -2%, светло-красный, если <= -0.5%; темно-зеленый, если >= 3%; зеленый, если >= 2%; светло-зеленый, если >= 0.5%.
Для каждого таймфрейма в таблице скринера отображается символ последнего (текущего) бара, в зависимости от цены закрытия относительно середины бара ((high + low) / 2) и расположения относительно линий индикатора Alligator: ⎾ — цена закрытия бара выше его середины; ⎿ — цена закрытия бара ниже его середины; ├ — цена закрытия бара равна его середине; 🟢 — Бычий Дивергентный бар, т.е. цена закрытия бара выше его середины, максимум бара ниже всех линий Alligator, минимум бара ниже минимума предыдущего бара; 🔴 — Медвежий Дивергентный бар, т.е. цена закрытия бара ниже его середины, минимум бара выше всех линий Alligator, максимум бара выше максимума предыдущего бара. При включении фильтрации в поле "TIMEFRAMES > Filtering by Divergent bar" данные в ячейках таблицы скринера будут отображаться только для тех таймфреймов, где есть Дивергентный бар. Также отображается сигнал высокого объема бара — 📶/📶², если объем бара больше чем на 40%/70% среднего значения объема, рассчитанного с помощью простой скользящей средней (SMA) в интервале 140 баров от последнего бара.
В настройках индикатора в поле "SYMBOL LIST" каждый тикер (например: OANDA:SPX500USD) должен быть на отдельной строке. Если рынок закрыт, то данные для запрашиваемых символов будут ограничены временем последнего (текущего) бара на графике, например, если текущий символ торговался последний день вчера, а запрашиваемый символ торгуется сегодня, при запросе данных для часового таймфрейма, последний бар будет за вчерашний день, если таймфрейм текущего графика не выше 1 дня. Поэтому по умолчанию на графике будет отображаться предупреждение вместо таблицы скринера о том, что если рынок открыт, то необходимо дождаться загрузки скринера (после первого изменения цены на текущем графике), или если в скринере самый высокий таймфрейм 1 день, то будет предложено изменить на текущем графике таймфрейм на 1 неделю, если в скринере запрашиваются данные для таймфрейма 1 неделя, то будет предложено изменить на текущем графике таймфрейм на 1 месяц, или же переключиться на другой символ на текущем графике, для которого рынок открыт (например: BINANCE:BTCUSDT), или отключить предупреждение в поле "SYMBOL LIST > Do not display screener if market is close".
Количество последних столбцов с цветом индикатора AO, которые будут отображены в таблице скринера для каждого таймфрейма, указывается в настройках индикатора в поле "AWESOME OSCILLATOR > Number of columns".
Для каждого таймфрейма отображается направление тренда между ценой самого высокого и самого низкого баров в указанном интервале баров от последнего бара — ↑, если тренд направлен вверх (самый высокий бар справа от самого низкого), или ↓, если тренд направлен вниз (самый низкий бар справа от самого высокого). Если есть дивергенция на индикаторе AO в указанном интервале, то также отображается символ — ∇. В указанном интервале также рассчитывается среднее значение объема с помощью простой скользящей средней (SMA). Количество баров устанавливается в настройках индикатора в поле "INTERVAL FOR HIGHEST AND LOWEST BARS > Bars count".
В настройках индикатора в поле "STYLE" можно изменить положение таблицы скринера относительно окна графика, цвет фона, цвет и размер текста.
