PROTECTED SOURCE SCRIPT
Star V12
⭐ Star Engine — Multi-Component, Multi-Timeframe Trade Execution System
The Star Engine is a stateful trade execution and analytics system designed to transform indicator confluence into structured, measurable trade runs. Rather than producing isolated buy/sell signals, the engine decomposes market behavior into pressure, confirmation, event grouping, and trade lifecycle management. Each component plays a specific role, and no single component is sufficient on its own. Below is a detailed breakdown of each subsystem and why it exists.
💣 Bomb Engine — Directional Pressure Measurement
The Bomb Engine is responsible for identifying directional pressure in the market. It evaluates whether price action exhibits sustained momentum in one direction, independent of whether that direction is immediately tradable.
What Bomb Uses
Bomb aggregates momentum- and trend-oriented inputs such as MACD-based momentum direction, momentum persistence and continuation logic, directional bias filters, and impulse strength evaluation. All inputs are evaluated across multiple timeframes, with each timeframe contributing independently.
How Bomb Works
Each timeframe produces a directional contribution (bullish, bearish, or neutral). Contributions are aggregated into a net Bomb total. The total is mapped into discrete tone buckets (blue, green, red, black, etc.). Higher totals indicate stronger directional dominance.
What Bomb Tells You
Bomb answers one question: Is there directional pressure building or persisting? It does not determine entry timing, exhaustion, or trade quality. Bomb is context, not execution. This allows Bomb to be early without being responsible for precision.
✨ Golden Engine — Structural Confirmation & Regime Filtering
The Golden Engine evaluates whether the directional pressure detected by Bomb is structurally supported. Golden exists to prevent entries during momentum exhaustion, conflicting timeframe regimes, and counter-structure moves.
What Golden Uses
Golden relies on a different indicator stack than Bomb, focused on confirmation and balance, including RSI regime classification (not simple overbought/oversold), momentum agreement vs divergence, trend-following vs counter-trend positioning, overextension detection, and compression and rotational behavior. Each timeframe is evaluated independently using the same logic.
The Role of RSI in Golden
RSI in Golden is used to identify regimes, not signals. It answers questions such as: Is momentum expanding or decaying? Is the move early, mid-structure, or extended? Do multiple timeframes share compatible RSI states? If RSI regimes conflict across timeframes, Golden will not confirm. This is one of the main mechanisms that makes Golden selective.
Momentum & Alignment Logic
Golden evaluates whether momentum supports continuation, is fragmenting, is diverging from price, or is contradicting higher-timeframe structure. If lower-timeframe impulses are not supported by higher-timeframe structure, Golden suppresses confirmation — even if Bomb remains strong.
What Golden Guarantees
Golden does not guarantee profitable trades. Golden guarantees that the detected directional pressure is not internally contradictory across RSI regimes, momentum behavior, and timeframe structure. This replaces vague terms like “clean” with explicit structural conditions.
🔗 Multi-Timeframe Aggregation (MTF)
Both Bomb and Golden operate on a multi-timeframe voting system. Lower timeframes capture early impulses, higher timeframes enforce structural context, each timeframe votes independently, conflicts weaken totals, and alignment strengthens totals. This creates temporal confluence, not just price-based confluence.
⭐ Star Events — Qualified Market Impulses
A Star (⭐) is created only when Bomb is active, Golden is active, both agree on direction, and all gating rules pass (thresholds, time filters, modes). A Star represents a qualified impulse, not a trade. Stars are atomic events used by the execution layer.
⏱ Star Clusters — Trade Run State
The Star Cluster groups Stars into runs. The first Star starts a cluster, anchor price, bar, and time are recorded, each additional Star increments the cluster count, and all Stars belong to the same run until exit. This prevents duplicate entries, signal spam, and overtrading in volatile conditions.
⛔ Reset Gap Logic — Temporal Control
To prevent rapid re-entry, a minimum time gap is required to start a new run. Stars occurring too close together are merged. Reset does not terminate active runs. This enforces time-based discipline, not indicator-based guessing.
1➡️ Entry Logic — Confirmation-Based Execution
The engine never enters on the first Star. Instead, the user defines 🔢 N (Entry Star Index). Entry occurs only on the Nth Star, and that bar is marked 1➡️🔢N. This ensures entries occur after persistence, not detection. At ENTRY, Best = 0.00 and Worst = 0.00. Statistics measure real trade performance, not early signal noise.
📊 STAT Engine — Live Trade Measurement
Once entry is active, the STAT engine tracks ⏱ run progression, 🏅 maximum favorable excursion, and 📉 maximum adverse excursion. Mechanics: uses highs and lows, not closes; updates every bar; entry bar resets stats; historical bars marked 🎨. This creates an objective performance envelope for every trade.
🛑 Exit Engine — Deterministic Outcomes
Trades are exited using explicit rules: 🏅 WIN → profit threshold reached, 📉 LOSE → risk threshold breached, ⏱ QUIT → structural or safety exit.
Safety Exits
🐢 Idle Stop — no Stars for N bars.
🧯 Freeze Failsafe — STAT inactivity.
QUIT is a controlled termination, not failure. Each exit is recorded with a short cause tag.
🧾 Trade Memory & Journaling
Every trade produces immutable records. Entry: time, price, side, confirmation index. Exit: time, price, PnL, result, cause. These records power tables, alerts, JSON output, and external automation.
📊 Time-Block Performance (NY Clock)
Performance is grouped by real time, not bar count. Rolling NY blocks (e.g. 3 hours). Independent statistics per block. Live trades persist across block boundaries. This enables session-based analysis.
🔔 Alerts & Automation
Alerts are state-based: Entry confirmed → Long / Short alert. Trade closed → Exit alert. Optional JSON output allows integration with bots, journals, and dashboards.
Summary
The Star Engine is a component-based trade execution system, where Bomb measures pressure, Golden validates structure, Stars qualify impulses, clusters define runs, entry is delayed by confirmation, stats measure reality, exits are deterministic, and results are time-aware. It is not designed to “predict the market”, but to control how trades are formed, managed, and evaluated.
The Star Engine is a stateful trade execution and analytics system designed to transform indicator confluence into structured, measurable trade runs. Rather than producing isolated buy/sell signals, the engine decomposes market behavior into pressure, confirmation, event grouping, and trade lifecycle management. Each component plays a specific role, and no single component is sufficient on its own. Below is a detailed breakdown of each subsystem and why it exists.
💣 Bomb Engine — Directional Pressure Measurement
The Bomb Engine is responsible for identifying directional pressure in the market. It evaluates whether price action exhibits sustained momentum in one direction, independent of whether that direction is immediately tradable.
What Bomb Uses
Bomb aggregates momentum- and trend-oriented inputs such as MACD-based momentum direction, momentum persistence and continuation logic, directional bias filters, and impulse strength evaluation. All inputs are evaluated across multiple timeframes, with each timeframe contributing independently.
How Bomb Works
Each timeframe produces a directional contribution (bullish, bearish, or neutral). Contributions are aggregated into a net Bomb total. The total is mapped into discrete tone buckets (blue, green, red, black, etc.). Higher totals indicate stronger directional dominance.
What Bomb Tells You
Bomb answers one question: Is there directional pressure building or persisting? It does not determine entry timing, exhaustion, or trade quality. Bomb is context, not execution. This allows Bomb to be early without being responsible for precision.
✨ Golden Engine — Structural Confirmation & Regime Filtering
The Golden Engine evaluates whether the directional pressure detected by Bomb is structurally supported. Golden exists to prevent entries during momentum exhaustion, conflicting timeframe regimes, and counter-structure moves.
What Golden Uses
Golden relies on a different indicator stack than Bomb, focused on confirmation and balance, including RSI regime classification (not simple overbought/oversold), momentum agreement vs divergence, trend-following vs counter-trend positioning, overextension detection, and compression and rotational behavior. Each timeframe is evaluated independently using the same logic.
The Role of RSI in Golden
RSI in Golden is used to identify regimes, not signals. It answers questions such as: Is momentum expanding or decaying? Is the move early, mid-structure, or extended? Do multiple timeframes share compatible RSI states? If RSI regimes conflict across timeframes, Golden will not confirm. This is one of the main mechanisms that makes Golden selective.
Momentum & Alignment Logic
Golden evaluates whether momentum supports continuation, is fragmenting, is diverging from price, or is contradicting higher-timeframe structure. If lower-timeframe impulses are not supported by higher-timeframe structure, Golden suppresses confirmation — even if Bomb remains strong.
What Golden Guarantees
Golden does not guarantee profitable trades. Golden guarantees that the detected directional pressure is not internally contradictory across RSI regimes, momentum behavior, and timeframe structure. This replaces vague terms like “clean” with explicit structural conditions.
🔗 Multi-Timeframe Aggregation (MTF)
Both Bomb and Golden operate on a multi-timeframe voting system. Lower timeframes capture early impulses, higher timeframes enforce structural context, each timeframe votes independently, conflicts weaken totals, and alignment strengthens totals. This creates temporal confluence, not just price-based confluence.
⭐ Star Events — Qualified Market Impulses
A Star (⭐) is created only when Bomb is active, Golden is active, both agree on direction, and all gating rules pass (thresholds, time filters, modes). A Star represents a qualified impulse, not a trade. Stars are atomic events used by the execution layer.
⏱ Star Clusters — Trade Run State
The Star Cluster groups Stars into runs. The first Star starts a cluster, anchor price, bar, and time are recorded, each additional Star increments the cluster count, and all Stars belong to the same run until exit. This prevents duplicate entries, signal spam, and overtrading in volatile conditions.
⛔ Reset Gap Logic — Temporal Control
To prevent rapid re-entry, a minimum time gap is required to start a new run. Stars occurring too close together are merged. Reset does not terminate active runs. This enforces time-based discipline, not indicator-based guessing.
1➡️ Entry Logic — Confirmation-Based Execution
The engine never enters on the first Star. Instead, the user defines 🔢 N (Entry Star Index). Entry occurs only on the Nth Star, and that bar is marked 1➡️🔢N. This ensures entries occur after persistence, not detection. At ENTRY, Best = 0.00 and Worst = 0.00. Statistics measure real trade performance, not early signal noise.
📊 STAT Engine — Live Trade Measurement
Once entry is active, the STAT engine tracks ⏱ run progression, 🏅 maximum favorable excursion, and 📉 maximum adverse excursion. Mechanics: uses highs and lows, not closes; updates every bar; entry bar resets stats; historical bars marked 🎨. This creates an objective performance envelope for every trade.
🛑 Exit Engine — Deterministic Outcomes
Trades are exited using explicit rules: 🏅 WIN → profit threshold reached, 📉 LOSE → risk threshold breached, ⏱ QUIT → structural or safety exit.
Safety Exits
🐢 Idle Stop — no Stars for N bars.
🧯 Freeze Failsafe — STAT inactivity.
QUIT is a controlled termination, not failure. Each exit is recorded with a short cause tag.
🧾 Trade Memory & Journaling
Every trade produces immutable records. Entry: time, price, side, confirmation index. Exit: time, price, PnL, result, cause. These records power tables, alerts, JSON output, and external automation.
📊 Time-Block Performance (NY Clock)
Performance is grouped by real time, not bar count. Rolling NY blocks (e.g. 3 hours). Independent statistics per block. Live trades persist across block boundaries. This enables session-based analysis.
🔔 Alerts & Automation
Alerts are state-based: Entry confirmed → Long / Short alert. Trade closed → Exit alert. Optional JSON output allows integration with bots, journals, and dashboards.
Summary
The Star Engine is a component-based trade execution system, where Bomb measures pressure, Golden validates structure, Stars qualify impulses, clusters define runs, entry is delayed by confirmation, stats measure reality, exits are deterministic, and results are time-aware. It is not designed to “predict the market”, but to control how trades are formed, managed, and evaluated.
نص برمجي محمي
تم نشر هذا النص البرمجي كمصدر مغلق. ومع ذلك، يمكنك استخدامه بحرية ودون أي قيود - تعرف على المزيد هنا.
PAG
إخلاء المسؤولية
لا يُقصد بالمعلومات والمنشورات أن تكون، أو تشكل، أي نصيحة مالية أو استثمارية أو تجارية أو أنواع أخرى من النصائح أو التوصيات المقدمة أو المعتمدة من TradingView. اقرأ المزيد في شروط الاستخدام.
نص برمجي محمي
تم نشر هذا النص البرمجي كمصدر مغلق. ومع ذلك، يمكنك استخدامه بحرية ودون أي قيود - تعرف على المزيد هنا.
PAG
إخلاء المسؤولية
لا يُقصد بالمعلومات والمنشورات أن تكون، أو تشكل، أي نصيحة مالية أو استثمارية أو تجارية أو أنواع أخرى من النصائح أو التوصيات المقدمة أو المعتمدة من TradingView. اقرأ المزيد في شروط الاستخدام.