741 GME vs AMCA very simple script to compare 7 shares of $AMC versus 1 share of $GME.
The script uses the closing price of the given securities.
Tìm kiếm tập lệnh với "墨尔本城vs西部联"
Bjorgum Double Tap█ OVERVIEW
Double Tap is a pattern recognition script aimed at detecting Double Tops and Double Bottoms. Double Tap can be applied to the broker emulator to observe historical results, run as a trading bot for live trade alerts in real time with entry signals, take profit, and stop orders, or to simply detect patterns.
█ CONCEPTS
How Is A Pattern Defined?
Doubles are technical formations that are both reversal patterns and breakout patterns. These formations typically have a distinctive “M” or a “W” shape with price action breaking beyond the neckline formed by the center of the pattern. They can be recognized when a pivot fails to break when tested for a second time and the retracement that follows breaks beyond the key level opposite. This can trap entrants that were playing in the direction of the prior trend. Entries are made on the breakout with a target projected beyond the neckline equal to the height of the pattern.
Pattern Recognition
Patterns are recognized through the use of zig-zag; a method of filtering price action by connecting swing highs and lows in an alternating fashion to establish trend, support and resistance, or derive shapes from price action. The script looks for the highest or lowest point in a given number of bars and updates a list with the values as they form. If the levels are exceeded, the values are updated. If the direction changes and a new significant point is made, a new point is added to the list and the process starts again. Meanwhile, we scan the list of values looking for the distinctive shape to form as previously described.
█ STRATEGY RESULTS
Back Testing
Historical back testing is the most common method to test a strategy due in part to the general ease of gathering quick results. The underlying theory is that any strategy that worked well in the past is likely to work well in the future, and conversely, any strategy that performed poorly in the past is likely to perform poorly in the future. It is easy to poke holes in this theory, however, as for one to accept it as gospel, one would have to assume that future results will match what has come to pass. The randomness of markets may see to it otherwise, so it is important to scrutinize results. Some commonly used methods are to compare to other markets or benchmarks, perform statistical analysis on the results over many iterations and on differing datasets, walk-forward testing, out-of-sample analysis, or a variety of other techniques. There are many ways to interpret the results, so it is important to do research and gain knowledge in the field prior to taking meaningful conclusions from them.
👉 In short, it would be naive to place trust in one good backtest and expect positive results to continue. For this reason, results have been omitted from this publication.
Repainting
Repainting is simply the difference in behaviour of a strategy in real time vs the results calculated on the historical dataset. The strategy, by default, will wait for confirmed signals and is thus designed to not repaint. Waiting for bar close for entires aligns results in the real time data feed to those calculated on historical bars, which contain far less data. By doing this we align the behaviour of the strategy on the 2 data types, which brings significance to the calculated results. To override this behaviour and introduce repainting one can select "Recalculate on every tick" from the properties tab. It is important to note that by doing this alerts may not align with results seen in the strategy tester when the chart is reloaded, and thus to do so is to forgo backtesting and restricts a strategy to forward testing only.
👉 It is possible to use this script as an indicator as opposed to a full strategy by disabling "Use Strategy" in the "Inputs" tab. Basic alerts for detection will be sent when patterns are detected as opposed to complex order syntax. For alerts mid-bar enable "Recalculate on every tick" , and for confirmed signals ensure it is disabled.
█ EXIT ORDERS
Limit and Stop Orders
By default, the strategy will place a stop loss at the invalidation point of the pattern. This point is beyond the pattern high in the case of Double Tops, or beneath the pattern low in the case of Double Bottoms. The target or take profit point is an equal-legs measurement, or 100% of the pattern height in the direction of the pattern bias. Both the stop and the limit level can be adjusted from the user menu as a percentage of the pattern height.
Trailing Stops
Optional from the menu is the implementation of an ATR based trailing stop. The trailing stop is designed to begin when the target projection is reached. From there, the script looks back a user-defined number of bars for the highest or lowest point +/- the ATR value. For tighter stops the user can look back a lesser number of bars, or decrease the ATR multiple. When using either Alertatron or Trading Connector, each change in the trail value will trigger an alert to update the stop order on the exchange to reflect the new trail price. This reduces latency and slippage that can occur when relying on alerts only as real exchange orders fill faster and remain in place in the event of a disruption in communication between your strategy and the exchange, which ensures a higher level of safety.
👉 It is important to note that in the case the trailing stop is enabled, limit orders are excluded from the exit criteria. Rather, the point in time that the limit value is exceeded is the point that the trail begins. As such, this method will exit by stop loss only.
█ ALERTS
Five Built-in 3rd Party Destinations
The following are five options for delivering alerts from Double Tap to live trade execution via third party API solutions or chat bots to share your trades on social media. These destinations can be selected from the input menu and alert syntax will automatically configure in alerts appropriately to manage trades.
Custom JSON
JSON, or JavaScript Object Notation, is a readable format for structuring data. It is used primarily to transmit data between a server and a web application. In regards to this script, this may be a custom intermediary web application designed to catch alerts and interface with an exchange API. The JSON message is a trade map for an application to read equipped with where its been, where its going, targets, stops, quantity; a full diagnostic of the current state and its previous state. A web application could be configured to follow the messages sent in this format and conduct trades in sync with alerts running on the TV server.
Below is an example of a rendered JSON alert:
{
"passphrase": "1234",
"time": "2022-05-01T17:50:05Z",
"ticker": "ETHUSDTPERP",
"plot": {
"stop_price": 2600.15,
"limit_price": 3100.45
},
"strategy": {
"position_size": 0.1,
"order_action": "buy",
"market_position": "long",
"market_position_size": 0,
"prev_market_position": "flat",
"prev_market_position_size": 0
}
}
Trading Connector
Trading Connector is a third party fully autonomous Chrome extension designed to catch alert webhooks from TradingView and interface with MT4/MT5 to execute live trades from your machine. Alerts to Trading Connector are simple; just select the destination from the input drop down menu, set your ticker in the "TC Ticker" box in the "Alert Strings" section and enter your URL in the alert window when configuring your alert.
Alertatron
Alertatron is an automated algo platform for cryptocurrency trading that is designed to automate your trading strategies. Although the platform is currently restricted to crypto, it offers a versatile interface with high flexibility syntax for complex market orders and conditions. To direct alerts to Alertatron, select the platform from the 3rd party drop down, configure your API key in the ”Alertatron Key” box and add your URL in the alert message box when making alerts.
3 Commas
3 Commas is an easy and quick to use click-and-go third party crypto API solution. Alerts are simple without overly complex syntax. Messages are simply pasted into alerts and executed as alerts are triggered. There are 4 boxes at the bottom of the "Inputs" tab where the appropriate messages to be placed. These messages can be copied from 3 Commas after the bots are set up and pasted directly into the settings menu. Remember to select 3 Commas as a destination from the third party drop down and place the appropriate URL in the alert message window.
Discord
Some may wish to share their trades with their friends in a Discord chat via webhook chat bot. Messages are configured to notify of the pattern type with targets and stop values. A bot can be configured through the integration menu in a Discord chat to which you have appropriate access. Select Discord from the 3rd party drop down menu and place your chat bot URL in the alert message window when configuring alerts.
👉 For further information regarding alert setup, refer to the platform specific instructions given by the chosen third party provider.
█ IMPORTANT NOTES
Setting Alerts
For alert messages to be properly delivered on order fills it is necessary to place the following placeholder in the alert message box when creating an alert.
{{strategy.order.alert_message}}
This placeholder will auto-populate the alert message with the appropriate syntax that is designated for the 3rd party selected in the user menu.
Order Sizing and Commissions
The values that are sent in alert messages are populated from live metrics calculated by the strategy. This means that the actual values in the "Properties" tab are used and must be set by the user. The initial capital, order size, commission, etc. are all used in the calculations, so it is important to set these prior to executing live trades. Be sure to set the commission to the values used by the exchange as well.
👉 It is important to understand that the calculations on the account size take place from the beginning of the price history of the strategy. This means that if historical results have inflated or depleted the account size from the beginning of trade history until now, the values sent in alerts will reflect the calculated size based on the inputs in the "Properties" tab. To start fresh, the user must set the date in the "Inputs" tab to the current date as to remove trades from the trade history. Failure to follow this instruction can result in an unexpected order size being sent in the alert.
█ FOR PINECODERS
• With the recent introduction of matrices in Pine, the script utilizes a matrix to track pivot points with the bars they occurred on, while tracking if that pivot has been traded against to prevent duplicate detections after a trade is exited.
• Alert messages are populated with placeholders ; capability that previously was only possible in alertcondition() , but has recently been extended to `strategy.*()` functions for use in the `alert_message` argument. This allows delivery of live trade values to populate in strategy alert messages.
• New arguments have been added to strategy.exit() , which allow differentiated messages to be sent based on whether the exit occurred at the stop or the limit. The new arguments used in this script are `alert_profit` and `alert_loss` to send messages to Discord
RSI vs BITFINEX BTC Longs/Shorts Margin Ratio Percentage RankThis indicator plots the RSI of the current token with a color based on percentage rank of the RSI of BITFINEX:BTCUSDLONGS divided by BITFINEX:BTCUSDSHORTS, with a plot of the moving average of the RSI. It can optionally plot the RSI in white and the ratio RSI in color, or the ratio as background color. It can also plot the raw ratio rather than the percentage rank if selected.
I was interested in the ratio of BITFINEX:BTCUSDLONGS to BITFINEX:BTCUSDSHORTS as a measure of market sentiment and how that sentiment would magnify RSI changes. The volatility of the BTCUSDLONGS : BTCUSDSHORTS ratio was too low to get a good read, using a percent rank of the RSI of the ratio made the results more visible.
This indicator should be used on a BTC chart.
Number of New Highs - Number of New Lows in US MarketShow numbers of new highs vs numbers of new lows for Nasdaq, NYSE and AMEA
Polarity Divergences█ OVERVIEW
This indicator looks at the polarity of the intrabars composing a chart bar and fills chart candles orange when a majority of intrabars does not have the same polarity as that of the chart bar.
█ CONCEPTS
Bar polarity
By bar polarity , we mean the direction of a bar, which is determined by looking at the bar's close vs its open .
Intrabars
Intrabars are chart bars at a lower timeframe than the chart's. Each 1H chart bar of a 24x7 market will, for example, usually contain 60 bars at the lower timeframe of 1min, provided there was market activity during each minute of the hour. Mining information from intrabars can be useful in that it offers traders visibility on the activity inside a chart bar.
Lower timeframes (LTFs)
A lower timeframe is a timeframe that is smaller than the chart's timeframe. This script determines which LTF to use by examining the chart's timeframe. The LTF determines how many intrabars are examined for each chart bar; the lower the timeframe, the more intrabars are analyzed. This table shows which LTF is used for each range of chart timeframes:
Chart TF LTF
< 1D 1min
< 1W 30min
>= 1W 1D
█ HOW TO USE IT
The idea underlying this indicator is that if the polarity of a chart bar is up or down, the majority of its constituent intrabars should also be up or down. If that is not the case, then we can consider the bar to be abnormal, and so worthy of our attention. You will notice that such anomalies often occur before reversals, but irregularities do not necessarily announce reversals, as they also occur on pauses in trends or in trend-less conditions.
The indicator will update in real time, as intrabars composing the realtime chart bar are gradually built. The closer the realtime bar is to being closed, the more reliable the result will be, as that is when the indicator can analyze the most intrabars.
█ NOTES FOR Pine Script™ CODERS
This script uses the recently released request.security_lower_tf() Pine Script™ function discussed in this blog post . It works differently from the usual request.security() in that it can only be used at LTFs, and it returns an array containing one value per intrabar. This makes it much easier for programmers to access intrabar information.
A script can access a maximum of 100K intrabars; that is the reason we step the LTF by taking into account the chart's timeframe. By progressively increasing the LTF as the chart's timeframe increases, we provide users with optimal coverage of the chart bars. Always using a 1min LTF would, for example, limit the chart coverage to the last 69 bars on a 1D chart of a 24x7 market because each chart bar will usually contain 1440 intrabars (100K / 1440 = 69.4). By using a 30min LTF for 1D charts, we cover 100K / 48 = 2083 bars.
Look first. Then leap.
Volume Impulse & Candlestick Patterns - FontiramisuIndicator showing volume impulse & engulfing candlestick pattern.
You can set up multiple parameter for both events.
Volume Impulse :
Volume Period : Lenght of the average volume calculated.
Volume Multiplier : Factor to compare actual volume with average volume.
Engulfing Pattern :
VS avg body : Let you chose to compare body candle to average body of the last few candles (define with parameter : lenghtSizeAvgBody ), otherwise it will be compared to the last body candle.
Engulfing Multiplier : Factor to compare and validate the pattern.
EHMA Range StrategyThis script is a modified version of @borserman's script for the Exponential Hull Moving Average
All credit for the EHMA goes to him :)
In addition to the EHMA, this script works with a range around the EHMA (which can be modified), in an attempt to be robust against fake signals. Many times a bar will close below a moving average, only to reverse again the next bar, which eats away at your profits. Especially on shorter timeframes, but also on choppy longer timeframes this can make a strategy unattractive to use.
With the range around the EHMA, the strategy only enters a long/exit-short position if a bar crosses above the upper range. Vice versa, it only enters a short/exit-long position if a bar crosses below the lower range. This avoids positions if bars behave choppy within the EHMA range & only enters a position if the market is confident in it's direction. Having said that, fakeouts are still possible, but a lot less frequent. Having backtested this strategy vs the regular EHMA strategy (and having experimented with various settings), this version seems to be a lot more robust & profitable!
Disclaimer
Please remember that past performance may not be indicative of future results.
Due to various factors, including changing market conditions, the strategy may no longer perform as good as in historical backtesting.
This post and the script don’t provide any financial advice.
Ranged Volume DCA Strategy - R3c0nTraderUpdate: Republishing this as Public Open-Source script.
Credits:
Thank you "EvoCrypto" for granting me permission to use "Ranged Volume" to create this strategy.
Thank you "junyou0424" for granting me permission to use "DCA Bot with SuperTrend Emulator" which I used for adding bot inputs, calculations, and strategy
What does this do?
This script is mainly used for backtesting a Ranged Volume strategy to see how a 3Commas bot would perform.
I created this script out of necessity and I wanted a way to test a 3Commas DCA bot with a strategy based on “Volume.”
I came across "EvoCrypto’s" "Ranged Volume" study and strategy in TradingView and I liked it. I wanted to configure it so it can be used for DCA bot backtesting. I used parts from "junyou0424’s" "DCA Bot with SuperTrend Emulator" to add the following:
1. The Start Time and End Time
2. Price deviation to open safety orders (%)
3. Target Take Profit (%)
4. Trailing deviation
5. Base Order and Safety Order
6. Safety order volume scale
7. Safety order step scale
8. Max safety orders
In addition to the above, I also added chart indicators for "Take Profit" as well as "Safety Order"
Pre-requisites:
You can use this script without a 3Commas account and see how 3Commas DCA Bot and Ranged Volume strategy would perform vs. a non-DCA strategy. However, I highly recommend signing up for their free account and going through their training. This would give you a base understanding on the settings you will see in this strategy and why you will need to know them.
That said these are the pre-requisites I suggest you have:
1. Base Knowledge of 3Commas DCA bots
2. Base knowledge of settings such as “Max safety trades count”, “safety order volume scale” and “safety order step scale”. If these are alien to you, I suggest you read up on these.
3. Knowledge of setting up a Single-pair 3Commas bot for receiving custom TradingView signal.
4. A paper-bot to test your ideas. (Do not use a real money bot until you have tested it sufficiently with a paper-bot. You alone are responsible for your results!)
5. Add the study I created called "R3c0nTrader’s Ranged Volume Study” which adds a separate chart in its own pane showing the volume spikes. It will also generate the “buy” signals for your bot. NOTE: The study also has the same color scheme as this strategy and having the colors in both the strategy and the study will make things easier to see. If you use EvoCrypto’s Ranged Volume Study instead, just keep in mind that the colors won’t match, and you will have to manually match them.
6. Make your buy signals from your strategy are the same as in your study! To do this, use the same “Volume Range Length” you entered in the STRATEGY and enter that value for the “Volume Range Length” in the STUDY. Also ensure you have the same settings for “Heikin Ashi” (On or Off).
Comparisons of Ranged Volume Strategy vs Ranged Volume DCA Strategy
BTCUSD
Beware of Strategies that claim super high profits. This can easily be done by lowering the initial capital to something unrealistic. If I did that with this strategy and set the initial capital $100 and base order size to $100, I get a net profit of 2,864% which is not realistic.
How to Use
1. On the “Inputs” tab:
a. Set your Start and End Time to backtest against.
b. Set your “Volume Range Length” (number of bars to look back)
c. “Heikin Ashi Colors” – Usually I leave this enabled
d. “Show Bar Colors” – Leave enabled
e. “Show Break-Out” – Leave enabled
f. “Show Range” – Leave enabled
g. Set your other inputs which are those settings you would find in your 3Commas bot that you want to test (e.g., Price deviation to open safety orders, Target Take Profit, Base order, Safety order, etc.).
h. Quick Example for BTCUSD on 2hr chart:
i. Price deviation to open safety orders (%) = 6
ii. Target Take Profit (%) = 14
iii. Trailing deviation = 0
iv. Base order = 100
v. Safety order = 200
vi. Safety order volume scale = 2
vii. Safety order step scale = 1.4
viii. Max safety order = 5
2. On the “Properties” tab, set your initial capital, base currency, etc.
a. Initial capital – Default is 10,000 (Please use realistic values here. The amount here should be able to cover ALL your safety orders if they were triggered. Ideally, you should have funds left over and not use all trade capital.)
b. Base currency – Select your currency
c. Order Size - Not used. Use the “Inputs” tab to change your base order size.
d. Leave “Pyramiding” set to 999. This acts as a ceiling to the “Max safety orders” on the “Inputs” tab. It must always be higher than your “Max safety orders.” For example, if you set your “Max safety orders” to “4” and “Pyramiding” to “4” then it effectively means you have “3” “Max safety orders” and not “4” because it is counting each successive entry including the initial order.
e. “Commission” - Optional
f. “Verify price for limit orders” – Leave at zero. This does not change anything that I can tell.
g. Optional - Enter a value for “Commission”
h. Slippage – Optional. Slippage does not occur in backtesting but does occur in real trading but it can be simulated. Example use case for tracking performance of a real money bot: You enter the start date and time of your bot’s trade into this strategy and you notice some values are a little off due to slippage (average price, take profit, safety orders are not lining up) then you would go back here and increase the slippage until those lines up close enough with your actuals.
i. Margin for long positions – I don’t use this honestly.
j. Margin for short positions – I don’t use this honestly.
k. Recalculate “After order is filled” and “On every tick” – I don’t use this honestly.
3. “Style” tab
a. Ranged Volume Bar Coloring - You must disable bar coloring in any studies you added or this may not work properly
i. Color 0 – Default Yellow; appears when a volume breakout occurs
ii. Color 1 – Default Red; appears when a volume breakdown occurs
iii. Color 2 – Light Blue; appears when Close is higher than the Open
iv. Color 3 – Dark Blue; appears when the Close is lower than the Open
b. Take profit – Default Green; take profit line
c. Safety order – Default Light Blue; safety order line
d. No Safety Orders left – Default Red; when a trade runs out of safety orders, the line turns red and there is no safety orders left underneath to catch any further falling price movements.
e. Avg Position Price – Default Orange; your average position price for any given trade.
f. Take Profit Plot Area – Default Green; creates a highlighted area for your take profit
g. SO Plot Area – Default Light Blue; creates a highlighted area for your safety orders
h. Trades on chart – Show or hide your trades on the chart
i. Signal labels – Show or hide the trade signal labels on the chart
j. Quantity – Show or hide the trade quantity on the chart
Explanation of Chart lines and colors on chart
4C Daily Levels Suite + Premarket High/LowThis '4C Daily Levels Suite + Premarket High/Low' indicator is a clean way to automatically plot important daily levels including:
Prior Day High
Prior Day Low
Prior Day Close
50% level between Prior High/Low
Today's Open
Today's Premarket Low+High
This Daily Levels indicator is unique in its ability to:
-Plot all of the daily level PLUS premarket high/low levels (extended hours must be turned ON)
-Can hide past days levels, only plotting levels on the current day, to keep chart cleaner
-Can extend line levels right or fullscreen
-Plots the level price at each level on the chart
-Can show/hide price levels labels
-Can add supplemental premarket levels plot to show levels being formed during the premarket time period
-Coded with line.new vs plot so dashed lines are available as a style
-Automatically hides the indicator if the timeframe selected is Daily or greater
SEE SCREENSHOT EXAMPLES BELOW
Default mode, with extended hours showing:
With supplemental premarket plot showing:
Default mode without extended hours showing:
Showing past day’s levels
Extend lines to fullscreen
Some parts of this code were adapted from 'pd Levels' by CryptoCurl
ORB-PreDay_PerM_LevelsThis script provides following levels:
1. ORB Level - You can adjust the timeframe of Opening Range (plots from 9am to 4pm)
2. ORB Fib Extension - 1.618 and 2.618 Fibonacci Extension of ORB High and Low (plots from 9am to 4pm)
3. Previous Day High/Low/Close - You can adjust color/thickness of the lines (plots from two days ago so that you can clearly see the levels)
4. Previous Two Days High/Low (plots from two days ago so that you can clearly see the levels)
5. Pre-Market High/Low (plots from 6:30am to 11am)
All in one indicator gives much better clarity of where current instrument is trading in relation to ORB, Previous Day Levels and Previous Two Days Levels along with Pre Market Levels.
You could combine these levels with your favorite EMA or EMA Cloud to create a trading system.
You could combine these levels with MA Cloud and ATR vs DTR script to gauge the move.
Look at the TWTR Chart today and see how these levels are respected.
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.
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
