I heard that it is possible to get a client's deposit through API keys by trading manipulation. Is that true?

How does it work?

First, it is necessary to find a low-liquid trading pair with a high price gap. A gap in price is the difference between the most expensive buy order and the cheapest sell order.

On Binance, maximum gaps on low liquid pairs can reach 2%, but they are not stable.

Next, we have a client account (CA) and an intruder account (IA).

  • CA places a limit order per trade step above the most expensive buy order.
  • IA fills this order by market order.
  • CA places a limit sell order.
  • CA fills this order by market order.

As a result of this cycle, the amount of USDT (or other quote currency) on the CA will decrease by the value of the gap, and on the IC will increase by the value of the GAP.


Why isn't this interesting?

Let us set the perfect conditions for such an operation (which, of course, do not occur in real life):

  1. During all the buy and sell cycles, the price will not change.
  2. The size of the gap is fixed at 2%

Let's assume that there is $1000 on CA, and the goal is to transfer it to your account using this scheme. After one transaction cycle, funds on CA will decrease by $20 (2%). However, IC  will get only $16 out of it. To complete the cycle, you have to execute 4 orders (two on the side of CA and two on the side of IC). The commission for each order is 0.1%. As the result, we get that one cycle costs 0.4% regardless of the gap size.


In other words, with such a good gap, the efficiency of such an operation is already 80%. 


To "transfer" 90% of the deposit from the CA to IC, 114 cycles are needed. To "transfer" 99% of the deposit - 228 cycles. Taking into account the fact that there is time for a response from the exchange after each order has been placed, one cycle cannot take less than 1 second.


So far, we have been the only participants on the exchange.


On real exchanges, if your limit order is the last to the gap, the frontrunner robots will be activated immediately.


Frontrunners are HFT robots. The goal of these robots is the same as ours.


Buy below the gap and sell above the gap. The difference is in the infrastructure. They are designed to be fast and usually run in the same data center (or even in the same rack) as the exchange servers. Some of these robots are owned by the exchange. In general, we can not overtake them in speed - it is a matter of sufficiently big expenses.


So, the situation is as follows: AC puts a limit order to buy at the edge of the gap, and several frontrunners put their limit orders ahead of it. Besides, the orders will be set before AC receives the message about the successful placement of its own order. Next, IC may have two strategies (and they are both bad).


  1. Immediately after the confirmation, IC makes a sale on the market for the amount of AC's order. As a result, the order of AC is not fully executed, because there are already other orders of frontrunners in front of it.
  2. After confirmation IC we wait for information from the exchange about new limit orders frontrunners, and we make a purchase on the market, but already taking into account again exposed demands, buying up them as well.
  3. During those two minutes that we will conduct our operations, the pump/dump robots will not come to the pair. (and such sudden activity might trigger them).


The second way is worse than the first because we give more time for frontrunners to place their bids. But the point remains the same. We have bought more coins not interesting to us, at the price not interesting to us (frontrunners buy at a higher price than AC, and it interferes with a strategy of a deposit).


The total value of the frontrunners orders may be from ~20% of our limit order or be several times more than that. Let's calculate it at the minimum value of 20%. That means we have bought 20% extra coins. Now we have to get rid of them. And we have a 2% gap. This means that at this 20%, we do not earn, and lose 2%. It turns out the following picture. Of the remaining 80%, we lose 20% of revenues, and 60% of sales are gainful. 60%-20% = 40%. That is the efficiency of our operation. We will lose the same 40% at the second stage of our cycle, namely when IC places a limit order and AC buys on the market. 


Under the most perfect conditions, when we are hampered only by very loyal frontrunners (who are not able to do icebergs (limit orders only partially displayed in the order book, appeared as they are redeemed), and the exchange executes only one of our orders per tick), we get an efficiency approaching 0%.


In real conditions, with a constantly changing gap, with changing price, with other participants and robots, and if the frontrunners will play at least half power (40-50% of our limit order) the efficiency of this strategy for IC will be negative.


Which means it won't be interesting at all. That is why it is impossible to "lose" / obtain deposit funds through API.

    Was this article helpful?
    0 out of 0 found this helpful