Binance Trades History Understanding
2023-08-31 18:41
A trader who initiates trades (for example, by placing a market order) and consumes liquidity from the order book is referred to as the "taker." The individual who was already present in the order book and provides liquidity for the trade is known as the "maker."
When you place a market order, it typically matches with the best order in the order book, and the corresponding trade is recorded in the history. However, if your market order is larger than the best order in the order book, it will match with multiple orders. Each match results in a separate trade, and everyone can see these trades in the history as distinct transactions.
Usually, you would consider a trade to be the result of a market order that matched with some liquidity in the order book, rather than viewing it as just a separate taker-maker match as displayed in the trade history. To do this, you can group consecutive trades in the history by their taker order ID.
taker example
Of course, market orders are not the only type that can trigger immediate trades. There are two types of taker-limit orders: Fill-or-Kill (FOK) and Immediate-or-Cancel (IOC). Both are like market orders but include a price-limiting parameter. If there isn't enough liquidity in the order book to execute the order at a favorable price, it won't be executed. Specifically, an FOK order will be canceled entirely, while an IOC order will execute as much as possible at the available price.
Each trade has a "side": either buy or sell. If the taker of the trade is the buyer, then the trade is categorized as a buy; otherwise, it is categorized as a sell.
Stop orders
Firstly, it appears that when a trade is executed at the price of a stop order, the entire cluster of stop orders is executed atomically and simultaneously with the trigger trade execution.
Secondly, when stop orders are executed as trades, the resulting trades will have taker order IDs equal to the initial stop order IDs. Why is this useful? When a market order is executed on Binance, a new order ID is generated. Consequently, you will observe an increment in the taker order ID within the trade history. However, this increment occurs only when the trades are not stop orders!
If a single market order triggers a cluster of stop orders, this will be evident in the trade history: you'll see one normal trade followed by a group of trades with suspiciously lower taker order IDs, all sharing the same timestamp as the first trade.
Here is an example of a large cluster of stop orders. They are marked by '🛑'.
stop losses cluser example
If you wish to view this in the data, you should consume the trade stream via Binance WebSocket API. Trade history accessed via Binance REST API does not contain taker/maker IDs. You can also execute Python code on this data in our cloud. See the example for finding triangular arbitrage deals.
It's worth noting that the same characteristics could be found in other types of orders with triggering logic. For instance, sometimes you may find trades in the history that were triggered as stop orders but in opposite directions. These could be a form of take-profit orders that operate not via limit orders. Additionally, Binance offers OCO (One Cancels the Other) trades, which include both a stop order and a take-profit based on a limit order. Trades executed by these OCO orders will also use the initial OCO order ID as the taker order ID.
It's interesting one. Basically, on large market order, icebergs are just executed immediately.
OCO execution
When the stop part of an OCO (One-Cancels-the-Other) order executes, the take-profit part should be canceled. The take-profit part is typically a simple limit order. Thus, you should see a reduced amount for the corresponding price in the order book diff.
Taker Order ID Gaps
Sometimes, you might notice gaps in taker order ID between two consecutive trades for the same symbol. These gaps could be due to the creation of limit orders or stop orders. They might also arise from "expired" orders. On Binance, for example, an "expired" status is given to orders that could not be created. This status might be received when there's a failure to create a fill-or-kill (FOK) limit order.
High-frequency traders often create multiple orders instantaneously to increase their chances of being first in the race. They typically open their positions via taker limit orders (like FOK or Immediate-or-Cancel (IOC)) rather than market orders, as this allows them to have more control over the opening price. Late orders may expire because the market prices have already shifted in a different direction. As a result, you might occasionally observe this side effect - large gaps in highly concurrent trading activities.
By examining these gaps, you can gauge how many orders were actually attempting to execute at that particular moment. This can provide an estimate of the number of participants, even if they weren't able to establish a position. It can also hint at the load on the exchange's matching engine. If the exchange is overloaded, you'll notice that timestamps of consecutive orders increase rapidly, even if the actual orders were placed very close together in time. This growing gap in timestamps is a direct result of exchange overloading.