V 13357 New Features Journal
This article will give more details on the newly implemented features, the logic behind them and hopefully help you make better use of them in your trading!
Orders save/load on core shutdown/start.
Functionality of retaining the states of TP\SLs and restoring them when restarting the core. This functionality also removes orders from algorithms that are not currently running. For example, the core was stopped for an emergency (crashed, VPS crashed/was restarted, or some other unforeseen circumstance), then it was restarted and the orders that were opened by the algorithm were found during initialization. This checks if the algorithms are working, and whether they work with these orders, and if not, then the orders are closed. This functionality is needed to implement more sustainable autonomous operation, to be able to restart, to auto-refresh with open trades, running algorithms and emergency restart.
Graph lines (Bid\Ask, Ticker, Trades, Mark lines) options to graph settings
The chart displays prices from different sources, such as orderbook best Bid & Ask, trades average (executed orders, trades), ticker source (single source of all recent prices), Mark Price. The goal — to complement the chart with the more convenient tools — the lines, because it is quite difficult to get the picture from several points on the screen on low liquidity markets, when trades are rare. For debugging purposes, different lines are drawn at different times, such as the time at which the price came to the client, at the time of the core, and at the time of the exchange. There may be scenarios where the lines of the same price will not coincide (the data came to the core or the client with a delay relative to the time when it occurred on the exchange), if the graph was opened at such moments, we will be able to see and assess the causes and consequences, identify the causes of delay and further seek to optimize for different scenarios (when the exchange is slow, when data arrives with a delay, see if data arrived in time, but took too long to be processed by our application)
Markets Watcher data source changed. Markets watcher significantly optimized
We have significantly optimized the work with the data from the exchange. We connected a new data source — Ticker Source. This source gives us information every 0.5 seconds about price changes in all markets, in which the price changed. The source is good, at this stage we can call it reliable, in our tests we didn’t notice any delay during volatility on the markets. The core is connected to this source right from the start and we need it for normal operation and Markets Watcher, which will be used for price change signals and is not too demanding in terms of speed, is perfect for working on this data source. That is, even if we know that price changes with 0.5 seconds delay, it is acceptable and suitable for Markets Watcher’s work. So, if you are running Markets Watcher, now there will be no additional load on the core, you do not need to connect additional data sources, the core is already connected to the required source by default. You can observe that when you start Markets Watcher, the consumed resources are almost unchanged.
Shot Algo Delta check optimization, new Delta types(Coin delta, BTC delta, time frames to choose from)
Now, to check markets using filters specified in algorithm parameters, the core doesn’t need to connect to tick data of all markets and keep these connections and suffer from the amount of incoming information. We already know the prices and price change deltas and we don’t need additional, more accurate data sources to decide whether the market goes through the user-defined filters or not (Ticker source, data source, to which the core is always connected). However, after passing through the filters, the source of price from which the shot runs remains the source of executed orders (trades source). This is an additional very accurate and fast source of price, which requires additional system and network resources. Therefore, algorithms that fail to pass through the delta or daily volume filters should not consume additional resources. Only the shots that are placed and work with orders will consume resources.
New Shot Algo option — Use Ticker Source
Now, for «safe» shots — those that stay far enough from the current price, those that don’t fear the price approaching in half a second, those that catch good deep shots at 0.5-0.7 distance and above — there is an option to use the new data source for making a «stand still or move» decision. What’s the advantage? The advantage is in resource consumption. Shots that use this data source do not consume additional resources for «tracking the price and constant recalculation of the current distance», such shots use resources only when it is necessary to move. This will give you the opportunity to work on many markets simultaneously, it is a great opportunity to keep many deep shots on many markets.
Shot Algo new filter — 24h quote volume
New volume filter in algorithms. Quote 24 hour rolling volume. This is the volume of the last 24 hours for this pair in its quoted unit. On pairs BTCUSDT,BNBUSDT, XRPUSDT volumes are measured in USDT, on pairs BNBBTC, ETHBTC — volumes are measured and specified in BTC
Shot Algo and manual trading new parameters. StopLoss delay.
Stop Loss Delay. Delay on stop loss setting, in seconds. It will be useful for working with shots in low liquidity markets when we catch a shot, it empties the orderbook, the orderbook is not filled and this same shot triggers stops of other market participants, it may pull the price even lower for a few seconds, later the orderbook is filled and the price takes a more natural movement. This is a possible means of protection against the triggering of a stop in an empty orderbook. For example, you stood at a distance of 3%, you have a stop loss still at -3% totaling 6%, you caught a shot, which emptied the orderbook to a depth of 10%, a few seconds after this shot the orderbook is still empty at full depth and random transactions occur until it is filled, transactions can be both at the same price level and at any level of the resulting emptiness, possibly below your stop-loss, which can cause it to trigger, when you would have rather waited.
AutoPriceDown takes the Take Profit down every X seconds, by X%, to the limit level of X% from the entry point. It would be useful to take out at least some profit, where after the shoot the price did not return to the zone where we are waiting for it with the TP. Optimization of your exit strategy should reduce the number of exits by SL. You can even use negative values, but not as deep as a stop loss.