Internal Racing Conditions in Crypto Exchanges — Part II

Crypto Chassis
Open Crypto Trading Initiative
3 min readMay 23, 2023
Photo by Jonathan Chng on Unsplash

Greetings, Ladies and Gentlemen! In one of our previous publications entitled “Internal Racing Conditions in Crypto Exchanges”, we provided detailed discussions about the general exchange server architecture, how racing conditions might happen among different components of the exchange server, and what the implications and impacts are for high frequency trading (HFT) clients. We introduced one way of creating and canceling orders in a well-defined pattern as a method of studying the internal structures of the exchange server and their potential racing conditions. At the end of the article, we left an open-ended question for our curious readers: “What might happen if we perform experiments of swiftly creating/canceling orders in other well-defined patterns? Are there any phenomena that could possibly be taken advantage of?” We will try to provide our own answers in this article.

To begin with our discussions, let us first examine the flowchart about the general architecture of the exchange server. For details, please refer to our previous article entitled “Internal Racing Conditions in Crypto Exchanges”.

General Overview of Exchange Server Architecture

For many exchanges, if the client’s request is to create an order and the request is able to pass the risk engine, an order id is generated at this point (i.e. the point between the “Risk Engine” and the “FIFO Queue” in the above-shown flowchart) and the exchange returns and broadcasts this exchange-generated order id back to the client. Once the client receives this order id, s/he can use this order id to cancel the order. Therefore, let us perform the following simple experiment: for any given exchange, send a request to create a maker order, wait until an exchange generated order id is received on our side, immediately use this order id to cancel the order, wait for a few seconds (this way we fully respect any exchange’s rate limit), repeat. In theory, this process can go on forever. However, when some hidden racing conditions happen on the exchange, something unexpected might happen. At the time of writing, if we perform the above-described experiment on MEXC, we notice that there is a small but observable chance that the cancel order request might be rejected with an error code “-2011” which translates to “Unknown order sent”. Notice that our order cancellation request was sent using the exchange-generated order id that we received from the order creation confirmation. By the time that we sent our order cancellation request, the order should already exist somewhere in the exchange’s system. To deal with the spurious error response, we can use a simple approach by adding a small delay between order creation and order cancellation. However, we think that there might be a profound implication from this phenomenon and it can potentially be taken advantage of. When market is very volatile, market makers can frequently encounter the situation in which they send out an order creation request, then a few milliseconds later the market moves dramatically and they find that their order is at great risk of being adversely selected, therefore they have to cancel the order as soon as possible. But if there are exchange server racing conditions like above that prevent them from making timely order cancellations, then market takers can take advantage of this situation and “eat” these orders at good prices. Therefore, if we are asked to perform cross exchange market making, we’d probably choose MEXC as a taker exchange rather than a maker exchange due to the above-described phenomenon. For those of you as market makers who have great headaches in order cancellation failures, we recommend you to also read another one of our previous publications entitled “The Cancel-Order Failure: A Bad Headache for Market Makers”.

If you are interested in our work or collaborating with us, join us on Discord: https://discord.gg/b5EKcp9s8T or find us on Github: https://github.com/crypto-chassis/ccapi 🎉. We specialize in market data collection, high speed trading system, infrastructure optimization, and proprietary market making.

Disclaimer: This is an educational article rather than investment/financial advice.

--

--