We automate crypto trading on the exchange, as well as on DEX

We automate crypto trading on the exchange, as well as on DEX

Hello, Habre! In this article, I share the tools that have allowed me to effectively create an automated trading system (AST) for cryptocurrency on centralized (CEX) and decentralized (DEX) exchanges. The system went into production in early 2022 and worked only on centralized exchanges. After the US government began blocking crypto exchanges for US citizens in the summer of 2023, it was decided to connect a decentralized exchange because decentralization does not require KYC.
So let’s get started!

SYSTEM BACKEND ARCHITECTURE.

I proceed from the fact that thousands of customers actively use the trading system, which means that it must be reliable, with business logic that is understandable to the average person, protected, scalable. The system manages other people’s assets and interacts with external independent services that are prone to changes and downtime, so it is necessary to be able to quickly add a new feature or fix a bug.
Let’s draw an architecture with three microservices. Everyone has a task, that is. that do not overlap in terms of functionality.

Figure 1.

The listener connects to the websocket of the exchange and subscribes to certain crypto pairs, for example ETHUSDT, BTCUSD. The tasks of the Listener are to receive current prices (2222 USDT for 1 ETH) and trades (from the order ID).
As soon as the Listener has determined that the order of our trading system is in the FILLED status, it sends a message to the Controller using a message broker (Kafka or RabbitMQ). It is fast (for Kafka a million messages per second without problems), reliable, secure (SSL), scalable (you can add many Controllers as message consumers).
Next, the Controller uses the business logic of the trading strategy. The microservice sends requests to the exchange using the REST API using the create_order, get_order, cancel_order endpoints.
If there is a failure in the chain described above, then a function is provided that regularly polls the exchange about filling orders of the trading system. Dubler is responsible for this. During a failure, this additional verification will allow trading to continue consistently, albeit with a temporary delay.

UNIVERSAL LIBRARY OF INTERACTION WITH EXCHANGES

Dozens of exchanges are active on the crypto market, each with its own API. If you want to connect to a new exchange, you will have to learn their API, rewrite a new class in your code, add new tests. This can take the developer up to a month. To reduce development time, I recommend considering the free CCXT universal library. Then the architecture will implement the Proxy pattern and look like this:

Figure 2.

PROGRAMMING LANGUAGES

My system does not yet have a serious requirement for trade processing speed, as this is not high-frequency trading. Therefore, it is not a shame to use the programming languages ​​in which exchange clients or CCXT are already written. For example, you can use non-agile Python.

ERROR PROCESSING

There are errors in the exchange API. They are most often found:

  • the user has insufficient funds;

  • warrant not found;

  • order creation error;

  • expired API keys;

  • failed KYC;

The trading system must be able to handle these errors, otherwise the client’s trading logic may be broken and his work will stop creating new orders. Anticipate halftime and retry. Add functionality to alert the customer about a problem that only they can fix.

SYSTEM TESTING

It is important to have integration tests. For this, exchanges provide testnet API. That is, you register a user in the test network and the exchange gives him a test cryptocurrency for free to test the code of your trading system. I haven’t implemented CI, so I’m running the trading system code, Kafka and Redis in DockerDesktop. Having experience connecting robots to centralized exchanges Binance, Kucoin, Bitso, women a short review. Binance is reliable, with detailed documentation, and quite fast technical support. In Kucoin, there are failures or you come across non-obvious logic, the main thing is to learn how to handle such cases.

DECENTRALIZED EXCHANGE

In September 2023, I was looking for a decentralized exchange that is functionally as close as possible to a centralized exchange. That is, one where you can create MARKET and LIMIT orders, listen to changes in the status of your order. The closest I found was 1inch, but its functionality met our needs by less than 70%. Therefore, I had to write a DEX Component that resembles a mini-exchange with the functions of processing and storing orders. Schematically it looks like this:

Figure 3.

The plan is to add its smart contract to Layer 2 in 2024.

Related posts