Mizar_LibraryThe "Mizar_Library" is a powerful tool designed for Pine Script™ programmer’s, providing a collection of general functions that facilitate the usage of Mizar’s DCA (Dollar-Cost-Averaging) bot system.
To begin using the Mizar Library, you first need to import it into your indicator script. Insert the following line below your indicator initiation line: import Mizar_Trading/Mizar_Library/1 as mizar (mizar is the chosen alias).
In the import statement, Mizar_Trading.Mizar_Library_v1 refers to the specific version of the Mizar Library you wish to use. Feel free to modify mizar to your preferred alias name.
Once the library is imported, you can leverage its functions by prefixing them with mizar. . This will prompt auto-completion suggestions displaying all the available user-defined functions provided by the Mizar Library.
Now, let's delve into some of the key functions available in the Mizar Library:
DCA_bot_msg(_cmd)
The DCA_bot_msg function accepts an user-defined type (UDT) _cmd as a parameter and returns a string with the complete JSON command for a Mizar DCA bot.
Parameters:
_cmd (bot_params) : ::: User-defined type (UDT) that holds all the necessary information for the bot command.
Returns: A string with the complete JSON command for a Mizar DCA bot.
rounding_to_ticks(value, ticks, rounding_type)
The rounding_to_ticks function rounds a calculated price to the nearest actual price based on the specified tick size.
Parameters:
value (float) : ::: The calculated price as float type, to be rounded to the nearest real price.
ticks (float) : ::: The smallest possible price obtained through a request in your script.
rounding_type (int) : ::: The rounding type for the price: 0 = closest real price, 1 = closest real price above, 2 = closest real price below.
Returns: A float value representing the rounded price to the next tick.
bot_params
Bot_params is an user-defined type (UDT) that represents the parameters required for a Mizar DCA bot.
Fields:
bot_id (series string) : The ID number of your Mizar DCA bot.
api_key (series string) : Your private API key from your Mizar account (keep it confidential!).
action (series string) : The command to perform: "open" (standard) or "close" optional .
tp_perc (series string) : The take profit percentage in decimal form (1% = "0.01") optional .
base_asset (series string) : The cryptocurrency you want to buy (e.g., "BTC").
quote_asset (series string) : The coin or fiat currency used for payment (e.g., "USDT" is standard if not specified) optional .
direction (series string) : The direction of the position: "long" or "short" (only applicable for two-way hedge bots) optional .
To obtain the JSON command string for the alert_function call, you can use the DCA_bot_msg function provided by the library. Simply pass the cmd_msg UDT as an argument and assign the returned string value to a variable.
Here's an example to illustrate the process:
// Import of the Mizar Library to use the included functions
import/Mizar_Trading/Mizar_Library/1 as mizar
// Example to set a variable called “cmd_msg” and all of its parameters
cmd_msg = mizar.bot_params. new()
cmd_msg.action := "open"
cmd_msg.api_key := "top secret"
cmd_msg.bot_id := "9999"
cmd_msg.base_asset := "BTC"
cmd_msg.quote_asset := "USDT"
cmd_msg.direction := "long"
cmd_msg.tp_perc := "0.015"
// Calling the Mizar conversion function named “DCA_bot_msg()” with the cmd_msg as argument to receive the JSON command and save it in a string variable called “alert_msg”
alert_msg = mizar.DCA_bot_msg(cmd_msg)
Feel free to utilize (series) string variables instead of constant strings. By incorporating the Mizar Library into your Pine Script, you gain access to a powerful set of functions and can leverage them according to your specific requirements.
For additional help or support, you can join the Mizar Discord channel. There, you'll find a dedicated Pine Script channel where you can ask any questions related to Pine Script.
Search in scripts for "文华财经tick价格"
SL and TP - ATRThis indicator is using ATR ( Average True Range ) to set the Target point and Stop loss.
Use the pink number as target, always.
If you are in Long position, use the green number as stop loss, so the red number is not useful in Buys.
If you are in Short position, use the Red number as stop loss, so the green number is not useful in Sells.
** Need to enter the numbers in ticks --> VERY IMPORTANT: Write it completely, even the numbers after the point sign but DO NOT WRITE the point sign itself. e.g. : if the target tick on indicator is 123.75, you have to write 12375 ticks for your TP. ( one more example: If the number is 0.0001203 , write 1203 ticks. )
Enter the information of the opening candle.
Most of the times, risk/reward ratio is a bit higher than 1.
Works on multi timeframes. P.S: Haven't checked the weekly timeframe.
Not trying to oversell the indicator, but this is perhaps the best TP/SL specifier.
For beauty purposes, change (Sl @ buy) and (TP @ sell) to histograms.
Histograms are only for visual purposes. Customize the indicator as you want :)) Hope you enjoy
Linear Regression & RSI Multi-Function Screener with Table-LabelHi fellow traders..
Happy to share a Linear Regression & RSI Multi-Function Custom Screener with Table-Labels...
The Screener scans for Linear Regression 2-SD Breakouts and RSI OB/OS levels for the coded tickers and gives Summary alerts
Uses Tables (dynamica resizing) for the scanner output instead of standard labels!
This Screener cum indicator collection has two distinct objectives..
1. Attempt re-entry into trending trades.
2. Attempt Counter trend trades using linear regression , RSI and Zigzag.
Briefly about the Screener functions..
a. It uses TABLES as Labels a FIRST for any Screener on TV.
b. Tables dynamically resize based on criteria..
c. Alerts for breakouts of the UPPER and the LOWER regression channels.(2 SD)
d. In addition to LinReg it also Screens RSI for OB/OS levels so a multifunction Screener.
e. Of course has the standard summary Alerts and programmable format for Custom functions.
f. Uses only the inbuilt Auto Fib and Lin Reg code for the screener.(No proprietary stuff)
g. The auto Zigzag code is derived(Auto fib).
Question what are all these doing in a single screener ??
ZigZag is very useful in determining Trend Up or Down from one Pivot to another.
So Once you have a firm view of the Current Trend for your chosen timeframe and ticker…
We can consider few possible trading scenarios..
a. Re-entry in an Up Trend - Combination of OS Rsi And a Lower Channel breach followed by a re-entry back into the regression channel CAN be used as an effective re-entry.
b. Similarily one can join a Down Trend on OB Rsi and Upper Channel line breach followed by re-entry into the regression channel.
If ZigZag signals a range-bound market, bound within channel lines then the Upper breakout can be used to Sell and vice-versa!
In short many possibilities for using these functions together with Scanner and Alerts.
This facilitates timely PROFITABLE Trending and Counter trend opportunities across multiple tickers.
You must give a thorough READ to the various available tutorials on ZigZag / Regression and Fib retracements before attempting counter trend trades using these tools!!
A small TIP – Markets are sideways or consolidating 70% of the time!!
Acknowledgements: - Thanks a lot DGTRD for the Auto ZigZag code and also for the eagerness to help wherever possible..Respect!!
Disclaimer: The Alerts and Screener are just few tools among many and not any kind of Buy/Sell recommendations. Unless you have sufficient trading experience please consult a Financial advisor before investing real money.
*The alerts are set for crossovers however for viewing tickers trading above or below the channel use code in line 343 and 344 after setting up the Alerts!
** RSI alerts are disabled by default to avoid clutter, but if needed one can activate code lines 441,442,444 and 445
Wish you all, Happy Profitable Trading!
Bitmex BTC Perpetual PremiumThis script tracks the premium of the Bitcoin Perpetual futures at Bimex exchange relative to 3 different reference prices.
The difference between this script and already published scripts is that it tracks the premium relative to 3 different reference prices. This tends to produce slightly different results.
This script is also open source, so you can verify the calculations, or use it as a basis for your own script.
The 3 plots uses the following reference prices:
Blue Area:
Bitmex Index price, ticker: BITMEX:XBT
Red line:
Bitmex Perpetual Premium, ticker XBTUSDPI
(This one is not used as reference, but simply plots the ticker*100)
Orange line:
The reference here is a price calculated by the tickers in trading view based on the Bitmex indices with weighing as follows:
Bitstamp:28,81%
Bittrex:5,5%
Coinbase: 38,07%
Gemini: 7,34%
Kraken: 20,28
Please note that Bitmex changes the bases of its indices regularly. Bitmex might also "rule out" on of these exchanges if there is a short term problem.
Realtime RenkoI've been working on real-time renko for a while as a coding challenge. The interesting problem here is building renko bricks that form based on incoming tick data rather than waiting for bar closes. Every tick that comes through gets processed immediately, and when price moves enough to complete a brick, that brick closes and a new one opens right then. It's just neat because you can run it and it updates as you'd expect with renko, forming bricks based purely on price movement happening in real time rather than waiting for arbitrary time intervals to pass.
The three brick sizing methods give you flexibility in how you define "enough movement" to form a new brick. Traditional renko uses a fixed price range, so if you set it to 10 ticks, every brick represents exactly 10 ticks of movement. This works well for instruments with stable tick sizes and predictable volatility. ATR-based sizing calculates the average true range once at startup using a weighted average across all historical bars, then divides that by your brick value input. If you want bricks that are one full ATR in size, you'd use a brick value of 1. If you want half-ATR bricks, use 2. This inverted relationship exists because the calculation is ATR divided by your input, which lets you work with multiples and fractions intuitively. Percentage-based sizing makes each brick a fixed percentage move from the previous brick's close, which automatically scales with price level and works well for instruments that move proportionally rather than in absolute tick increments.
The best part about this implementation is how it uses varip for state management. When you first load the indicator, there's no history at all. Everything starts fresh from the moment you add it to your chart because varip variables only exist in real-time. This means you're watching actual renko bricks form from real tick data as it arrives. The indicator builds its own internal history as it runs, storing up to 250 completed bricks in memory, but that history only exists for the current session. Refresh the page or reload the indicator and it starts over from scratch.
The visual implementation uses boxes for brick bodies and lines for wicks, drawn at offset bar indices to create the appearance of a continuous renko chart in the indicator pane. Each brick occupies two bar index positions horizontally, which spaces them out and makes the chart readable. The current brick updates in real time as new ticks arrive, with its high, low, and close values adjusting continuously until it reaches the threshold to close and become finalized. Once a brick closes, it gets pushed into the history array and a new brick opens at the closing level of the previous one.
What makes this especially useful for debugging and analysis are the hover tooltips on each brick. Clicking on any brick brings up information showing when it opened with millisecond precision, how long it took to form from open to close, its internal bar index within the renko sequence, and the brick size being used. That time delta measurement is particularly valuable because it reveals the pace of price movement. A brick that forms in five seconds indicates very different market conditions than one that takes three minutes, even though both bricks represent the same amount of price movement. You can spot acceleration and deceleration in trend development by watching how quickly consecutive bricks form.
The pine logs that generate when bricks close serve as breadcrumbs back to the main chart. Every time a brick finalizes, the indicator writes a log entry with the same information shown in the tooltip. You can click that log entry and TradingView jumps your main chart to the exact timestamp when that brick closed. This lets you correlate renko brick formation with what was happening on the time-based chart, which is critical for understanding context. A brick that closed during a major news announcement or at a key support level tells a different story than one that closed during quiet drift, and the logs make it trivial to investigate those situations.
The internal bar indexing system maintains a separate count from the chart's bar_index, giving each renko brick its own sequential number starting from when the indicator begins running. This makes it easy to reference specific bricks in your analysis or when discussing patterns with others. The internal index increments only when a brick closes, so it's a pure measure of how many bricks have formed regardless of how much chart time has passed. You can match these indices between the visual bricks and the log entries, which helps when you're trying to track down the details of a specific brick that caught your attention.
Brick overshoot handling ensures that when price blows through the threshold level instead of just barely touching it, the brick closes at the threshold and the excess movement carries over to the next brick. This prevents gaps in the renko sequence and maintains the integrity of the brick sizing. If price shoots up through your bullish threshold and keeps going, the current brick closes at exactly the threshold level and the new brick opens there with the overshoot already baked into its initial high. Without this logic, you'd get renko bricks with irregular sizes whenever price moved aggressively, which would undermine the whole point of using fixed-range bricks.
The timezone setting lets you adjust timestamps to your local time or whatever reference you prefer, which matters when you're analyzing logs or comparing brick formation times across different sessions. The time delta formatter converts raw milliseconds into human-readable strings showing days, hours, minutes, and seconds with fractional precision. This makes it immediately clear whether a brick took 12.3 seconds or 2 minutes and 15 seconds to form, without having to parse millisecond values mentally.
This is the script version that will eventually be integrated into my real-time candles library. The library version had an issue with tooltips not displaying correctly, which this implementation fixes by using a different approach to label creation and positioning. Running it as a standalone indicator also gives you more control over the visual settings and makes it easier to experiment with different brick sizing methods without affecting other tools that might be using the library version.
What this really demonstrates is that real-time indicators in Pine Script require thinking about state management and tick processing differently than historical indicators. Most indicator code assumes bars are immutable once closed, so you can reference `close ` and know that value will never change. Real-time renko throws that assumption out because the current brick is constantly mutating with every tick until it closes. Using varip for state variables and carefully tracking what belongs to finalized bricks versus the developing brick makes it possible to maintain consistency while still updating smoothly in real-time. The fact that there's no historical reconstruction and everything starts fresh when you load it is actually a feature, not a limitation, because you're seeing genuine real-time brick formation rather than some approximation of what might have happened in the past.
ATR DAILY PROGRESSION)Indicator: ATR Daily Progression — Final Compact Edition
1. Indicator Objective
The ATR Daily Progression indicator measures the progression of intraday volatility as a percentage of the daily Average True Range (ATR).
It provides a quick visual overview of whether the market has reached or exceeded its average daily range of movement.
This helps traders avoid entering low-probability continuation trades once the day’s ATR is already completed.
2. Visual Presentation
Horizontal bar ranging from 0% to 150% of the ATR.
Green color up to 100%, then red beyond that point.
Main ticks: 0, 25, 50, 75, 90, 100, and 150%.
Full-height white vertical lines at 0%, 100%, and 150%.
A floating badge displaying the current ATR completion percentage, always visible.
Compact Height mode enabled by default for optimal visual integration.
3. Key Features
Function Description
Precise alignment The transition from green to red occurs exactly after the 100% tick.
Audio & visual alerts Triggered at 75%, 90%, 100%, and 150%.
Session flash effects The filled bar blinks when the ATR is reached (100%) or exceeded (150%).
Dynamic badge Displays the current ATR %, green before 100%, red after.
Compact layout Three-line table format for better chart integration.
4. Recommended Settings
ATR Length (Daily): 14
Bar width (steps): 32–40 (depending on chart size)
Always green below 100%: enabled
Show floating % badge: enabled
Compact Height: enabled by default
Flash at 75% and 90%: enabled
Flash at 100% and 150%: enabled
5. Strategic Use
The ATR Done Today is a visual discipline tool designed to help traders:
Identify when the market has likely completed its daily move.
Avoid late-session counter-trend trades.
Visualize volatility compression or expansion.
Determine optimal times to take profits or pause trading.
ATAI Volume analysis with price action V 1.00ATAI Volume Analysis with Price Action
1. Introduction
1.1 Overview
ATAI Volume Analysis with Price Action is a composite indicator designed for TradingView. It combines per‑side volume data —that is, how much buying and selling occurs during each bar—with standard price‑structure elements such as swings, trend lines and support/resistance. By blending these elements the script aims to help a trader understand which side is in control, whether a breakout is genuine, when markets are potentially exhausted and where liquidity providers might be active.
The indicator is built around TradingView’s up/down volume feed accessed via the TradingView/ta/10 library. The following excerpt from the script illustrates how this feed is configured:
import TradingView/ta/10 as tvta
// Determine lower timeframe string based on user choice and chart resolution
string lower_tf_breakout = use_custom_tf_input ? custom_tf_input :
timeframe.isseconds ? "1S" :
timeframe.isintraday ? "1" :
timeframe.isdaily ? "5" : "60"
// Request up/down volume (both positive)
= tvta.requestUpAndDownVolume(lower_tf_breakout)
Lower‑timeframe selection. If you do not specify a custom lower timeframe, the script chooses a default based on your chart resolution: 1 second for second charts, 1 minute for intraday charts, 5 minutes for daily charts and 60 minutes for anything longer. Smaller intervals provide a more precise view of buyer and seller flow but cover fewer bars. Larger intervals cover more history at the cost of granularity.
Tick vs. time bars. Many trading platforms offer a tick / intrabar calculation mode that updates an indicator on every trade rather than only on bar close. Turning on one‑tick calculation will give the most accurate split between buy and sell volume on the current bar, but it typically reduces the amount of historical data available. For the highest fidelity in live trading you can enable this mode; for studying longer histories you might prefer to disable it. When volume data is completely unavailable (some instruments and crypto pairs), all modules that rely on it will remain silent and only the price‑structure backbone will operate.
Figure caption, Each panel shows the indicator’s info table for a different volume sampling interval. In the left chart, the parentheses “(5)” beside the buy‑volume figure denote that the script is aggregating volume over five‑minute bars; the center chart uses “(1)” for one‑minute bars; and the right chart uses “(1T)” for a one‑tick interval. These notations tell you which lower timeframe is driving the volume calculations. Shorter intervals such as 1 minute or 1 tick provide finer detail on buyer and seller flow, but they cover fewer bars; longer intervals like five‑minute bars smooth the data and give more history.
Figure caption, The values in parentheses inside the info table come directly from the Breakout — Settings. The first row shows the custom lower-timeframe used for volume calculations (e.g., “(1)”, “(5)”, or “(1T)”)
2. Price‑Structure Backbone
Even without volume, the indicator draws structural features that underpin all other modules. These features are always on and serve as the reference levels for subsequent calculations.
2.1 What it draws
• Pivots: Swing highs and lows are detected using the pivot_left_input and pivot_right_input settings. A pivot high is identified when the high recorded pivot_right_input bars ago exceeds the highs of the preceding pivot_left_input bars and is also higher than (or equal to) the highs of the subsequent pivot_right_input bars; pivot lows follow the inverse logic. The indicator retains only a fixed number of such pivot points per side, as defined by point_count_input, discarding the oldest ones when the limit is exceeded.
• Trend lines: For each side, the indicator connects the earliest stored pivot and the most recent pivot (oldest high to newest high, and oldest low to newest low). When a new pivot is added or an old one drops out of the lookback window, the line’s endpoints—and therefore its slope—are recalculated accordingly.
• Horizontal support/resistance: The highest high and lowest low within the lookback window defined by length_input are plotted as horizontal dashed lines. These serve as short‑term support and resistance levels.
• Ranked labels: If showPivotLabels is enabled the indicator prints labels such as “HH1”, “HH2”, “LL1” and “LL2” near each pivot. The ranking is determined by comparing the price of each stored pivot: HH1 is the highest high, HH2 is the second highest, and so on; LL1 is the lowest low, LL2 is the second lowest. In the case of equal prices the newer pivot gets the better rank. Labels are offset from price using ½ × ATR × label_atr_multiplier, with the ATR length defined by label_atr_len_input. A dotted connector links each label to the candle’s wick.
2.2 Key settings
• length_input: Window length for finding the highest and lowest values and for determining trend line endpoints. A larger value considers more history and will generate longer trend lines and S/R levels.
• pivot_left_input, pivot_right_input: Strictness of swing confirmation. Higher values require more bars on either side to form a pivot; lower values create more pivots but may include minor swings.
• point_count_input: How many pivots are kept in memory on each side. When new pivots exceed this number the oldest ones are discarded.
• label_atr_len_input and label_atr_multiplier: Determine how far pivot labels are offset from the bar using ATR. Increasing the multiplier moves labels further away from price.
• Styling inputs for trend lines, horizontal lines and labels (color, width and line style).
Figure caption, The chart illustrates how the indicator’s price‑structure backbone operates. In this daily example, the script scans for bars where the high (or low) pivot_right_input bars back is higher (or lower) than the preceding pivot_left_input bars and higher or lower than the subsequent pivot_right_input bars; only those bars are marked as pivots.
These pivot points are stored and ranked: the highest high is labelled “HH1”, the second‑highest “HH2”, and so on, while lows are marked “LL1”, “LL2”, etc. Each label is offset from the price by half of an ATR‑based distance to keep the chart clear, and a dotted connector links the label to the actual candle.
The red diagonal line connects the earliest and latest stored high pivots, and the green line does the same for low pivots; when a new pivot is added or an old one drops out of the lookback window, the end‑points and slopes adjust accordingly. Dashed horizontal lines mark the highest high and lowest low within the current lookback window, providing visual support and resistance levels. Together, these elements form the structural backbone that other modules reference, even when volume data is unavailable.
3. Breakout Module
3.1 Concept
This module confirms that a price break beyond a recent high or low is supported by a genuine shift in buying or selling pressure. It requires price to clear the highest high (“HH1”) or lowest low (“LL1”) and, simultaneously, that the winning side shows a significant volume spike, dominance and ranking. Only when all volume and price conditions pass is a breakout labelled.
3.2 Inputs
• lookback_break_input : This controls the number of bars used to compute moving averages and percentiles for volume. A larger value smooths the averages and percentiles but makes the indicator respond more slowly.
• vol_mult_input : The “spike” multiplier; the current buy or sell volume must be at least this multiple of its moving average over the lookback window to qualify as a breakout.
• rank_threshold_input (0–100) : Defines a volume percentile cutoff: the current buyer/seller volume must be in the top (100−threshold)%(100−threshold)% of all volumes within the lookback window. For example, if set to 80, the current volume must be in the top 20 % of the lookback distribution.
• ratio_threshold_input (0–1) : Specifies the minimum share of total volume that the buyer (for a bullish breakout) or seller (for bearish) must hold on the current bar; the code also requires that the cumulative buyer volume over the lookback window exceeds the seller volume (and vice versa for bearish cases).
• use_custom_tf_input / custom_tf_input : When enabled, these inputs override the automatic choice of lower timeframe for up/down volume; otherwise the script selects a sensible default based on the chart’s timeframe.
• Label appearance settings : Separate options control the ATR-based offset length, offset multiplier, label size and colors for bullish and bearish breakout labels, as well as the connector style and width.
3.3 Detection logic
1. Data preparation : Retrieve per‑side volume from the lower timeframe and take absolute values. Build rolling arrays of the last lookback_break_input values to compute simple moving averages (SMAs), cumulative sums and percentile ranks for buy and sell volume.
2. Volume spike: A spike is flagged when the current buy (or, in the bearish case, sell) volume is at least vol_mult_input times its SMA over the lookback window.
3. Dominance test: The buyer’s (or seller’s) share of total volume on the current bar must meet or exceed ratio_threshold_input. In addition, the cumulative sum of buyer volume over the window must exceed the cumulative sum of seller volume for a bullish breakout (and vice versa for bearish). A separate requirement checks the sign of delta: for bullish breakouts delta_breakout must be non‑negative; for bearish breakouts it must be non‑positive.
4. Percentile rank: The current volume must fall within the top (100 – rank_threshold_input) percent of the lookback distribution—ensuring that the spike is unusually large relative to recent history.
5. Price test: For a bullish signal, the closing price must close above the highest pivot (HH1); for a bearish signal, the close must be below the lowest pivot (LL1).
6. Labeling: When all conditions above are satisfied, the indicator prints “Breakout ↑” above the bar (bullish) or “Breakout ↓” below the bar (bearish). Labels are offset using half of an ATR‑based distance and linked to the candle with a dotted connector.
Figure caption, (Breakout ↑ example) , On this daily chart, price pushes above the red trendline and the highest prior pivot (HH1). The indicator recognizes this as a valid breakout because the buyer‑side volume on the lower timeframe spikes above its recent moving average and buyers dominate the volume statistics over the lookback period; when combined with a close above HH1, this satisfies the breakout conditions. The “Breakout ↑” label appears above the candle, and the info table highlights that up‑volume is elevated relative to its 11‑bar average, buyer share exceeds the dominance threshold and money‑flow metrics support the move.
Figure caption, In this daily example, price breaks below the lowest pivot (LL1) and the lower green trendline. The indicator identifies this as a bearish breakout because sell‑side volume is sharply elevated—about twice its 11‑bar average—and sellers dominate both the bar and the lookback window. With the close falling below LL1, the script triggers a Breakout ↓ label and marks the corresponding row in the info table, which shows strong down volume, negative delta and a seller share comfortably above the dominance threshold.
4. Market Phase Module (Volume Only)
4.1 Concept
Not all markets trend; many cycle between periods of accumulation (buying pressure building up), distribution (selling pressure dominating) and neutral behavior. This module classifies the current bar into one of these phases without using ATR , relying solely on buyer and seller volume statistics. It looks at net flows, ratio changes and an OBV‑like cumulative line with dual‑reference (1‑ and 2‑bar) trends. The result is displayed both as on‑chart labels and in a dedicated row of the info table.
4.2 Inputs
• phase_period_len: Number of bars over which to compute sums and ratios for phase detection.
• phase_ratio_thresh : Minimum buyer share (for accumulation) or minimum seller share (for distribution, derived as 1 − phase_ratio_thresh) of the total volume.
• strict_mode: When enabled, both the 1‑bar and 2‑bar changes in each statistic must agree on the direction (strict confirmation); when disabled, only one of the two references needs to agree (looser confirmation).
• Color customisation for info table cells and label styling for accumulation and distribution phases, including ATR length, multiplier, label size, colors and connector styles.
• show_phase_module: Toggles the entire phase detection subsystem.
• show_phase_labels: Controls whether on‑chart labels are drawn when accumulation or distribution is detected.
4.3 Detection logic
The module computes three families of statistics over the volume window defined by phase_period_len:
1. Net sum (buyers minus sellers): net_sum_phase = Σ(buy) − Σ(sell). A positive value indicates a predominance of buyers. The code also computes the differences between the current value and the values 1 and 2 bars ago (d_net_1, d_net_2) to derive up/down trends.
2. Buyer ratio: The instantaneous ratio TF_buy_breakout / TF_tot_breakout and the window ratio Σ(buy) / Σ(total). The current ratio must exceed phase_ratio_thresh for accumulation or fall below 1 − phase_ratio_thresh for distribution. The first and second differences of the window ratio (d_ratio_1, d_ratio_2) determine trend direction.
3. OBV‑like cumulative net flow: An on‑balance volume analogue obv_net_phase increments by TF_buy_breakout − TF_sell_breakout each bar. Its differences over the last 1 and 2 bars (d_obv_1, d_obv_2) provide trend clues.
The algorithm then combines these signals:
• For strict mode , accumulation requires: (a) current ratio ≥ threshold, (b) cumulative ratio ≥ threshold, (c) both ratio differences ≥ 0, (d) net sum differences ≥ 0, and (e) OBV differences ≥ 0. Distribution is the mirror case.
• For loose mode , it relaxes the directional tests: either the 1‑ or the 2‑bar difference needs to agree in each category.
If all conditions for accumulation are satisfied, the phase is labelled “Accumulation” ; if all conditions for distribution are satisfied, it’s labelled “Distribution” ; otherwise the phase is “Neutral” .
4.4 Outputs
• Info table row : Row 8 displays “Market Phase (Vol)” on the left and the detected phase (Accumulation, Distribution or Neutral) on the right. The text colour of both cells matches a user‑selectable palette (typically green for accumulation, red for distribution and grey for neutral).
• On‑chart labels : When show_phase_labels is enabled and a phase persists for at least one bar, the module prints a label above the bar ( “Accum” ) or below the bar ( “Dist” ) with a dashed or dotted connector. The label is offset using ATR based on phase_label_atr_len_input and phase_label_multiplier and is styled according to user preferences.
Figure caption, The chart displays a red “Dist” label above a particular bar, indicating that the accumulation/distribution module identified a distribution phase at that point. The detection is based on seller dominance: during that bar, the net buyer-minus-seller flow and the OBV‑style cumulative flow were trending down, and the buyer ratio had dropped below the preset threshold. These conditions satisfy the distribution criteria in strict mode. The label is placed above the bar using an ATR‑based offset and a dashed connector. By the time of the current bar in the screenshot, the phase indicator shows “Neutral” in the info table—signaling that neither accumulation nor distribution conditions are currently met—yet the historical “Dist” label remains to mark where the prior distribution phase began.
Figure caption, In this example the market phase module has signaled an Accumulation phase. Three bars before the current candle, the algorithm detected a shift toward buyers: up‑volume exceeded its moving average, down‑volume was below average, and the buyer share of total volume climbed above the threshold while the on‑balance net flow and cumulative ratios were trending upwards. The blue “Accum” label anchored below that bar marks the start of the phase; it remains on the chart because successive bars continue to satisfy the accumulation conditions. The info table confirms this: the “Market Phase (Vol)” row still reads Accumulation, and the ratio and sum rows show buyers dominating both on the current bar and across the lookback window.
5. OB/OS Spike Module
5.1 What overbought/oversold means here
In many markets, a rapid extension up or down is often followed by a period of consolidation or reversal. The indicator interprets overbought (OB) conditions as abnormally strong selling risk at or after a price rally and oversold (OS) conditions as unusually strong buying risk after a decline. Importantly, these are not direct trade signals; rather they flag areas where caution or contrarian setups may be appropriate.
5.2 Inputs
• minHits_obos (1–7): Minimum number of oscillators that must agree on an overbought or oversold condition for a label to print.
• syncWin_obos: Length of a small sliding window over which oscillator votes are smoothed by taking the maximum count observed. This helps filter out choppy signals.
• Volume spike criteria: kVolRatio_obos (ratio of current volume to its SMA) and zVolThr_obos (Z‑score threshold) across volLen_obos. Either threshold can trigger a spike.
• Oscillator toggles and periods: Each of RSI, Stochastic (K and D), Williams %R, CCI, MFI, DeMarker and Stochastic RSI can be independently enabled; their periods are adjustable.
• Label appearance: ATR‑based offset, size, colors for OB and OS labels, plus connector style and width.
5.3 Detection logic
1. Directional volume spikes: Volume spikes are computed separately for buyer and seller volumes. A sell volume spike (sellVolSpike) flags a potential OverBought bar, while a buy volume spike (buyVolSpike) flags a potential OverSold bar. A spike occurs when the respective volume exceeds kVolRatio_obos times its simple moving average over the window or when its Z‑score exceeds zVolThr_obos.
2. Oscillator votes: For each enabled oscillator, calculate its overbought and oversold state using standard thresholds (e.g., RSI ≥ 70 for OB and ≤ 30 for OS; Stochastic %K/%D ≥ 80 for OB and ≤ 20 for OS; etc.). Count how many oscillators vote for OB and how many vote for OS.
3. Minimum hits: Apply the smoothing window syncWin_obos to the vote counts using a maximum‑of‑last‑N approach. A candidate bar is only considered if the smoothed OB hit count ≥ minHits_obos (for OverBought) or the smoothed OS hit count ≥ minHits_obos (for OverSold).
4. Tie‑breaking: If both OverBought and OverSold spike conditions are present on the same bar, compare the smoothed hit counts: the side with the higher count is selected; ties default to OverBought.
5. Label printing: When conditions are met, the bar is labelled as “OverBought X/7” above the candle or “OverSold X/7” below it. “X” is the number of oscillators confirming, and the bracket lists the abbreviations of contributing oscillators. Labels are offset from price using half of an ATR‑scaled distance and can optionally include a dotted or dashed connector line.
Figure caption, In this chart the overbought/oversold module has flagged an OverSold signal. A sell‑off from the prior highs brought price down to the lower trend‑line, where the bar marked “OverSold 3/7 DeM” appears. This label indicates that on that bar the module detected a buy‑side volume spike and that at least three of the seven enabled oscillators—in this case including the DeMarker—were in oversold territory. The label is printed below the candle with a dotted connector, signaling that the market may be temporarily exhausted on the downside. After this oversold print, price begins to rebound towards the upper red trend‑line and higher pivot levels.
Figure caption, This example shows the overbought/oversold module in action. In the left‑hand panel you can see the OB/OS settings where each oscillator (RSI, Stochastic, Williams %R, CCI, MFI, DeMarker and Stochastic RSI) can be enabled or disabled, and the ATR length and label offset multiplier adjusted. On the chart itself, price has pushed up to the descending red trendline and triggered an “OverBought 3/7” label. That means the sell‑side volume spiked relative to its average and three out of the seven enabled oscillators were in overbought territory. The label is offset above the candle by half of an ATR and connected with a dashed line, signaling that upside momentum may be overextended and a pause or pullback could follow.
6. Buyer/Seller Trap Module
6.1 Concept
A bull trap occurs when price appears to break above resistance, attracting buyers, but fails to sustain the move and quickly reverses, leaving a long upper wick and trapping late entrants. A bear trap is the opposite: price breaks below support, lures in sellers, then snaps back, leaving a long lower wick and trapping shorts. This module detects such traps by looking for price structure sweeps, order‑flow mismatches and dominance reversals. It uses a scoring system to differentiate risk from confirmed traps.
6.2 Inputs
• trap_lookback_len: Window length used to rank extremes and detect sweeps.
• trap_wick_threshold: Minimum proportion of a bar’s range that must be wick (upper for bull traps, lower for bear traps) to qualify as a sweep.
• trap_score_risk: Minimum aggregated score required to flag a trap risk. (The code defines a trap_score_confirm input, but confirmation is actually based on price reversal rather than a separate score threshold.)
• trap_confirm_bars: Maximum number of bars allowed for price to reverse and confirm the trap. If price does not reverse in this window, the risk label will expire or remain unconfirmed.
• Label settings: ATR length and multiplier for offsetting, size, colours for risk and confirmed labels, and connector style and width. Separate settings exist for bull and bear traps.
• Toggle inputs: show_trap_module and show_trap_labels enable the module and control whether labels are drawn on the chart.
6.3 Scoring logic
The module assigns points to several conditions and sums them to determine whether a trap risk is present. For bull traps, the score is built from the following (bear traps mirror the logic with highs and lows swapped):
1. Sweep (2 points): Price trades above the high pivot (HH1) but fails to close above it and leaves a long upper wick at least trap_wick_threshold × range. For bear traps, price dips below the low pivot (LL1), fails to close below and leaves a long lower wick.
2. Close break (1 point): Price closes beyond HH1 or LL1 without leaving a long wick.
3. Candle/delta mismatch (2 points): The candle closes bullish yet the order flow delta is negative or the seller ratio exceeds 50%, indicating hidden supply. Conversely, a bearish close with positive delta or buyer dominance suggests hidden demand.
4. Dominance inversion (2 points): The current bar’s buyer volume has the highest rank in the lookback window while cumulative sums favor sellers, or vice versa.
5. Low‑volume break (1 point): Price crosses the pivot but total volume is below its moving average.
The total score for each side is compared to trap_score_risk. If the score is high enough, a “Bull Trap Risk” or “Bear Trap Risk” label is drawn, offset from the candle by half of an ATR‑scaled distance using a dashed outline. If, within trap_confirm_bars, price reverses beyond the opposite level—drops back below the high pivot for bull traps or rises above the low pivot for bear traps—the label is upgraded to a solid “Bull Trap” or “Bear Trap” . In this version of the code, there is no separate score threshold for confirmation: the variable trap_score_confirm is unused; confirmation depends solely on a successful price reversal within the specified number of bars.
Figure caption, In this example the trap module has flagged a Bear Trap Risk. Price initially breaks below the most recent low pivot (LL1), but the bar closes back above that level and leaves a long lower wick, suggesting a failed push lower. Combined with a mismatch between the candle direction and the order flow (buyers regain control) and a reversal in volume dominance, the aggregate score exceeds the risk threshold, so a dashed “Bear Trap Risk” label prints beneath the bar. The green and red trend lines mark the current low and high pivot trajectories, while the horizontal dashed lines show the highest and lowest values in the lookback window. If, within the next few bars, price closes decisively above the support, the risk label would upgrade to a solid “Bear Trap” label.
Figure caption, In this example the trap module has identified both ends of a price range. Near the highs, price briefly pushes above the descending red trendline and the recent pivot high, but fails to close there and leaves a noticeable upper wick. That combination of a sweep above resistance and order‑flow mismatch generates a Bull Trap Risk label with a dashed outline, warning that the upside break may not hold. At the opposite extreme, price later dips below the green trendline and the labelled low pivot, then quickly snaps back and closes higher. The long lower wick and subsequent price reversal upgrade the previous bear‑trap risk into a confirmed Bear Trap (solid label), indicating that sellers were caught on a false breakdown. Horizontal dashed lines mark the highest high and lowest low of the lookback window, while the red and green diagonals connect the earliest and latest pivot highs and lows to visualize the range.
7. Sharp Move Module
7.1 Concept
Markets sometimes display absorption or climax behavior—periods when one side steadily gains the upper hand before price breaks out with a sharp move. This module evaluates several order‑flow and volume conditions to anticipate such moves. Users can choose how many conditions must be met to flag a risk and how many (plus a price break) are required for confirmation.
7.2 Inputs
• sharp Lookback: Number of bars in the window used to compute moving averages, sums, percentile ranks and reference levels.
• sharpPercentile: Minimum percentile rank for the current side’s volume; the current buy (or sell) volume must be greater than or equal to this percentile of historical volumes over the lookback window.
• sharpVolMult: Multiplier used in the volume climax check. The current side’s volume must exceed this multiple of its average to count as a climax.
• sharpRatioThr: Minimum dominance ratio (current side’s volume relative to the opposite side) used in both the instant and cumulative dominance checks.
• sharpChurnThr: Maximum ratio of a bar’s range to its ATR for absorption/churn detection; lower values indicate more absorption (large volume in a small range).
• sharpScoreRisk: Minimum number of conditions that must be true to print a risk label.
• sharpScoreConfirm: Minimum number of conditions plus a price break required for confirmation.
• sharpCvdThr: Threshold for cumulative delta divergence versus price change (positive for bullish accumulation, negative for bearish distribution).
• Label settings: ATR length (sharpATRlen) and multiplier (sharpLabelMult) for positioning labels, label size, colors and connector styles for bullish and bearish sharp moves.
• Toggles: enableSharp activates the module; show_sharp_labels controls whether labels are drawn.
7.3 Conditions (six per side)
For each side, the indicator computes six boolean conditions and sums them to form a score:
1. Dominance (instant and cumulative):
– Instant dominance: current buy volume ≥ sharpRatioThr × current sell volume.
– Cumulative dominance: sum of buy volumes over the window ≥ sharpRatioThr × sum of sell volumes (and vice versa for bearish checks).
2. Accumulation/Distribution divergence: Over the lookback window, cumulative delta rises by at least sharpCvdThr while price fails to rise (bullish), or cumulative delta falls by at least sharpCvdThr while price fails to fall (bearish).
3. Volume climax: The current side’s volume is ≥ sharpVolMult × its average and the product of volume and bar range is the highest in the lookback window.
4. Absorption/Churn: The current side’s volume divided by the bar’s range equals the highest value in the window and the bar’s range divided by ATR ≤ sharpChurnThr (indicating large volume within a small range).
5. Percentile rank: The current side’s volume percentile rank is ≥ sharp Percentile.
6. Mirror logic for sellers: The above checks are repeated with buyer and seller roles swapped and the price break levels reversed.
Each condition that passes contributes one point to the corresponding side’s score (0 or 1). Risk and confirmation thresholds are then applied to these scores.
7.4 Scoring and labels
• Risk: If scoreBull ≥ sharpScoreRisk, a “Sharp ↑ Risk” label is drawn above the bar. If scoreBear ≥ sharpScoreRisk, a “Sharp ↓ Risk” label is drawn below the bar.
• Confirmation: A risk label is upgraded to “Sharp ↑” when scoreBull ≥ sharpScoreConfirm and the bar closes above the highest recent pivot (HH1); for bearish cases, confirmation requires scoreBear ≥ sharpScoreConfirm and a close below the lowest pivot (LL1).
• Label positioning: Labels are offset from the candle by ATR × sharpLabelMult (full ATR times multiplier), not half, and may include a dashed or dotted connector line if enabled.
Figure caption, In this chart both bullish and bearish sharp‑move setups have been flagged. Earlier in the range, a “Sharp ↓ Risk” label appears beneath a candle: the sell‑side score met the risk threshold, signaling that the combination of strong sell volume, dominance and absorption within a narrow range suggested a potential sharp decline. The price did not close below the lower pivot, so this label remains a “risk” and no confirmation occurred. Later, as the market recovered and volume shifted back to the buy side, a “Sharp ↑ Risk” label prints above a candle near the top of the channel. Here, buy‑side dominance, cumulative delta divergence and a volume climax aligned, but price has not yet closed above the upper pivot (HH1), so the alert is still a risk rather than a confirmed sharp‑up move.
Figure caption, In this chart a Sharp ↑ label is displayed above a candle, indicating that the sharp move module has confirmed a bullish breakout. Prior bars satisfied the risk threshold — showing buy‑side dominance, positive cumulative delta divergence, a volume climax and strong absorption in a narrow range — and this candle closes above the highest recent pivot, upgrading the earlier “Sharp ↑ Risk” alert to a full Sharp ↑ signal. The green label is offset from the candle with a dashed connector, while the red and green trend lines trace the high and low pivot trajectories and the dashed horizontals mark the highest and lowest values of the lookback window.
8. Market‑Maker / Spread‑Capture Module
8.1 Concept
Liquidity providers often “capture the spread” by buying and selling in almost equal amounts within a very narrow price range. These bars can signal temporary congestion before a move or reflect algorithmic activity. This module flags bars where both buyer and seller volumes are high, the price range is only a few ticks and the buy/sell split remains close to 50%. It helps traders spot potential liquidity pockets.
8.2 Inputs
• scalpLookback: Window length used to compute volume averages.
• scalpVolMult: Multiplier applied to each side’s average volume; both buy and sell volumes must exceed this multiple.
• scalpTickCount: Maximum allowed number of ticks in a bar’s range (calculated as (high − low) / minTick). A value of 1 or 2 captures ultra‑small bars; increasing it relaxes the range requirement.
• scalpDeltaRatio: Maximum deviation from a perfect 50/50 split. For example, 0.05 means the buyer share must be between 45% and 55%.
• Label settings: ATR length, multiplier, size, colors, connector style and width.
• Toggles : show_scalp_module and show_scalp_labels to enable the module and its labels.
8.3 Signal
When, on the current bar, both TF_buy_breakout and TF_sell_breakout exceed scalpVolMult times their respective averages and (high − low)/minTick ≤ scalpTickCount and the buyer share is within scalpDeltaRatio of 50%, the module prints a “Spread ↔” label above the bar. The label uses the same ATR offset logic as other modules and draws a connector if enabled.
Figure caption, In this chart the spread‑capture module has identified a potential liquidity pocket. Buyer and seller volumes both spiked above their recent averages, yet the candle’s range measured only a couple of ticks and the buy/sell split stayed close to 50 %. This combination met the module’s criteria, so it printed a grey “Spread ↔” label above the bar. The red and green trend lines link the earliest and latest high and low pivots, and the dashed horizontals mark the highest high and lowest low within the current lookback window.
9. Money Flow Module
9.1 Concept
To translate volume into a monetary measure, this module multiplies each side’s volume by the closing price. It tracks buying and selling system money default currency on a per-bar basis and sums them over a chosen period. The difference between buy and sell currencies (Δ$) shows net inflow or outflow.
9.2 Inputs
• mf_period_len_mf: Number of bars used for summing buy and sell dollars.
• Label appearance settings: ATR length, multiplier, size, colors for up/down labels, and connector style and width.
• Toggles: Use enableMoneyFlowLabel_mf and showMFLabels to control whether the module and its labels are displayed.
9.3 Calculations
• Per-bar money: Buy $ = TF_buy_breakout × close; Sell $ = TF_sell_breakout × close. Their difference is Δ$ = Buy $ − Sell $.
• Summations: Over mf_period_len_mf bars, compute Σ Buy $, Σ Sell $ and ΣΔ$ using math.sum().
• Info table entries: Rows 9–13 display these values as texts like “↑ USD 1234 (1M)” or “ΣΔ USD −5678 (14)”, with colors reflecting whether buyers or sellers dominate.
• Money flow status: If Δ$ is positive the bar is marked “Money flow in” ; if negative, “Money flow out” ; if zero, “Neutral”. The cumulative status is similarly derived from ΣΔ.Labels print at the bar that changes the sign of ΣΔ, offset using ATR × label multiplier and styled per user preferences.
Figure caption, The chart illustrates a steady rise toward the highest recent pivot (HH1) with price riding between a rising green trend‑line and a red trend‑line drawn through earlier pivot highs. A green Money flow in label appears above the bar near the top of the channel, signaling that net dollar flow turned positive on this bar: buy‑side dollar volume exceeded sell‑side dollar volume, pushing the cumulative sum ΣΔ$ above zero. In the info table, the “Money flow (bar)” and “Money flow Σ” rows both read In, confirming that the indicator’s money‑flow module has detected an inflow at both bar and aggregate levels, while other modules (pivots, trend lines and support/resistance) remain active to provide structural context.
In this example the Money Flow module signals a net outflow. Price has been trending downward: successive high pivots form a falling red trend‑line and the low pivots form a descending green support line. When the latest bar broke below the previous low pivot (LL1), both the bar‑level and cumulative net dollar flow turned negative—selling volume at the close exceeded buying volume and pushed the cumulative Δ$ below zero. The module reacts by printing a red “Money flow out” label beneath the candle; the info table confirms that the “Money flow (bar)” and “Money flow Σ” rows both show Out, indicating sustained dominance of sellers in this period.
10. Info Table
10.1 Purpose
When enabled, the Info Table appears in the lower right of your chart. It summarises key values computed by the indicator—such as buy and sell volume, delta, total volume, breakout status, market phase, and money flow—so you can see at a glance which side is dominant and which signals are active.
10.2 Symbols
• ↑ / ↓ — Up (↑) denotes buy volume or money; down (↓) denotes sell volume or money.
• MA — Moving average. In the table it shows the average value of a series over the lookback period.
• Σ (Sigma) — Cumulative sum over the chosen lookback period.
• Δ (Delta) — Difference between buy and sell values.
• B / S — Buyer and seller share of total volume, expressed as percentages.
• Ref. Price — Reference price for breakout calculations, based on the latest pivot.
• Status — Indicates whether a breakout condition is currently active (True) or has failed.
10.3 Row definitions
1. Up volume / MA up volume – Displays current buy volume on the lower timeframe and its moving average over the lookback period.
2. Down volume / MA down volume – Shows current sell volume and its moving average; sell values are formatted in red for clarity.
3. Δ / ΣΔ – Lists the difference between buy and sell volume for the current bar and the cumulative delta volume over the lookback period.
4. Σ / MA Σ (Vol/MA) – Total volume (buy + sell) for the bar, with the ratio of this volume to its moving average; the right cell shows the average total volume.
5. B/S ratio – Buy and sell share of the total volume: current bar percentages and the average percentages across the lookback period.
6. Buyer Rank / Seller Rank – Ranks the bar’s buy and sell volumes among the last (n) bars; lower rank numbers indicate higher relative volume.
7. Σ Buy / Σ Sell – Sum of buy and sell volumes over the lookback window, indicating which side has traded more.
8. Breakout UP / DOWN – Shows the breakout thresholds (Ref. Price) and whether the breakout condition is active (True) or has failed.
9. Market Phase (Vol) – Reports the current volume‑only phase: Accumulation, Distribution or Neutral.
10. Money Flow – The final rows display dollar amounts and status:
– ↑ USD / Σ↑ USD – Buy dollars for the current bar and the cumulative sum over the money‑flow period.
– ↓ USD / Σ↓ USD – Sell dollars and their cumulative sum.
– Δ USD / ΣΔ USD – Net dollar difference (buy minus sell) for the bar and cumulatively.
– Money flow (bar) – Indicates whether the bar’s net dollar flow is positive (In), negative (Out) or neutral.
– Money flow Σ – Shows whether the cumulative net dollar flow across the chosen period is positive, negative or neutral.
The chart above shows a sequence of different signals from the indicator. A Bull Trap Risk appears after price briefly pushes above resistance but fails to hold, then a green Accum label identifies an accumulation phase. An upward breakout follows, confirmed by a Money flow in print. Later, a Sharp ↓ Risk warns of a possible sharp downturn; after price dips below support but quickly recovers, a Bear Trap label marks a false breakdown. The highlighted info table in the center summarizes key metrics at that moment, including current and average buy/sell volumes, net delta, total volume versus its moving average, breakout status (up and down), market phase (volume), and bar‑level and cumulative money flow (In/Out).
11. Conclusion & Final Remarks
This indicator was developed as a holistic study of market structure and order flow. It brings together several well‑known concepts from technical analysis—breakouts, accumulation and distribution phases, overbought and oversold extremes, bull and bear traps, sharp directional moves, market‑maker spread bars and money flow—into a single Pine Script tool. Each module is based on widely recognized trading ideas and was implemented after consulting reference materials and example strategies, so you can see in real time how these concepts interact on your chart.
A distinctive feature of this indicator is its reliance on per‑side volume: instead of tallying only total volume, it separately measures buy and sell transactions on a lower time frame. This approach gives a clearer view of who is in control—buyers or sellers—and helps filter breakouts, detect phases of accumulation or distribution, recognize potential traps, anticipate sharp moves and gauge whether liquidity providers are active. The money‑flow module extends this analysis by converting volume into currency values and tracking net inflow or outflow across a chosen window.
Although comprehensive, this indicator is intended solely as a guide. It highlights conditions and statistics that many traders find useful, but it does not generate trading signals or guarantee results. Ultimately, you remain responsible for your positions. Use the information presented here to inform your analysis, combine it with other tools and risk‑management techniques, and always make your own decisions when trading.
Blue Ocean BOATS 24/5 US Market DataThis script utilizes Blue Ocean's ATS (Alternative Trading System) and U.S. exchange market data to create a continuous candlestick chart. The continuous data has the option to be used as an indicator or strategy source.
Requirements
The main chart symbol (which can be unrelated to the user-input Ticker Symbol) needs to be a 24/7 chart. An example symbol is CRYPTO:BTCUSD. CME_MINI:ES1! and FX:SPX500 work too, but are not truly 24/5 and will miss ~4 hours of the total trading week from the extended U.S. session.
The main chart's timeframe needs to be intraday. Because the script's output is currently inconsistent on daily or higher timeframes, it will disable itself.
The Ticker Symbol chosen should be a ticker that is traded on U.S. exchanges. This will provide both U.S. extended session data and a BOATS equivalent.
Usage & configuration
This script visualizes the 24-hour Monday-Friday chart of a U.S. exchange ticker. Going a step further, it can be used to compare the performance indices or cryptocurrencies to stock constituents of indices, cryptocurrency treasury stocks or holding ETFs.
The script's output, candlesticks, can be overlaid on the main chart or used as is. A "Price Source" plot is used for indicators or strategies.
Ticker Symbol: The U.S. ticker you'd like to view extended session and Blue Ocean ATS session data for.
Price Source: Price source that can be used for indicators or strategies.
Highlight Sessions: Highlight the different trading sessions.
Last Price Line: Show a horizontal line at the last traded price.
Ticker Symbol Check: Plots a label that will display only if the selected Ticker Symbol is not detected as a U.S. exchange traded ticker.
Earnings Label: Creates a label at the time of past earnings of the chosen Ticker Symbol. The time that the earnings are plotted is approximate. Because of this, the label is meant as an explanation for price action.
What this script does and how it works
It creates OHLC candlesticks by merging Blue Ocean's ATS market data and U.S. exchange data. From the OHLC data of both, a single output can be used for indicators or strategies.
References and further information
www.tradingview.com
The Blue Ocean ATS allows trading from 20:00 to 4:00 Eastern Time, Sunday through Thursday. This critical timeframe bridges the eight-hour overnight gap when major U.S. exchanges are closed.
blueocean-tech.io
Blue Ocean ATS, LLC is a US broker dealer which operates the alternative trading system BOATS. Our trading platform offers electronic access, price discovery, compliant regulatory reporting requirements, and standard clearing and settlement processes.
www.nyse.com
Hours mentioned are in Eastern Time.
Overnight trading remains far less active than extended hours trading. The hour with the highest overnight volume is 9:00PM, which averages 2.94 million shares per day and coincides with several Asian market opens. This volume is a fraction of the last hour of extended hours trading, which averages 43.22 million shares. The first hour of pre-core reported volume averages 113.30 million shares per day.
Overnight executions, in addition to the peak in the 9:00PM hour, also exhibits a smaller peak at 3:00AM, of 2.35 million shares. This coincides with several Asian bourses’ end of their regular trading day.
Example of using the script in the main chart window and the difference in how RSI may be calculated.
Note: ATS is not the name of the 20:00 to 4:00 ET session itself, and the term refers to a broader definition of trading systems that include dark pools, which can be different.
24/5 Monday-Friday really means NY time Sunday night to Friday afternoon.
Nasdaq Risk Calculator - DTFXNasdaq Risk Calculator
This Pine Script (v5) indicator provides a dashboard-style tool for calculating trading risk based on manually input tick measurements for Nasdaq futures contracts (NQ and MNQ). Designed as an overlay on the main chart, it displays key risk metrics in a fixed-position table, allowing traders to assess contract type, lot size, risk ticks, and actual risk in dollars relative to a user-defined risk amount.
Features:
Manual Tick Input: Enter the number of ticks (e.g., from a ruler measurement) to define the price range for risk calculation.
Risk Calculation: Computes the optimal contract (NQ or MNQ), number of lots, risk ticks (half the input range), and actual risk in dollars, targeting the specified risk amount (default: $100).
Customizable Dashboard: Displays results in a single-cell table with a semi-transparent white background and gray border, positioned in one of four chart corners (Top Left, Top Right, Bottom Left, Bottom Right) via user selection.
Reset Option: Includes a toggle to clear the dashboard and start anew.
How to Use:
Add the indicator to your chart (best suited for NQ or MNQ futures).
In the settings, input your "Risk Amount ($)" and "Ticks" (e.g., 400 for a 100-point range on NQ).
Select the "Dashboard Corner" to position the table.
View the calculated risk details in the chosen corner.
Adjust inputs or reset as needed.
Notes:
NQ tick value is $5.00 (NQ_MULTIPLIER = 5.0), and MNQ tick value is $0.50 (MNQ_MULTIPLIER = 0.5).
Ideal for traders planning risk based on measured price ranges, such as support/resistance zones.
ValueAtTime█ OVERVIEW
This library is a Pine Script® programming tool for accessing historical values in a time series using UNIX timestamps . Its data structure and functions index values by time, allowing scripts to retrieve past values based on absolute timestamps or relative time offsets instead of relying on bar index offsets.
█ CONCEPTS
UNIX timestamps
In Pine Script®, a UNIX timestamp is an integer representing the number of milliseconds elapsed since January 1, 1970, at 00:00:00 UTC (the UNIX Epoch ). The timestamp is a unique, absolute representation of a specific point in time. Unlike a calendar date and time, a UNIX timestamp's meaning does not change relative to any time zone .
This library's functions process series values and corresponding UNIX timestamps in pairs , offering a simplified way to identify values that occur at or near distinct points in time instead of on specific bars.
Storing and retrieving time-value pairs
This library's `Data` type defines the structure for collecting time and value information in pairs. Objects of the `Data` type contain the following two fields:
• `times` – An array of "int" UNIX timestamps for each recorded value.
• `values` – An array of "float" values for each saved timestamp.
Each index in both arrays refers to a specific time-value pair. For instance, the `times` and `values` elements at index 0 represent the first saved timestamp and corresponding value. The library functions that maintain `Data` objects queue up to one time-value pair per bar into the object's arrays, where the saved timestamp represents the bar's opening time .
Because the `times` array contains a distinct UNIX timestamp for each item in the `values` array, it serves as a custom mapping for retrieving saved values. All the library functions that return information from a `Data` object use this simple two-step process to identify a value based on time:
1. Perform a binary search on the `times` array to find the earliest saved timestamp closest to the specified time or offset and get the element's index.
2. Access the element from the `values` array at the retrieved index, returning the stored value corresponding to the found timestamp.
Value search methods
There are several techniques programmers can use to identify historical values from corresponding timestamps. This library's functions include three different search methods to locate and retrieve values based on absolute times or relative time offsets:
Timestamp search
Find the value with the earliest saved timestamp closest to a specified timestamp.
Millisecond offset search
Find the value with the earliest saved timestamp closest to a specified number of milliseconds behind the current bar's opening time. This search method provides a time-based alternative to retrieving historical values at specific bar offsets.
Period offset search
Locate the value with the earliest saved timestamp closest to a defined period offset behind the current bar's opening time. The function calculates the span of the offset based on a period string . The "string" must contain one of the following unit tokens:
• "D" for days
• "W" for weeks
• "M" for months
• "Y" for years
• "YTD" for year-to-date, meaning the time elapsed since the beginning of the bar's opening year in the exchange time zone.
The period string can include a multiplier prefix for all supported units except "YTD" (e.g., "2W" for two weeks).
Note that the precise span covered by the "M", "Y", and "YTD" units varies across time. The "1M" period can cover 28, 29, 30, or 31 days, depending on the bar's opening month and year in the exchange time zone. The "1Y" period covers 365 or 366 days, depending on leap years. The "YTD" period's span changes with each new bar, because it always measures the time from the start of the current bar's opening year.
█ CALCULATIONS AND USE
This library's functions offer a flexible, structured approach to retrieving historical values at or near specific timestamps, millisecond offsets, or period offsets for different analytical needs.
See below for explanations of the exported functions and how to use them.
Retrieving single values
The library includes three functions that retrieve a single stored value using timestamp, millisecond offset, or period offset search methods:
• `valueAtTime()` – Locates the saved value with the earliest timestamp closest to a specified timestamp.
• `valueAtTimeOffset()` – Finds the saved value with the earliest timestamp closest to the specified number of milliseconds behind the current bar's opening time.
• `valueAtPeriodOffset()` – Finds the saved value with the earliest timestamp closest to the period-based offset behind the current bar's opening time.
Each function has two overloads for advanced and simple use cases. The first overload searches for a value in a user-specified `Data` object created by the `collectData()` function (see below). It returns a tuple containing the found value and the corresponding timestamp.
The second overload maintains a `Data` object internally to store and retrieve values for a specified `source` series. This overload returns a tuple containing the historical `source` value, the corresponding timestamp, and the current bar's `source` value, making it helpful for comparing past and present values from requested contexts.
Retrieving multiple values
The library includes the following functions to retrieve values from multiple historical points in time, facilitating calculations and comparisons with values retrieved across several intervals:
• `getDataAtTimes()` – Locates a past `source` value for each item in a `timestamps` array. Each retrieved value's timestamp represents the earliest time closest to one of the specified timestamps.
• `getDataAtTimeOffsets()` – Finds a past `source` value for each item in a `timeOffsets` array. Each retrieved value's timestamp represents the earliest time closest to one of the specified millisecond offsets behind the current bar's opening time.
• `getDataAtPeriodOffsets()` – Finds a past value for each item in a `periods` array. Each retrieved value's timestamp represents the earliest time closest to one of the specified period offsets behind the current bar's opening time.
Each function returns a tuple with arrays containing the found `source` values and their corresponding timestamps. In addition, the tuple includes the current `source` value and the symbol's description, which also makes these functions helpful for multi-interval comparisons using data from requested contexts.
Processing period inputs
When writing scripts that retrieve historical values based on several user-specified period offsets, the most concise approach is to create a single text input that allows users to list each period, then process the "string" list into an array for use in the `getDataAtPeriodOffsets()` function.
This library includes a `getArrayFromString()` function to provide a simple way to process strings containing comma-separated lists of periods. The function splits the specified `str` by its commas and returns an array containing every non-empty item in the list with surrounding whitespaces removed. View the example code to see how we use this function to process the value of a text area input .
Calculating period offset times
Because the exact amount of time covered by a specified period offset can vary, it is often helpful to verify the resulting times when using the `valueAtPeriodOffset()` or `getDataAtPeriodOffsets()` functions to ensure the calculations work as intended for your use case.
The library's `periodToTimestamp()` function calculates an offset timestamp from a given period and reference time. With this function, programmers can verify the time offsets in a period-based data search and use the calculated offset times in additional operations.
For periods with "D" or "W" units, the function calculates the time offset based on the absolute number of milliseconds the period covers (e.g., `86400000` for "1D"). For periods with "M", "Y", or "YTD" units, the function calculates an offset time based on the reference time's calendar date in the exchange time zone.
Collecting data
All the `getDataAt*()` functions, and the second overloads of the `valueAt*()` functions, collect and maintain data internally, meaning scripts do not require a separate `Data` object when using them. However, the first overloads of the `valueAt*()` functions do not collect data, because they retrieve values from a user-specified `Data` object.
For cases where a script requires a separate `Data` object for use with these overloads or other custom routines, this library exports the `collectData()` function. This function queues each bar's `source` value and opening timestamp into a `Data` object and returns the object's ID.
This function is particularly useful when searching for values from a specific series more than once. For instance, instead of using multiple calls to the second overloads of `valueAt*()` functions with the same `source` argument, programmers can call `collectData()` to store each bar's `source` and opening timestamp, then use the returned `Data` object's ID in calls to the first `valueAt*()` overloads to reduce memory usage.
The `collectData()` function and all the functions that collect data internally include two optional parameters for limiting the saved time-value pairs to a sliding window: `timeOffsetLimit` and `timeframeLimit`. When either has a non-na argument, the function restricts the collected data to the maximum number of recent bars covered by the specified millisecond- and timeframe-based intervals.
NOTE : All calls to the functions that collect data for a `source` series can execute up to once per bar or realtime tick, because each stored value requires a unique corresponding timestamp. Therefore, scripts cannot call these functions iteratively within a loop . If a call to these functions executes more than once inside a loop's scope, it causes a runtime error.
█ EXAMPLE CODE
The example code at the end of the script demonstrates one possible use case for this library's functions. The code retrieves historical price data at user-specified period offsets, calculates price returns for each period from the retrieved data, and then populates a table with the results.
The example code's process is as follows:
1. Input a list of periods – The user specifies a comma-separated list of period strings in the script's "Period list" input (e.g., "1W, 1M, 3M, 1Y, YTD"). Each item in the input list represents a period offset from the latest bar's opening time.
2. Process the period list – The example calls `getArrayFromString()` on the first bar to split the input list by its commas and construct an array of period strings.
3. Request historical data – The code uses a call to `getDataAtPeriodOffsets()` as the `expression` argument in a request.security() call to retrieve the closing prices of "1D" bars for each period included in the processed `periods` array.
4. Display information in a table – On the latest bar, the code uses the retrieved data to calculate price returns over each specified period, then populates a two-row table with the results. The cells for each return percentage are color-coded based on the magnitude and direction of the price change. The cells also include tooltips showing the compared daily bar's opening date in the exchange time zone.
█ NOTES
• This library's architecture relies on a user-defined type (UDT) for its data storage format. UDTs are blueprints from which scripts create objects , i.e., composite structures with fields containing independent values or references of any supported type.
• The library functions search through a `Data` object's `times` array using the array.binary_search_leftmost() function, which is more efficient than looping through collected data to identify matching timestamps. Note that this built-in works only for arrays with elements sorted in ascending order .
• Each function that collects data from a `source` series updates the values and times stored in a local `Data` object's arrays. If a single call to these functions were to execute in a loop , it would store multiple values with an identical timestamp, which can cause erroneous search behavior. To prevent looped calls to these functions, the library uses the `checkCall()` helper function in their scopes. This function maintains a counter that increases by one each time it executes on a confirmed bar. If the count exceeds the total number of bars, indicating the call executes more than once in a loop, it raises a runtime error .
• Typically, when requesting higher-timeframe data with request.security() while using barmerge.lookahead_on as the `lookahead` argument, the `expression` argument should be offset with the history-referencing operator to prevent lookahead bias on historical bars. However, the call in this script's example code enables lookahead without offsetting the `expression` because the script displays results only on the last historical bar and all realtime bars, where there is no future data to leak into the past. This call ensures the displayed results use the latest data available from the context on realtime bars.
Look first. Then leap.
█ EXPORTED TYPES
Data
A structure for storing successive timestamps and corresponding values from a dataset.
Fields:
times (array) : An "int" array containing a UNIX timestamp for each value in the `values` array.
values (array) : A "float" array containing values corresponding to the timestamps in the `times` array.
█ EXPORTED FUNCTIONS
getArrayFromString(str)
Splits a "string" into an array of substrings using the comma (`,`) as the delimiter. The function trims surrounding whitespace characters from each substring, and it excludes empty substrings from the result.
Parameters:
str (series string) : The "string" to split into an array based on its commas.
Returns: (array) An array of trimmed substrings from the specified `str`.
periodToTimestamp(period, referenceTime)
Calculates a UNIX timestamp representing the point offset behind a reference time by the amount of time within the specified `period`.
Parameters:
period (series string) : The period string, which determines the time offset of the returned timestamp. The specified argument must contain a unit and an optional multiplier (e.g., "1Y", "3M", "2W", "YTD"). Supported units are:
- "Y" for years.
- "M" for months.
- "W" for weeks.
- "D" for days.
- "YTD" (Year-to-date) for the span from the start of the `referenceTime` value's year in the exchange time zone. An argument with this unit cannot contain a multiplier.
referenceTime (series int) : The millisecond UNIX timestamp from which to calculate the offset time.
Returns: (int) A millisecond UNIX timestamp representing the offset time point behind the `referenceTime`.
collectData(source, timeOffsetLimit, timeframeLimit)
Collects `source` and `time` data successively across bars. The function stores the information within a `Data` object for use in other exported functions/methods, such as `valueAtTimeOffset()` and `valueAtPeriodOffset()`. Any call to this function cannot execute more than once per bar or realtime tick.
Parameters:
source (series float) : The source series to collect. The function stores each value in the series with an associated timestamp representing its corresponding bar's opening time.
timeOffsetLimit (simple int) : Optional. A time offset (range) in milliseconds. If specified, the function limits the collected data to the maximum number of bars covered by the range, with a minimum of one bar. If the call includes a non-empty `timeframeLimit` value, the function limits the data using the largest number of bars covered by the two ranges. The default is `na`.
timeframeLimit (simple string) : Optional. A valid timeframe string. If specified and not empty, the function limits the collected data to the maximum number of bars covered by the timeframe, with a minimum of one bar. If the call includes a non-na `timeOffsetLimit` value, the function limits the data using the largest number of bars covered by the two ranges. The default is `na`.
Returns: (Data) A `Data` object containing collected `source` values and corresponding timestamps over the allowed time range.
method valueAtTime(data, timestamp)
(Overload 1 of 2) Retrieves value and time data from a `Data` object's fields at the index of the earliest timestamp closest to the specified `timestamp`. Callable as a method or a function.
Parameters:
data (series Data) : The `Data` object containing the collected time and value data.
timestamp (series int) : The millisecond UNIX timestamp to search. The function returns data for the earliest saved timestamp that is closest to the value.
Returns: ( ) A tuple containing the following data from the `Data` object:
- The stored value corresponding to the identified timestamp ("float").
- The earliest saved timestamp that is closest to the specified `timestamp` ("int").
valueAtTime(source, timestamp, timeOffsetLimit, timeframeLimit)
(Overload 2 of 2) Retrieves `source` and time information for the earliest bar whose opening timestamp is closest to the specified `timestamp`. Any call to this function cannot execute more than once per bar or realtime tick.
Parameters:
source (series float) : The source series to analyze. The function stores each value in the series with an associated timestamp representing its corresponding bar's opening time.
timestamp (series int) : The millisecond UNIX timestamp to search. The function returns data for the earliest bar whose timestamp is closest to the value.
timeOffsetLimit (simple int) : Optional. A time offset (range) in milliseconds. If specified, the function limits the collected data to the maximum number of bars covered by the range, with a minimum of one bar. If the call includes a non-empty `timeframeLimit` value, the function limits the data using the largest number of bars covered by the two ranges. The default is `na`.
timeframeLimit (simple string) : (simple string) Optional. A valid timeframe string. If specified and not empty, the function limits the collected data to the maximum number of bars covered by the timeframe, with a minimum of one bar. If the call includes a non-na `timeOffsetLimit` value, the function limits the data using the largest number of bars covered by the two ranges. The default is `na`.
Returns: ( ) A tuple containing the following data:
- The `source` value corresponding to the identified timestamp ("float").
- The earliest bar's timestamp that is closest to the specified `timestamp` ("int").
- The current bar's `source` value ("float").
method valueAtTimeOffset(data, timeOffset)
(Overload 1 of 2) Retrieves value and time data from a `Data` object's fields at the index of the earliest saved timestamp closest to `timeOffset` milliseconds behind the current bar's opening time. Callable as a method or a function.
Parameters:
data (series Data) : The `Data` object containing the collected time and value data.
timeOffset (series int) : The millisecond offset behind the bar's opening time. The function returns data for the earliest saved timestamp that is closest to the calculated offset time.
Returns: ( ) A tuple containing the following data from the `Data` object:
- The stored value corresponding to the identified timestamp ("float").
- The earliest saved timestamp that is closest to `timeOffset` milliseconds before the current bar's opening time ("int").
valueAtTimeOffset(source, timeOffset, timeOffsetLimit, timeframeLimit)
(Overload 2 of 2) Retrieves `source` and time information for the earliest bar whose opening timestamp is closest to `timeOffset` milliseconds behind the current bar's opening time. Any call to this function cannot execute more than once per bar or realtime tick.
Parameters:
source (series float) : The source series to analyze. The function stores each value in the series with an associated timestamp representing its corresponding bar's opening time.
timeOffset (series int) : The millisecond offset behind the bar's opening time. The function returns data for the earliest bar's timestamp that is closest to the calculated offset time.
timeOffsetLimit (simple int) : Optional. A time offset (range) in milliseconds. If specified, the function limits the collected data to the maximum number of bars covered by the range, with a minimum of one bar. If the call includes a non-empty `timeframeLimit` value, the function limits the data using the largest number of bars covered by the two ranges. The default is `na`.
timeframeLimit (simple string) : Optional. A valid timeframe string. If specified and not empty, the function limits the collected data to the maximum number of bars covered by the timeframe, with a minimum of one bar. If the call includes a non-na `timeOffsetLimit` value, the function limits the data using the largest number of bars covered by the two ranges. The default is `na`.
Returns: ( ) A tuple containing the following data:
- The `source` value corresponding to the identified timestamp ("float").
- The earliest bar's timestamp that is closest to `timeOffset` milliseconds before the current bar's opening time ("int").
- The current bar's `source` value ("float").
method valueAtPeriodOffset(data, period)
(Overload 1 of 2) Retrieves value and time data from a `Data` object's fields at the index of the earliest timestamp closest to a calculated offset behind the current bar's opening time. The calculated offset represents the amount of time covered by the specified `period`. Callable as a method or a function.
Parameters:
data (series Data) : The `Data` object containing the collected time and value data.
period (series string) : The period string, which determines the calculated time offset. The specified argument must contain a unit and an optional multiplier (e.g., "1Y", "3M", "2W", "YTD"). Supported units are:
- "Y" for years.
- "M" for months.
- "W" for weeks.
- "D" for days.
- "YTD" (Year-to-date) for the span from the start of the current bar's year in the exchange time zone. An argument with this unit cannot contain a multiplier.
Returns: ( ) A tuple containing the following data from the `Data` object:
- The stored value corresponding to the identified timestamp ("float").
- The earliest saved timestamp that is closest to the calculated offset behind the bar's opening time ("int").
valueAtPeriodOffset(source, period, timeOffsetLimit, timeframeLimit)
(Overload 2 of 2) Retrieves `source` and time information for the earliest bar whose opening timestamp is closest to a calculated offset behind the current bar's opening time. The calculated offset represents the amount of time covered by the specified `period`. Any call to this function cannot execute more than once per bar or realtime tick.
Parameters:
source (series float) : The source series to analyze. The function stores each value in the series with an associated timestamp representing its corresponding bar's opening time.
period (series string) : The period string, which determines the calculated time offset. The specified argument must contain a unit and an optional multiplier (e.g., "1Y", "3M", "2W", "YTD"). Supported units are:
- "Y" for years.
- "M" for months.
- "W" for weeks.
- "D" for days.
- "YTD" (Year-to-date) for the span from the start of the current bar's year in the exchange time zone. An argument with this unit cannot contain a multiplier.
timeOffsetLimit (simple int) : Optional. A time offset (range) in milliseconds. If specified, the function limits the collected data to the maximum number of bars covered by the range, with a minimum of one bar. If the call includes a non-empty `timeframeLimit` value, the function limits the data using the largest number of bars covered by the two ranges. The default is `na`.
timeframeLimit (simple string) : Optional. A valid timeframe string. If specified and not empty, the function limits the collected data to the maximum number of bars covered by the timeframe, with a minimum of one bar. If the call includes a non-na `timeOffsetLimit` value, the function limits the data using the largest number of bars covered by the two ranges. The default is `na`.
Returns: ( ) A tuple containing the following data:
- The `source` value corresponding to the identified timestamp ("float").
- The earliest bar's timestamp that is closest to the calculated offset behind the current bar's opening time ("int").
- The current bar's `source` value ("float").
getDataAtTimes(timestamps, source, timeOffsetLimit, timeframeLimit)
Retrieves `source` and time information for each bar whose opening timestamp is the earliest one closest to one of the UNIX timestamps specified in the `timestamps` array. Any call to this function cannot execute more than once per bar or realtime tick.
Parameters:
timestamps (array) : An array of "int" values representing UNIX timestamps. The function retrieves `source` and time data for each element in this array.
source (series float) : The source series to analyze. The function stores each value in the series with an associated timestamp representing its corresponding bar's opening time.
timeOffsetLimit (simple int) : Optional. A time offset (range) in milliseconds. If specified, the function limits the collected data to the maximum number of bars covered by the range, with a minimum of one bar. If the call includes a non-empty `timeframeLimit` value, the function limits the data using the largest number of bars covered by the two ranges. The default is `na`.
timeframeLimit (simple string) : Optional. A valid timeframe string. If specified and not empty, the function limits the collected data to the maximum number of bars covered by the timeframe, with a minimum of one bar. If the call includes a non-na `timeOffsetLimit` value, the function limits the data using the largest number of bars covered by the two ranges. The default is `na`.
Returns: ( ) A tuple of the following data:
- An array containing a `source` value for each identified timestamp (array).
- An array containing an identified timestamp for each item in the `timestamps` array (array).
- The current bar's `source` value ("float").
- The symbol's description from `syminfo.description` ("string").
getDataAtTimeOffsets(timeOffsets, source, timeOffsetLimit, timeframeLimit)
Retrieves `source` and time information for each bar whose opening timestamp is the earliest one closest to one of the time offsets specified in the `timeOffsets` array. Each offset in the array represents the absolute number of milliseconds behind the current bar's opening time. Any call to this function cannot execute more than once per bar or realtime tick.
Parameters:
timeOffsets (array) : An array of "int" values representing the millisecond time offsets used in the search. The function retrieves `source` and time data for each element in this array. For example, the array ` ` specifies that the function returns data for the timestamps closest to one day and one week behind the current bar's opening time.
source (float) : (series float) The source series to analyze. The function stores each value in the series with an associated timestamp representing its corresponding bar's opening time.
timeOffsetLimit (simple int) : Optional. A time offset (range) in milliseconds. If specified, the function limits the collected data to the maximum number of bars covered by the range, with a minimum of one bar. If the call includes a non-empty `timeframeLimit` value, the function limits the data using the largest number of bars covered by the two ranges. The default is `na`.
timeframeLimit (simple string) : Optional. A valid timeframe string. If specified and not empty, the function limits the collected data to the maximum number of bars covered by the timeframe, with a minimum of one bar. If the call includes a non-na `timeOffsetLimit` value, the function limits the data using the largest number of bars covered by the two ranges. The default is `na`.
Returns: ( ) A tuple of the following data:
- An array containing a `source` value for each identified timestamp (array).
- An array containing an identified timestamp for each offset specified in the `timeOffsets` array (array).
- The current bar's `source` value ("float").
- The symbol's description from `syminfo.description` ("string").
getDataAtPeriodOffsets(periods, source, timeOffsetLimit, timeframeLimit)
Retrieves `source` and time information for each bar whose opening timestamp is the earliest one closest to a calculated offset behind the current bar's opening time. Each calculated offset represents the amount of time covered by a period specified in the `periods` array. Any call to this function cannot execute more than once per bar or realtime tick.
Parameters:
periods (array) : An array of period strings, which determines the time offsets used in the search. The function retrieves `source` and time data for each element in this array. For example, the array ` ` specifies that the function returns data for the timestamps closest to one day, week, and month behind the current bar's opening time. Each "string" in the array must contain a unit and an optional multiplier. Supported units are:
- "Y" for years.
- "M" for months.
- "W" for weeks.
- "D" for days.
- "YTD" (Year-to-date) for the span from the start of the current bar's year in the exchange time zone. An argument with this unit cannot contain a multiplier.
source (float) : (series float) The source series to analyze. The function stores each value in the series with an associated timestamp representing its corresponding bar's opening time.
timeOffsetLimit (simple int) : Optional. A time offset (range) in milliseconds. If specified, the function limits the collected data to the maximum number of bars covered by the range, with a minimum of one bar. If the call includes a non-empty `timeframeLimit` value, the function limits the data using the largest number of bars covered by the two ranges. The default is `na`.
timeframeLimit (simple string) : Optional. A valid timeframe string. If specified and not empty, the function limits the collected data to the maximum number of bars covered by the timeframe, with a minimum of one bar. If the call includes a non-na `timeOffsetLimit` value, the function limits the data using the largest number of bars covered by the two ranges. The default is `na`.
Returns: ( ) A tuple of the following data:
- An array containing a `source` value for each identified timestamp (array).
- An array containing an identified timestamp for each period specified in the `periods` array (array).
- The current bar's `source` value ("float").
- The symbol's description from `syminfo.description` ("string").
Moving Average Crossover Swing StrategyMoving Average Crossover Swing Strategy
**Overview:**
The basic concept of this strategy is to generate a signal when a faster/shorter length moving average crosses over (for Longs) or crosses under (for Shorts) a medium/longer length moving average. All of which are customizable. This strategy can work on any timeframe, however the daily is the timeframe used for the default settings and screenshots, as it was designed to be a multi-day swing strategy. Once a signal has been confirmed with a candle close, based on user options, the strategy will enter the trade on the open of the next candle.
The crossover strategy is nothing new to trading, but what can make this strategy unique and helpful, is the addition of further confirmation points, ATR based stop loss and take profit targets, optional early exit criteria, customizable to your needs and style, and just about everything visual can be toggled on/off. This strategy is based on a Trend (MA) indicator and a Momentum (MACD) indicator. While a Volume-based indicator is not shown here, one could consider using their favorite from that category to further compliment the signal idea.
It should be noted that depending on the time frame, direction(s) chosen, the signal options, confirmation options, and exit options selected, that a ticker may not produce more than 100 trades on the back test. Depending on your style and frequency, one could consider adjusting options and/or testing multiple tickers. It should also be noted that this strategy simply tests the underlying stock prices, not options contracts. And of course, testing this strategy against historical data does not assume that the same results will occur in future price action.
Shoutout given to Ripster's Clouds Indicator as pieces of that code were taken and modified to create both the Cloud visualization effects, and the Moving Average Pair Plots that are implemented in this strategy.
BASIC DEFAULTS
All can be changed as normal
Initial capital = 10,000
Order Sizing = 25% of equity (use the "Inputs" tab to modify this)
Pyramiding = 0
Commission = 0.65 USD per order
Price Verification = 1 tick
Slippage = 1 tick
RISK MANAGMENT
You will notice two different percentage options and ATR multipliers. This strategy will adjust position sizing by not exceeding either one of those % values based on the ATR (Average True Range) of the symbol and the multipliers selected, should the stock hit the stop loss price.
For Example, lets assume these values are true:
Account size = $10,000,
Max Risk = 1% of account size
Max Position Size = 25% of the account size
Stock Price = 23.45
ATR = 3.5
ATR Stop Loss Multiplier = 1.4
Then the formulas would be:
ACCT_SIZE * MaxRisk_% = 10000 * .01 = $100 (MaxCashRisk)
-----
MaxCashRisk / (ATR * ATR_SL_MULTIPLIER) = 100 / (3.5 * 1.4) = 20.4 Shares based on Max Cash Risk
-----
(ACCT_SIZE * MaxEquity_%) / STOCK_PRICE = (10000 * .25) / 23.45 = 106.61 Shares based on Max Equity Allocation
The minimum value of each of those options is then used, which in this case would be to purchase 20 shares so as not to exceed the max dollar risk should the stock reach the stop loss target. Likewise, if the ATR were to be much lower, say 0.48 cents, and all else the same, then the strategy would purchase the 106 shares based on Max Equity Allocation because the Max Cash Risk would require 149.25 shares.
MOVING AVERAGE OPTIONS
Select between and change the length & type of up to 5 pairs (10 total) of moving averages
The "Show Cloud-x" option will display a fill color between the "a" and "b" pairs
All moving averages lines can be toggled on/off in the "Style" tab, as well as adjusting their colors.
Visualization features do not affect calculations, meaning you could have all or nothing on the chart and the strategy will still produce results
SIGNAL CHOICES
Choose the fast/shorter length MA and the medium/longer length MA to determine the entry signal
CONFIRMATION OPTIONS
Both of these have customizable values and can be toggled on/off
A candle close over a slower/much longer length moving average
An additional cross-over (cross-under for Shorts) on the MACD indicator using default MACD values. While the MACD indicator is not necessary to have on the chart, it can help to add that for visualization. The calculations will perform whether the indicator is on the chart or not.
EARLY EXIT CRITERIA
Both can be toggled on/off with customizable values
MA Cross Exit will exit the trade early if the select moving averages cross-under (for longs) or cross-over (for shorts), indicating a potential reversal.
Max Bars in Trades will act as a last-resort exit by simply calculating the amount of full bars the trade has been open, and exiting on the opening of the next bar. For example: the default value is 8 bars, so after 8 full bars in the trade, if no other exit has been triggered (Stop Loss, Take Profit, or MA Cross(if enabled)), then the trade will exit at the opening of the 9th bar.
Finally, there is a table displaying the amount of trades taken for each side, and the amount & percent of both early exits. This table can be turned off in the "Style" tab
ADDITIONAL PLOTS
MACD (Moving Average Convergence/Divergence):
- The MACD is an optional confirmation indicator for this strategy.
- Plotting the indicator is not necessary for the strategy to work, but it can be helpful to visually see the status and position of the MACD if this feature is enabled in the strategy
- This helps to identify if there is also momentum behind the entry signal
Syminfo [Epi]Hello! This little script tells you everything TradingView lets you access in a ticker's syminfo in Pine Script:
- description
- type: crypto, economic, forex, fund, futures, index, spread, stock
- tickerid, such as AMEX:BLOK
- prefix, such as AMEX
- Ticker, such as BLOK
- root: for derivatives such as futures contracts
- currency, such as USD
- base currency: returns 'BTC' for the ticker 'BTCUSD'
- mintick
- point value
- session: regular, extended
- timezone
Some surprises I found in my development:
- there are some more types than mentioned in the documentation,
- the tickerid takes on additional information if you adjust for dividends or show extended session,
- the prefix contains "_DL" additions depending on your data subscriptions, .e.g. "CME_MINI_DL:ES1!",
- with futures, TV will show session.regular both for the 'regular' and the 'electronic' session.
- Unfortunately, syminfo does not contain the 'sector', although TV has the information in the database (the sector is shown in the screener but not accessed in Pine Script).
I use this little utility in my development and hope it's useful for the community. I see such a great number of contributions from the community and would like to give back, even if it's not much.
Market Sector Scanner/Screener With MOM + RSI + MFI + DMI + MACDMARKET SECTOR SCANNER/SCREENER MOM + RSI + MFI + DMI + MACD FOR STOCKS CRYPTO & FOREX
This script scans 9 markets constantly and returns the values of 5 different popular indicators.
This indicator helps you see when one of your favorite stocks is bullish or bearish when you are not watching that chart so you can always catch the big moves as they happen.
***HOW TO USE***
A great way to use this market screener is to set up separate chart layouts for each sector you like to trade. Such as the top 9 stocks in the S & P 500, top 9 stocks in the XLF etf, etc. Make sure to set up separate chart layouts in Tradingview so you don’t have to change the symbols constantly. This will give you a good idea in real time if that entire sector is bullish, bearish or mixed. When the entire grid goes red or green, those are very strong signs of market direction across that entire sector, so trades in the corresponding direction are quite safe.
This can be done for crypto as well, using the top 9 cryptocurrencies by market cap. Watch the grid and wait for the entire lot to turn green or red and then take a position in that direction.
You can also use this with a variety of your favorite tickers so you can see when specific markets are looking strong in either direction, instead of constantly changing charts or missing good opportunities because you weren’t watching that specific chart.
This grid can also be used to determine how long to hold a position as well. If the entire grid is still green or red, according to your trade direction, you can usually expect price to continue in that direction until you see some conflicting colors start to pop up on the grid. As it starts to give mixed signals, you can expect the market to be indecisive or reverse which is a good time to get out.
If you have your scanner setup to show similar markets in one sector, be careful taking trades when the grid is very mixed in color. This shows signs of indecision and will likely have choppy price action until the market decides a direction so make sure to use caution when the grid is mixed. It is best to wait for the entire grid to turn green or red and then take position.
***COLOR MEANINGS***
When each indicator value is in bullish territory, the background of that value will turn green.
When each indicator value is in bearish territory, the background of that value will turn red.
When each indicator value is in neutral territory, the background of that value will turn blue.
When all 5 indicators for a ticker are bullish, the ticker background will turn green.
When all 5 indicators for a ticker are bearish, the ticker background will turn red.
When there is a mixture of bullish and bearish values, the ticker background will turn blue.
***CUSTOMIZATION***
You can customize which tickers are in your scanner including stocks, crypto, futures and forex, the source of the indicators, the length of the indicator settings and the smoothing parameters.
***INDICATORS USED***
The indicators used for each ticker are as follows:
Momentum(MOM) - Default length is 14. Bullish is above zero, bearish is below zero.
Relative Strength Index(RSI) - Default length is 14. Bullish is above 50, bearish is below 50.
Money Flow Index(MFI) - Default length is 14. Bullish is above 50, bearish is below 50.
Directional Movement Index(DMI) - Default length is 14 and smoothing is 14. Calculated by subtracting di minus from di plus. If the value is positive, it is bullish. If the value is negative, it is bearish.
Moving Average Convergence & Divergence(MACD) - Default settings are 12, 26, 9. If the short line is greater than the long line, then it is bullish. If the short line is less than the long line, it is bearish.
***MARKETS***
This market scanner can be used as a signal on all markets, including stocks, crypto, futures and forex.
***TIMEFRAMES***
This scanner can be used on all timeframes and pulls data from other tickers using the same timeframe as what your current chart is set to.
***TIPS***
Try using numerous indicators of ours on your chart so you can instantly see the bullish or bearish trend of multiple indicators in real time without having to analyze the data. Some of our favorites are Trend Friend Scalp & Swing Signals, Auto Fibonacci, Directional Movement Index, Volume Profile With Buy/Sell Pressure, Auto Support And Resistance and Money Flow Index in combination with this Scanner. They all have real time Bullish and Bearish labels as well so you can immediately understand each indicator's trend.
Template Trailing Strategy (Backtester)💭 Overview
+ Title: Template Trailing Strategy (Backtester)
+ Author: Iason Nikolas (jason5480)
+ License: CC BY-NC-SA 4.0
💢 What is the "Template Trailing Strategy (Backtester)" ❓
The "Template Trailing Strategy (Backtester)" (TTS) is a back-tester orchestration framework. It supercharges the implementation-test-evaluation lifecycle of new trading strategies, by making it possible to plug in your own trading idea.
While TTS offers a vast number of configuration settings, it primarily allows the trader to:
Test and evaluate your own trading logic that is described in terms of entry, exit, and cancellation conditions.
Define the entry and exit order types as well as their target prices when the limit, stop, or stop-limit order types are used.
Utilize a variety of options regarding the placement of the stop-loss and take-profit target(s) prices and support for well-known techniques like moving to breakeven and trailing.
Provide well-known quantity calculation methods to properly handle risk management and easily evaluate trading strategies and compare them.
Alert on each trading event or any related change through a robust and fully customizable messaging system.
All of the above makes TTS a practical toolkit: once you learn it, many repetitive tasks that strategy authors usually re-implement are eliminated. Using TradingView’s built-in backtesting engine makes testing and comparing ideas straightforward.
By utilizing the TTS one can easily swap "trading logic" by testing, evaluating, and comparing each trading idea and/or individual component of a strategy.
Finally, TTS, through its per-event alert management (and debugging) system, provides an automated solution that supports live trading with brokers via webhooks.
NOTE: The "Template Trailing Strategy (Backtester)" does not dictate how you can combine different indicator types. Thus, it should not be confused as a "Trading System", because it gives its user full flexibility on that end (for better or worse).
💢 What is a "Signal Indicator" ❓
"Signal Indicator" (SI) is an indicator that can output a "signal" that follows a specific convention so that the "Template Trailing Strategy (Backtester)" can "understand" and execute the orders accordingly. The SI realizes the core trading logic signaling to the TTS when to enter, exit, or cancel an order. A SI instructs the TTS "when" to enter or exit, and the TTS determines "how" to enter and exit the position once the Signal Indicator generates a signal.
A very simple example of a Signal Indicator might be a 200-day Simple Moving Average Signal. When the price of the security closes above the 200-day SMA, a SI would provide TTS with a "long entry signal". Once TTS receives the "long entry signal", the TTS will open a long position and send an alert or automated trade message via webhook to a broker, based on the Entry settings defined in TTS. If the TTS Entry settings specify a "Market" order type, then the open long position will be executed by TTS immediately. But if the TTS Entry settings specify a "Stop" order type with a 1% Stop Distance, then when the price of the security rises by 1% after the "long entry signal" occurs, the TTS will open a long position and the Long Entry alert or webhook to the broker will be sent.
🤔 How to Guide
💢 How to connect a "signal" from a "Signal Indicator" ❓
The "Template Trailing Strategy (Backtester)" was designed to receive external signals from a "Signal Indicator". In this way, a "new trading idea" can be developed, configured, and evaluated separately from the TTS. Similarly, the SI can be held constant, and the trading mechanics can change in the TTS settings and back-tested to answer questions such as, "Am I better with a different stop loss placement method, what if I used a limit order instead of a stop order to enter, what if I used 25% margin instead of trading spot market?"
To make that possible by connecting an external signal indicator to TTS, you should:
Add both your SI (e.g. "Two MA Signal Indicator" , "Click Signal Indicator" , "Signal Adapter" , "Signal Composer" ) and the TTS script to the same chart.
Open the script's Settings / Inputs dialog for the TTS.
In the 🛠️ STRATEGY group set 𝐃𝐞𝐚𝐥 𝐂𝐨𝐧𝐝𝐢𝐨𝐧𝐬 𝐌𝐨𝐝𝐞 to 🔨External (this makes TTS listen to an external signal source).
Still inside 🛠️ STRATEGY locate the 🔌𝐒𝐢𝐠𝐧𝐚𝐥 🛈 input and choose the plotted output of your SI. The option should look like: "<SI short title>:🔌Signal to TTS" .
Verbose troubleshooting & tips
If the SI does not appear in the 🔌Signal 🛈 selector, confirm both scripts are added to the same chart and the SI exposes a plotted series (title often "🔌Signal to TTS").
When using multiple SIs, pick the SI instance that actually outputs the "🔌Signal to TTS" plotted series.
Validate on the chart: when your SI changes state, the plotted "🔌Signal" series in the TTS (visible in the data window) should change accordingly.
The TTS accepts only signals that follow the tts_convention DealConditions structure. Do not attempt to feed arbitrary scalar series without using conv.getDealConditions / conv.DealConditions.
Make sure your SI composes a DealConditions value following the TTS convention (startLong, endLong, startShort, endShort — optional cancel fields). See the template below.
If the plot is present but TTS does not react, ensure the SI plot is non-repainting (or accept realtime/backtest limitations). Test on historical bars first.
Create alerts on the strategy (see the Alerts section). Use the {{strategy.order.alert_message}} placeholder in the Create Alert dialog to forward TTS messages.
💢 How to create a custom trading logic ❓
The "Template Trailing Strategy (Backtester)" provides two ways to plug in your custom trading logic. Both of them have their advantages and disadvantages.
✍️ Develop your own Customized "Signal Indicator" 💥
The first approach is meant to be used for relatively more complex trading logic. The advantages of this approach are the full control and customization you have over the trading logic and the relatively simple configuration setup by having two scripts only. The downsides are that you have to have some experience with pinescript or you are willing to learn and experiment. You should also know the exact formula for every indicator you will use since you have to write it by yourself. Copy-pasting from existing open-source indicators will get you started quite fast though.
The idea here is either to create a new indicator script from scratch or to copy an existing non-signal indicator and make it a "Signal Indicator". To create a new script, press the "Pine Editor" button below the chart to open the "Pine Editor" and then press the "Open" button to open the drop-down menu with the templates. Select the "New Indicator" option. Add it to your chart to copy an existing indicator and press the source code {} button. Its source code will be shown in the "Pine Editor" with a warning on top stating that this is a read-only script. Press the "create a working copy". Now you can give a descriptive title and a short title to your script, and you can work on (or copy-paste) the (other) indicators of your interest. Once you have the information needed to decide, define a DealConditions object and plot it like this:
import jason5480/tts_convention/ as conv
// Calculate the start, end, cancel start, cancel end conditions
dealConditions = conv.DealConditions.new(
startLongDeal = ,
startShortDeal = ,
endLongDeal = ,
endShortDeal = ,
cnlStartLongDeal = ,
cnlStartShortDeal = ,
cnlEndLongDeal = ,
cnlEndShortDeal = )
// Use this signal in scripts like "Template Trailing Strategy (Backtester)" and "Signal Composer" that can utilize its value
// Emit the current signal value according to the TTS framework convention
plot(series = conv.getSignal(dealConditions), title = '🔌Signal to TTS', color = #808000, editable = false, display = display.data_window + display.status_line, precision = 0)
You should import the latest version of the tts_convention library and write your deal conditions appropriately based on your trading logic and put them in the code section shown above by replacing the "…" part after "=". You can omit the conditions that are not relevant to your logic. For example, if you use only market orders for entering and exiting your positions the cnlStartLongDeal, cnlStartShortDeal, cnlEndLongDeal, and cnlEndShortDeal are irrelevant to your case and can be safely omitted from the DealConditions object. After successfully compiling your new custom SI script add it to the same chart with the TTS by pressing the "Add to chart" button. If all goes well, you will be able to connect your "signal" to the TTS as described in the "How to connect a "signal" from a "Signal Indicator"?" guide.
🧩 Adapt and Combine existing non-signal indicators 💥
The second approach is meant to be used for relatively simple trading logic. The advantages of this approach are the lack of pine script and coding experience needed and the fact that it can be used with closed-source indicators as long as the decision-making part is displayed as a line in the chart. The drawback is that you have to have a subscription that supports the "indicator on indicator" feature so you can connect the output of one indicator as an input to another indicator. Please check if your plan supports that feature here
To plug in your own logic that way you have to add your indicator(s) of preference in the chart and then add the "Signal Adapter" script in the same chart as well. This script is a "Signal Indicator" that can be used as a proxy to define your custom logic in the CONDITIONS group of the "Settings/Inputs" tab after defining your inputs from your preferred indicators in the VARIABLES group. Then a "signal" will be produced, if your logic is simple enough it can be directly connected to the TTS that is also added to the same chart for execution. Check the "How to connect a "signal" from a "Signal Indicator"?" in the "🤔 How to Guide" for more information.
If your logic is slightly more complicated, you can add a second "Signal Adapter" in your chart. Then you should add the "Signal Composer" in the same chart, go to the SIGNALS group of the "Settings/Inputs" tab, and connect the "signals" from the "Signal Adapters". "Signal Composer" is also a SI so its composed "signal" can be connected to the TTS the same way it is described in the "How to connect a "signal" from a "Signal Indicator"?" guide.
At this point, due to the composability of the framework, you can add an arbitrary number (bounded by your subscription of course) of "Signal Adapters" and "Signal Composers" before connecting the final "signal" to the TTS.
💢 How to set up ⏰Alerts ❓
The "Template Trailing Strategy (Backtester)" provides a fully customizable per-event alert mechanism. This means that you may have an entirely different message for entering and exiting into a position, hitting a stop-loss or a take-profit target, changing trailing targets, etc. There are no restrictions, and this gives you great flexibility.
First enable the events you want under the "🔔 ALERT MESSAGES" module. Each enabled event exposes a text area where you can craft the message using placeholders that TTS replaces with actual values when the event occurs.
The placeholder categories (exact names used by the script) are:
Chart & instrument:
{{ticker}}
{{base_currency}}
{{quote_currency}}
Entry / exit / stop / TP prices & offsets:
{{entry_price}}
{{exit_price}}
{{stop_loss_price}}
{{take_profit_price_1}} ... {{take_profit_price_5}}
{{entry+_price}}, {{entry-_price}}, {{exit+_price}}, {{exit-_price}} — Optional offset helpers (computed using "Offset Ticks")
Quantities, percents & derived quantities:
{{entry_base_quantity}} — base units at entry (e.g. BTC)
{{entry_quote_quantity}} — quote amount at entry (e.g. USD)
{{risk_perc}} — % of capital risked for that entry (multiplied by 100 when "Percentage Range " is enabled)
{{remaining_quantity_perc}} — % of the initial position remaining at close/SL
{{remaining_base_quantity}} — remaining base units at close/SL
{{take_profit_quantity_perc_1}} ... {{take_profit_quantity_perc_5}} — % sold/bought at each TP
{{take_profit_base_quantity_1}} ... {{take_profit_base_quantity_5}} — base units closed at each TP
❗ Important: the per-event alert text is injected into the Create Alert dialog using TradingView's strategy placeholder:
{{strategy.order.alert_message}}
During the creation of a strategy alert, make sure the placeholder {{strategy.order.alert_message}} exists in the "Message" box. TradingView will substitute the per-event text you configured and enabled in TTS Settings/Inputs before sending it via webhook/notification.
Tip: For webhook/broker execution, set the proper "Condition" in the Create Alert dialog (for changing-entry/exit/SL notifications use "Order fills and alert() function calls" or "alert() function calls only" as appropriate).
💢 How to execute my orders in a broker ❓
To execute your orders in a broker that supports webhook integration, you should enable the appropriate alerts in the "Template Trailing Strategy (Backtester)" first (see the "How to set up Alerts?" guide above). Then you should go to the "Create Alert/Notifications" tab check the "Webhook URL" and paste the URL provided by your broker. You have to read the documentation of your broker for more information on what messages are expected.
Keep in mind that some brokers have deep integration with TradingView so a per-event alert approach might be overkill.
📑 Definitions
This section tries to give some definitions in terms that appear in the "Settings/Inputs" tab of the "Template Trailing Strategy (Backtester)"
💢 What is Trailing ❓
Trailing is a technique where a price target follows another "barrier" price (usually high or low) by trying to keep a maximum distance from the "barrier" when it moves in only one direction (up or down). When the "barrier" moves in the other direction the price target will not change. There are as many types of trailing as price targets, which means that there are entry trailing, exit trailing, stop-loss trailing, and take-profit trailing techniques.
💢 What is a Moonbag ❓
A Moonbag in a trade is the quantity of the position that is reserved and will not be exited even if all take-profit targets defined in the strategy are hit, the quantity will be exited only if the stop-loss is hit or a close signal is received. This makes the stop-loss trailing technique in a trend-following strategy a good candidate to take advantage of a Moonbag.
💢 What is Distance ❓
Distance is the difference between two prices.
💢 What is Bias ❓
Bias is a psychological phenomenon where you make decisions based on market sentiment. For example, when you want to enter a long position you have a long bias, and when you want to exit from the long position you have a short bias. It is the other way around for the short position.
💢 What is the Bias Distance of a price target ❓
The Bias Distance of a price target is the distance that the target will deviate from its initial price. The direction of this deviation depends on the bias of the market. For example, suppose you are in a long position, and you set a take-profit target to the local highest high. In that case, adding a bias distance of five ticks will place your take-profit target 5 ticks below this local highest high because you have a short bias when exiting a long position. When the bias is long the bias distance will be added resulting in a higher target price and when you have a short bias the bias distance will be subtracted.
⚙️ Settings
In the "Settings/Inputs" tab of the "Template Trailing Strategy (Backtester)", you can find all the customizable settings that are provided by the framework. The variety of those settings is vast; hence we will only scratch the surface here. However, for every setting, there is an information icon 🛈 where you can learn more if you mouse over it. The "Settings/Inputs" tab is divided into ten main groups. Each one of them is responsible for one module of the framework. Every setting is part of a group that is named after the module it represents. So, to spot the module of a setting find the title that appears above it comes with an emoji and uppercase letters. Some settings might have the same name but belong to different modules e.g. "Tgt Dist Mtd" (Target Distance Method). Some settings are indented, which means that they are closely related to the non-indented setting above. Usually, indented settings provide further configuration for one or more options of the non-indented setting above. The groups that correspond to each module of the framework are the following:
🗺️ Quick Module Cross-Reference (use emojis to jump to setting groups)
📆 FILTERS — session, date & weekday filters
🛠️ STRATEGY — internal vs external deal-conditions; pick the signal source
🔧 STRATEGY – INTERNAL — built-in Two MA logic for demonstration purposes
🎢 VOLATILITY — ATR / StDev update modes
🔷 ENTRY — entry order types & trailing
🎯 TAKE PROFIT — multi-step TP and trailing rules
🛑 STOP LOSS — stop placement, move-to-breakeven, trailing
🟪 EXIT — exit order types & cancel logic
💰 QUANTITY/RISK MANAGEMENT — position sizing, moonbag, limits
📊 ANALYTICS — stats, streaks, seasonal tables
🔔 ALERT MESSAGES — per-event alert templates & placeholders
😲 Caveats
💢 Does "Template Trailing Strategy (Backtester)" have repainting behavior? ❓
The answer is that the "Template Trailing Strategy (Backtester)" does not repaint as long as the "Signal Indicator" that is connected also does not repaint. If you developed your own SI make sure that you understand and know how to prevent this behavior. The publication by @PineCoders here will give you a good idea on how to avoid most of the repainting cases.
⚠️ There is an exception though, when the "Enable Trail⚠️💹" checkbox is checked, the Take Profit trailing feature is enabled, and a tick-based approach is used, meaning that after a while, when the TradingView discards all the real-time data, assumptions will be made by the backtesting engine that will cause a form of repainting. To avoid making false assumptions please disable this feature in the early stages and evaluate its usefulness in your strategy later on, after first confirming the success of the logic without this feature. In this case, consider turning on the bar magnifier feature. This way you will get more accurate backtest results when the Take Profit trailing feature is enabled.
💢 Can "Template Trailing Strategy (Backtester)" satisfy all my trading strategies ❓
While this framework can satisfy quite a large number of trading strategies there are cases where it cannot do so. For example, if you have a custom logic for your stop-loss or take-profit placement, or if you want to dollar cost average, then it might be better to start a new strategy script from scratch.
⚠️ It is not recommended to copy the official TTS code and start developing unless you are a Pine wizard! Even in that case, there is a stiff learning curve that might not be worth your time. Last, you must consider that I do not offer support for customized versions of the TTS script and if something goes wrong in the process you are all alone.
💝 Support & Feedback
For feedback, bug reports, or feature requests, contact me via TradingView PM or use the script comments.
Note: The author's personal links and contact are available on the TradingView profile.
🤗 Thanks
Special thanks to the welcoming community members, who regularly gave feedback all those years and helped me to shape the framework as it is today! Thanks everyone who contributed by either filing a "defect report" or asking questions that helped me to understand what improvements were necessary to help traders.
Enjoy!
Jason
LargestMarketCapsThis trading system uses a MA to check if the LARGEST CAP stocks are above or below the MA.
You can see from the indicator below how well it manages to capture big moves.
It aggregates the data of all the tickers to create the histogram indicator at the bottom of the chart called MarketLeaders.
If a ticker is above its moving average, then the output will increase by +1 and -1 if a ticker is below its moving average.
This is a powerful system because it uses not only data from one stock but from the stocks that really affect the market big time. If those stocks don't do well, the market won't do well either.
Basically if all the market leaders are doing well, then this system will buy those 20 tickers and keep positions open until the MarketLeaders indicator crosses below 0 -- meaning red.
It also has a red stop loss line, with a wide 15% stop loss to keep us in the trades for the long term.
I've used a 5-day chart because I wanted fewer signals, but higher quality signals.
There are no profit targets, this exits when the indicator turns red -- meaning below 0 or if a position falls 15% in price.
The MA setting is adjustable, the default is 20
These are the tickers that the strategy and indicator currently looks at
The tickers will need to be updated every 6-12 months to remove and ad those who have dropped out of the largest 20 stocks.
It would be a good idea to create a watchlist and alerts for the Large Cap tickers so you can scroll through to see how the system performed on each ticker
"SPX"
"QQQ"
"AAPL"
"MSFT"
"GOOG"
"FB"
"BRK.A"
"TSLA"
"V"
"JPM"
"WMT"
"UNH"
"MA"
"KO"
"PYPL"
"PG"
"HD"
"DIS"
"BAC"
"ADBE"
"CMCSA"
"NKE"
RELATED IDEAS / Indicators
Market Leaders Ribbon
Market Leaders Large Performance Table
Nic's VIX CorrelationIdentifies divergences in price action between the VIX (volatility index) and a ticker. Divergences can be a 'red flag' identifying lack of confidence in the price action.
Best used in with volume studies, across multiple time frames, and across multiple tickers.
Supports any volatility ticker (VIX, VXN, RVX).
Breakout Reversal Entry on WMA - NG1! Overnight ver 1This script is for learning purposes only
This strategy will plot arrows when price breaks so far above/below WMA. The strategy will enter when the price breaks away from WMA. All entries are reversals. Users can set WMA length and source; also the distance of the price away from WMA to enter. Adjustable bracket orders are placed for exit, with trailing stop or market stop choice. Last, users can set the time of day they want to enter a trade.
My Preference: I am testing this strategy on NG1! over night on 1 minute candle. with .003 on price drop/climb, I get entries almost every night. Also 10 tick stop and 5 tick profit seems backward to most, but with a high win/loss ratio, it performs quite well. Trailing stops generally help out as well.
INPUTS:
Length - The is the WMA length
Source - WMA source (High, Low, Open, Close...)
When Price Drops - This is the distance in ticks when the price drops away from WMA, an arrow is plotted, and reversal entry order is placed
When Price Climbs - Same as price drop, just in the opposite direction
Trailing Stop check box - Check if you want to place a trailing stop so many tick away from entry. Unchecked is Market (hard) stop so many ticks from entry.
Stop - Number of ticks away from entry a the stop or trailing stop is set (for NG 1 tick = $0.001)
Limit Out - Number of ticks away from entry a limit order is placed to take profits
Limit Time of day check box - check to use the time of day to limit what time of day order entry will occur.
Start/Stop Trades (Est Time) - First box is when the strategy will be allowed to start buying and stop is when the strategy will stop being allowed to buy. Sell orders continue until a stop or limit triggers an exit. These times are Eastern time zone
PROPERTIES:
Pyramiding - This feature will allow multiple entries to occur. If set to 1, the strategy should only trade 1 contract at a time. If set to 2, the strategy will enter a second order if entry requirements are met. This allows you to be holding 2 contracts. Basically on a good day, it will multiply your earnings, on a bad day, you'll just lose more. For testing, I keep this on 1.
TIPS:
- If you want to go long only, set "When Price Climbs" to an impossible number, like 10,000. It's not possible for NG to move $10 is a matter of minutes so it will not enter the market with a short order. Also keep in mind you can set different requirements for going long vs going short. If you think there is more pull on the market in a particular direction.
Fixed Dollar Risk Lines V2*This is a small update to the original concept that adds greater customization of the visual elements of the script. Since some folks have liked the original I figured I'd put this out there.*
Fixed Dollar Risk Lines is a utility indicator that converts a user-defined dollar risk into price distance and plots risk lines above and below the current price for popular futures contracts. It helps you place stops or entries at a consistent dollar risk per trade, regardless of the market’s tick value or tick size.
What it does:
-You choose a dollar amount to risk (e.g., $100) and a futures contract (ES, NQ, GC, YM, RTY, PL, SI, CL, BTC).
The script automatically:
-Looks up the contract’s tick value and tick size
-Converts your dollar risk into number of ticks
-Converts ticks into price distance
Plots:
-Long Risk line below current price
-Short Risk line above current price
-Optional labels show exact price levels and an information table summarizes your settings.
Key features
-Consistent dollar risk across instruments
-Supports major futures contracts with built‑in tick values and sizes
-Toggle Long and Short risk lines independently
-Customizable line width and colors (lines and labels)
-Right‑axis price level display for quick reading
-Compact info table with contract, risk, and computed prices
Typical use
-Long setups: use the green line as a stop level below entry to match your chosen dollar risk.
-Short setups: use the red line as a stop level above entry to match your chosen dollar risk.
-Quickly compare how the same dollar risk translates to distance on different contracts.
Inputs
-Risk Amount (USD)
-Futures Contract (ES, NQ, GC, YM, RTY, PL, SI, CL, BTC)
-Show Long/Short lines (toggles)
-Line Width
-Colors for lines and labels
Notes
-Designed for futures symbols that match the listed contracts’ tick specs. If your symbol has different tick value/size than the defaults, results will differ.
-Intended for educational/informational use; not financial advice.
-This tool streamlines risk placement so you can focus on execution while keeping dollar risk consistent across markets.
Multivariate Kalman Filter🙏🏻 I see no1 ever posted an open source Multivariate Kalman filter on TV, so here it is, for you. Tested and mathematically correct implementation, with numerical safeties in place that do not affect the final results at all. That’s the main purpose of this drop, just to make the tool available here. Linear algebra everywhere, Neo would approve 4 sure.
...
Personally I haven't found any real use case of it for myself, aside from a very specific one I will explain later, but others usually do…
Almost every1 in the quant industry who uses Kalman is in fact misusing it, because by its real definition, it should be applied to Not the exact known values (e.g as real ticks provided by transparent audited regulated exchange), but “measurements” of those ‘with errors’.
If your measurements don’t have errors or you have real precise data, by its internal formulas Kalman will output the exact inputs. So most who use it come up with some imaginary errors of sorts, like from some kind of imaginary fair price etc. The important easy to miss point, the errors of your measurements have to be symmetric around its mean ‘ at least ’, if errors are biased, Kalman won’t provide.
For most tasks there are better tools, including other state space models , but still Multivariate Kalman is a very powerful instrument, you can make it do all kinds of stuff. Also as a state space model it can also provide confidence & prediction intervals without explicit calculations of dem.
...
In this script I included 2 example use cases, the first one is the classic tho perfectly working misuse, the second one is what I do with it:
One
Naive, estimates “hidden” adaptive moving regression endpoint. The result you can see on the chart above. You can imagine that your real datapoints are in fact non perfect measures of some hidden state, and by defining measurement noise and process noise, and by constructing the input matrixes in certain ways, you can express what that state should be.
Two
Upscaling tick lattice, aka modelling prices as if native tick size would’ve been lower. Kinda very specific task, mostly needed in HFT or just for analytical purposes. Some like ZN have huge tick sizes, they are traded a lot but barely do more than 20 ticks range in a session. The idea is to model raw data as AR2 process , learn the phi1 and phi2, make one point forecasts based on dem, and the process noise would be the variance of errors from these forecasts. The measurement noise here is legit, it’s quantization noise based on tick size, no need in olympic gold in mental gymnastics xd
^^ artificially upscaling ZN futures tick lattice
...
I really made it available there so You guys can take it and some crazy ish with it, just let state space models abduct your conciseness and never look back
∞
SP500 Session Gap Fade StrategySummary in one paragraph
SPX Session Gap Fade is an intraday gap fade strategy for index futures, designed around regular cash sessions on five minute charts. It helps you participate only when there is a full overnight or pre session gap and a valid intraday session window, instead of trading every open. The original part is the gap distance engine which anchors both stop and optional target to the previous session reference close at a configurable flat time, so every trade’s risk scales with the actual gap size rather than a fixed tick stop.
Scope and intent
• Markets. Primarily index futures such as ES, NQ, YM, and liquid index CFDs that exhibit overnight gaps and regular cash hours.
• Timeframes. Intraday timeframes from one minute to fifteen minutes. Default usage is five minute bars.
• Default demo used in the publication. Symbol CME:ES1! on a five minute chart.
• Purpose. Provide a simple, transparent way to trade opening gaps with a session anchored risk model and forced flat exit so you are not holding into the last part of the session.
• Limits. This is a strategy. Orders are simulated on standard candles only.
Originality and usefulness
• Unique concept or fusion. The core novelty is the combination of a strict “full gap” entry condition with a session anchored reference close and a gap distance based TP and SL engine. The stop and optional target are symmetric multiples of the actual gap distance from the previous session’s flat close, rather than fixed ticks.
• Failure mode it addresses. Fixed sized stops do not scale when gaps are unusually small or unusually large, which can either under risk or over risk the account. The session flat logic also reduces the chance of holding residual positions into late session liquidity and news.
• Testability. All key pieces are explicit in the Inputs: session window, minutes before session end, whether to use gap exits, whether TP or SL are active, and whether to allow candle based closes and forced flat. You can toggle each component and see how it changes entries and exits.
• Portable yardstick. The main unit is the absolute price gap between the entry bar open and the previous session reference close. tp_mult and sl_mult are multiples of that gap, which makes the risk model portable across contracts and volatility regimes.
Method overview in plain language
The strategy first defines a trading session using exchange time, for example 08:30 to 15:30 for ES day hours. It also defines a “flat” time a fixed number of minutes before session end. At the flat bar, any open position is closed and the bar’s close price is stored as the reference close for the next session. Inside the session, the strategy looks for a full gap bar relative to the prior bar: a gap down where today’s high is below yesterday’s low, or a gap up where today’s low is above yesterday’s high. A full gap down generates a long entry; a full gap up generates a short entry. If the gap risk engine is enabled and a valid reference close exists, the strategy measures the distance between the entry bar open and that reference close. It then sets a stop and optional target as configurable multiples of that gap distance and manages them with strategy.exit. Additional exits can be triggered by a candle color flip or by the forced flat time.
Base measures
• Range basis. The main unit is the absolute difference between the current entry bar open and the stored reference close from the previous session flat bar. That value is used as a “gap unit” and scaled by tp_mult and sl_mult to build the target and stop.
Components
• Component one: Gap Direction. Detects full gap up or full gap down by comparing the current high and low to the previous bar’s high and low. Gap down signals a long fade, gap up signals a short fade. There is no smoothing; it is a strict structural condition.
• Component two: Session Window. Only allows entries when the current time is within the configured session window. It also defines a flat time before the session end where positions are forced flat and the reference close is updated.
• Component three: Gap Distance Risk Engine. Computes the absolute distance between the entry open and the stored reference close. The stop and optional target are placed as entry ± gap_distance × multiplier so that risk scales with gap size.
• Optional component: Candle Exit. If enabled, a bullish bar closes short positions and a bearish bar closes long positions, which can shorten holding time when price reverses quickly inside the session.
• Session windows. Session logic uses the exchange time of the chart symbol. When changing symbols or venues, verify that the session time string still matches the new instrument’s cash hours.
Fusion rule
All gates are hard conditions rather than weighted scores. A trade can only open if the session window is active and the full gap condition is true. The gap distance engine only activates if a valid reference close exists and use_gap_risk is on. TP and SL are controlled by separate booleans so you can use SL only, TP only, or both. Long and short are symmetric by construction: long trades fade full gap downs, short trades fade full gap ups with mirrored TP and SL logic.
Signal rule
• Long entry. Inside the active session, when the current bar shows a full gap down relative to the previous bar (current high below prior low), the strategy opens a long position. If the gap risk engine is active, it places a gap based stop below the entry and an optional target above it.
• Short entry. Inside the active session, when the current bar shows a full gap up relative to the previous bar (current low above prior high), the strategy opens a short position. If the gap risk engine is active, it places a gap based stop above the entry and an optional target below it.
• Forced flat. At the configured flat time before session end, any open position is closed and the close price of that bar becomes the new reference close for the following session.
• Candle based exit. If enabled, a bearish bar closes longs, and a bullish bar closes shorts, regardless of where TP or SL sit, as long as a position is open.
What you will see on the chart
• Markers on entry bars. Standard strategy entry markers labeled “long” and “short” on the gap bars where trades open.
• Exit markers. Standard exit markers on bars where either the gap stop or target are hit, or where a candle exit or forced flat close occurs. Exit IDs “long_gap” and “short_gap” label gap based exits.
• Reference levels. Horizontal lines for the current long TP, long SL, short TP, and short SL while a position is open and the gap engine is enabled. They update when a new trade opens and disappear when flat.
• Session background. This version does not add background shading for the session; session logic runs internally based on time.
• No on chart table. All decisions are visible through orders and exit levels. Use the Strategy Tester for performance metrics.
Inputs with guidance
Session Settings
• Trading session (sess). Session window in exchange time. Typical value uses the regular cash session for each contract, for example “0830-1530” for ES. Adjust if your broker or symbol uses different hours.
• Minutes before session end to force exit (flat_before_min). Minutes before the session end where positions are forced flat and the reference close is stored. Typical range is 15 to 120. Raising it closes trades earlier in the day; lowering it allows trades later in the session.
Gap Risk
• Enable gap based TP/SL (use_gap_risk). Master switch for the gap distance exit engine. Turning it off keeps entries and forced flat logic but removes automatic TP and SL placement.
• Use TP limit from gap (use_gap_tp). Enables gap based profit targets. Typical values are true for structured exits or false if you want to manage exits manually and only keep a stop.
• Use SL stop from gap (use_gap_sl). Enables gap based stop losses. This should normally remain true so that each trade has a defined initial risk in ticks.
• TP multiplier of gap distance (tp_mult). Multiplier applied to the gap distance for the target. Typical range is 0.5 to 2.0. Raising it places the target further away and reduces hit frequency.
• SL multiplier of gap distance (sl_mult). Multiplier applied to the gap distance for the stop. Typical range is 0.5 to 2.0. Raising it widens the stop and increases risk per trade; lowering it tightens the stop and may increase the number of small losses.
Exit Controls
• Exit with candle logic (use_candle_exit). If true, closes shorts on bullish candles and longs on bearish candles. Useful when you want to react to intraday reversal bars even if TP or SL have not been reached.
• Force flat before session end (use_forced_flat). If true, guarantees you are flat by the configured flat time and updates the reference close. Turn this off only if you understand the impact on overnight risk.
Filters
There is no separate trend or volatility filter in this version. All trades depend on the presence of a full gap bar inside the session. If you need extra filtering such as ATR, volume, or higher timeframe bias, they should be added explicitly and documented in your own fork.
Usage recipes
Intraday conservative gap fade
• Timeframe. Five minute chart on ES regular session.
• Gap risk. use_gap_risk = true, use_gap_tp = true, use_gap_sl = true.
• Multipliers. tp_mult around 0.7 to 1.0 and sl_mult around 1.0.
• Exits. use_candle_exit = false, use_forced_flat = true. Focus on the structured TP and SL around the gap.
Intraday aggressive gap fade
• Timeframe. Five minute chart.
• Gap risk. use_gap_risk = true, use_gap_tp = false, use_gap_sl = true.
• Multipliers. sl_mult around 0.7 to 1.0.
• Exits. use_candle_exit = true, use_forced_flat = true. Entries fade full gaps, stops are tight, and candle color flips flatten trades early.
Higher timeframe gap tests
• Timeframe. Fifteen minute or sixty minute charts on instruments with regular gaps.
• Gap risk. Keep use_gap_risk = true. Consider slightly higher sl_mult if gaps are structurally wider on the higher timeframe.
• Note. Expect fewer trades and be careful with sample size; multi year data is recommended.
Properties visible in this publication
• On average our risk for each position over the last 200 trades is 0.4% with a max intraday loss of 1.5% of the total equity in this case of 100k $ with 1 contract ES. For other assets, recalculations and customizations has to be applied.
• Initial capital. 100 000.
• Base currency. USD.
• Default order size method. Fixed with size 1 contract.
• Pyramiding. 0.
• Commission. Flat 2 USD per order in the Strategy Tester Properties. (2$ buying + 2$selling)
• Slippage. One tick in the Strategy Tester Properties.
• Process orders on close. ON.
Realism and responsible publication
• No performance claims are made. Past results do not guarantee future outcomes.
• Costs use a realistic flat commission and one tick of slippage per trade for ES class futures.
• Default sizing with one contract on a 100 000 reference account targets modest per trade risk. In practice, extreme slippage or gap through events can exceed this, so treat the one and a half percent risk target as a design goal, not a guarantee.
• All orders are simulated on standard candles. Shapes can move while a bar is forming and settle on bar close.
Honest limitations and failure modes
• Economic releases, thin liquidity, and limit conditions can break the assumptions behind the simple gap model and lead to slippage or skipped fills.
• Symbols with very frequent or very large gaps may require adjusted multipliers or alternative risk handling, especially in high volatility regimes.
• Very quiet periods without clean gaps will produce few or no trades. This is expected behavior, not a bug.
• Session windows follow the exchange time of the chart. Always confirm that the configured session matches the symbol.
• When both the stop and target lie inside the same bar’s range, the TradingView engine decides which is hit first based on its internal intrabar assumptions. Without bar magnifier, tie handling is approximate.
Legal
Education and research only. This strategy is not investment advice. You remain responsible for all trading decisions. Always test on historical data and in simulation with realistic costs before considering any live use.
Sigma Trinity ModelAbstract
Sigma Trinity Model is an educational framework that studies how three layers of market behavior interact within the same trend: (1) structural momentum (Rasta), (2) internal strength (RSI), and (3) continuation/compounding structure (Pyramid). The model deliberately combines bar-close momentum logic with intrabar, wick-aware strength checks to help users see how reversals form, confirm, and extend. It is not a signal service or automation tool; it is a transparent learning instrument for chart study and backtesting.
Why this is not “just a mashup”
Many scripts merge indicators without explaining the purpose. Sigma Trinity is a coordinated, three-engine study designed for a specific learning goal:
Rasta (structure): defines when momentum actually flips using a dual-line EMA vs smoothed EMA. It gives the entry/exit framework on bar close for clean historical study.
RSI (energy): measures internal strength with wick-aware triggers. It uses RSI of LOW (for bottom touches/reclaims) and RSI of HIGH (for top touches/exhaustion) so users can see intrabar strength/weakness that the close can hide.
Pyramid (progression): demonstrates how continuation behaves once momentum and strength align. It shows the logic of adds (compounding) as a didactic layer, also on bar close to keep historical alignment consistent.
These three roles are complementary, not redundant: structure → strength → progression.
Architecture Overview
Execution model
Rasta & Pyramid: bar close only by default (historically stable, easy to audit).
RSI: per tick (realtime) with bar-close backup by default, using RSI of LOW for entries and RSI of HIGH for exits. This makes the module sensitive to intra-bar wicks while still giving a close-based safety net for backtests.
Stops (optional in strategy builds): wick-accurate: trail arms/ratchets on HIGH; stop hit checks with LOW (or Close if selected) with a small undershoot buffer to avoid micro-noise hits.
Visual model
Dual lines (EMA vs smoothed EMA) for Rasta + color fog to see direction and compression/expansion.
Rungs (small vertical lines) drawn between the two Rasta lines to visualize wave spacing and rhythm.
Clean labels for Entry/Exit/Pyramid Add/RSI events. Everything is state-locked to avoid spamming.
Module 1 — Rasta (Structural Momentum Layer)
Goal: Identify structural momentum reversals and maintain a consistent, replayable backbone for study.
Method:
Compute an EMA of a chosen price source (default Close), and a smoothed version (SMA/EMA/RMA/WMA/None selectable).
Flip points occur when the EMA line crosses the smoothed line.
Optional EMA 8/21 trend filter can gate entries (long-bias when EMA8 > EMA21). A small “adaptive on flip” option lets an entry fire when the filter itself flips to ON and the EMA is already above the smoothed line—useful for trend resumption.
Why bar close only?
Bar-close Rasta gives a stable, auditable timeline for the structure of the trend. It teaches users to separate “structure” (close-resolved) from “energy” (intrabar, via RSI).
Visuals:
Fog between the lines (green/red) to show regime.
Rungs between lines to show spread (compression vs expansion).
Optional plotting of EMA8/EMA21 so users can see the gating effect.
Module 2 — RSI (Internal Strength / Energy Layer)
Goal: Reveal the intrabar strength/weakness that often precedes or confirms structural flips.
Method:
Standard RSI with adjustable length and signal smoothing for the panel view.
Logic uses wick-aware sources:
Entry trigger: RSI of LOW (same RSI length) touching or below a lower band (default 15). Think of it as intraband reactivation from the bottom, using the candle’s deepest excursion.
Exit trigger: RSI of HIGH touching or above an upper band (default 85). Think of it as exhaustion at the top, using the candle’s highest excursion.
Realtime + Close Backup: fires intrabar on tick, but if the realtime event was missed, the close backup will note it at bar end.
Cooldown control: optional bars-between-signals to avoid rapid re-triggers on choppy sequences.
Why wick-aware RSI?
A close-only RSI can miss the true micro-extremes that cause reversals. Using LOW/HIGH for triggers captures the behavior that traders actually react to during the bar, while the bar-close backup preserves historical reproducibility.
Module 3 — Pyramid (Continuation / Compounding Layer)
Goal: Teach how continuation behaves once a trend is underway, and how adds can be structured.
Method:
Same dual-line logic as Rasta (EMA vs smoothed EMA), but only fires when already in a position (or after prior entry conditions).
Supports the same EMA 8/21 filter and optional adaptive-on-flip behavior.
Bar close only to maintain historical cohesion.
What it teaches:
Adds tend to cluster when momentum persists.
Students can experiment with add spacing and compare “one-shot entries” vs “laddered adds” during strong regimes.
How the Pieces Work Together
Rasta establishes the structural frame (when the wave flip is real enough to record at close).
RSI validates or challenges that structure by tracking intrabar energy at the extremes (low/high touches).
Pyramid shows what sustained continuation looks like once (1) and (2) align.
This produces a layered view: Structure → Energy → Progression. Users can see when all three line up (strongest phases) and when they diverge (riskier phases or transitions).
How to Use It (Step-by-Step)
Quick Start
Apply script to any symbol/timeframe.
In Strategy/Indicator Properties:
Enable On every tick (recommended).
If available, enable Using bar magnifier and choose a lower resolution (e.g., 1m) to simulate intrabar fills more realistically.
Keep On bar close unchecked if you want to observe realtime logic in live charts (strategies still place orders on close by platform design).
Default behavior: Rasta & Pyramid = bar close; RSI = per tick with close backup.
Reading the Chart
Watch for Rasta Entry/Exit labels: they define clean structural turns on close.
Watch RSI Entry (LOW touch at/below lower band) and RSI Exit (HIGH touch at/above upper band) to gauge internal energy extremes.
Pyramid Add labels reveal continuation phases once a move is already in progress.
Tuning
Rasta smoothing: choose SMA/EMA/RMA/WMA or None. Higher smoothing → later but cleaner flips; lower smoothing → earlier but choppier.
RSI bands: a common educational setting is 15/85 for strong extremes; 20/80 is a bit looser.
Cooldown: increase if you see too many RSI re-fires in chop.
EMA 8/21 filter: toggle ON to study “trend-gated” entries, OFF to study raw momentum flips.
Backtesting Notes (for Strategy Builds)
Stops (optional): trail is armed when price advances by a trigger (default D–F₀), ratchets only upward from HIGH, and hits from LOW (or Close if chosen) with a tiny undershoot buffer to avoid micro-wicks.
Order sequencing per bar (mirrors the script’s code comments):
Trail ratchet via HIGH
Intrabar stop hit via LOW/CLOSE → immediate close
If still in position at bar close: process exits (Rasta/RSI)
If still in position at bar close: process Pyramid Add
If flat at bar close: process entries (Rasta/RSI)
Platform reality: strategies place orders at bar close in historical testing; the intrabar logic improves realism for stops and event marking but final order timestamps are still close-resolved.
Inputs Reference (common)
Modules: enable/disable RSI and Pyramid learning layers.
Rasta: EMA length, smoothing type/length, EMA8/21 filter & adaptive flip, fog opacity, rungs on/off & limit.
RSI: RSI length, signal MA length (panel), Entry band (LOW), Exit band (HIGH), cooldown bars, labels.
Pyramid: EMA length, smoothing, EMA8/21 filter & adaptive adds.
Execution: toggle Bar Close Only for Rasta/Pyramid; toggle Realtime + Close Backup for RSI.
Stops (strategy): Fixed Stop % (first), Fixed Stop % (add), Trail Distance %, Trigger rule (auto D–F₀ or custom), undershoot buffer %, and hit source (LOW/CLOSE).
What to Study With It
Convergence: how often RSI-LOW entry touches precede the next Rasta flip.
Divergence: cases where RSI screams exhaustion (HIGH >= upper band) but Rasta hasn’t flipped yet—often transition zones.
Continuation: how Pyramid adds cluster in strong moves; how spacing changes with smoothing/filter choices.
Regime changes: use EMA8/21 filter toggles to see what happens at macro turns vs chop.
Limitations & Scope
This is a learning tool, not a trade copier. It does not provide financial advice or automated execution.
Intrabar results depend on data granularity; bar magnifier (when available) can help simulate lower-resolution ticks, but true tick-by-tick fills are a platform-level feature and not guaranteed across all symbols.
Suggested Publication Settings (Strategy)
Initial capital: 100
Order size: 100 USD (cash)
Pyramiding: 10
Commission: 0.25%
Slippage: 3 ticks
Recalculate: ✓ On every tick
Fill orders: ✓ Using bar magnifier (choose 1m or similar); leave On bar close unchecked for live viewing.
Educational License
Released under the Michael Culpepper Gratitude License (2025).
Use and modify freely for education and research with attribution. No resale. No promises of profitability. Purpose is understanding, not signals.
Fixed Dollar Risk LinesFixed Dollar Risk Lines is a utility indicator that converts a user-defined dollar risk into price distance and plots risk lines above and below the current price for popular futures contracts. It helps you place stops or entries at a consistent dollar risk per trade, regardless of the market’s tick value or tick size.
What it does:
-You choose a dollar amount to risk (e.g., $100) and a futures contract (ES, NQ, GC, YM, RTY, PL, SI, CL, BTC).
The script automatically:
-Looks up the contract’s tick value and tick size
-Converts your dollar risk into number of ticks
-Converts ticks into price distance
Plots:
-Long Risk line below current price
-Short Risk line above current price
-Optional labels show exact price levels and an information table summarizes your settings.
Key features
-Consistent dollar risk across instruments
-Supports major futures contracts with built‑in tick values and sizes
-Toggle Long and Short risk lines independently
-Customizable line width and colors (lines and labels)
-Right‑axis price level display for quick reading
-Compact info table with contract, risk, and computed prices
Typical use
-Long setups: use the green line as a stop level below entry to match your chosen dollar risk.
-Short setups: use the red line as a stop level above entry to match your chosen dollar risk.
-Quickly compare how the same dollar risk translates to distance on different contracts.
Inputs
-Risk Amount (USD)
-Futures Contract (ES, NQ, GC, YM, RTY, PL, SI, CL, BTC)
-Show Long/Short lines (toggles)
-Line Width
-Colors for lines and labels
Notes
-Designed for futures symbols that match the listed contracts’ tick specs. If your symbol has different tick value/size than the defaults, results will differ.
-Intended for educational/informational use; not financial advice.
-This tool streamlines risk placement so you can focus on execution while keeping dollar risk consistent across markets.
DayFlow VWAP Relay Forex Majors StrategySummary in one paragraph
DayFlow VWAP Relay is a day-trading strategy for major FX pairs on intraday timeframes, demonstrated on EURUSD 15 minutes. It waits for alignment between a daily anchored VWAP regime check, residual percentiles, and lower-timeframe micro flow before suggesting trades. The originality is the fusion of daily VWAP residual percentiles with a live micro-flow score from 1 minute data to switch between fade and breakout behavior inside the same session. Add it to a clean chart and use the markers and alerts.
Scope and intent
• Markets: Major FX pairs such as EURUSD, GBPUSD, USDJPY, AUDUSD, USDCHF, USDCAD
• Timeframes: One minute to one hour
• Default demo in this publication: EURUSD on 15 minutes
• Purpose: Reduce false starts by acting only when context, location and micro flow agree
• Limits: This is a strategy. Orders are simulated on standard candles only
Originality and usefulness
• Core novelty: Residual percentiles to daily anchored VWAP decide “balanced versus expanding day”. A separate 1 minute micro-flow score confirms direction, so the same model fades extremes in balance and rides range breaks in expansion
• Failure modes addressed: Chop fakeouts and unconfirmed breakouts are filtered by the expansion gate and micro-flow threshold
• Testability: Every input is exposed. Bands, background regime color, and markers show why a suggestion appears
• Portable yardstick: Stops and targets are ATR multiples converted to ticks, which transfer across symbols
• Open source status: No reused third-party code that requires attribution
Method overview in plain language
The day is anchored with a VWAP that updates from the daily session start. Price minus VWAP is the residual. Percentiles of that residual measured over a rolling window define location extremes for the current day. A regime score compares residual volatility to price volatility. When expansion is low, the day is treated as balanced and the model fades residual extremes if 1 minute micro flow points back to VWAP. When expansion is high, the model trades breakouts outside the VWAP bands if slope and micro flow agree with the move.
Base measures
• Range basis: True Range smoothed by ATR for stops and targets, length 14
• Return basis: Not required for signals; residuals are absolute price distance to VWAP
Components
• Daily Anchor VWAP Bands. VWAP with standard-deviation bands. Slope sign is used for trend confirmation on breakouts
• Residual Percentiles. Rolling percentiles of close minus VWAP over Signal length. Identify location extremes inside the day
• Expansion Ratio. Standard deviation of residuals divided by standard deviation of price over Signal length. Classifies balanced versus expanding day
• Micro Flow. Net up minus down closes from 1 minute data across a short span, normalized to −1..+1. Confirms direction and avoids fades against pressure
• Session Window optional. Restricts trading to your configured hours to avoid thin periods
• Cooldown optional. Bars to wait after a position closes to prevent immediate re-entry
Fusion rule
Gating rather than weighting. First choose regime by Expansion Ratio versus the Expansion gate. Inside each regime all listed conditions must be true: location test plus micro-flow threshold plus session window plus cooldown. Breakouts also require VWAP slope alignment.
Signal rule
• Long suggestion on balanced day: residual at or below the lower percentile and micro flow positive above the gate while inside session and cooldown is satisfied
• Short suggestion on balanced day: residual at or above the upper percentile and micro flow negative below the gate while inside session and cooldown is satisfied
• Long suggestion on expanding day: close above the upper VWAP band, VWAP slope positive, micro flow positive, session and cooldown satisfied
• Short suggestion on expanding day: close below the lower VWAP band, VWAP slope negative, micro flow negative, session and cooldown satisfied
• Positions flip on opposite suggestions or exit by brackets
What you will see on the chart
• Markers on suggestion bars: L for long, S for short
• Exit occurs on reverse signal or when a bracket order is filled
• Reference lines: daily anchored VWAP with upper and lower bands
• Optional background: teal for balanced day, orange for expanding day
Inputs with guidance
Setup
• Signal length. Residual and regime window. Typical 40 to 100. Higher smooths, lower reacts faster
Micro Flow
• Micro TF. Lower timeframe used for micro flow, default 1 minute
• Micro span bars. Count of lower-TF bars. Typical 5 to 20
• Micro flow gate 0..1. Minimum absolute flow. Raising it demands stronger confirmation and reduces trade count
VWAP Bands
• VWAP stdev multiplier. Band width. Typical 0.8 to 1.6. Wider bands reduce breakout frequency and increase fade distance
• Expansion gate 0..3. Threshold to switch from fades to breakouts. Raising it favors fades, lowering it favors breakouts
Sessions
• Use session filter. Enable to trade only inside your window
• Trade window UTC. Default 07:00 to 17:00
Risk
• ATR length. Stop and target basis. Typical 10 to 21
• Stop ATR x. Initial stop distance in ATR multiples
• Target ATR x. Profit target distance in ATR multiples
• Cooldown bars after close. Wait bars before a new entry
• Side. Both, long only, or short only
View
• Show VWAP and bands
• Color bars by residual regime
Properties visible in this publication
• Initial capital 10000
• Base currency Default
• request.security uses lookahead off everywhere
• Strategy: Percent of equity with value 3. Pyramiding 0. Commission cash per order 0.0001 USD. Slippage 3 ticks. Process orders on close ON. Bar magnifier ON. Recalculate after order is filled OFF. Calc on every tick OFF. Using standard OHLC fills ON.
Realism and responsible publication
No performance claims. Past results never guarantee future outcomes. Fills and slippage vary by venue. Shapes can move while a bar forms and settle on close. Strategies must run on standard candles for signals and orders.
Honest limitations and failure modes
High impact news, session opens, and thin liquidity can invalidate assumptions. Very quiet days can reduce contrast between residuals and price volatility. Session windows use the chart exchange time. If both stop and target are touched within a single bar, TradingView’s standard OHLC price-movement model decides the outcome.
Expect different behavior on illiquid pairs or during holidays. The model is sensitive to session definitions and feed time. Past results never guarantee future outcomes.
Legal
Education and research only. Not investment advice. You are responsible for your decisions. Test on historical data and in simulation before any live use. Use realistic costs.
