A lot of things happening. Starting with V5 trading this week several times and the market ending with a crash. Let's get to it.
At the moment we are running trades on BTC-USD, BTC-EUR, BTC-USDT, and BTC USDC. Not every pair ended in profit. Actually only BTC-EUR ended in profit. How come? In the V5 backtests EUR outperforms USD. This has to do with USD having more volume which is leading the price compared to EUR. Arbitrage bots make the market efficient by following the price of USD. But due to the delay (even so slightly), and the fact that EUR is lagging compared to USD, means that it's a bit less volatile and smoother.
This in turn makes in some situations -especially on V5- trigger EUR less often. While USD following pairs triggered a sell on Saturday 23rd February, before the pump, the EUR didn't and stayed in the ~5% pump that followed. This meant that EUR accounts closed ~2.7% net profit while other pairs experienced a net loss of ~1.7%.
I also promised to share a backtest from the pump on Feb 17th which we missed out. Due to V4/V5 being paused because of increased risk and not having a supporting strategy that got our backs. As you can see in the picture above we would see some small losses but would have catched the pump with around 4.68% gross profit. This is BTC-USD so it would buy in late at the second pump in the picture. The sell before the crash was not triggered by the supporting strategy as it's only enforcing the stop loss now, not the crash monitoring function. ￼ I will consider to run all V5 pairs on EUR data instead. Not 100% decided yet as this can also be partly solved with the supporting strategy. More below.
The supporting strategy is probably one of the most important strategies I've done up until now. It's an early version and only monitors if the price exceeds our hard exits of -5% at any moment in time. It's real-time. So for now it's an over-engineered stop-loss.
However it opens up a lot of opportunities to decrease risk. I'm working on a solution to sell during high downwards price volatility that happens within a couple minutes. This will not work very well if we run this 100% of the time as we will have many false positives. That means, it looks like the price is going to crash, but it will recover quickly. Need to think how to solve these situations.
The best way to implement this anti-crash monitor though is to be able to turn this on during times were there's low confidence. For example last week when I paused trading due to increased risk. Another time would be for example when there's movement in the Mt. Gox wallets, that may cause dumping of a significant amount of BTC. We can then turn on the anti-crash monitor and stay on high alert, but still hold a position.
The monitoring of high profile wallets (Satoshi, Mt. Gox, etc.) is something that the Master strategy would handle and may act upon.
It will also be useful for running along the C1 crash strategy. With C1 it might run along with it 100% of the time.
I'm pretty excited about the supporting strategy as we can add second and third layers to de-risking situations. I will share more details next week as it takes shape. And spend some time learning more about what all happened this week.
The supportive strategy is actually similar to the Master strategy I talked about in my last blog post. As in how it works. This will also speed up development for the planned Master strategy in Q2.
If we leave out any false positives, yes. It would have confirmed the incoming crash a bit earlier. Besides that, during the second pump once we bought in, it would have had considerable less risk if the market crashed sooner than it happened.
If we reverse the algo to spot the incoming pump, it might have bought in sooner for USD pairs. I will test this more coming week.
So now that the market crashed, I saw that the crash strategy signaled a buy at 3.30AM on 25th February. I'm pretty curious how this will unfold. If I run the crash strategy with the algorithm that detects incoming crashes, this would be an interesting strategy to deploy. We don't know if the market will crash further so the algorithm would protect against it. I'll keep an eye out on this and report back next week.
If this works, I will make an implementation together with the supporting strategy and deploy it as a stand-alone strategy first. Then later possibly running it along V5. V4 is less suitable for that.
Fixed a bug where our Binance execution server would not accept our market order, due a thin orderbook that we eat into with larger orders. I will push an update that will fix this. The server will create the order size based on the latest state of the orderbook. Coinbase does this automatically for you but for Binance this is done manually from our side. This is the premium you pay basically for using USDC, slightly higher prices as USDT has more volume and thicker order books, resulting in less slippage. There are solutions for this though, but for now not a high priority.
Fix ready for our circuit breaker that checks how many trades we do within 24h. If there's a bug that keeps trading positions, or the bot is being hunted by other bots (yes that exists), there's a circuit breaker that will stop trading so that I can take a closer look at it.
That's it for now, more soon.