Indicators and strategies

Equalhigh JAPANESE TRIPLE RCI EQUALHIGH — JAPANESE TRIPLE RCI 9/26/52 OVERVIEW This indicator implements the triple Rank Correlation Index configuration commonly used in Japanese technical analysis. It combines three RCI horizons: • RCI 9 — short-term momentum • RCI 26 — swing direction • RCI 52 — underlying trend Unlike RSI, RCI does not primarily measure the magnitude of price changes. It measures how closely the chronological order of the bars corresponds to the ranked order of their prices. The indicator is designed to identify: • Progressive market reversals • Momentum recoveries after pullbacks • Bullish or bearish multi-horizon alignment • Trend deterioration • Choppy and conflicting market conditions CALCULATION RCI is based on Spearman’s rank correlation between: 1. The chronological rank of each bar 2. The price rank of each bar The result is scaled from −100 to +100. • +100 indicates a perfectly ordered upward movement. • −100 indicates a perfectly ordered downward movement. • Values near zero indicate weak directional organization or conflicting price action. This implementation calculates the full Spearman rank correlation and assigns an average rank to tied prices. INDICATOR LINES CYAN — RCI 9: SHORT-TERM IMPULSE RCI 9 reacts quickly to changes in momentum. It is useful for detecting early rebounds, short-term exhaustion and the first phase of a possible reversal. ORANGE — RCI 26: SWING DIRECTION RCI 26 confirms whether the short-term movement is developing into a more meaningful swing. PURPLE — RCI 52: UNDERLYING TREND RCI 52 is the slowest component. It represents the broader directional structure and acts as the main trend filter. KEY LEVELS +80: Upper extreme zone +50: Strong positive momentum 0: Directional equilibrium −50: Strong negative momentum −80: Lower extreme zone An extreme RCI reading does not automatically mean that price must reverse. A strong trend can keep the RCI near +80 or −80 for an extended period. SIGNALS R+ — EARLY BULLISH REVERSAL An R+ signal appears when: • RCI 9 crosses upward out of the lower extreme zone • RCI 26 is already rising This identifies an early improvement in price organization. It is not a complete trend confirmation and should ideally be supported by price action, volume or a support level. R− — EARLY BEARISH REVERSAL An R− signal appears when: • RCI 9 crosses downward out of the upper extreme zone • RCI 26 is already falling This indicates early deterioration in short-term momentum. A+ — NEW BULLISH ALIGNMENT An A+ signal appears when RCI 9, RCI 26 and RCI 52 become positive simultaneously. This confirms that short-term momentum, the swing structure and the underlying trend are all on the bullish side of equilibrium. A− — NEW BEARISH ALIGNMENT An A− signal appears when all three RCI horizons become negative simultaneously. This confirms bearish alignment across the three observed time horizons. PRACTICAL INTERPRETATION STRONG BULLISH REGIME • RCI 52 is above zero • RCI 26 is above zero or recovering • RCI 9 moves out of a temporary pullback • An R+ or A+ signal is supported by bullish price action STRONG BEARISH REGIME • RCI 52 is below zero • RCI 26 is below zero or deteriorating • RCI 9 turns down after a temporary recovery • An R− or A− signal is supported by bearish price action POSSIBLE PROGRESSIVE REVERSAL A bullish reversal often develops in stages: 1. RCI 9 turns upward 2. RCI 26 begins to recover 3. RCI 52 stabilizes or turns upward 4. All three RCIs eventually move above zero The bearish sequence is the opposite. CHOPPY OR LOW-CONVICTION MARKET When the three lines repeatedly cross each other around zero, the market lacks a stable directional structure. Trend-following signals are generally less reliable in this environment. SUGGESTED WORKFLOW FOR SWING TRADING For a potential long setup: 1. Confirm that price is near support or breaking above resistance. 2. Look for an R+ early reversal signal. 3. Check that RCI 26 is rising. 4. Prefer situations where RCI 52 is positive, stabilizing or improving. 5. Use A+ as stronger multi-horizon confirmation. 6. Define risk with price structure or an ATR-based stop. For a potential short setup, apply the opposite conditions. DEFAULT SETTINGS • Short RCI: 9 • Medium RCI: 26 • Long RCI: 52 • Source: Close • Extreme level: 80 • Reversal trigger: 80 • Signal confirmation: Bar close The default 9/26/52 configuration is suitable for swing analysis on daily and four-hour charts. Because the periods represent bars, their actual duration changes with the selected timeframe. USER SETTINGS RCI Short Controls the sensitivity of short-term momentum. A lower value reacts faster but produces more noise. RCI Medium Represents the intermediate swing structure. RCI Long Acts as the broader trend filter. Higher values provide a slower and more stable reading. Extreme Level Defines the upper and lower visual zones. The default setting is +80 and −80. Reversal Trigger Determines the level used to generate early R+ and R− reversal signals. Confirm Only at Bar Close When enabled, signals are validated only after the current candle closes. This helps prevent temporary intrabar signals. Show Early Reversals Displays the R+ and R− markers. Show 9/26/52 Alignments Displays the A+ and A− markers. Shade Extreme Zones Highlights the upper and lower RCI extreme areas. Shade Background by Alignment Optionally colors the indicator background according to bullish or bearish triple alignment. ALERTS Four PulseWire alert conditions are included: • RCI — Early Bullish Reversal • RCI — Early Bearish Reversal • RCI — New Bullish Alignment • RCI — New Bearish Alignment For more stable signals, alerts should normally be configured “Once Per Bar Close.” REPAINTING BEHAVIOR The indicator uses only current and historical price data. It does not use future bars. RCI values can naturally change while the current candle is still forming. When “Confirm Only at Bar Close” is enabled, signal markers and alerts are confirmed at the candle close and do not subsequently repaint on completed bars. LIMITATIONS RCI is a market-structure and momentum indicator, not a standalone trading system. It does not account for: • Fundamental valuation • Earnings announcements • Liquidity conditions • Volatility regime changes • Support and resistance • Position sizing • Transaction costs Extreme readings should not automatically be interpreted as buy or sell signals. The indicator is most effective when combined with price structure, volume, volatility and disciplined risk management. DISCLAIMER This indicator is provided for educational and analytical purposes only. It does not constitute financial advice or a recommendation to buy or sell any financial instrument. Past performance does not guarantee future results.

Indicator

TRADION Gaussian Trend Engine TRADION Gaussian Trend Engine OVERVIEW TRADION Gaussian Trend Engine is a multi-factor trend analysis framework designed to evaluate market direction, trend strength, momentum alignment and volatility within a unified model. The indicator is built around an independently implemented multi-pole Gaussian cascade. Instead of using Gaussian direction alone as a trading signal, the engine evaluates several additional dimensions of market behavior before qualifying a directional transition. The framework combines: • Configurable multi-pole Gaussian smoothing • ATR-normalized Gaussian slope • Price displacement from the Gaussian baseline • RSI momentum analysis • Rate of Change (ROC) • A composite 0–100 Trend Strength Score • Volatility-adaptive trend ribbons • Three-level BUY / SELL classification • Confirmed-bar signal generation • Dedicated PulseWire alerts The design objective is selective trend qualification rather than generating a signal on every minor directional fluctuation. ──────────────────────────── GAUSSIAN TREND ENGINE ──────────────────────────── The core of the indicator is a configurable multi-pole Gaussian cascade. The user can control two primary parameters: Gaussian Period: Controls the smoothing horizon of the filter. Gaussian Poles: Controls the number of sequential Gaussian smoothing stages used by the engine, from 1 to 6. Each additional pole applies another stage of Gaussian smoothing to the previous output. This architecture provides a configurable balance between responsiveness and noise reduction. The final output of the selected pole becomes the Gaussian trend baseline used by the rest of the engine. ──────────────────────────── TREND DIRECTION ──────────────────────────── Directional state is determined from the slope of the Gaussian baseline. When the current Gaussian value is above its previous value, the engine identifies a bullish directional state. When the current Gaussian value is below its previous value, the engine identifies a bearish directional state. The Gaussian line changes dynamically: Green = Bullish Gaussian direction Red = Bearish Gaussian direction An unchanged Gaussian value preserves the previous directional state. ──────────────────────────── VOLATILITY NORMALIZATION ──────────────────────────── Raw price movement has different significance across instruments and volatility regimes. For this reason, ATR is used as a normalization reference within the engine. Two important measurements are normalized relative to ATR: • Gaussian slope magnitude • Distance between price and the Gaussian baseline This allows the strength model to evaluate movement relative to current market volatility rather than relying only on absolute price changes. ──────────────────────────── TREND STRENGTH SCORE ──────────────────────────── TRADION Gaussian Trend Engine calculates a composite Trend Strength Score ranging from 0 to 100. The score combines four normalized components: 1. Gaussian Slope Strength — 40% 2. Price Distance from Gaussian — 20% 3. RSI Momentum Intensity — 25% 4. ROC Magnitude — 15% Gaussian Slope Strength measures the magnitude of directional movement in the Gaussian baseline relative to ATR. Price Distance measures the absolute displacement of price from the Gaussian baseline relative to ATR. RSI Momentum Intensity measures the distance of RSI from its neutral 50 level. ROC Magnitude measures the absolute velocity of price movement. Each component is normalized before being incorporated into the final weighted score. The result is a single 0–100 metric designed to describe the degree of agreement between trend movement, price expansion and momentum. ──────────────────────────── MOMENTUM CONFIRMATION ──────────────────────────── Momentum confirmation can be enabled or disabled by the user. For bullish confirmation, the default model requires: • RSI above 50 plus the selected Neutral Zone • Positive ROC For bearish confirmation, it requires: • RSI below 50 minus the selected Neutral Zone • Negative ROC This layer prevents every Gaussian slope change from automatically qualifying as a BUY or SELL event. The RSI Neutral Zone is configurable, allowing the user to control how much momentum separation is required around the RSI 50 equilibrium level. ──────────────────────────── DIRECTIONAL QUALIFICATION ──────────────────────────── A qualified bullish setup requires: • Rising Gaussian direction • Price above the Gaussian baseline • Valid bullish momentum when momentum confirmation is enabled • Trend Strength above the configured minimum threshold A qualified bearish setup requires: • Falling Gaussian direction • Price below the Gaussian baseline • Valid bearish momentum when momentum confirmation is enabled • Trend Strength above the configured minimum threshold This means that Gaussian direction, price structure, momentum and trend strength are evaluated together before a directional event is accepted. ──────────────────────────── THREE-LEVEL SIGNAL CLASSIFICATION ──────────────────────────── Qualified transitions are classified according to their Trend Strength Score. Bullish classifications: BUY STRONG BUY EXTREME BUY Bearish classifications: SELL STRONG SELL EXTREME SELL The default thresholds are: Minimum Signal Strength: 25 Strong Signal Threshold: 55 Extreme Signal Threshold: 75 These thresholds are fully configurable. A standard signal represents a qualified directional transition below the Strong threshold. A STRONG signal represents a transition whose Trend Strength reaches the Strong threshold. An EXTREME signal represents a transition whose Trend Strength reaches the highest configured classification threshold. These labels describe the strength of the conditions detected by the model. They are not predictions of future returns. ──────────────────────────── CONFIRMED-BAR SIGNAL ENGINE ──────────────────────────── Signal generation uses confirmed-bar logic. A new directional signal is accepted only when the current chart bar is confirmed. This prevents temporary intrabar conditions from being treated as completed signals before the candle closes. The engine also maintains directional signal state. Once a bullish signal has been generated, another bullish signal is not repeatedly produced while the signal state remains bullish. A new bullish event becomes possible after the engine has transitioned through the opposite qualified state, and vice versa. This creates cleaner transition-based signal behavior. ──────────────────────────── VOLATILITY-ADAPTIVE TREND RIBBON ──────────────────────────── The trend ribbon provides a visual representation of directional state and adaptive market conditions. Its base width is calculated using ATR. The final ribbon width also incorporates the current Trend Strength Score. As calculated trend strength increases, the ribbon can expand according to the user-defined Trend Strength Width Effect. During bullish states, the ribbon is positioned below the Gaussian baseline. During bearish states, the ribbon is positioned above the Gaussian baseline. The ribbon consists of multiple visual layers, creating a clear distinction between the Gaussian baseline and the outer volatility-adjusted trend zone. This makes direction and changes in trend intensity easier to interpret directly from the chart. ──────────────────────────── VISUAL INTERPRETATION ──────────────────────────── GREEN GAUSSIAN / GREEN RIBBON The Gaussian baseline is rising and the engine is operating in a bullish directional regime. RED GAUSSIAN / RED RIBBON The Gaussian baseline is falling and the engine is operating in a bearish directional regime. BUY / SELL A new directional setup has passed the minimum qualification requirements. STRONG BUY / STRONG SELL A qualified transition has reached the configured Strong Trend Strength threshold. EXTREME BUY / EXTREME SELL A qualified transition has reached the configured Extreme Trend Strength threshold. ──────────────────────────── USER CONTROLS ──────────────────────────── Gaussian Engine: • Source • Gaussian Period • Gaussian Poles Momentum Confirmation: • Enable / Disable Momentum Confirmation • RSI Period • ROC Period • RSI Neutral Zone Trend Strength: • ATR Period • Gaussian Slope Sensitivity • Price Distance Sensitivity • Minimum Signal Strength • Strong Signal Threshold • Extreme Signal Threshold Adaptive Trend Ribbon: • Show / Hide Adaptive Trend Ribbon • Ribbon ATR Width • Trend Strength Width Effect Visual Settings: • Show Trading Signals • Color Price Bars • Show Gaussian Trend Line ──────────────────────────── ALERTS ──────────────────────────── Six dedicated PulseWire alert conditions are included: • TRADION BUY • TRADION STRONG BUY • TRADION EXTREME BUY • TRADION SELL • TRADION STRONG SELL • TRADION EXTREME SELL This allows each signal classification to be monitored independently. ──────────────────────────── PRACTICAL USE ──────────────────────────── TRADION Gaussian Trend Engine can be used as: • A directional trend filter • A trend-strength visualization tool • A momentum-confirmed transition detector • A volatility-adaptive trend framework • A confirmation layer for discretionary analysis • An alert-based trend monitoring system Because sensitivity depends on the selected parameters, instrument and timeframe, users should evaluate settings according to their own methodology. Higher sensitivity may detect directional changes earlier but can increase exposure to market noise. Greater smoothing and higher qualification thresholds can reduce signal frequency but may identify transitions later. ──────────────────────────── DESIGN PHILOSOPHY ──────────────────────────── The central idea behind TRADION Gaussian Trend Engine is that trend direction alone provides incomplete information. A rising filter does not necessarily represent a strong trend. For this reason, the engine evaluates four questions: 1. What direction is the Gaussian structure moving? 2. How significant is that movement relative to volatility? 3. Is price positioned consistently with that direction? 4. Does momentum support the directional structure? The Trend Strength model then measures the degree of alignment between these components. This creates a unified framework for analyzing direction, momentum, volatility and trend intensity rather than treating each component as an isolated indicator. ──────────────────────────── IMPORTANT NOTES ──────────────────────────── TRADION Gaussian Trend Engine is an analytical indicator, not a strategy and not a prediction system. BUY, STRONG BUY, EXTREME BUY, SELL, STRONG SELL and EXTREME SELL labels represent mathematical classifications produced by the indicator's current conditions. They do not guarantee future price direction, profitability or trade outcomes. Signals are confirmed at bar close, but confirmed-bar processing does not eliminate normal market risk or signal lag. Users should independently evaluate the indicator and apply appropriate risk management. For research and educational purposes.

Indicator

Market Leadership Structure 3D [NeuralMarkets]OVERVIEW Market Leadership Structure 3D compares six assets to show who is driving the group, who is following, and whether leadership is persistent or rotating. It separates relative rank from absolute evidence. The top-ranked asset is always shown as the relative candidate, but the script reports NO CLEAR LEADER unless that candidate has sufficient evidence, separation from the runner-up, and at least one qualified outgoing relationship. The indicator provides three views: • Summary • Leadership Terrain • Parameter Stability HOW IT WORKS For every asset pair, the model compares both possible lead-lag directions. Directional evidence blends the strongest positive lagged correlation with the average positive correlation across the tested lags. Directional advantage A → B = Evidence A → B − Evidence B → A An edge is retained only when it passes Minimum Forward Evidence and exceeds the reverse direction by Minimum Directional Asymmetry. Qualified edges form a directed network using NeuralMarketsNetworkToolkit: Net influence = Outbound influence − Inbound influence The asset with the highest smoothed net influence receives rank #1. Recognition requires separate absolute-evidence and rank-separation thresholds, so being ranked first does not automatically imply meaningful leadership. READING THE SUMMARY Recognized — The accepted leader or NO CLEAR LEADER. Relative candidate — The asset currently ranked #1, even when evidence is insufficient for recognition. Absolute evidence — Strength and coverage of the candidate’s qualified outgoing relationships. It is not min-maxed and does not force the strongest asset to score 100. Rank separation — Normalized gap between the top two assets. A small gap means leadership is closely contested. Leader persistence — Share of the history window occupied by the current recognized leader. No-clear-leader bars remain separate states. Clear-state share — Percentage of the history window in which any clear leader existed. Rotation risk — LOW, MEDIUM, HIGH, or UNDEFINED when no leader is recognized. Concentration — Whether directional influence is concentrated or broadly distributed. The optional ranking table shows all six assets with net influence, absolute evidence, and normalized leadership. LEADERSHIP TERRAIN The waterfall mesh displays all six assets through recent history: • X-axis: ticker • Depth: historical slices from NOW toward older bars • Height: normalized leadership, approximately −1 to +1 Above zero indicates more outbound than inbound influence. Below zero indicates follower behavior. Each historical ridge is drawn as a colored curtain from the zero plane, while rails connect each ticker through time. Older slices fade to keep the current structure prominent. Look for: • A sustained elevated ridge — persistent leadership • A ridge rising toward NOW — strengthening leadership • A ridge falling toward zero — fading leadership • Two similar current peaks — close competition • Rapidly alternating peaks — unstable rotation • A flat surface near zero — weak directional structure A leader marker appears only when the recognition requirements are satisfied. PARAMETER STABILITY This view rebuilds the network across a 6 × 6 grid: • X-axis: relationship lookback • Depth: maximum lag from 1 to 6 bars • Height and color: robustness Robustness combines 50% absolute evidence, 30% rank separation, and 20% agreement with the currently recognized leader. Cells without qualified outgoing coverage score zero. Broad elevated regions indicate that leadership survives several parameter choices. An isolated peak suggests that the result is parameter-sensitive. HOW TO USE IT 1. Choose a coherent universe Use a preset or select six related assets. Interpretation is clearest when the group represents one theme, such as cross-asset ETFs, US sectors, or mega-cap stocks. 2. Check the recognized state If the script reports NO CLEAR LEADER, do not treat the relative candidate as confirmed leadership. 3. Confirm evidence and separation Prefer cases where the candidate has both meaningful absolute evidence and adequate distance from the runner-up. 4. Check persistence and rotation Established leadership is generally more credible than a one-bar rank change. Falling persistence, a young leader age, or HIGH rotation risk signals a less settled structure. 5. Inspect Leadership Terrain Check whether the leader remains above zero through history and whether its ridge strengthens toward NOW. Watch for challengers rising beneath it. 6. Inspect Parameter Stability Prefer a broad plateau over one sharp peak. If leadership disappears after a small lookback or lag change, it is fragile. 7. Use alerts to trigger review Alerts identify structural transitions. Combine them with price action, trend, liquidity, and risk management rather than treating them as automatic entries. UNIVERSE PRESETS Cross-Asset — SPY, QQQ, IWM, HYG, TLT, DBC US Sectors — XLK, XLF, XLY, XLI, XLE, XLV Mega-Cap — NVDA, MSFT, AAPL, META, AMZN, GOOGL Custom — Six user-selected symbols IMPORTANT SETTINGS Relationship Lookback — Estimation window. Shorter values react faster but are noisier. Maximum Lead Lag — Earlier bars tested. One lag equals one chart bar. Rank Smoothing — Reduces rank churn at the cost of slower response. Leadership History — Window used for persistence and rotation statistics. Minimum Forward Evidence — Minimum blended relationship required for an edge. Minimum Directional Asymmetry — Required advantage over the reverse direction. Minimum Absolute Evidence / Rank Separation — Requirements for recognizing a clear leader. Terrain spacing, skew, separation, and height settings change only the drawing—not the model. KEY DEFAULTS Relationship Lookback: 80 Maximum Lead Lag: 5 Directional Weight Power: 1.25 Rank Smoothing: 3 Leadership History: 100 Minimum Forward Evidence: 0.18 Minimum Directional Asymmetry: 0.02 Minimum Absolute Evidence: 15 Minimum Rank Separation: 5% Terrain History: 8 slices spaced 5 bars apart ALERTS Clear Leader Rotation — Fires only on a direct transition between two different recognized leaders. A transition through NO CLEAR LEADER is not counted. High Rotation Risk — Fires when risk changes to HIGH while a clear leader exists. Clear Leader Established — Fires when the candidate first satisfies the recognition requirements. Clear Leader Lost — Fires when the recognized leader no longer satisfies them. LIMITATIONS This indicator is descriptive market-structure research, not a calibrated probability or a claim of predictive alpha. Lagged correlation and directional asymmetry do not establish causality. The model focuses on positive lead-lag relationships and does not explicitly represent inverse edges. Parameter Stability measures current in-sample robustness, not out-of-sample forecasting performance. The terrain is a 2D perspective projection whose appearance depends on chart zoom. Results depend on timeframe, available history, liquidity, and alignment between trading sessions. All six symbols should have sufficient data. Use rank to identify the relative candidate. Use evidence, separation, persistence, terrain, and parameter stability to decide how seriously that ranking should be taken.

Indicator

by NeuralMarkets

Icon Bot Changing privacy settingsThe Icon Bot⚡ is your automated trade-tracking companion built for killzone-based execution. It watches your session windows around the clock, tags entries the moment your setups trigger — complete with signed contract sizing based on your own risk-per-trade — and never lets a trade close without a verdict: Take Profit or Stop Loss, clearly marked, every time. Under the hood, it's built to scale with you. Risk, reward ratio, stop distance, and position sizing are all fully adjustable and automatically recalculate for whatever instrument you're trading — jump from MNQ to Gold and your risk math stays exact, no manual re-tuning. A live multi-timeframe trend dashboard keeps you oriented across six timeframes at a glance, while a customizable session map highlights your active killzones in real time. Every visual — entry badges, exit markers, borders, backgrounds, text — is yours to style, so the chart looks the way you want it to, not the way it shipped. And when you're ready to go hands-off, the bot speaks fluent webhook: structured alerts fire the instant a trade is confirmed, ready to plug straight into your automation stack. Built to watch the clock, track the trade, and call the outcome — so you don't have to babysit the chart to know how you did.

Indicator

by laurajulianaaa

Range Commander ORB [JOAT]An Opening Range Breakout command center: captures the opening range, projects measured-move targets, and tracks the breakout live. ◆ WHAT IT IS The opening range — the high and low of the first minutes of a session — is one of the most-watched intraday reference structures. Range Commander captures it automatically, locks it into a clean box, and builds a full breakout and target framework around it. It is a context and structure tool: it maps the range, marks the breaks, and tracks the targets — it does not fire endless buy/sell arrows. This is 100% original code, written from scratch. It does not reuse any other author's ORB script. ◆ HOW IT WORKS 1. Range capture. During your chosen session window (default 09:30–09:45 New York, fully adjustable with a timezone selector), the indicator records the running high and low into a live box. 2. Lock and project. When the window closes, the range locks. Its height becomes 1R , and the tool projects measured-move target rails at ±0.5R, ±1R and ±1.5R (all configurable), plus the range midline. 3. Breakout logic. A breakout is registered on either a close beyond the range (cleaner) or a wick beyond the range (faster) — your choice. An option stamps only the first break per side per day to keep the chart immaculate. A minimum range-size filter (in ATR) lets you skip dead, low-range opens. 4. Retests and targets. After a break, the first return to the broken edge is marked with a subtle diamond, and each measured-move target is tracked as hit or unhit in the dashboard. ◆ WHAT YOU SEE • A precision opening-range box with high/low rails and optional midline • Measured-move target rails at ±0.5R / ±1R / ±1.5R • Minimal breakout stamps and retest diamonds — no arrow spam • A resizable command dashboard with breakout status, OR high/low with intact-or-broken state, range height, range-versus-ATR quality (tight / normal / wide), which targets have printed, and retest status ◆ HOW TO USE IT • Set the session window to match your instrument and desired ORB length (e.g. 0930-1000 for a 30-minute range). • A wide range vs. ATR often signals a more energetic session; a tight range warns breakouts may be prone to failure. • Use the ±R target rails as objective, pre-defined profit references and the opposite range edge as a natural invalidation. • Designed for intraday timeframes . On daily and higher charts the session concept does not apply, and the dashboard will say so. ◆ NOTES & LIMITATIONS Use on standard candlestick charts and intraday timeframes. Opening-range breakouts fail as well as follow through — the tool maps structure and targets, it is not financial advice and cannot guarantee a break will run. Combine it with your own analysis and risk management. — made with passion by officialjackofalltrade

Indicator

by officialjackofalltrades

Equalhigh - Lepage Dual-Regime Detector Equalhigh — Lepage Dual-Regime Detector User Manual Overview The Equalhigh Lepage Dual-Regime Detector is a non-parametric change-point indicator for PulseWire. It is designed to identify recent changes in either: Location: the central level of the return distribution. Scale: the dispersion of the return distribution. Both simultaneously: a mixed structural break. Unlike a conventional momentum oscillator, the indicator does not ask whether price is overbought or oversold. It asks whether recent return behavior is statistically different from earlier return behavior inside the active window. This is a diagnostic regime detector, not an automatic buy-and-sell system. Why use a location-scale test? A market transition does not always begin with an obvious directional move. Sometimes the median return changes while volatility remains stable. In other cases, volatility expands or contracts before a clear directional shift becomes visible. The Lepage framework combines two rank-based components: The Wilcoxon rank-sum component measures a change in location. The Ansari–Bradley component measures a change in scale. The combined statistic can therefore detect more types of structural change than a location-only test. Observation series The test is applied to multi-bar logarithmic returns: Observation = 100 × ln(Source / Source ) Using returns instead of raw prices reduces the tendency to classify the normal upward drift of an asset as a permanent structural break. Logarithmic returns require positive source values. The indicator remains unavailable when the active window contains invalid or non-positive source observations. Core calculation For every active window, the script: Stores the return observations chronologically. Assigns average Wilcoxon ranks to equal observations. Assigns average Ansari–Bradley center-weighted scores to equal observations. Tests every split that leaves at least the selected Minimum segment size on both sides. Standardizes the location and scale score sums at each split. Calculates the Lepage statistic: L = Z_location² + Z_scale² Selects the split with the highest Lepage statistic. Calculates the fixed-split asymptotic p-value: p_fixed ≈ exp(−L / 2) Applies a conservative Bonferroni correction for all admissible splits: p_scan = min(1, Number of tested splits × p_fixed) Uses medians and median absolute deviations to classify the type and practical size of the detected change. The scan correction is important because selecting the strongest result from many candidate splits would otherwise make the displayed p-value too optimistic. Understanding the components Location Z The location component is displayed with an intuitive directional sign: Location Z > 0: the later segment shifted upward. Location Z < 0: the later segment shifted downward. A larger absolute value represents stronger rank-based location evidence. Scale Z The scale component describes the change in return dispersion: Scale Z > 0: the later segment became more dispersed. Scale Z < 0: the later segment became less dispersed. A larger absolute value represents stronger rank-based scale evidence. The combined statistic squares both components, so the p-value measures the strength of the overall break. The signs are used to interpret its direction. Color system Color or marker Interpretation Green — LEVEL + Confirmed positive location shift without a qualifying scale shift Red — LEVEL − Confirmed negative location shift without a qualifying scale shift Purple — VOL + Confirmed scale expansion without a qualifying location shift Blue — VOL − Confirmed scale compression without a qualifying location shift Orange — MIXED Confirmed location and scale shift occurring together Yellow — ? Possible break with incomplete statistical confirmation Gray No currently actionable break A volatility expansion is not automatically bearish, and a volatility compression is not automatically bullish. These states describe dispersion, not market direction. The orange mixed state does not encode direction by itself. Use Median Shift and MAD Scale Shift in the dashboard to determine whether the mixed change combines an upward or downward level shift with expansion or compression. Confidence line The main line is calculated as: Scan-adjusted confidence = 100 × (1 − p_scan) The default boundaries are: 95: confirmed statistical zone when the confirmed p-value is 0.05. 85: possible statistical zone when the possible-break p-value is 0.15. The line color reflects the currently classified regime. Important: this confidence value is not the probability that price will rise, the probability that a trade will be profitable, a win rate, or a forecast-accuracy score. Confirmation logic A confirmed regime requires all of the following: The scan-adjusted p-value is less than or equal to Confirmed scan p-value. The estimated break is no older than Maximum actionable break age. At least one component passes its practical-effect threshold. The contributing component also passes Minimum component Z. Positive or negative location shift The robust location effect reaches Minimum location shift. The absolute Location Z reaches Minimum component Z. The scale component does not independently pass all its confirmation filters. The sign of the median shift determines positive or negative classification. Scale expansion or compression The symmetric MAD scale-ratio change reaches Minimum scale-ratio change. The absolute Scale Z reaches Minimum component Z. The location component does not independently pass all its confirmation filters. The MAD ratio determines expansion or compression. Mixed break Both the location and scale components pass their effect-size and component-Z filters. Possible break The scan-adjusted p-value is above the confirmed threshold but no higher than the possible-break threshold. At least one component must also reach half of its normal effect-size and component-Z requirements. Dashboard Dashboard field Meaning Lepage State Current regime classification Scan-Adj P Bonferroni-adjusted approximate p-value for the split scan Break Age Estimated number of bars since the selected split Location Z Directional standardized Wilcoxon component Scale Z Directional standardized Ansari–Bradley component Median Shift Post-break median return minus pre-break median return, in percentage points Location Effect Median shift divided by a robust sigma estimate MAD Scale Shift Conventional percentage change from pre-break MAD to post-break MAD Additional dashboard states include: FILTERED BREAK: the combined statistic is significant and recent, but neither component passes all practical-effect and Z filters. OLD BREAK: the combined statistic remains significant inside the window, but the estimated split is older than Maximum actionable break age. STABLE REGIME: no currently actionable or possible break. Input guide 1. Observations Price sourceSeries used to calculate logarithmic returns. Close is the standard setting. Log-return horizonNumber of bars covered by each return observation. Lower values react to short moves. Higher values emphasize slower market behavior but create more overlap between consecutive observations. Lepage windowNumber of return observations in each rolling test. Short windows react faster but are noisier. Long windows are more stable but respond later. Minimum segment sizeMinimum number of observations required before and after every candidate split. Increasing it reduces unstable edge detections but prevents the test from selecting extremely recent breaks. 2. Validation Confirmed scan p-valueMaximum adjusted p-value for confirmation. The default is 0.05. Lower values produce fewer and more selective events. Possible-break scan p-valueMaximum adjusted p-value for the yellow early-warning state. The default is 0.15. Maximum actionable break ageMaximum number of bars allowed between the estimated split and the current bar. Minimum location shiftMinimum median shift measured in robust sigma units. The robust sigma is 1.4826 × window MAD, with standard deviation used as a fallback when necessary. Minimum scale-ratio change (%)Minimum symmetric difference between pre-break and post-break MAD. Symmetric measurement treats a doubling and a halving of scale as equally large changes for filtering purposes. Minimum component ZPrevents a regime label from being attributed to a component that contributed too little to the combined Lepage statistic. The default is 1.00. Confirm signals at bar closeWhen enabled, new markers and alert events are confirmed only when the current bar closes. This is the recommended setting. 3. Display These settings independently control regime backgrounds, confirmed labels, possible-break markers, and the dashboard. Suggested starting profiles Use case Return horizon Window Minimum segment Maximum age Location effect Scale change Component Z General swing trading 5 60 10 10 0.25 25% 1.00 Faster monitoring 3 50 8 7 0.30 30% 1.25 Slower regime analysis 10 90 15 15 0.35 30% 1.00 These profiles are starting points, not optimized trading parameters. Test settings across different assets and unseen market periods. Interpretation examples Green location event Suppose the dashboard shows: Scan-adjusted p-value: 0.03 Break age: 6 Median shift: +0.80 pp Location effect: +0.55 sigma MAD scale shift: +10% The evidence supports a recent upward change in the central return level, while the scale change remains below its filter. Purple volatility-expansion event Suppose the location effect is small, but post-break MAD is 60% higher, Scale Z is strongly positive, and the adjusted p-value is below 0.05. The indicator classifies a volatility expansion. Market direction must be determined separately. Orange mixed event If both median returns and dispersion change materially, the indicator displays MIXED. A positive Median Shift with a positive MAD Scale Shift represents improving returns accompanied by expanding volatility. A negative Median Shift with expanding volatility can represent a more hostile risk regime. Practical workflow Use ordinary candlesticks on a liquid instrument. Keep Confirm signals at bar close enabled. Treat yellow as an observation state rather than an entry instruction. When a confirmed event appears, inspect Location Z, Scale Z, Median Shift, and MAD Scale Shift. Confirm the interpretation with price structure, volume, liquidity, and higher-timeframe context. Define entry, invalidation, position sizing, and exit rules independently. The indicator is particularly useful as a regime filter. For example, a trend strategy may be treated differently during purple volatility expansion than during blue volatility compression. Alerts Six alert conditions are available: Lepage — Possible break Lepage — Positive level shift Lepage — Negative level shift Lepage — Volatility expansion Lepage — Volatility compression Lepage — Mixed regime break A confirmed alert fires when a qualifying state first appears, when the confirmed regime type changes, or when the estimated split resets to a more recent point. A possible alert follows equivalent first-appearance and break-reset logic. When bar-close confirmation is enabled, configure PulseWire alerts as Once Per Bar Close. Repainting and event timing The script does not use future data, lookahead, or a negative plot offset. It places a marker on the bar where the break is detected and never moves that marker backward to the estimated historical split. However, the estimator is rolling. As a new bar enters the window and an old bar leaves it, the selected split, component scores, p-value, break age, and current state can change. Values can also fluctuate on an open real-time bar. Bar-close confirmation prevents provisional intrabar markers from being treated as confirmed events. Historical events are calculated only from information available on their respective bars. Statistical limitations The fixed-split chi-square p-value is asymptotic rather than exact. Bonferroni correction is conservative because the candidate splits are dependent. The correction covers the splits inside one window, not repeated testing across every bar in the chart. Consecutive multi-bar returns overlap and are not independent. The adjusted p-value should therefore be interpreted as comparative evidence rather than a perfectly calibrated probability. The classical Lepage components are most naturally interpreted as location and scale tests under regular distributional conditions. Strong skew changes or complex distribution changes can affect both components. The detector selects one dominant split per rolling window. Multiple rapid changes can interfere with one another. A statistically significant regime change does not guarantee persistence, directional continuation, or trading profitability. Median absolute deviation can be close to zero on discrete or insufficiently variable data. The script uses a small numerical floor, but scale percentages can still become unusually large. Results on Heikin Ashi, Renko, Range, Kagi, Point & Figure, or other synthetic charts describe transformed data rather than ordinary traded prices. Always evaluate the indicator on unseen data and combine it with independent risk controls. Data Window outputs The script exposes: State code. Scan-adjusted p-value. Estimated break age. Location Z component. Scale Z component. Median shift in percentage points. Robust location effect. MAD scale change percentage. Lepage statistic. State codes are: Code State 4 Mixed location-scale break 3 Scale expansion 2 Positive location shift 1 Possible break 0 Stable, filtered, or old break −2 Negative location shift −3 Scale compression PulseWire publication metadata Primary category: Oscillators Secondary category: Trend Analysis Suggested tags: Lepage Test, Change Point, Regime Detection, Statistics, Non-Parametric, Volatility, Structural Break References Y. Lepage, “A Combination of Wilcoxon's and Ansari-Bradley's Statistics,” Biometrika, 1971. F. Rublík, “The Multisample Version of the Lepage Test,” Kybernetika, Vol. 41, No. 6, 2005, pp. 713–733: paper. G. J. Ross, D. K. Tasoulis and N. M. Adams, “Nonparametric Monitoring of Data Streams for Changes in Location and Scale,” Technometrics, Vol. 53, No. 4, 2011, pp. 379–389: DOI. H. Murakami, “A Nonparametric Location–Scale Statistic for Detecting a Change Point,” The International Journal of Advanced Manufacturing Technology, Vol. 61, 2012, pp. 449–455: DOI. Disclaimer This indicator is provided for research and educational purposes. It does not constitute investment advice, a recommendation, or a guarantee of future performance. Trading involves risk, including the possible loss of capital.

Indicator

VWAP-MACD with Volume Confirmation VWAP-MACD with Volume Confirmation VWAP-MACD+ replaces the price series inside a classic MACD calculation with an anchored VWAP series, then adds a volume-strength filter so that crossover signals are only flagged as "confirmed" when they occur on above-average volume. The result is a momentum oscillator that reflects shifts in the volume-weighted average price rather than raw closing price, with a built-in sanity check against low-conviction crosses. How it works Anchored VWAP — VWAP is calculated from hlc3 * volume, accumulated and reset at the start of each new period based on the selected anchor (Session, Week, or Month). This is the same anchoring logic as PulseWire's native VWAP, just computed manually so it can feed into the MACD below. VWAP-based MACD — instead of EMA-ing close like a standard MACD, this script EMAs the VWAP series itself (fast length default 12, slow length default 26). The difference between the fast and slow EMAs of VWAP is the MACD line; a further EMA of that (default 9) is the signal line; their difference is the histogram. Because VWAP is smoother and volume-weighted, the resulting MACD reacts to shifts in the "fair value" price rather than every tick of noise in the close. Volume Momentum Filter — each bar's volume is compared to its moving average (default 20-period SMA) to get a relative volume ratio. Bars are classified as strong (≥1.5x average), weak (<0.75x average), or normal, and the histogram's color intensity reflects this — brighter columns mean the current move is backed by stronger volume, faded columns mean it's on thin volume. Volume-Confirmed Crossovers — a standard MACD/signal-line crossover only becomes a plotted "confirmed" signal when relative volume is at or above average (≥1.0x). This is meant to filter out crossovers that happen on quiet, low-conviction bars. Reading the indicator Blue line — VWAP-based MACD line. Orange line — signal line (EMA of the MACD line). Histogram columns — MACD minus signal, colored green above zero / red below zero, with intensity scaled by relative volume (bright = strong volume, faded = weak volume, mid = normal). Green up-triangle — bullish crossover confirmed by volume. Red down-triangle — bearish crossover confirmed by volume. Zero line — dashed gray reference; crosses of the MACD line through zero can also be used as a secondary trend-context read, though this script's plotted signals are specifically the signal-line crossovers. Suggested use This is a trend/momentum tool built around volume-weighted price rather than raw close, intended for: Traders who already use VWAP as an intraday or swing fair-value reference and want a momentum oscillator derived from that same series instead of close price Filtering out MACD crossovers that occur on low-volume, low-conviction bars by relying on the "confirmed" triangle markers rather than every raw crossover Combining with the anchor period that matches your trading horizon — Session for intraday, Week or Month for swing/position context As with any momentum oscillator, it works best alongside broader trend or structure context (e.g., higher-timeframe trend, support/resistance) rather than as a standalone signal — volume confirmation reduces noise but doesn't guarantee follow-through. Inputs Fast Length / Slow Length / Signal Smoothing — EMA lengths for the VWAP-MACD calculation VWAP Anchor Period — Session, Week, or Month Volume MA Lookback — averaging period for the relative volume filter Enable Volume Confirmation Shading — toggles both the histogram's volume-based color intensity and the volume requirement on confirmed crossover signals Alerts Two alert conditions are built in: VWAP-MACD Bullish Cross (Vol Confirmed) VWAP-MACD Bearish Cross (Vol Confirmed)

Indicator

by AlwaysBearish

Jagdip Toolkit FVG + Order Blocks + Liquidity MTF Fair Value Gaps Bullish & bearish FVGs Midpoint/full-fill mitigation Order Blocks based on the last opposite candle before an impulsive move OB mitigation Liquidity levels from swing highs/lows Buy-side & sell-side liquidity sweeps Trend EMA Bullish/bearish SMC confluence signals PulseWire alerts for FVG, OB, liquidity sweeps and confluence

Indicator

Entry Checklist Panel ## The 13 checklist points, explained **1. Trend breaks swing / bias** — Is the market actually trending right now? The script looks at recent swing highs and lows and checks if price has been making higher highs and higher lows (uptrend) or lower highs and lower lows (downtrend) two times in a row. If yes, there's a real trend to trade with. **2. Pullback small + low volume** — When price pulls back against the trend, is that pullback small and quiet, not a big aggressive move? A weak, low-volume pullback suggests the trend is just resting, not reversing. **3. Volume match move** — Was the volume during the actual trending move bigger than the volume during the pullback? If the trend candles had more participation (volume) than the pullback candles, that's a sign the trend is the "real" move and the pullback is just noise. **4. 9EMA/VWAP close** — Are the 9-period moving average and VWAP sitting near each other (within 1%)? If they're far apart, price is stretched too far in one direction and may need to cool off before continuing. **5. Entry near 9EMA/VWAP** — Is your actual entry price close to one of those two reference lines? Entering too far away from either means you're chasing price rather than getting a fair, supported entry. **6. Breaking ORB high/low** — Has price broken above or below the opening range (the high/low set in the first several minutes of the session)? This is often the sign that a real directional move for the day is starting. **7. Key level out of way (manual)** — Is there a support/resistance line you've drawn nearby that price hasn't cleared yet? You check this yourself — if a key level is sitting right in the way, it's not a clean entry. **8. 200/400 SMA not in the way** — Are the longer-term moving averages either trending clearly, or is price already clear of both? If they're flat and price is tangled up in them, that's resistance/support you'd be fighting. **9. FTFC aligned (manual)** — Does your "timeframe continuity" indicator agree with the direction you want to trade? You check this yourself since it depends on a separate tool. **10. SL makes sense (manual)** — Is your stop-loss placed sensibly — not too wide, with room to reach your target, and beyond the levels that would prove you wrong? A judgment call only you can make. **11. Not consolidating at entry** — Is the current candle showing real movement, or is price just chopping sideways in a tight range? Trading during dead chop is a losing habit; this row checks for actual expansion. **12. Bid/ask held 5s (manual)** — For quick order-book-based (BW) entries: did the price actually hold at your entry level for a few seconds instead of just flickering through it? You confirm this yourself in the moment. **13. Pullback engulfed (manual)** — Did the move back in your favor "engulf" (fully cover) the pullback candle before you? Not required, but it's a stronger signal when it happens — you judge this by eye.

Indicator

Bindu Pin Points This is for very use full for jyarce pharm stratagie once we have to finalize the key point and we have to see for buy and sell signals

Indicator

by blogpakkaofficial

FLOWMATIX - OBX FLOWMATIX - OBX is a customizable PulseWire indicator designed to automatically identify and display time-based OBX zones. It supports two independent zones, OBX1 and OBX2, with presets for Gold, Indices, Forex, or custom session times. Each zone can be enabled separately and includes its own display, history, and balance settings. The indicator can automatically remove a zone after a breakout once price has spent a specified amount of valid time back inside the zone. Balance time is only counted during the selected trading session, preventing overnight or Asian-session activity from incorrectly removing the zone.

Indicator

ATK / DEF Advanced Battle Engine ## Overview ATK / DEF Advanced Battle Engine is a market behavior analysis and visua tool that combines liqui conditions, price movement, volati behavior, and swing struc to provide a mu-dimenal reference around signcant price highs and lows. Raher than trting price movement as a simple upward or downward ratio, this indicator examines how liquidity conditions and price movement inract with one anoer around swing points. The ATK / DEF concept is used as a structural repsentation of changing market behavior. It is not inteed to repsent a conntional direcnal indicator or a simple adce/dine measement. ## Core Concept The indicator combines several market observations into a unied analytical framework: • Swing High and Swing Low structure • Liquidity pressure • Liquidity changes • Price movement behavior • ADL-based tracking • ADL directional behavior • ADL attraction characteristics • Volatility conditions • Combined behavior assessment The purpose of combining these components is to provide additional context around hw price behaves when it rches or develops around important high and low areas. Instead of evating a high or low from prie alone, the indicator considers the surrnding liqity and movement conditions at the se time. ## High & Low Behavior Swing High and Swing Low points form the structural foution of the indicator. When a high or low is idenied, the indicator displays additional contextal information associed with that location, including the current ADL tracking condition and liquidity pressure. This creates a layered view of each structural point. A high is therefore not trted simply as a numical pric leel, and a low is not treed simpl as an isolaed turing point. The surroding conditions are displayd together to provide a broader represtation of the behavior occring around that area. ## Liquidity Analysis Liquidity information is reprented through two primary observions: ### Liquidity Pressure Liquidity Pressure compares the current volume condition with its corresnding average levl. The result is normalized into a bounded rae and classied into dferent pressure levls. This provides a reference for identiing whether the current market envirment is operating under relatily higher, normal, or lower liqdity conditions. ### Liquidity Change Liquidity Change exanes the change in volume conditions across a dened period. It provides a reference for whether liquidity conditions are incasing, decasing, or remning relavely balanc. These measements are used as conttual information raer than as stalone directional measuments. ## ADL Tracking The ADL Tracking component evaates the relaonship between price change and changs in volume conditions. The resuing value is normalized into a range and categized into several intensity levels. This allows the indicator to reprent the current relatiohip between price movement and liquidity conditions without reducing the analysis to price direction alone. The displayed levels provide a visua reference for changes in the inteity of this relationship. ## ADL Trend ADL Trend measures the change in the ADL tracking condition over a dened period. It classifies the observed behavior as: • Up • Down • Sideways The associated strgth value proides additional context rerding the magtude of the oerved change. This component is intended to describe the changing state of the undeying measurement rather than simply deribing whether price is risg or faing. ## ADL Attraction ADL Attraction examines the difference between the ADL-based movement component and the unrlying price-change component. The resulting value is smoothed and normalized to provide a serate referce for directional pressure within the combed calculan. The indicator presents this condition through: • Direction • Strength • Intensity level This helps distinguish the behavior of the combined liquidity/price relationship from the raw movement of price itelf. ## Volatility Behavior Volatility Behavior compares the current candle range with ATR-based volatility conditions. The result provides a normalized reprentation of the relative size of the current price range. The indicator classifies volatility into several levels, allowing users to distiuish between relatively qut price behavior and periods with greater range expansion. Volatility is presented as contextual information alongside liquidity and structural observations. ## Behavior Detection The Behavior Detection component combines ADL Tracking and ADL Attraction into a single reference value. This produces a brder repsentation of the conditions being obrved by the indicator. The resulting classifation provides a simplified summary of the combined measurements while retaining the underlying components in the analysis table. It should be viewed as a composite reference rather than a standalone directional measurement. ## ATK / DEF Framework The ATK / DEF terminogy describes two sies of market behavior around structural price areas. **ATK** reprsents the obsvation of upward-side interaction around relevant high-side structure. **DEF** reprsents the obseration of downward-side interaction around relevant low-side structure. These tems are usd as visal and structural laels for intpreting the relatiship between price, liqdity, and swing behavior. They do not represent direct market instructions. ## Analysis Table The intated analysis table prides a compact view of the current analytical state. It includes: • ADL Tracking • ADL Trend • ADL Attraction • Liquidity Pressure • Liquidity Change • Volatility Behavior • Behavior Detection The table allows the different measurements to be vied togher rather than interpreting each component independently. ## Swing Labels When ebled, Swing High and Swing Low labels display the strtural price level together with contextual liquidity and ADL information. This allows histical swing locations to rein addtional analycal information instead of displaying only the price level. The result is a more detaled visual reprentation of how liqdity and price behavior were charterized around the detected structural area. ## Design Philosophy The design of ATK / DEF Advanced Battle Engine is based on combining multle forms of market information rather than relng on a single measurement. Price strture provides the location. Liquidity provides conttual participation information. ADL calculaons provide a relaonship between price movement and volume conditions. Volatity provides information about the sce of current price movement. Together, these components create a multi-layer reference for stud market behavior around highs, lows, and chaing structural conditions. ## Important Note This indicator is intended for market behavior analysis and visual reference. It is not designed as a stalone desion-mag sysm. The displayed measuments should be evalted together with other anatical tools, market contet, and indendent intertation. The values and classiations are callated from historal price and volume da and may chang as new mat dat devels. Histor behavior does not guara future conditions. ATK / DEF Advanced Battle Engine is designed to provide additional analytical

Indicator

Rolling VWAP + Volume Profile by Flip On Dip Rolling VWAP + Volume Profile draws a volume weighted average over a moving window of trading days, and a separate volume profile for each of the last few sessions. 🔁 The VWAP here is not anchored. Instead of resetting at the open it holds a sliding window of the last N sessions, so the line carries through the open and over the weekend without jumping. Two deviation bands sit either side, built from the volume weighted standard deviation rather than a plain one, so they widen when size trades away from the mean instead of just following range. 🕐 Session length is measured off the chart rather than assumed. A 6.5 hour stock day, a 23 hour gold day and a 24 hour crypto day all count as one day, so a 7 day window really is seven sessions on any symbol at any timeframe. 📊 Each session gets its own profile, built from a candle step you set. That step is independent of your chart, so the same 5m profile shows up whether you're looking at a 1m or a 1h chart and switching timeframes won't change the shape. Volume from each candle is spread across every level it touches, weighted by how much of the candle's range falls inside each one, instead of being dumped at the close. Point of control and value area are marked, and the session in progress rebuilds as it fills. On that last point, worth being clear about what moves and what doesn't. The session in progress is live and will keep changing until it closes, roughly once a minute as volume comes in. That's the whole idea of a developing profile. Once a session ends its profile is drawn once and never touched again, so nothing behind you shifts around. The VWAP behaves the same way: it updates on the current bar like any average does, and past values stay where they were. Two horizons. Micro gives daily profiles with a week long VWAP, Macro switches to weekly profiles with a fortnight long VWAP across a longer stretch of history. Each one keeps its own settings, so flipping between them doesn't cost you your tuning. ⚠️ Not every ticker reports real volume, and that changes what a profile means. Spot gold, most FX and index feeds publish nothing at all, while forex and CFD tickers that do publish are usually counting ticks rather than contracts. The indicator checks and tells you which one you're on. Where there's no volume it falls back to counting time spent at each price, which is still a useful map of where the market lingered, and the panel says so rather than leaving you to work out why the shape looks odd. The panel in the corner handles the rest of it. Active horizon, VWAP window, profile step, and whether volume on this ticker is traded, tick only or missing. If something is quietly limiting the drawing, the chart timeframe being wrong for the horizon, the 500 box platform limit, not enough history loaded for the window you asked for, it writes it out in plain words with what to change. There's also an optional fixed step for the VWAP itself, which makes the line identical on every timeframe. Off by default, since the chart bars are what most people expect. ⚡ Nothing is calculated outside the visible window, and every box and line is allocated once and reused instead of being deleted and redrawn, so panning around stays smooth even on long intraday history. Three colour presets, Default, Light and Dark, or Custom to set every colour and transparency yourself. Row spacing and width, gradients, borders, POC and VAH/VAL lines, the 3D shadow, price labels and the panel are all configurable. Open source, free to study or extend.

Indicator

World Sessions & Countdown [AFD] Which session is actually running right now, and how many bars are left in it? Every session tool on the shelf draws the same coloured stripes. Almost all of them are built on a fixed UTC offset, which means twice a year they are quietly an hour wrong and nothing on the chart says so. The highest-profile clock script in the niche states plainly in its own description that it requires manual UTC offset adjustment at each changeover. World Sessions is anchored to IANA time zone names instead - Europe/London, America/New_York, Asia/Tokyo, Australia/Sydney. Each window follows its own city's daylight-saving policy, on its own, with nothing for you to adjust. The script draws a rectangle around each session's own bars rather than a full-height stripe, a separate rectangle wherever sessions overlap, and a dashboard that tells you what time it is in all four cities and how much of the current session is left. Why the time zone thing matters 14 January - London GMT, New York EST - overlap 15:00-17:00 UTC, two hours. 25 March - London BST, New York EDT - overlap 14:00-17:00 UTC, three hours. 15 July - London BST, New York EDT - overlap 14:00-16:00 UTC, two hours. 28 October - London GMT, New York EDT - overlap 14:00-17:00 UTC, three hours. A fixed-offset script prints one identical row for all four. The late-October row is the one that bites: Europe has left summer time and the United States has not, so the two cities are five hours apart instead of the usual four, and every band built on a captured offset is an hour wrong for that week. This is a statement about how the script resolves time. It says nothing about volatility, liquidity, or what you should do with any of it. At a glance Session boxes - one rectangle per session RUN, spanning that run's own high and low, not a full-height stripe. Overlap box - a separate rectangle over the bars two or more sessions share, carrying its own composite name. IANA time zones - each session follows its own city's daylight-saving policy, with no UTC offset to maintain. Bars left in session - not minutes, BARS, on your current timeframe. Dashboard - each session's hours, its city's live clock, an open/closed dot, a progress bar, and the countdown to its next boundary. Five sessions - Sydney, Tokyo, London, New York, and one Custom slot of your own. New York hours - regular, extended-equities, or CME Globex, chosen automatically from the symbol or forced by hand. Eight alerts - four session opens, all sessions closed, overlap start, N seconds to bar close, and last bar of session. Appearance - fill, four gradient depths in two directions, border transparency, width and style, or outline-only. One box per run, not one box per chart A session's rectangle is bounded by that session's run, identified by the instant that run closes, and not by a stretch of bars on which the session happened to be live. The distinction is not academic. On a regular-hours US chart every bar is inside New York's 09:30-16:00 window, so a liveness-based tool never sees New York stop being live: it opens one rectangle on the first bar of history and never closes it, washing the entire chart in one color. This product drew exactly that defect once, and the lifecycle is now keyed on the run instead. You get one box per day, with clean gaps between them. A box is a session's EXTENT, not a level. It has a top and a bottom and that is where the resemblance to a zone tool stops - no line is drawn at either edge, no edge is labelled or alerted with a price, and nothing downstream reads one. The overlap box Two or more enabled sessions running at once get their own rectangle over the shared bars, spanning the high and low of those bars only, and it carries the name of the sessions that actually made it - TOKYO + LONDON, LONDON + NEW YORK. One color at any depth, deliberately: Sydney, Tokyo and London genuinely stack three deep, and a per-pair colour scheme has no honest answer for a three-way overlap. Overlap only is the shipped default, so out of the box the chart draws the overlap rectangle and nothing else. On a chart with no overlap running that means no rectangles at all - the intended state, not a fault. Set Overlap to Highlight overlap to see every session box alongside it, or Off for session boxes with no overlap rectangle. Every session is named exactly once. Where the overlap box is drawn it carries the joint name, so a session's own name centres on the bars it held ALONE. A session that is never alone shows no separate name, because it has already been named. The dashboard Per session - a colour chip, the name, an open/closed dot, that session's own hours, the current wall clock in its city (marked +1 or -1 when the city is on another date), a progress bar, and OPENS IN or CLOSES IN to its next boundary. The open session's row is tinted in its own color and its name set bold. Two kinds of time, on purpose - LOCAL, the dot, PROGRESS and NEXT are real-world clock readings and stay current on a weekend, on a scrolled-back chart, and in Bar Replay. BAR CLOSE is a property of the bar in front of you and shows an em dash on anything but a genuinely live bar, because a countdown to the close of a bar that has already closed cannot mean what it says. BARS LEFT keeps counting where BAR CLOSE cannot, because one is a bar-structure count and the other is a clock reading. It names the session it is following. Both step green, then amber, then red as they run out. The progress column always says something - the bar while a session runs, Not in session while it is closed, and No bars here when that session's window has no bars at all on the symbol you are looking at. Tokyo on a US regular-hours chart is the common case. Position, background, grid lines, the outer frame and its width, one text size for the whole panel, and progress-bar width are all settings. The frame's Countdown mode makes it the same green-amber-red traffic light BARS LEFT carries. Weekdays are digits, and the rule has a trap in it Weekdays live in a field of their own, because input.session() renders two clock fields and no weekday picker. 1 is Sunday through 7 is Saturday, so the shipped '23456' is Monday to Friday. They are not optional. A session string without them applies to EVERY day of the week - invisible on a stock chart, but on a 24/7 symbol it draws a London box straight through Saturday. For a session that runs past midnight, the digits name the day it ENDS. PulseWire's own documented example is 1700-1700:23456, in which the Monday session starts Sunday at 17:00 and ends Monday at 17:00. So the CME Globex window here is 1800-1700 with the ordinary 23456 - Sunday evening through Friday afternoon, five sessions, the real Globex week. The intuitive-looking 12345 invents a Saturday-evening session that never trades and loses Thursday evening entirely. Alerts Sydney session open Tokyo session open London session open New York session open All sessions closed Session overlap start N seconds to bar close - the threshold is a user input, and 0 turns it off Last bar of session - off by default Create these from PulseWire's alert dialog. How often an alert re-fires while its condition holds is set in that dialog, not in the script. How to use it Add it to an INTRADAY time-based chart. Boxes and session names need an intraday timeframe; the dashboard works on any timeframe, because its countdowns read the wall clock. Leave Overlap on Overlap only for the overlap rectangle alone, or switch to Highlight overlap to see every session. Turn off the sessions you do not follow. Set hours and weekday digits to match what you actually trade. On a futures contract, check the New York hours group is on extended hours if the Globex window is the one you want boxed. Auto by symbol handles this for you on a real futures contract. Everything else - fill, gradient depth and direction, border style, boxes kept, panel appearance - is a setting to configure once to taste. What it deliberately does not do It draws no zone and publishes no session high or low as a level. It offers no fixed UTC offset option, because a dropdown reading UTC-5 would let you silently break the one thing the product is for. It gives no arrows, no signals, and nothing about what price will do during any session. Educational chart context, not financial advice. Data, timeframes and repainting The script uses current chart data only. There are no request.security() calls, no higher-timeframe imports, and no lookahead of any kind. A running session's box updates as new highs and lows print on the forming bar, and its right edge advances with the chart; it is final once that session's run has ended. Confirm the behaviour with the bar-replay tool on your own chart and timeframe before relying on it. The dashboard's clock columns advance per tick. Pine provides no timer, so on a closed market - where no tick arrives - they hold at the last moment the script executed rather than ticking on by themselves. Scrolling, zooming, or changing any setting re-executes the script and brings them current. This is platform behaviour, not a setting. Boxes and session names are intraday-only. On a daily or higher chart a session window is shorter than one bar, so they are not drawn. Drawing history is bounded by Pine's limits. The source declares budgets of 500 boxes and 500 labels, and Session boxes kept is trimmed automatically to stay inside the box ceiling - a faded session costs one box per gradient step plus its outline. Standard time-based candles. The session arithmetic reads chart time. A running alert keeps the inputs, symbol and timeframe it was created with - recreate an alert after changing any of them. Originality and credit Other session tools draw stripes on a fixed offset. This one bounds each session run by its own high and low, names the overlap for the sessions that actually made it, resolves every window through an IANA time zone so it holds across daylight saving, and reports the one number the shelf does not carry - how many bars are left in the session you are in, on the timeframe you are on. Open source under the Mozilla Public License 2.0. (c) Auction Foundry. Disclosure: this indicator describes session structure and elapsed time on the current chart. It is not a forecast, a signal, or financial advice.

Indicator

by AuctionFoundry

Mr Mike Fibonacci ### Mr Mike Fibonacci — Script Description **Mr Mike Fibonacci** automatically identifies the latest swing high and swing low and draws a custom Fibonacci range between them. The indicator uses the following levels: * **0%** — White * **29.5%** — Red * **50%** — Green * **70.5%** — Red * **100%** — White The Fibonacci automatically reverses depending on whether the range is bullish or bearish. Swing points are based on the actual candle wicks. The **Swing Strength** setting is fully adjustable, allowing users to choose smaller or larger market swings. The indicator displays clean horizontal Fibonacci levels with the corresponding price levels and **no background fill**. **Designed to help traders quickly identify key retracement and reaction levels within the latest market swing.**

Indicator

by Mister-Mike-Tradetools

Reversal Signal: ZigZag Trend + RSI Divergence + HA What it does: Trend — finds swing highs/lows (ZigZag-style) and calls the market bearish when both the highs and lows are stepping down (lower highs + lower lows). RSI divergence — compares RSI at the two most recent swing lows; flags bullish divergence when price prints a lower low but RSI prints a higher low. Custom Heikin Ashi — computed manually from OHLC (not PulseWire's built-in HA candle type), plotted as an overlay, and used to detect the first green candle after a run of red ones. Buy signal — fires only when all three align: bearish trend + recent bullish divergence + first green HA candle. Dynamic stop loss — a red line drawn just below the swing low that triggered the signal, with an adjustable buffer. There's also a small dashboard in the top-right showing live trend/divergence/stop status, plus an alert condition you can wire up to PulseWire alerts.

Indicator

mussyjasxau| BOS + CHoCH + Liquidity Sweep prima versione seria dell’indicatore SMC pensata proprio per l’entrata: BOS, CHoCH, swing HH/HL/LH/LL, Buy-Side Liquidity, Sell-Side Liquidity e Liquidity Sweep, con alert separati.

Indicator

OptiPine: High-Performance Caching and Data Pipelines OptiPine is a high performance architecture library for Pine Script™, built for algorithms that push beyond ordinary indicator workloads. It turns caching, sparse updates, reusable storage and workload-aware data structures into practical APIs that stay small at the call site. In a small indicator, optimization is often optional. In a rendering engine, machine learning library, simulation, dashboard or object system, it can determine whether a feature runs at all. The problem is rarely one slow formula. It is the thousands of unnecessary operations around it: recalculating unchanged results, shifting rolling arrays, scanning large collections for a few changes, and moving stored objects when one disappears. OptiPine attacks that layer with techniques used in projects such as Pine3D and NeuraLib . The idea is simple: do less work, move less data, and let the representation follow the workload. Compared with conventional Pine implementations of the same task, OptiPine's optimized paths commonly ran 15% to 40% faster . Sparse updates and indexed lookups exceeded 90% when the alternative scanned or searched the full collection. Most users can stay entirely within the high-level API. A Memo cache with several dependencies looks like this: // Pseudocode: trendRegime and volatilityRegime are floats; // rebuildModel() is a pure calculation. var op.FloatMemo model = op.floatMemo() if model.staleOn(trendRegime, volatilityRegime) model.store(rebuildModel(trendRegime, volatilityRegime)) float result = model.get() // Output: rebuildModel() runs once, then only when either regime changes. Memo owns the previous dependencies, first-run state, validity and cached result. The caller only declares what the result depends on. ---------------------------------------------------------------------------------------------------------------- 🔷 DO NOT CALCULATE THE SAME THING TWICE The fastest expensive calculation is the one that never needed to run. Models, simulations and generated geometry often remain valid across many script executions. Memo is the direct choice when the cached result is an int, float, bool, string or color. staleOn() checks up to four floats, two integers, one Boolean and one string; store() saves a rebuilt value, and get() returns it. Many models respond to regimes rather than every tiny change in raw data. Round the inputs into meaningful regimes, pass them to staleOn() , and the model runs only when a regime changes. In practice: Memo is useful for scenario models, parameter sweeps, numerical solvers and other expensive pure calculations that reduce to one primitive result. If its dependencies repeat on nine out of ten executions, it avoids roughly 90% of those model runs. For collections or a variable dependency list, use Memo's explicit begin() , dependencies.watch*() and miss() lifecycle. Keep guarded work pure: Stateful ta.* and similar history-dependent calls must remain outside Memo and Watch guards. Compute them every bar, then pass their results into the guarded calculation. 🔸 WATCH: CHANGE DETECTION WITHOUT RESULT STORAGE Watch is the lighter choice when the caller already owns the result. Several consumers can observe the same producer independently by giving each its own Watch. changed() returns true on the first observation and whenever one scalar, primitive array or OptiPine row ring changes. Row rings expose an internal revision, so checking them is O(1). For a single source, the dependency check should take less attention than the calculation it protects. Here another component supplies one caller-owned feature array: // Pseudocode: getFeatureSnapshot() supplies an array. array features = getFeatureSnapshot() var op.Watch featureWatch = op.watch() var float modelScore = na if featureWatch.changed(features) modelScore := evaluateModel(features) // Output: modelScore is rebuilt only when the features array changes. Because OptiPine does not own features , it compares the array with a retained snapshot and rewrites that snapshot only after a change. Supported row rings use their internal revision instead. The call stays the same, and this compare-first array pattern measured roughly 35% to 60% faster than rewriting the snapshot every time. The array comparison is still O(N), so use it when the avoided calculation costs more than the comparison. If the producer already provides one reliable change flag, use the flag directly. For several dependencies, use an explicit pass. begin() starts the comparison, the typed watch*() methods add dependencies, and finish() returns true if the completed set changed. A Watch remembers dependencies; it does not store the result. // Pseudocode dependencies: int length, float multiplier, // and array features. var op.Watch settingsWatch = op.watch() var float result = na settingsWatch.begin() settingsWatch.watchInt(length) settingsWatch.watchFloat(multiplier) settingsWatch.watchFloats(features) bool dependenciesChanged = settingsWatch.finish() if dependenciesChanged result := rebuild(length, multiplier, features) // Output: result is rebuilt when any observed dependency changes. Construct the Watch once with var , then run begin() and finish() on every comparison pass. For one dependency, changed(source) is the shorter path. In practice: Watch fits module boundaries: a model can observe a feature array, a renderer can observe a managed ring, or a cache can observe several mixed settings without duplicating the producer's change logic. CadenceGate limits how often work may run. due() is periodic; dueWhenChanged() also requires a producer revision and remembers changes until the cadence opens. Use it for intentionally delayed work such as periodic model fitting, not results that must update immediately. ---------------------------------------------------------------------------------------------------------------- 🔷 ROLLING HISTORY WITHOUT SHIFTING IT Rolling histories often perform work that adds nothing to the result. If an array keeps the latest 200 events, removing the oldest one and shifting the other 199 entries is unnecessary. FloatRowRing and IntRowRing keep fixed-width rows in reusable storage. Once full, the next row overwrites the oldest physical slot while reads remain chronological. var op.FloatRowRing history = op.floatRowRing(200, 3) float atr14 = ta.atr(14) if barstate.isconfirmed history.push(array.from(close, volume, atr14)) float oldestPrice = history.at(0, 0) float latestPrice = history.newestAt(0, 0) // Output: after a confirmed push, these are the oldest and newest retained closes. A push costs O(width), or O(1) through pushValue() for a width-one ring. Rings also provide chronological windows and gathered rows. When several producers can mutate a ring, a separate consumer can detect its revision with Watch.changed(ring) in O(1). In practice: Row rings fit pivots, completed trades, sampled features and other fixed event histories. Performance: A full ring overwrites one row instead of shifting every retained row. Its chronological output uses at most two native contiguous copies, which measured 90% faster than rebuilding a 512-cell, width-four output row by row. Use RingCursor when several caller-owned arrays need the same circular layout. Ordinary series history such as close should remain native Pine. ---------------------------------------------------------------------------------------------------------------- 🔷 KEEP DYNAMIC OBJECTS STABLE Dynamic objects become surprisingly expensive when identity is tied to array position. If one object is removed from several parallel arrays, every later entry shifts, every synchronized payload array needs the same removal, and every external reference to those positions becomes fragile. StablePool is not the zone storage itself. It keeps one association: an object ID supplied by the script points to a reusable array slot. The ID answers "which zone is this?" while the slot answers "where is this zone's data stored?" The example has three different logical zones named A, B and C. Their IDs, 1001, 1002 and 1003, are arbitrary unique values chosen for readability. Real IDs may come from a pivot bar, timestamp, order number or incrementing counter. const int ZONE_A_ID = 1001 const int ZONE_B_ID = 1002 const int ZONE_C_ID = 1003 var op.StablePool zonePool = op.stablePool() // This example never has more than two active zones. var array prices = array.new(2, na) if barstate.isfirst // A receives slot 0. B receives slot 1. = zonePool.acquire(ZONE_A_ID) = zonePool.acquire(ZONE_B_ID) prices.set(slotA, 100.0) prices.set(slotB, 200.0) // Zone A no longer exists. Its slot becomes available. zonePool.release(ZONE_A_ID) // C is a new zone with a new identity, but it can reuse A's old slot. = zonePool.acquire(ZONE_C_ID) prices.set(slotC, 300.0) // Output: B keeps slot 1. C has ID 1003 but reuses A's released slot 0. // prices is . Why C needs a new ID: C is a different zone, even though it occupies the same array position A once used. Reusing 1001 would describe A returning, not a new zone C. IDs preserve object identity; slots are only reusable storage addresses. Several fields, one slot: In production, the same slot usually addresses every field belonging to the object. Continuing the A, B and C lifecycle with four parallel arrays: const int ZONE_A_ID = 1001 const int ZONE_B_ID = 1002 const int ZONE_C_ID = 1003 var op.StablePool zonePool = op.stablePool() var array zonePrices = array.new() var array zoneTimes = array.new() var array zoneStrengths = array.new() var array zoneColors = array.new() if barstate.isfirst = zonePool.acquire(ZONE_A_ID) = zonePool.acquire(ZONE_B_ID) // Grow every payload array to cover the allocated slots. int required = zonePool.slotCount() op.ensureSizeFloat(zonePrices, required, na) op.ensureSizeInt(zoneTimes, required, na) op.ensureSizeFloat(zoneStrengths, required, na) op.ensureSizeColor(zoneColors, required, na) zonePrices.set(slotA, 100.0) zoneTimes.set(slotA, 10) zoneStrengths.set(slotA, 0.40) zoneColors.set(slotA, color.blue) zonePrices.set(slotB, 200.0) zoneTimes.set(slotB, 20) zoneStrengths.set(slotB, 0.80) zoneColors.set(slotB, color.red) zonePool.release(ZONE_A_ID) = zonePool.acquire(ZONE_C_ID) // C reuses A's slot, so every field at that slot must be overwritten. zonePrices.set(slotC, 300.0) zoneTimes.set(slotC, 30) zoneStrengths.set(slotC, 0.60) zoneColors.set(slotC, color.lime) // Output: B keeps slot 1 in every array. C owns slot 0 in every array. // Nothing is removed or shifted. acquire(id) returns the slot and whether the ID was newly added. Calling it again for an active ID returns the same slot. release(id) frees the slot, but does not erase its array data, so every field must be overwritten when that slot is reused. The example preallocates two values because it has at most two active zones. A dynamic script can grow its payload arrays with ensureSize*() whenever acquire() reports a new ID. zonePool.slots() returns the currently active slots as a read-only view. In practice: One zone slot can index its price, time, color, strength and line across several arrays. In the complete example later, the pivot bar and event type form each zone ID. Releasing one zone frees its slot without shifting other zones or breaking saved positions. Performance: StablePool is independent of payload layout: its slots can index parallel arrays or one array of UDTs. acquire() , release() and find() are O(1), and releasing an object never shifts caller-owned payloads. For a few fixed objects, manual indices are simpler. StablePool becomes useful when IDs appear and disappear over time, several payload arrays share the same slots, or other parts of the script retain those positions. SlotCache is the frame-based alternative. Call begin() , acquire every active key, then call finish() ; previously active keys that were not touched are retired automatically. ---------------------------------------------------------------------------------------------------------------- 🔷 UPDATE ONLY WHAT CHANGED Large state does not imply large change. A dashboard may contain 10,000 cells while only a few change on one bar, or a large object system may need to refresh only a handful of entries. A conventional dirty-flag array must be cleared and scanned in full. DirtySet stores only the changed indices, removes duplicate marks and begins a new cycle without clearing the entire universe. It is a work list, not payload storage or an ID-to-slot map. Here StablePool resolves zoneId , the arrays store zone data, and DirtySet schedules the slots that need rebuilding. The event values are pseudocode: int MAX_ZONES = 50000 var op.StablePool zones = op.stablePool() var op.DirtySet dirtySlots = op.dirtySet(MAX_ZONES) var array tops = array.new() var array bottoms = array.new() var array midpoints = array.new() // Start this bar's sparse-work cycle. dirtySlots.begin() if zoneGeometryChanged // StablePool converts the logical ID into a reusable physical slot. = zones.acquire(zoneId) if created op.ensureSizeFloat(tops, zoneSlot + 1, na) op.ensureSizeFloat(bottoms, zoneSlot + 1, na) op.ensureSizeFloat(midpoints, zoneSlot + 1, na) tops.set(zoneSlot, newTop) bottoms.set(zoneSlot, newBottom) dirtySlots.mark(zoneSlot) if zoneStyleChanged int styleSlot = zones.find(zoneId) if styleSlot >= 0 dirtySlots.mark(styleSlot) // A second mark of the same slot is ignored. // Process only the distinct physical slots marked during this bar. for dirtySlot in dirtySlots.values() float midpoint = (tops.get(dirtySlot) + bottoms.get(dirtySlot)) * 0.5 midpoints.set(dirtySlot, midpoint) redrawZone(zones.keyAt(dirtySlot), midpoint) // Output: one zone is rebuilt once even if geometry and style both mark it. Repeated marks are deduplicated, and unmarked zones are never visited. Work scales with the number of changed slots, not the size of the collection. If the natural address is already a dense index, mark it directly without StablePool. In practice: Several producers can mark work, then one consumer updates each affected cell, drawing or record once. With 1% of entries changed, this measured 93% faster than clearing and scanning the full universe. ---------------------------------------------------------------------------------------------------------------- 🔷 KEYED LOOKUP WITHOUT GUESSWORK Keyed lookup appears throughout object systems, caches and grouped data, but no structure fits every key set. Distribution, rebuild frequency and query volume change the best choice. OptiPine sees the completed keys at build() , then selects the lookup shape that fits them. 🔸 TYPED STORES: ONE VALUE PER KEY A typed store maps each integer key to one primitive value. build() pairs entries at matching positions in the key and value arrays. Consecutive IDs allow direct addressing: var op.IntFloatStore scores = op.intFloatStore() if barstate.isfirst // Four entries are shown for readability; both arrays may be much larger. scores.build( array.from(410, 411, 412, 413), array.from(0.80, 0.30, 0.95, 0.50)) float selected = scores.get(412) // Output: integer key 412 resolves to float value 0.95. Lookup is one-way: get(412) returns 0.95 , but values may repeat, so get(0.95) has no general meaning. What automatic mode chooses: Consecutive ascending keys: Direct arithmetic indexing. Compact key ranges: A dense lookup table. Other unordered keys: A native map when within Pine's map limit. Ascending sparse keys: Binary search, or a map within that limit when expectedQueries justifies its build cost. Linear lookup remains available for unusual workloads that rebuild far more often than they query. Automatic mode only selects it for non-empty stores when linearMaxEntries is deliberately configured. The same API avoids hashing when direct addressing fits, uses a map when it pays, and remains usable beyond Pine's map capacity. Automatic mode is the normal default. Use op.indexConfigDynamic() when future query volume is unknown and the store may need to promote itself later. build(keys, values, expectedQueries) accepts two same-length arrays. The optional hint tells OptiPine how many lookups to expect before the next build. Stores support int, float, bool, string and color values. Use one IntIndex for several payload fields, or IntBuckets when a key owns several integers. In practice: Batch-build IDs to scores, states or metadata, then query them without committing to a representation. Direct integer addressing measured 21% faster than a map, while a map measured 91% faster than repeated linear lookup with 32 entries. 🔸 INTBUCKETS: ONE KEY TO MANY INTEGER VALUES A Store returns one value for each key. IntBuckets returns a group of integers, usually object IDs or physical slots. Repeating a key adds another member instead of replacing the previous one. var op.IntBuckets cellMembers = op.intBuckets() var array matches = array.new() if barstate.isfirst // Six (cell, object slot) pairs. Cell 7 appears three times. array cellKeys = array.from(7, 2, 7, 5, 2, 7) array objectSlots = array.from(101, 205, 412, 990, 777, 888) cellMembers.buildFromPairs(cellKeys, objectSlots) // Read cell 7's group from flat storage. matches is only demo output. = cellMembers.rangeByKey(7) if count > 0 for position = start to start + count - 1 matches.push(cellMembers.valueAt(position)) // Output: matches contains , the object slots assigned to cell 7. What happens: Each key is paired with the slot at the same array position. Cell 7 appears three times, so its group contains 101, 412 and 888. rangeByKey() returns where that group starts and how many values it contains. A missing key returns a count of 0. Lifecycle: buildFromPairs() replaces all previous groups. Use buildBegin() , add() and buildFinish() only when pairs arrive one at a time. In practice: A price cell can own several zone slots, a graph node can own several neighbors, or a category can own several record IDs. One query visits only that group. Why use it: A native map stores one value per key, and Pine does not allow an array directly as that value. Giving one key several values therefore requires a small wrapper UDT containing an array. IntBuckets provides that relationship directly, packing every group into shared contiguous storage. It suits batch rebuilds followed by repeated traversal, while the wrapper approach is more convenient when individual groups change constantly. In the tested 64-key traversal workload, IntBuckets averaged 19% faster across four runs. ---------------------------------------------------------------------------------------------------------------- 🔷 REUSE STATE INSTEAD OF REBUILDING IT IntDoubleBuffer and FloatDoubleBuffer retain current and previous arrays. swap() exchanges their references in O(1), preserves the old result and clears the new current buffer for reuse. That clear still costs O(N). This is useful when one pass must remain readable while the next is built. In this small search, node n has children 2n and 2n + 1 . Each pass reads the active level and writes the next one: var op.IntDoubleBuffer searchFrontier = op.intDoubleBuffer() if barstate.isfirst searchFrontier.current.push(1) for depth = 1 to 3 = searchFrontier.swap() for nodeId in activeFrontier nextFrontier.push(nodeId * 2) nextFrontier.push(nodeId * 2 + 1) // Output: current contains . // previous contains . What happens: swap() makes the completed level available as activeFrontier and returns the other retained array, already empty, as nextFrontier . No level is copied and no replacement array is created. The same pattern supports graph searches, flood fills, iterative clustering and simulations. Use swapSized() when every pass needs a fixed-size output. A var array can also be reused. The ensureSize*() , resize*() and refill*() families modify existing storage, while sameExact*() compares primitive arrays without Pine's float-comparison rounding. Revision handles caller-owned state that OptiPine cannot observe. The producer calls bump() after a change; each consumer compares its own saved token with changedSince() instead of keeping a snapshot. ---------------------------------------------------------------------------------------------------------------- 🔷 WEIGHTED SELECTION FOR STATIC AND DYNAMIC SYSTEMS Weighted selection chooses entries in proportion to their weights. It is useful in simulations, randomized search and priority sampling. WeightedSampler is the high-level interface. Set weights, then supply a fraction to select a slot. The sampler does not generate randomness; use math.random() or a repeatable fraction sequence: var op.WeightedSampler sampler = op.weightedSampler(512) if barstate.isfirst sampler.setWeight(10, 0.25) sampler.setWeight(11, 0.80) sampler.setWeight(12, 0.10) float fraction = 0.50 int selected = sampler.sample(fraction) // Output: selected is 11 for the supplied fraction of 0.50. The default cumulative prefix suits stable weights. Pass op.weightConfigSparseUpdates() and the sampler can move to an update-friendly Fenwick tree as the workload changes. sample() stays the same. Use WeightedIndex for circular ranges or explicit policy control. In practice: Each slot can represent a candidate model, simulation outcome or work item. Update its weight when its score changes, then sample repeatedly through the same interface. ---------------------------------------------------------------------------------------------------------------- 🔷 THREE LEVELS OF CONTROL OptiPine is layered so high-level code describes the problem rather than the mechanism. Start with Tier 1 and move deeper only when the workload requires more control: Tier 1, Quick: Ready-to-use APIs with automatic defaults, including Watch, Memo, CadenceGate, typed stores, StablePool, DirtySet, row rings, double buffers and WeightedSampler. Tier 2, Composable: Explicit lifecycles, configuration and representation policies through IntIndex, IntBuckets, SlotCache, RingCursor and Revision. Tier 3, Expert: Physical addressing, unchecked operations and scoped raw mutation for measured hot paths. Ordinary read-only views are not Tier 3. Editor warnings: Methods such as get() , set() , push() and clear() intentionally match Pine's collection vocabulary. Any shadowing-method warning is cosmetic; the receiver's type determines which method runs. ---------------------------------------------------------------------------------------------------------------- 🔷 COMPLETE, COPY-PASTE EXAMPLES The fragments above isolate one idea at a time. These two copy-paste indicators combine them in practical workflows, using native Pine where it is simpler and OptiPine where it removes real work. 🔸 Complete example 1: high-level cached stress model What it does: The indicator plots a probability-weighted downside estimate for the current trend and volatility regime, while exposing both regime values in the Data Window. The EMA and ATR calculations run normally on every bar. Their rounded regimes change less often, so Memo recalculates the 401-scenario model only when one of those regimes changes and serves the cached result between changes. //@version=6 indicator("OptiPine - Cached Regime Stress", overlay = false) import Alien_Algorithms/OptiPine/1 as op // Test 401 possible moves, giving more weight to common moves. // This function is pure: its result depends only on its inputs. estimateDownside(float trendInAtr, float atrPercent) => float result = na if not na(trendInAtr) and not na(atrPercent) and atrPercent > 0 float weightedDownside = 0.0 float totalWeight = 0.0 for scenario = -200 to 200 float standardShock = scenario / 40.0 float weight = math.exp(-0.5 * standardShock * standardShock) float projectedMove = (trendInAtr + standardShock) * atrPercent float downside = math.max(-projectedMove, 0.0) weightedDownside += downside * weight totalWeight += weight result := totalWeight > 0 ? weightedDownside / totalWeight : na result // Stateful Pine calculations stay outside the Memo guard. float ema20 = ta.ema(close, 20) float ema50 = ta.ema(close, 50) float atr14 = ta.atr(14) float trendInAtr = atr14 > 0 ? (ema20 - ema50) / atr14 : na float atrPercent = close > 0 ? atr14 / close * 100.0 : na // Quantization makes the dependencies describe a regime, not every tick. float trendRegime = math.round( math.max(-3.0, math.min(3.0, trendInAtr)) * 10.0) / 10.0 float volatilityRegime = math.round(atrPercent * 4.0) / 4.0 var op.FloatMemo downsideStress = op.floatMemo() if downsideStress.staleOn(trendRegime, volatilityRegime) downsideStress.store( estimateDownside(trendRegime, volatilityRegime)) float stress = downsideStress.get() plot(stress, "Expected downside (%)", color.orange, linewidth = 2) plot(trendRegime, "Trend regime (ATR units)", display = display.data_window) plot(volatilityRegime, "Volatility regime (%)", display = display.data_window) 🔸 Complete example 2: advanced zone-cluster engine What it does: The indicator draws recent pivot levels, thickens those near the current price, plots the strongest price cluster and reports its key statistics in the Data Window. StablePool preserves drawing slots, the ring tracks retirement order, DirtySet queues redraws, IntBuckets forms price clusters and IntFloatStore looks up their strength. Relevant benchmarks: These are component results, not a total for this 32-zone indicator. In larger matching workloads, DirtySet saved 93% at 1% dirty and IntBuckets averaged 19% with 64 keys. For typed lookup, direct addressing saved 21% over a map on compact keys, while a map saved 91% over linear search at 32 entries. Automatic mode selects the representation. StablePool and the ring manage recycling. The script still scans live zones for proximity changes, then DirtySet avoids unnecessary drawing updates. //@version=6 indicator("OptiPine - Zone Cluster Engine", overlay = true, max_lines_count = 100) import Alien_Algorithms/OptiPine/1 as op int pivotLength = input.int(5, "Pivot length", minval = 1) int maxZones = input.int(32, "Maximum zones", minval = 4, maxval = 100) int bucketTicks = input.int(25, "Cluster size in ticks", minval = 1) float bucketSize = syminfo.mintick * bucketTicks // Stateful Pine calculations remain outside every conditional rebuild. float pivotHigh = ta.pivothigh(high, pivotLength, pivotLength) float pivotLow = ta.pivotlow(low, pivotLength, pivotLength) float pivotStrength = math.max(nz(volume , 1.0), 1.0) float highlightDistance = ta.atr(14) var op.StablePool zones = op.stablePool() var op.IntRowRing zoneOrder = op.intRowRing(maxZones, 1) var op.DirtySet dirtyZones = op.dirtySet(maxZones) var array zonePrices = array.new(maxZones, na) var array zoneStrengths = array.new(maxZones, 0.0) var array zoneTimes = array.new(maxZones, na) var array resistance = array.new(maxZones, false) var array highlighted = array.new(maxZones, false) var array zoneLines = array.new(maxZones) var op.IntBuckets zonesByBucket = op.intBuckets() var op.IntFloatStore strengthByBucket = op.intFloatStore() // Retained build storage is resized and overwritten, never cleared and repopulated. var array bucketKeyByPosition = array.new() var array aggregateKeys = array.new() var array aggregateStrengths = array.new() var int strongestBucketKey = na var float strongestBucketStrength = na var int strongestZoneCount = 0 dirtyZones.begin() bool topologyChanged = barstate.isfirst // Logical pivot IDs receive stable, reusable physical drawing slots. for event = 0 to 1 float level = event == 0 ? pivotHigh : pivotLow if barstate.isconfirmed and not na(level) int pivotBar = bar_index - pivotLength int pivotTime = time int zoneId = pivotBar * 2 + event int slot = zones.find(zoneId) // Only a new logical pivot enters the retirement queue. if slot < 0 if zoneOrder.rowCount() == maxZones int oldestId = zoneOrder.at(0, 0) zones.release(oldestId) = zones.acquire(zoneId) slot := newSlot zoneOrder.pushValue(zoneId) zonePrices.set(slot, level) zoneStrengths.set(slot, pivotStrength) zoneTimes.set(slot, pivotTime) resistance.set(slot, event == 0) highlighted.set(slot, false) dirtyZones.mark(slot) topologyChanged := true // Proximity can mark a newly created slot again; DirtySet still stores it once. for slot in zones.slots() bool isHighlighted = math.abs(close - zonePrices.get(slot)) <= highlightDistance if isHighlighted != highlighted.get(slot) highlighted.set(slot, isHighlighted) dirtyZones.mark(slot) // Only changed drawings cross the line API boundary. for slot in dirtyZones.values() float level = zonePrices.get(slot) color baseColor = resistance.get(slot) ? color.red : color.lime line zoneLine = zoneLines.get(slot) if na(zoneLine) zoneLine := line.new(zoneTimes.get(slot), level, time, level, xloc = xloc.bar_time) zoneLines.set(slot, zoneLine) line.set_xy1(zoneLine, zoneTimes.get(slot), level) line.set_xy2(zoneLine, time, level) line.set_extend(zoneLine, extend.right) line.set_width(zoneLine, highlighted.get(slot) ? 3 : 1) line.set_color(zoneLine, color.new(baseColor, highlighted.get(slot) ? 0 : 55)) // Rebuild grouped lookup only after the explicit creation event. if topologyChanged array liveSlots = zones.slots() int liveCount = liveSlots.size() op.resizeInt(bucketKeyByPosition, liveCount, 0) if liveCount > 0 for position = 0 to liveCount - 1 int slot = liveSlots.get(position) int bucketKey = int(math.round(zonePrices.get(slot) / bucketSize)) bucketKeyByPosition.set(position, bucketKey) // Repeated bucket keys accumulate several physical zone slots. zonesByBucket.buildFromPairs(bucketKeyByPosition, liveSlots) int bucketCount = zonesByBucket.bucketCount() op.resizeInt(aggregateKeys, bucketCount, 0) op.resizeFloat(aggregateStrengths, bucketCount, 0.0) strongestBucketKey := na strongestBucketStrength := na strongestZoneCount := 0 if bucketCount > 0 for bucketSlot = 0 to bucketCount - 1 int bucketKey = zonesByBucket.keyAt(bucketSlot) = zonesByBucket.rangeBySlot(bucketSlot) float totalStrength = 0.0 if count > 0 for position = start to start + count - 1 int zoneSlot = zonesByBucket.valueAt(position) totalStrength += zoneStrengths.get(zoneSlot) aggregateKeys.set(bucketSlot, bucketKey) aggregateStrengths.set(bucketSlot, totalStrength) if na(strongestBucketStrength) or totalStrength > strongestBucketStrength strongestBucketKey := bucketKey strongestBucketStrength := totalStrength strongestZoneCount := count strengthByBucket.build(aggregateKeys, aggregateStrengths) // Query the current price cluster directly and display the strongest cluster. int currentBucketKey = int(math.round(close / bucketSize)) float nearbyStrength = strengthByBucket.get(currentBucketKey, 0.0) float strongestClusterPrice = na(strongestBucketKey) ? na : strongestBucketKey * bucketSize plot(strongestClusterPrice, "Strongest zone cluster", color.orange, linewidth = 2, style = plot.style_stepline) plot(nearbyStrength, "Strength near current price", display = display.data_window) plot(strongestBucketStrength, "Strongest cluster strength", display = display.data_window) plot(strongestZoneCount, "Zones in strongest cluster", display = display.data_window) plot(dirtyZones.size(), "Drawings updated", display = display.data_window) ---------------------------------------------------------------------------------------------------------------- 🔷 API REFERENCE This is a compact index of the main public entry points. 🔸 Watch and Memo: changed(source) handles one scalar, primitive array or row ring. For several dependencies, use begin() , watch*() and finish() . Typed Memos add staleOn() , store() , get() and invalidate() . 🔸 Revision and Cadence: revision() exposes bump() , current() and changedSince() for manual change tracking. cadenceGate() provides due() and change-aware dueWhenChanged() scheduling. 🔸 Row Rings: floatRowRing() and intRowRing() provide push() , width-one pushValue() , at() , setAt() , newestAt() , chronological() and gather() . 🔸 RingCursor: Circular addressing for caller-owned arrays. Use reserve() to advance, physical() and logical() to translate positions, and newest() or oldest() to locate retained rows. 🔸 StablePool: acquire() and release() manage stable key-to-slot assignments. Lookup and traversal use find() , contains() , keyAt() , slots() and size() . Recycled slots retain their caller-owned payload until overwritten. 🔸 SlotCache: Frame-based stable allocation follows begin() , acquire() , finish() . active() , retired() and size() expose its state. 🔸 DirtySet: begin() starts a cycle; mark() , markMany() and markRange() add entries. Read the distinct work list with values() and size() . 🔸 Typed Stores: intIntStore() , intFloatStore() , intBoolStore() , intStringStore() and intColorStore() map integer keys to primitive values. Build with build() , then use get() , set() , contains() or getMany() . 🔸 IntIndex: A shared integer key-to-slot directory for custom payloads and explicit lookup policy. Build with buildBegin() , add() or addMany() and buildFinish() ; query with find() , keyAt() and findMany() . IndexConfig controls representation and duplicate policy. 🔸 IntBuckets: A one-key-to-many-integers index. Build directly with buildFromPairs() , or incrementally with buildBegin() , add() or addMany() and buildFinish() . Read groups with rangeByKey() and valueAt() . 🔸 Double Buffers: intDoubleBuffer() and floatDoubleBuffer() retain current and previous arrays. swap() exchanges them; swapSized() also sizes and refills the new current buffer. 🔸 Weighted Sampling: weightedSampler() provides weight updates, sample() , sampleMany() , probability() and total() . It maps caller-supplied fractions; it does not generate randomness. weightedIndex() adds circular ranges and explicit policy control. 🔸 Storage Utilities: ensureSize*() , resize*() , refill*() and sameExact*() handle primitive arrays. Other helpers cover flat/matrix conversion, transposition and bulk ring reads. ---------------------------------------------------------------------------------------------------------------- 🔷 WHY OPTIPINE EXISTS Pine's limits are real, but standard architecture often reaches them long before the idea itself has to. Repeating unchanged calculations, shifting rolling storage, scanning mostly untouched collections and rebuilding state all consume the same execution budget the feature needs to exist. OptiPine reclaims that budget. Expensive models can run only when their inputs change. Large dashboards can refresh only what moved. Dynamic object systems can grow and recycle storage without reorganizing everything around them. The APIs stay approachable, while the architecture underneath is built for workloads that would normally force a Pine project to scale back. At large scale, optimization is no longer simply about feature speed. It is the factor that dictates whether an ambitious idea can ship at all. ---------------------------------------------------------------------------------------------------------------- This work is licensed under (CC BY-NC-SA 4.0) , meaning usage is free for non-commercial purposes given that Alien_Algorithms is credited in the description for the underlying software. For commercial use licensing, contact Alien_Algorithms The publication diagram has been rendered natively by Pine3D .

Library

by Alien_Algorithms

VWAP Slope Trend Filter # VWAP Slope Trend Filter The **VWAP Slope Trend Filter** is designed to identify the current intraday market direction by analyzing both the position and the slope of the Volume Weighted Average Price (VWAP). Instead of simply checking whether price is above or below VWAP, the indicator measures how strongly VWAP is rising or falling. This helps filter out flat or sideways market conditions where trend-following entries are more likely to fail. The VWAP slope is normalized using ATR, allowing the filter to adapt to different levels of market volatility. ## Trend Colors **Green VWAP – Bullish Trend** The VWAP is rising with sufficient momentum. Traders can use this condition as a filter for long setups. **Red VWAP – Bearish Trend** The VWAP is falling with sufficient momentum. Traders can use this condition as a filter for short setups. **Gray VWAP – Neutral / Range** The VWAP slope is too weak to confirm a clear trend. These conditions can be avoided to reduce trades during sideways markets. ## Main Features * Session VWAP * ATR-normalized VWAP slope * Bullish, bearish, and neutral trend detection * Adjustable slope sensitivity * Adjustable slope lookback length * Dynamic VWAP coloring * Optional background trend highlighting * Trend-change markers * Bullish and bearish alert conditions ## Example Usage The indicator can be used as a directional filter for another entry system. A possible long setup: 1. Price is above VWAP. 2. VWAP is green and rising. 3. The primary entry indicator produces a long signal. 4. Enter the trade with predefined risk management. A possible short setup: 1. Price is below VWAP. 2. VWAP is red and falling. 3. The primary entry indicator produces a short signal. 4. Enter the trade with predefined risk management. When the VWAP is gray, traders may choose to avoid new positions until a clearer directional trend develops. ## Important This indicator is intended to be used as a **trend filter**, not as a standalone trading system. It does not guarantee profitable trades and should be combined with proper entry rules, stop-loss placement, risk management, and backtesting. The optimal Slope Length and Minimum Slope settings may vary depending on the market, trading session, and timeframe.

Indicator

evancator dfgargkldsh;fngvndgvawsdfvb kfadngbqawilesfhfgwredftgqwyuehftbyuisdgasdhifgbsaidghfwsrbese

Indicator

by treyfinance33

Reticle - Structural Reversal Grid Why This Works Financial markets rarely move in uninterrupted straight lines. Asset prices expand in directional vectors, exhaust themselves, and retrace back toward their origins to trap counter-trend traders before continuing. Reticle is designed to map this structural reality geometrically. Most traders rely on static, horizontal support and resistance levels. The Reticle engine relies on the mathematical squaring of time and price. By anchoring a vector to a verified structural leg (A to B), the script projects a dynamic diagonal trend floor (the "Death Line") and mathematically subdivides the entire move. Furthermore, historical testing across crypto and legacy markets consistently demonstrates that the 50% to 62.5% retracement band is the highest-probability zone for trend continuation to occur following a structural push. How This Works Reticle operates as a dual-engine geometric tracker: The Anchoring Engine: It auto-detects the dominant macro swing (highest high and lowest low over a specified lookback period) to find the current active leg in the market. It marks the start of the move as Anchor A and the climax as Anchor B. The Geometry Engine: Once A and B are locked, it draws an 8x8 fractional lattice to subdivide the zone, extends a golden Exhaustion Box highlighting the 50–62.5% retracement levels, and calculates the true geometric "Death Line." The slope of this line dynamically adjusts to the actual ratio of the move, preventing the distortion that usually ruins diagonal trendlines across varying chart scales. How to Use Reticle The primary utility of this script is finding high-confluence continuation entries and identifying exact structural invalidation points. 1. Finding Entries in the Exhaustion Zone Wait for an impulsive move to define Anchors A and B. As the price pulls back from B, watch for it to enter the golden 50–62.5% Exhaustion Box. This is your strike zone. You want to see the price wick into this box and print a strong rejection candle that closes back outside of it. The box dynamically flares red the deeper price pushes into it, visually highlighting peak tension. 2. Managing the Trade via the Death Line The red diagonal Death Line originating from Anchor A acts as the ultimate structural invalidation. It rises in tandem with time. If the asset respects its market geometry, it should bounce out of the Exhaustion Box and remain on the "safe" side of the Death Line. 3. Trading the Break If a candle cleanly closes across the Death Line (marked on the chart by a red ✕), the geometric structure of that leg is broken. If you are in a trend-continuation trade, this is your hard exit signal. Conversely, advanced traders can use this Death Line break as an entry trigger to play the structural reversal. Settings Guide Every chart and asset breathes differently. Use these settings to perfectly calibrate Reticle to your chosen instrument. Anchor Mode & MTF Auto Anchors: Leave this checked to let the script find the A and B swing points automatically. Unchecking it disables the script until you define manual time anchors. Use Higher Timeframe (MTF) Swings: A powerful feature that allows you to calculate the dominant A→B swing on a macro timeframe (like the Daily) while executing your trades on a lower timeframe (like a 40-minute chart) without losing the structural geometry. Auto Engine: Choose between "Dominant Swing" (finds the absolute high and low of the lookback window) or "Latest Pivots" (strictly grabs the last two confirmed pivot points). Dominant Swing Lookback / Pivot Strengths: Adjusts how many bars the script scans to define a swing. Increase these numbers to track massive macro trends; decrease them to trade rapid intraday micro-structures. Engine Parameters & Squaring Death Line Slope Basis: Dictates the math behind the red invalidation line. Auto (A→B Ratio): Recommended. The slope perfectly mirrors the steepness of the structural push. Squaring Factor: Forces the line to rise by a fixed, absolute price amount per bar, achieving true Gann-style 1x1 squaring. True Squaring (Price Units per Bar): Active only if "Squaring Factor" is chosen above. Input exactly how many dollars/cents the line should rise per bar (e.g., 100 means a $100 climb per candle). Death Line Angle ×: Multiplies the final slope. 0.5 acts as a 1x2 support line hugging price action. 1.0 acts as a steep 1x1. Exhaustion Band Forward Extension: Determines how many bars into the future the golden retracement box is drawn. Toggle Visuals: Checkboxes to hide or show the Lattice, the Band, the Death Line, and the A→B Vector Spine to keep your chart uncluttered. Alerts Select exactly which structural events you want to be notified about. Reticle features a unified alert system that ensures signals are only fired on confirmed candle closes to avoid false wick triggers. Format Alerts as JSON: Check this box if you are connecting the indicator to automated trading bots via webhooks. It outputs a clean, machine-readable data payload instead of standard text. Status Table Show Status Table: Toggles the HUD panel that provides live data readouts regarding the current vector size, slope settings, and the exact percentage distance between current price and the Death Line invalidation. Position: Move the data panel to any corner of the chart to prevent it from covering active price action.

Indicator

MTF SMC / ICT Market State Engine # MTF SMC / ICT Market State & Reversal Dashboard A multi-timeframe market-structure dashboard designed for traders using **Smart Money Concepts (SMC), ICT, liquidity and price-action analysis**. The indicator combines structural information across **1D, 4H, 15M and 1M** into a single compact dashboard, helping traders identify the current **directional bias, market stage, liquidity condition and potential reversals** without having to manually compare multiple timeframes. ### What the Dashboard Shows For each timeframe, the dashboard displays: * **Bias** — Bullish, Bearish or Neutral * **Structure** — HH/HL, LH/LL, BOS, MSS or CHOCH * **Market Stage** — Accumulation, Liquidity Build, Manipulation, Confirmed Shift, Expansion, Retracement, Continuation, Exhaustion, Distribution or Reversal * **Liquidity** — BSL, SSL, EQH, EQL and recently swept liquidity * **Reversal State** — Normal, Reversal Warning, Reversal Developing or Confirmed Reversal * **Structural Confidence** — Low, Medium or High ### Multi-Timeframe Bias The indicator treats each timeframe according to its role in the market hierarchy: **1D → Macro Bias** **4H → Primary/Intraday Bias** **15M → Setup & Market Structure** **1M → Execution Structure** This allows the indicator to distinguish between a genuine trend reversal and a simple lower-timeframe retracement. For example: **1D Bullish → 4H Bullish → 15M Bearish → 1M Bearish** may be classified as: > **HTF BULLISH / LTF RETRACEMENT** rather than incorrectly changing the overall bias to bearish. ### Reversal Detection The indicator does not treat every liquidity sweep or MSS as a confirmed reversal. Reversal conditions progress through four stages: **Normal → Reversal Warning → Reversal Developing → Confirmed Reversal** A stronger reversal requires multiple structural factors such as: * Liquidity sweep * Displacement * MSS/CHOCH * Protected high/low violation * Structural follow-through This helps separate **liquidity manipulation and retracement** from an actual change in market structure. ### Market-State Engine Rather than displaying disconnected SMC signals, the indicator interprets them as part of a market cycle: **Accumulation → Liquidity Build → Manipulation → Confirmed Shift → Expansion → Retracement → Continuation → Exhaustion → Reversal** The purpose is to answer four key questions: > **What is the market direction?** > **What stage is the market currently in?** > **Where is the relevant liquidity?** > **Is the market continuing, retracing or beginning a reversal?** ### Designed for SMC / ICT Traders The indicator is intended as a **market-analysis and decision-support tool**, not an automatic trading system. It does not attempt to predict future price or provide guaranteed buy/sell signals. Instead, it organizes multi-timeframe structural information into a clear framework so traders can make more consistent discretionary decisions. **Primary workflow:** **1D Bias → 4H Structure → 15M Setup → 1M Confirmation → Liquidity → Market Stage → Reversal Status**

Indicator

VWAP 1m Calculates VWAP for each candle using the underlying 1-minute price and volume data, instead of estimating from the HTF candle's open/high/low/close. Always pulls from 1m. No inputs, no bands, just one VWAP line per candle.

Indicator

In-depth global business and economic analysis Comprehensive trading education and market insights