Trend Day IndentificationVolatility is cyclical, after a large move up or down the market typically "ranges" during the next session. Directional order flow that enters the market during this subsequent session tends not to persist, this non-persistency of transactions leads to a non-trend day which is when I trade intraday reversionary strategies.
This script finds trend days in BTC with the purpose of:
1) counting trend day frequency
2) predicting range contraction for the next 1-2 days so I can run intraday reversion strategies
Trend down is defined as daily bar opening within X% of high and closing within X% of low
Trend up is defined as daily bar opening within X% of low and closing within X% of high
default parameters are:
1) open range extreme = 15% (open is within 15% of high or low)
2) close range extreme = 15% (close is within 15% of high or low)
There is also an atr filter that checks that the trend day has a larger range than the previous 4 bars this is to make sure we find true range expansion vs recent ranges.
Notes:
If a trend day occurs after a prolonged sideways contraction it can signal a breakout - this is less common but is an exception to the rule. These types of occurrences can lead to the persistency of order flow and result in extended directional daily runs.
If a trend day occurs close to 20 days high or low (stopping just short OR pushing slightly through) then wait an additional day before trading intraday reversion strategies.
Cari dalam skrip untuk "新泻天鹅vs川崎前锋"
Bogdan Ciocoiu - CoordinatorDescription
The Coordinator is an indicator developed on the back of the RSI algorithm, modified substantially to form a cloud. In addition, the Coordinator uses EMA/SMA to compare the location of the RSI cloud with the chosen moving averages (EMA vs SMA).
This indicator is helpful as it confirms when a trader should enter a position or exit based on the proximity of the RSI cloud to the relevant MA.
Uniqueness
The Coordinator provides unique benefits, including:
It shows the strength of the RSI in the shape of the RSI cloud, using two sets of dimensions (one more long term and one more short-term oriented).
It indicates the positioning of the RSI cloud in conjunction with the relevant moving averages to help traders remain in positions for longer.
It shows the RSI 14 (useful when spotting divergences aligned with the price action).
Open-source
The Coordinator uses the following open-source scripts:
www.tradingview.com
Wick StrategyThis measure bull vs bear power by taking wicks length calculation. Wicks means price rejection. !
Lankou VS BTC all
/!\ To make it work well use -> pin at new right scale
This script displays the comparison with BTCUSDT
it permits to see if an asset is gaining value against BTC, and fastly scan USDT asset to determine if they are bullish
It works for ANY asset, as it's dividing it's price by the BTCUSDT one
BTC Price vs COP Spread Chart Wanted to create a spread chart using BTC and some cost of production estimates. In any commodity using COP is a great way to define "value" and typically there's about 100-150% markup for investors to keep in mind when using this metric in their analysis. Thanks to Grimm for the spread idea/request. #PMAFTW // Original cop code taken from;
MACRO BTC HEALTH 1WThis indicator is used as MACRO tool to view the outlook of BTC on the 1W time frame to illustrate (BLX chart works best)
BTC's price action and where it's at, it helps provide an indication of the crypto market's current health as BTC health is an overall indicator in the crypto market as a whole.
This indicator uses historic data to fit between 4 bands fitted to MA, top(red) when BTC is overheated, 2 bands in middle(yellow) when BTC in fair value, and bottom band(blue) when BTC is oversold
I combined MA that fit BTC 1W chart precisely to show when BTC looks overheated vs over sold using historic data.
When BTC is in the top bands historically overheated.
When BTC is in the middle it is fighting at fair value with the 2 yellow lines in the middle, bullish when above yellow lines, as they act as support, and in downtrend when price is below yellow lines and can act as resistance.
Historically the 200W MA is where BTC finds support at an oversold level at the bottom blue line.
When two yellow lines in middle cross downwards historically results in a downtrend to the bottom oversold line (blue). and when two yellow lines cross up and BTC holds them as support bullish trend continues until it is overheated passed the red band.
This indicator is not meant for day trading but is meant to illustrate a MACRO view of BTC current situation from a zoomed-out view, and to help illustrate to investors where things are at so they leave emotions out of the market and can make decisions based on BTC current levels using Historic data. Pro tip use bottom line(blue, oversold) as an opportunity to buy in and top line red(overheated) to scale out of positions, LONG TERM CRYPTO IS BULLISH BUT GREAT TO GET AN OUTLOOK OF THE CURRENT STATE OF BTC, WHILE ALSO USING MACRO ECONOMIC SENTIMENT IRL, FUNDAMENTAL ECONOMIC DECISIONS, ECONOMIC CONDITIONS/ENVIRONMENT, ECONOMIC HEALTH ,FED DECISIONS, INTEREST RATE ENVIRONMENT AND OF COURSE LOOKING AT CRYPTO ADOPTION.
Hope this indicator helps leave emotions out of the market by providing a good guide of BTC sentiment, and its current health to make decisions accordingly. NFA but good to envision the MACRO BTC HEALTH at the 1W timeframe.
High Low Index SPY Top 40Modification from original code for "High Low Index" by © LonesomeTheBlue
- Made modification specifically for Top 40 AMEX:SPY holdings
- Added Market sentiment histogram (Total count green vs red), and SMA line for it
- Added arrows for peaks and dips on High Low Index and Market Sentiment MA
Idea behind this indicator is that SPY should follow the overall sentiment of its top holdings. I believe this bring great value to SPY traders.
Enjoy~!
BankNifty - OBVThis script tries to draw OBV for BankNifty using Futures Volume along with Average OBV. For Nifty50 just change the Futures Volume symbol in settings. Look at devations in Price vs OBV or Average OBV breakout.
NSE:NIFTY
NSE:BANKNIFTY
HighTimeframeTimingLibrary "HighTimeframeTiming"
@description Library for sampling high timeframe (HTF) historical data at an arbitrary number of HTF bars back, using a single security() call.
The data is fixed and does not alter over the course of the HTF bar. It also behaves consistently on historical and elapsed realtime bars.
‼ LIMITATIONS: This library function depends on there being a consistent number of chart timeframe bars within the HTF bar. This is almost always true in 24/7 markets like crypto.
This might not be true if the chart doesn't produce an update when expected, for example because the asset is thinly traded and there is no volume or price update from the feed at that time.
To mitigate this risk, use this function on liquid assets and at chart timeframes high enough to reliably produce updates at least once per bar period.
The consistent ratio of bars might also break down in markets with irregular sessions and hours. I'm not sure if or how one could mitigate this.
Another limitation is that because we're accessing a multiplied number of chart bars, you will run out of chart bars faster than you would HTF bars. This is only a problem if you use a large historical operator.
If you call a function from this library, you should probably reproduce these limitations in your script description.
However, all of this doesn't mean that this function might not still be the best available solution, depending what your needs are.
If a single chart bar is skipped, for example, the calculation will be off by 1 until the next HTF bar opens. This is certainly inconsistent, but potentially still usable.
@function f_offset_synch(float _HTF_X, int _HTF_H, int _openChartBarsIn, bool _updateEarly)
Returns the number of chart bars that you need to go back in order to get a stable HTF value from a given number of HTF bars ago.
@param float _HTF_X is the timeframe multiplier, i.e. how much bigger the selected timeframe is than the chart timeframe. The script shows a way to calculate this using another of my libraries without using up a security() call.
@param int _HTF_H is the historical operator on the HTF, i.e. how many bars back you want to go on the higher timeframe. If omitted, defaults to zero.
@param int _openChartBarsIn is how many chart bars have been opened within the current HTF bar. An example of calculating this is given below.
@param bool _updateEarly defines whether you want to update the value at the closing calculation of the last chart bar in the HTF bar or at the open of the first one.
@returns an integer that you can use as a historical operator to retrieve the value for the appropriate HTF bar.
🙏 Credits: This library is an attempt at a solution of the problems in using HTF data that were laid out by Pinecoders in "security() revisited" -
Thanks are due to the authors of that work for an understanding of HTF issues. In addition, the current script also includes some of its code.
Specifically, this script reuses the main function recommended in "security() revisited", for the purposes of comparison. And it extends that function to access historical data, again just for comparison.
All the rest of the code, and in particular all of the code in the exported function, is my own.
Special thanks to LucF for pointing out the limitations of my approach.
~~~~~~~~~~~~~~~~|
EXPLANATION
~~~~~~~~~~~~~~~~|
Problems with live HTF data: Many problems with using live HTF data from security() have been clearly explained by Pinecoders in "security() revisited"
In short, its behaviour is inconsistent between historical and elapsed realtime bars, and it changes in realtime, which can cause calculations and alerts to misbehave.
Various unsatisfactory solutions are discussed in "security() revisited", and understanding that script is a prerequisite to understanding this library.
PineCoders give their own solution, which is to fix the data by essentially using the previous HTF bar's data. Importantly, that solution is consistent between historical and realtime bars.
This library is an attempt to provide an alternative to that solution.
Problems with historical HTF data: In addition to the problems with live HTF data, there are different issues when trying to access historical HTF data.
Why use historical HTF data? Maybe you want to do custom calculations that involve previous HTF bars. Or to use HTF data in a function that has mutable variables and so can't be done in a security() call.
Most obviously, using the historical operator (in this description, represented using { } because the square brackets don't render) on variables already retrieved from a security() call, e.g. HTF_Close{1}, is not very useful:
it retrieves the value from the previous *chart* bar, not the previous HTF bar.
Using {1} directly in the security() call instead does get data from the previous HTF bar, but it behaves inconsistently, as we shall see.
This library addresses these concerns as well.
Housekeeping: To follow what's going on with the example and comparisons, turn line labels on: Settings > Scales > Indicator Name Label.
The following explanation assumes "close" as the source, but you can change it if you want.
To quickly see the difference between historical and realtime bars, set the HTF to something like 3 minutes on a 15s chart.
The bars at the top of the screen show the status. Historical bars are grey, elapsed realtime bars are red, and the realtime bar is green. A white vertical line shows the open of a HTF bar.
A: This library function f_offset_synch(): When supplied with an input offset of 0, it plots a stable value of the close of the *previous* HTF bar. This value is thus safe to use for calculations and alerts.
For a historical operator of {1}, it gives the close of the *last-but-one* bar. Sounds simple enough. Let's look at the other options to see its advantages.
B: Live HTF data: Represented on the line label as "security(){0}". Note: this is the source that f_offset_synch() samples.
The raw HTF data is very different on historical and realtime bars:
+ On historical bars, it uses a flat value from the end of the previous HTF bar. It updates at the close of the HTF bar.
+ On realtime bars, it varies between and within each chart bar.
There might be occasions where you want to use live data, in full knowledge of its drawbacks described above. For example, to show simple live conditions that are reversible after a chart bar close.
This library transforms live data to get the fixed data, thus giving you access to both live and fixed data with only one security() call.
C: Historical data using security(){H}: To see how this behaves, set the {H} value in the settings to 1 and show options A, B, and C.
+ On historical bars, this option matches option A, this library function, exactly. It behaves just like security(){0} but one HTF bar behind, as you would expect.
+ On realtime bars, this option takes the value of security(){0} at the end of a HTF bar, but it takes it from the previous *chart* bar, and then persists that.
The easiest way to see this inconsistency is on the first realtime bar (marked red at the top of the screen). This option suddenly jumps, even if it's in the middle of a HTF bar.
Contrast this with option A, which is always constant, until it updates, once per HTF bar.
D: PineCoders' original function: To see how this behaves, show options A, B, and D. Set the {H} value in the settings to 0, then 1.
The PineCoders' original function (D) and extended function (E) do not have the same limitations as this library, described in the Limitations section.
This option has all of the same advantages that this library function, option A, does, with the following differences:
+ It cannot access historical data. The {H} setting makes no difference.
+ It always updates at the open of the first chart bar in a new HTF bar.
By contrast, this library function, option A, is configured by default to update at the close of the last chart bar in a HTF bar.
This little frontrunning is only a few seconds but could be significant in trading. E.g. on a 1D HTF with a 4H chart, an alert that involves a HTF change set to trigger ON CLOSE would trigger 4 hours later using this method -
but use exactly the same value. It depends on the market and timeframe as to whether you could actually trade this. E.g. at the very end of a tradfi day your order won't get executed.
This behaviour mimics how security() itself updates, as is easy to see on the chart. If you don't want it, just set in_updateEarly to false. Then it matches option D exactly.
E: PineCoders' function, extended to get history: To see how this behaves, show options A and E. Set the {H} value in the settings to 0, then 1.
I modified the original function to be able to get historical values. In all other respects it is the same.
Apart from not having the option to update earlier, the only disadvantage of this method vs this library function is that it requires one security() call for each historical operator.
For example, if you wanted live data, and fixed data, and fixed data one bar back, you would need 3 security() calls. My library function requires just one.
This is the essential tradeoff: extra complexity and less robustness in certain circumstances (the PineCoders function is simple and universal by comparison) for more flexibility with fewer security() calls.
StableCoin MC vs Total MC by Crypto5Max In this indicator you will find the sum of all stable coins (market cap) divided by the total crypto market cap.
I believe there's a positive correlation between stable coins issuance and BTC's(and other coins) price appreciation. Or shortly put, to me the rising levels of stable coins represent increased levels of buying power (and adoption) waiting on the sidelines.
Here, I am taking the total market cap of all stable coins and dividing it by the total crypto market cap to get a ratio. Note, only ~85% of all stable coins are calculated (rest are not on TV), however, it should still be a fairly good representation. Some of the stable coins are already locked in smart contracts for yield farming and what not. I'd also say, there's interesting 2-year long channel that's developing currently. That said, take this indicator with a grain of salt as we still have a limited set of data.
Yours truly
ETH vs BTC 200W SMA OverextensionHistorically, when BTC suffers a correction and ETH continues to rally, this hints at an impending market-wide correction. In Jan 2018, ETH rallies while BTC corrects, signalling the end of the bull cycle. In May 2021, ETH rallies while BTC ranges between $50-$60k, then a major correction occurs. This indicator attempts to monitor this phenomenon in order to help spot potential macro tops in the cryptocurrency market.
The indicator takes the price of the asset and divides it by the 200 week SMA value. This gives an over/undervaluation in percentage terms. When ETH becomes significantly more overvalued relative to BTC, the indicator will warn of a potential top forming (see red shaded areas).
This is for edutainment purposes only. Don't make financial decisions based on this indicator.
RSI v4 with Bands
Script is extended version of usual RSI script
This script plots VWMA(RSI7) vs EMA(RSI7) under pre-set time frame.
Strategy is to make sure both points remain in the Green zone while entering into BUY position
Use it as indicator not as financial advice.
~ @imbharat
ADX and DI+ v4.5 OptimizedThis script plots VWMA(ADX) vs EMA(DI+) under pre-set time frame.
Feature:
The Main Strategy is to look for potential BUY opportunity (Intraday trading, Session trading, Swing) when EMA(DI+) colored blue, entering upward into Green zone where ADX counterpart (default colored: Yellow) is also present.
Formula plot is also helpful to understand upcoming downtrend signal when both blue and yellow lines try to make diverted bifurcation like pattern on graph.
Disclaimer - This is an indicator script and not final Buy and Sell advice.
* Originally developed by © BeikabuOyaji and further extended & optimized by Bharat @imbharat to serve above features
BTCUSD vs S&P500 (Daily)This script plots an RSI of the difference between the BTCUSD (FTX) and S&P 500 (FRED) prices, useful to see how the BTCUSD price correlates to the stock market.
This works in the daily timeframe only (because the S&P 500 can only be sampled on this timeframe). You can try lower timeframes but they will be gapped / interpolated.
Secondary Chart with OverSized CandlesHi everyone, I'm sharing a simple script I made for a friend. He was looking for a way to add another asset to his chart, and monitor relevant movements \ spot eventual correlation, especially when trading Cryptocurrencies.
We couldn't find a similar script already available so here it is - the code is commented and I hope it's clear enough :)
Notes:
- The parameter scale = scale.left keeps the scales separated and therefore the chart is more organized, otherwise the chart would appear flat if the price difference is too big (e.g. BTC vs XRP)
- It is possible to have the script running in a separate panel (instead of overlay) by moving it to a new pane (when added to the chart) or by removing the parameter overlay = true at the beginning of the code.
- In case you wish to add indicators to this sub-chart (e.g. Bollinger Bands, EMA, etc..) you can do that by adding the relevant code and feed it with the variables OPEN \ HIGH \ LOW \ CLOSE as well as using the same method to retrieve new variables from the target asset with the request.security function.
Hope this comes handy.
Val - Protervus
Spread CRYPTO USDT VS PERPSimple spread script.
Calculate the difference between USDT and USDTPERP for major exchanges.
For use only with USDT charts
Works with all crypto if a future contract exists.
Upcoming updates
BUY/SELL SIGNALS from LSMA/ALMA/HMAThis indicator uses the Least Squares Moving Average (LSMA) in tandem with the Arnaud Legoux Moving Average (ALMA) and Hull Moving Average (HMA) to generate buy-sell signals, represented by the light blue and orange crosses respectively.
The yellow lines produced by the indicator show periods of market uncertainty and possible reversal, and a modified, user-defined VWAP is given along with a 200 EMA. The point of this indicator was to create a smoother, more visually appealing moving-average, price action-based indicator when compared to the trend-step and simple moving average indicators available. This indicator uses a fast (25 period) LSMA coupled with a slower (50 period) HMA and ALMA in order to make signals both smooth and fast.
This indicator will work on all markets, except the modified VWAP will naturally not function if the volume is unpublished for that market. Use of this indicator will be very strong in trending markets, as the yellow line will spot possible reversals quite early, meaning the trader can be ready early for the buy/sell signal to appear. Use of this indicator in sideways market conditions will be limited, as it is for all moving average-based indicators, but the damage will be minimal as bad trades will be quickly realized by the indicator and the color will switch to yellow, this is possible because of the settings differences between the period lengths of the LSMA vs the ALMA + HMA.
BarRange vs VolumeThis is a volume spread analysis/ breadth type indicator.
Compares average bar size to the average volume. Looks for small bar and high volume.
Percentage Levels by TimeframePlots the positive and negative percentage levels from a selection of timeframes and sources for any ticker. You can use this within a pullback trading system. For example, if you historically look at the average pullback of large cap stocks and ETF's, you can use this indicator to plot the levels it could pullback to for an entry to go long. It can be used as potential targets when trading a ticker short. Another use for this is to backtest the set percentage targets using TradingView's bar replay feature to see how ETF's and large cap stocks have reacted at these levels. Note: This is intended to be used at timeframes equal to higher than the chart's as it may cause re-painting issues.
Currently percentage levels are statically set to 1, 3, 5, 10, 15, 20, 25, and 30% levels above and below the chosen source (open, high, low, close). You can also display the data based on timeframes from Daily (1D) all the way up to Yearly (12M)
*Not financial advice but in my opinion the current percentage levels set (see above) are best used for ETF's and Large Cap Stocks.
Jan 2
Release Notes: Added the ability to select the historical bars to look back when plotting levels
Jan 2
Release Notes: To get a better display or proper resolution on your charts, change the view settings to "Scale Price Chart Only"
Jan 2
Release Notes: To add % labels for this indicator on the price axis, change your chart settings to include "Indicator Name Label" & "Indicator Last Value". You can find this under the Label section after hitting the gear icon in the bottom right of your chart.
Jan 2
Release Notes: Added: Custom Line Plot Extension Settings. Ideally both values should be equal to display optimal extended lines. To return to a base setting: '1' = Historical Lookback & '0' = Offset Lines. Also note this is dependent on the timeframe you are viewing on the chart.
Jan 2
Release Notes: Removed indicator from example chart that was not needed.
Jan 2
Release Notes: Updated some comments in the Pine Script
Jan 2
Release Notes: Update: Added commentary and instructions in the indicator settings to address recommended line plot settings for Stocks/ETF's vs Futures
Jan 2
Release Notes: Changed title from "Calculation Method" to "Calculation Source"
Jan 4 2021
Normal use of security() dictates that it only be used at timeframes equal to or higher than the chart's as it may cause re-painting
200DMA last DOM - ajhImplements and backtests a simple 200 day moving average trend following rules based on last day of month to limits trades to 12 per year.
From the book : 5 BEST Moving Average Strategies (That beat buy and hold) by Steve Burns and Holly Burns
Click on the cog to set the input date range eg; 2000-01-01 to 2016-12-31
The book back tested SP500 returns from 2000-2016 317% using this method vs 125% buy and hold only with less drawdown.
Simple 200 day moving average test and trading on last day of month.
(you may find it trades on next available day close to end of month as not all dates can be traded weekends etc..)
Rules are ;
1. if last day of month and stock over 200 day moving average, then go long 100%
2. if last day of month and stock under 200 day moving average, then close long 100% and goto cash.
Aims to miss market declines and keep you long for upside.
Note: Have found doesn't work well in choppy markets moving sideways like the FTSE100 for same period 2000-2016 and causes losses. Also for many stocks.
Abz Bonds/BTC divergenceDraft release: This indicator shows the comparative returns from US bonds vs BTC.
I was inspired by this Twitter thread: twitter.com
If you compare the price action of Bitcoin against bond returns over the last year, there's an extraordinary degree of correlation. This may give insights into what's coming next for BTC , but at some point the relationship will inevitably break down. In the meantime, there's much to gain.
DYOR.
Feedback welcome though it may take a while for me to respond.
[mdeacey] EMA% Channel + BB Range StrategyThis strategy is based off the users selection of an EMA and percentage defined channel. The strategy longs when a red "reversal candle" (that exceeds the averages of 3 and 9 above the EMA 3) is found until such time that either the price goes outside the Bollinger Band or the green reversal candle is found. The same but opposite process for shorts. If the price begins trending and moves outside the channel all trades are exited to prevent loss.
For trending markets the sister strategy (" EMA% Channel + Bollinger Band Trending Strategy") should instead be used.
The obvious fallback to this strategy is that:
- If the bands are too wide we don't have a good definition of trending vs ranging and the price can move up/down significantly and trend whilst remaining within the ranging channel. We try to mitigate this through use of a stoploss defined by ATR and a pretty tight channel. This is a tightrope exercise as making the percentage channels tighter misses earlier entries in optimal cases. Change the parameters to find an EMA and percentages to find the best R/R in your case.
Potential further iteration:
- It would be good to see if the R/R changes positively if we only allow shorts above the EMA and longs below it.
All options are configurable and code open source. Happy trading!
