Blacklisting coins with problematic trades without providing backtest evidence
Blacklisting coins after a huge red trade happened won’t ensure that a similar huge red trade won’t occur in the future with a different coin. Every day, new coins are listed, particularly on less strict exchanges. The best course of action is to block certain coins from live trade, but you also have to improve the strategy to make sure that the backtesting of the new version can handle those problematic coins. Although it’s not a certainty, at least your strategy can now deal with previously identified undesirable trades.
No hard stoploss because it will bounce
This is a risky way of thinking, especially in the cryptocurrency world where any coin—aside from Bitcoin—can fall into a deep hole. Recall LUNA? Or perhaps those metaverse coins, like MBOX. Not always will they bounce. It is exceedingly risky to play with a very loose stop loss and to move it up or down arbitrarily. At some points, the stop loss will be changed only few days after the last change. Have a fixed stop loss or a loose stop loss with several exit plans for when the indicators start screaming “DANGER!”. Having none is simply poor risk management. A single loss might essentially erase weeks or months’ worth of profits.
“Sophisticated” strategy
Truthfully, it would take a lot of time to read and analyze each and every line in the strategy file, which is what everyone must do before using an unfamiliar strategy. You must fully understand how the strategy will operate. Sadly, not many people have the patience to wait before investing their money into the real world.
Overfitted fixes
Consider this fix, changed from 0.022 to 0.023. Without any logical reasoning, that tiny adjustment to a parameter was made to make the backtest appear flawless. Or this fix, which made 0.990 into 0.995. This? This? Other than the fact that the adjustments would lead to favorable backtest results, I hope there are some logical scientific justifications for the adjustments.
Personally, I recommend keeping with a single number, like 0.95. Meanwhile, if you still want to change the number, it’s best to use appropriate increments; for instance, if the range is between 0 and 1, a 0.005 increase can be considered overfitting. The ideal increase to prevent overfitting is 0.05. But 0.005 would be OK if the range was 0 to 0.1. The best course of action is to add additional logics rather than alter the value of the parameters.
The updates happen too often
Rarely will a version be run over a prolonged period of time to evaluate its actual performance and compare it with the backtest. You might even get 6-7 updates a day on occasion. Because you get a newer version a few hours later, it’s difficult to judge whether the previous version is indeed poor and whether the new version is better. All evaluations are based on backtest results, but as I’ll discuss later, those results are questionable.
The only thing these regular updates have done is foster the FOMO attitude. It’s a common misconception among users that newer is always better. There is no solid evidence to support it. It’s also difficult to determine which components genuinely contribute to the increase or loss in performance in the most recent version due to tiny changes in each version.
Now to the strategy itself. Some issues with the strategy that I found are
Custom exit and partial entry/exit that trick backtest
To learn why and how to prevent traps in custom exits, click the link above. By having a lengthy if-else logic in the exit logics, you almost always get different results compared to backtest since it’s hard to get the same entry rate as backtest. You would even have different results on two bots running concurrently. The partial entry/exit problem have the same issue as the custom exit trap mentioned above.
Inconsistent startup_candle_count
It’s odd because startup_candle_count is defined as 800 yet these are written few lines below
# OKX, Kraken provides a lower number of candle data per API callifself.config["exchange"]["name"] in ["okx", "okex"]:self.startup_candle_count =480elifself.config["exchange"]["name"] in ["kraken"]:self.startup_candle_count =710elifself.config["exchange"]["name"] in ["bybit"]:self.startup_candle_count =199
Startup candle is a parameter that depends on indicators you use rather than the exchange you use, as it will have an impact on a number of indicators if the startup count is recklessly decreased. A brief look at the populate indicators reveals a handful that will break if this method is used on Bybit.
The phrase “trash input, trash output” was often used by my lecturer. Don’t expect the indicators to provide you with trustworthy outcomes if you provide them with inaccurate data. Don’t support the exchange if you believe it is incapable of handling such candle requests. Being safe is preferable to fighting with low-quality weapons.
Overcomplicated/overfitted logics
Not sure if anyone can really understand the logic behind buy #1. Let’s go through its logic together.
This entry’s logic is somewhat lengthy. According to my experience, combining all those lines into a single logic is risky because it would be difficult to determine which part triggered the bad entry and needed to be adjusted. In order to make it simpler to debug, optimize, and fix it in the future, I recommend that it be divided into manageable chunks and have their own entry tags. Same issue found on the exit logics, for example
Questions showed in my head when I read these lines
Why doesn’t the RSI limit increase from o_10 to o_11 and o_12?
Why is it increased by step of 2?
Why is the RSI limit increase from o_0 to o_1 8 rather than 2?
When the last candle indicates that the pair is in an oversold region, do you even want to exit?
High leverage setting (5x)
Since the hard stoploss (at the time this article was written) has been set at 30%, actual move of 6% would be sufficient to trigger it. Knowing the historical and present live trade history of NFI variations, -6% is not an uncommon occurrence. We don’t really know what we will obtain from the strategy on the futures market because I haven’t seen any backtest results done on it thus far. Before putting the bot into action with real money (live), if you wish to use it on futures, please do thorough backtests and lengthy dry runs.
One comment
[…] Why NostalgiaForInfinity shouldn’t be used for live trading […]
[…] Why NostalgiaForInfinity shouldn’t be used for live trading […]