Currency arbitrage. Front-running robots in the Python programming language.

The classic currency arbitrage strategy. To be profitable, it assumes that your robot will have the FASTEST order execution among dozens of other robots. In most cases, if the exchange on which you want to trade is already popular enough, achieving this will not be possible.

If this is impossible to achieve, it is likely advisable to choose a different trading strategy based on inefficiency following the base strategy. In this article, we will discuss possible strategies to neutralize the not-so-fast speed of your robots on the exchange.

1. OsEngine's place in the speed race.

Not the first. But not the last either. Here is a list of possible implementations of this algorithm according to speed. Some assumptions are made here, and there will probably be those who will dispute it.

Trading from the colocation area is when you have remote access to a Linux or Windows server that is located in close proximity to the exchange's core. It is usually located tens or hundreds of meters away, which usually provides the best conditions for speed of access to trades.

«From the exchange's colocation area» is listed separately because the speed of the second group is much worse right away:

1. C++ / Linux - fastest execution. Quantity: units.

2. C# / Linux. Quantity: units.

3. C++(C#) / Windows. OsEngine here. Quantity: units.

From a remote server specifically chosen based on its ping to the exchange:

1. C++ / Linux. Quantity: units.

2. C# / Linux. Quantity: units.

3. C++(C#) / Windows. OsEngine here. Quantity: tens.

4. Python / Linux (Windows, no difference). Quantity: hundreds.

5. Trading website engines offering auto-trading strategies (3 commas, etc.). Quantity: hundreds.

Conclusions:

1. There is no point in trading the classic currency arbitrage on OsEngine on any popular cryptocurrency exchange.

2. Robots on Linux and C++ trading from colocation areas will always be faster. If these guys have already come to the exchange, we won't make any profit.

3. It is necessary to trade the classic currency arbitrage on unpopular exchanges.

4. There are tens and hundreds of times more robots on Python, website engines, than custom application robots. They are slow, clumsy, but someone constantly wants to use them and try them out. You can try to earn even on popular exchanges with them. How? We'll talk about it below.

2. Slow robots create imbalance.

Classic currency arbitrage.

Let's remember the picture of how classic currency arbitrage works:

Fig. 1. Instant profit in currency arbitrage.

Hunting for an order in an illiquid book - an order placed by a person.

To take it, in this particular case, three transactions need to be made:

1. We have USDT in our account.

2. We make a buy operation in the GNSUSDT contract - essentially exchanging USDT for GNS.

3. We make a sell operation in the GNSBTC contract - essentially exchanging GNS for BTC.

4. We make a sell operation in the BTCUSDT contract - essentially exchanging BTC for USDT.

5. After the third operation, we have USDT in our account again. If we are the fastest, we are in profit and everything is good.

What do less-than-fast robots do?

Now let's imagine that you have a robot in Python, working from a remote server in Moscow. Or you work from a website, rented a robot, and the server is in France. Trading on Binance. Market type orders - i.e. executing at any price.

1. The signal was 150 ms ago. There is no profit anymore.

2. There are several hundred robots running like yours.

3. You make the first buy trade operation (GNSUSDT book) at a much higher price than at the signal moment, as others have already taken advantage of the instant liquidity in the contract.

4. 500 ms later, your robot places the second market order to sell in the GNSBTC contract, in even worse conditions. There was already no good level of instant liquidity in this contract, but the situation deteriorated sharply in the past 650 ms. You sell at a price worse than before the signal by 0.7%.

5. 500 milliseconds later, your robot places a third market sell order in the BTCUSDT contract. Instant liquidity has also diverged here. However, it's not as catastrophic as in the second (illiquid) contract. You end up worse off than 1150 milliseconds ago by 0.1%.

Fig. 2. Where 98% of all currency arbitrage traders actually execute.

Overall:

1. A significant loss of 0.3 to 1% on operations.

2. Order books return to a harmonious state within 5 seconds.

In OsEngine, there is the ability to check the situation after the signal:

Fig. 3: A robot to study movement after the signal on currency arbitrage.

GitHub link: https://github.com/AlexWan/OsEngine

This robot takes profitability snapshots immediately after the entry signal. It writes data about movement in its log file, which can be found in the «Engine/Log/» folder next to the executable.

The log file looks approximately like this:

Fig. 4: Snapshots of situations within 3 seconds after the signal.

As seen from this log, after the appearance of profit from the sequence, the profitability of the pair almost immediately goes into a sharply negative zone. In other words, slow robots with market orders eat up instant liquidity in thinly-filled order books.

Important!!!

1. It is better to take snapshots from remote servers located as close as possible to the exchange's core.

2. For a more accurate analysis of the situation after the signal, this robot can be redesigned to work with order books to see in which book and by what percentage the movement in the bid or ask occurred.

3. The essence of the strategy.

The strategy involves capturing market orders from other robots in the central order books of the sequence that was just signaled. To do this, you need to keep BTC and ETH on the account instead of USDT, so that the first order can be placed to buy in the second order book of the sequence, waiting for the robots to execute it.

Fig. 5: Placing an order to buy in the sparse order book significantly below the best bid.

If executed – excellent. We are already in profit. Calmly and without haste, we transfer back to BTC through other contracts. If our order isn't executed, we withdraw it after 3/5 seconds. Next time it will fill.

4. Possible implementations within OsEngine.

Fig. 6: The logic of the robot's operation to implement this strategy.

1. Create a BotTabPolygon source for the robot, which, after settings from the interface, will simply give us signals regarding which pair generated a profit.

2. It is more convenient to trade using the BotTabScreener source, controlling each order separately.

3. To create it, you will need from 100 to 300 lines of code and knowledge of the C# language at the «school level».

Successful algorithms!

Os Engine terminal support: https://t.me/osengine_support_english