Project refactor and overhaul

[Aureliano90]

This project was started when I was a newbie in Python and software development. I am glad it gathers a decent number of stars and hopefully some usage. However it feels outdated and lacking maintenance even though it still functions and makes money.

Therefore I'm soliciting feedbacks or suggestions to make an improvement plan. Given enough feedbacks and community contribution, an improvement plan will take effect.

[MichiganLu]

Hi Aureliano90,
Let me first acknowledge your great work. I have been using the project for a couple of months and customized quite some codes here and there to fit my own use. This is really excellent work both for both educational or monetary purpose, and for that I want to thank you.
Regarding suggestion, one functionality, or I should say risk management that I am very concerned about is volatile market management. We have witnessed how TRB drastically surged from 200U to 700U and plummeted to 100U in just 10 minutes in the first day of 2024. In this circumstance, the auto leverage ajustment method of this beautiful project would fail. It could detect the price surge, but could not make an order in time to prevent liquidation of perpetual. You would end up being left with only the spot position, losing all your swap.
How I managed this problem was to change all transaction type to multi-currency cross-margin transaction. This might increase the liquidation limit, but under very extreme circumstance, it could cost you everything in your account. So I saw this as an expedient method.
There is one more ideal solution that come to my mind. We will need to arbitrage on at least two cryptos at first. Whenever the system detects an unusual price change, let's say an increse of 50% in one minute, it will close other arbitrage pairs and add everything as margin to the radically changing pair. At the same time, it will try to close the radically changing pair, but you might expect long time and quite some lost due to a large spot-future price gap.
Another simple way is to place stop-loss order and take-profit order when making an arbitrage order. But this will freeze your position so that you cannot auto-leverage anymore.
Tell me if you have any thoughts. I will be very happy to hear a better solution.

Regards,
Richard

[Aureliano90]

Hi Aureliano90, Let me first acknowledge your great work. I have been using the project for a couple of months and customized quite some codes here and there to fit my own use. This is really excellent work both for both educational or monetary purpose, and for that I want to thank you. Regarding suggestion, one functionality, or I should say risk management that I am very concerned about is volatile market management. We have witnessed how TRB drastically surged from 200U to 700U and plummeted to 100U in just 10 minutes in the first day of 2024. In this circumstance, the auto leverage ajustment method of this beautiful project would fail. It could detect the price surge, but could not make an order in time to prevent liquidation of perpetual. You would end up being left with only the spot position, losing all your swap. How I managed this problem was to change all transaction type to multi-currency cross-margin transaction. This might increase the liquidation limit, but under very extreme circumstance, it could cost you everything in your account. So I saw this as an expedient method. There is one more ideal solution that come to my mind. We will need to arbitrage on at least two cryptos at first. Whenever the system detects an unusual price change, let's say an increse of 50% in one minute, it will close other arbitrage pairs and add everything as margin to the radically changing pair. At the same time, it will try to close the radically changing pair, but you might expect long time and quite some lost due to a large spot-future price gap. Another simple way is to place stop-loss order and take-profit order when making an arbitrage order. But this will freeze your position so that you cannot auto-leverage anymore. Tell me if you have any thoughts. I will be very happy to hear a better solution.

Regards, Richard

Thank you for your comments. I see three areas to improve:

1. Open each strategy in a sub-account with multi-currency cross-margin.
2. Telegram notification when the program encounters error.
3. Make functions modular and add unit tests.

[MichiganLu]

One thing I may want to address is that multicurrency cross-margin may not be the silver bullet to volatile market, because of such thing calls "discount rate"(https://www.okx.com/trade-market/discountrate). Basically, for many of the arbitrage pairs, only 50% value of your spot position is counted as margin. Let's say you short 100 crypto A by perpetual and long 100 crypto A in spot market. The value of your spot will be discounted to 50 crypto A when counted towards margin, making you vulnerable to volatile market. Mathamatically, you account will be liquidated if A rises by 200%(assuming 2x leverage). This is unlikely, but possible, considering TRB rose 250% in less than 5 minutes on Jan 1.

I knew a lot of arbitrageurs lost everything because of TRB, and the important thing is that we can learn a lesson from the past and find a way to deal with those vicious market manipulation when arbitraging.

[MichiganLu]

Regarding bugs, I also had some to share:

1. Futures-Spot-Arbitrage-OKEx-V5/src/monitor.py

   Line 192 in f6d9945

   if margin_reducible and liquidation_price > last * (1 + 1 / (leverage - 1)):

   When leverage sets to 1, "divided by 0" error occurs

2. Futures-Spot-Arbitrage-OKEx-V5/src/monitor.py

   Line 244 in f6d9945

   reducePosition.exitFlag = True

   Futures-Spot-Arbitrage-OKEx-V5/src/monitor.py

   Line 259 in f6d9945

   addPosition.exitFlag = True

   I am not sure what is the usage of the "exitFlag", but neither reducePosition nor addPosition class declares exitFlag in their class scope. I only find self.exit_flag within the class definition. So this line is not doing anything in my opinion.

3. Futures-Spot-Arbitrage-OKEx-V5/src/monitor.py

   Line 240 in f6d9945

   accelerated = True

   You do not reset the accelerated flag back to false when finishing the reduce task. You may want to reset it here, am I right?

   Futures-Spot-Arbitrage-OKEx-V5/src/monitor.py

   Line 275 in f6d9945

   adding = reducing = task_started = False

[Aureliano90]

Regarding bugs, I also had some to share:

1. Futures-Spot-Arbitrage-OKEx-V5/src/monitor.py

   Line 192 in f6d9945

   if margin_reducible and liquidation_price > last * (1 + 1 / (leverage - 1)):

   
   When leverage sets to 1, "divided by 0" error occurs

2. Futures-Spot-Arbitrage-OKEx-V5/src/monitor.py

   Line 244 in f6d9945

   reducePosition.exitFlag = True

   
   

   Futures-Spot-Arbitrage-OKEx-V5/src/monitor.py

   Line 259 in f6d9945

   addPosition.exitFlag = True

   
   I am not sure what is the usage of the "exitFlag", but neither reducePosition nor addPosition class declares exitFlag in their class scope. I only find self.exit_flag within the class definition. So this line is not doing anything in my opinion.

3. Futures-Spot-Arbitrage-OKEx-V5/src/monitor.py

   Line 240 in f6d9945

   accelerated = True

   
   You do not reset the accelerated flag back to false when finishing the reduce task. You may want to reset it here, am I right?

   Futures-Spot-Arbitrage-OKEx-V5/src/monitor.py

   Line 275 in f6d9945

   adding = reducing = task_started = False

Thank you.

1. True. However few would set leverage to 1.
2. AddPosition and ReducePosition should inherit exitFlag from the base class.
3. True. Should reset it.