crowdsourcing to build the next iteration of the arbitrage software

[kanekoshoyu]

Hi, I wanted to make an announcement here that I am considering a full rewrite of a new iteration of the trading software. I have not been comitting on this repo since I got an fortunate opportunity to partner with a hedge fund to work on a crypto trading platform as the main architect for last 6 months, and I was devoting so much there to validate a few previous assumptions I had for building a trading bot.

I got to learn that strategy is in fact not the most crucial element of a trading bot, as a proper trading bot should be capable of running a couple of strategies. I have been crowdsourcing quite a few ideas from very talented and seasoned people in this domain.

So far, there is a few key points that are missing in this kucoin_arbitrage.

1. cross exchange API crate that abstracts API into price and orders
2. multi strategy support that can be turned on/off, and a more flexible MPMC events stream
3. backtesting data that can be manually edited (data cleansing)
4. data visualization via API, with data-driven-design using database
5. accounting system that can tell profit or loss

and below are my action plan targeting each points

1. leverage AsyncAPI/OpenAPI to for code generation of exchange APIs at https://github.com/kanekoshoyu/henlo, and on top of it build abtraction layers and exchange traits
2. set up basic service with service state machine like idle/running with use of tokio::cancellation
3. make trading signals implement https://github.com/kanekoshoyu/reparo so it can be load from/stored in JSON or any other formats
4. start setting up postgres/graphql modules (within a feature, as I am still a event-driven system purist and believe a strategy should not depend on database data directly)
5. further investigation needed, frankly I think this is case by case per strategies and there is no one fit all solution, so it seems like I better get those raw trading replies and build accounting logics on top as PART of the strategy(as we should take trading replies as feedback loop, and yes it gets quite complicated), but I also need certain degree of abstraction like trade status and profit In such case, I better set a trait that says like "strategy status". Each stragegy action should be indexed and have its own object, with a function that says strategy_status() with enum status like success(profit) fail(reason).