Nearly all cryptocurrency exchanges include a “trade direction” field in transaction data accessible through their public APIs. The trade direction of an executed transaction denotes whether the transaction is classified by the exchange as either a “buy” or a “sell.” If you were to collect a trade marked as “buy,” what does this tell you about who is initiating the trade? As all trades include both a “buy” and a “sell” on either side of the transaction, you must know an additional layer of information in order to make use of such data. This additional layer of information is whether a trader on the stated side of the transaction is a “maker” or a “taker.”
The way exchanges report on trade direction varies greatly. While the majority of exchanges report trade direction from the perspective of a “taker,” a minority report from the perspective of a “maker,” some exchanges claim to report data from both perspectives, and others opt to exclude the field entirely from their transaction data. This article will explain what is meant by maker vs. taker and explore how individual exchanges go about classifying trade direction. We will then describe Kaiko’s “taker_side_sell” variable which is included as a field in our trade data for all 70 exchanges we cover.
The effort that goes into normalizing this variable proves why data providers are so important in cryptomarkets, where data standards still do not exist.
Makers add liquidity to an exchange’s order book by placing limit orders, or orders to buy or sell at a specific price that are not immediately filled. Makers place orders that are not immediately matched by an existing order. Without limit orders sitting on an order book, there would be little liquidity for a given pair as an exchange would be trying to match buy and sell market orders as they are placed. These Market Makers are crucial for maintaining price stability, as they fill up an order book with limit orders at different levels. Makers are typically rewarded with lower fees for providing liquidity to the market in the form of buy/sell limit orders.
Takers take liquidity, as in they place market orders to immediately buy or sell. Market orders are orders to take the best available price in the current market. Takers take the price that they want and in doing so, they are “taking” volume off of an order book. They place orders that are filled immediately by buy or sell orders already sitting on the books. Taker market orders are designed to never land on an exchange’s order book, as they are filled by the exchange’s matching engine as they are placed. Thus, taker fees are typically higher because their orders are filled immediately.
It can be assumed that every taker’s market order is filled by a maker’s limit order. Thus, by knowing the order type placed on just one side of a trade, you can automatically determine the other side’s order type.
Maker Buy →Taker Sell
Maker Sell →Taker Buy
*Some orders are only “partial fills,” meaning parts of the order go through immediately and other parts end up on an exchange’s order book. An order will now exist as more than 1 transaction, potentially a combination of both “buys” and “sells” based on how the exchange reports trade data.
Now we understand that “buy” (bids) and “sell” (asks) orders can be placed by both makers and takers. When you collect trade data from an exchange, there is almost always a buy/sell field, such as the example below from Gemini:
The transaction “type” is a “buy” for this particular trade, but who is buying? Did a maker’s buy order get filled by a taker’s sell order? Or did a taker’s buy order get filled by a maker’s sell order?
Ultimately, the only way to make use of trade direction data is to figure out the perspective that exchanges report this data from. To understand this data, we need to decipher how each individual exchange reports on trade direction, which is no simple task. Some exchanges explain how they report trade direction in their documentation, others responded to our question over email, and some exchanges don’t provide any documentation nor respond to our inquiries. What we realized when documenting this variable is that there is no universal standard for reporting trade direction, as exchanges report from the perspective of both maker side, taker side, and sometimes neither. However, we did find that a majority of exchanges opt to report trade direction from the perspective of a taker.
When an exchange reports trades from the perspective of maker orders, “buys” and “sells” refer to the maker order side. For example, Coinbase reports all trades from the maker order side. Thus, a trade marked as “buy” indicates that a maker’s buy order sitting on the exchange’s order book was filled by a taker’s sell order. A trade marked as “sell” indicates that a maker’s sell order was filled by a taker’s buy order.
When an exchange reports trades from the perspective of taker orders, “buys” and “sells” refer to the taker order side. For example, Gemini reportsall trades from the taker order side. Thus, a trade marked as “buy” indicates that a taker’s buy order was filled by a maker’s sell order. A trade marked as “sell” indicates that a taker’s sell order was filled by a maker’s buy order.
It is crucial to first understand which perspective an individual exchange reports trade direction from when interpreting “buy” and “sell” data. Luckily, Kaiko has done the hard work of interpreting trade direction so that you don’t have.
The results of our normalization efforts is the “taker_side_sell“ variable which takes the value of “true” or “false.” We have built this variable under the assumption that a taker’s sell order will always be filled by a maker’s buy order and a taker’s buy order will always be filled by a maker’s sell order. Thus, it is possible to create a single binary variable that indicates whether a taker was on the sell side or buy side of a transaction, no matter which perspective an exchange reports trade direction. Once you know whether a taker was buying or selling, you can determine a maker’s position.
When “taker_side_sell” is set to “true,” this means that a taker’s sell order was filled by a maker’s buy order. Thus the “taker” was on the “sell” side of a maker’s buy order, which would be reported by the exchange as a “buy” if the exchange records trades from a maker’s perspective and a “sell” if the exchange records trades from a taker’s perspective. When “taker_side_sell” is set to “false,” this means that a taker took the buy side of a maker’s sell order — a “taker” was not on the “sell” side of the transaction.
Maker Exchange
For example, Coinbase reports trades as either a “buy” or a “sell.” They report trade direction from the perspective of the maker, as specified in their documentation: “The trade ‘side’ indicates the maker order side.”
Thus, “taker_side_sell”:“true“ is equivalent to a transaction on Coinbase reported as “side”:“buy”, which means that a maker’s buy order was just filled by a taker’s sell order. “taker_side_sell”:“false” is equivalent to a transaction on Coinbase reported as “side”:“sell”, which means that a maker’s sell order was just filled by a taker’s buy order.
Taker Exchange
Gemini reports trades as either a “buy” or a “sell.” They report trade direction from the perspective of the taker, as specified in their documentation: “buy” means that an ask was removed from the book by an incoming buy order. “sell” means that a bid was removed from the book by an incoming sell order.”
Thus, “taker_side_sell”:“true” is equivalent to Gemini’s “type”:“sell” which means that a taker’s sell order was just filled by a maker’s buy order. “taker_side_sell”:“false” is equivalent to Gemini’s “type”:“buy” which means that a taker’s buy order was just filled by a maker’s sell order.
We have gone through every exchange’s documentation (and reached out to dozens of individual exchanges) to record whether they report trades from the perspective of a maker or a taker. We then normalize the data we receive to match the definition of our variable. This is an on-going process, as many exchanges don’t report anything and this requires extensive efforts to get a response from support desks. Another way to determine trade direction reporting is by studying the exchange’s order book and corresponding executed trades. We typically study very low liquidity pairs, which makes it easier to follow an order book in real-time. However, this method for determining how an exchange reports on trade direction can be quite unreliable especially given the presence of high-frequency/algorithmic traders that add and remove orders from an order book extremely fast. Thus, we always try to get an answer from the exchanges to confirm.
We have classified four categories of exchanges based on how they define trade direction:
Maker Side: Exchanges that report trades from the perspective of maker orders. A maker’s buy order will be expressed as “taker_side_sell”:”true” in our data.
Taker Side: Exchanges that report trades from the perspective of taker orders. A taker’s buy order will be expressed as “taker_side_sell”:”false” in our data.
Unspecified: Exchanges that do not specify which perspective they report trade direction. Nearly all exchanges do have a method for reporting trade direction, but their support staff are often unaware and not able to answer our questions. Thus, we have defined “taker_side_sell” for most “unspecified” exchanges as taker exchanges, as the majority of exchanges output data from a taker’s perspective.
Not Applicable/ Alternative Notation: Exchanges that do not include any type of buy/sell field or they use an alternative form of notation. For example, Korbit excludes a buy/sell field, thus we always return a “null” for “taker_side_sell.”
We have classified all exchanges we cover into 1 of these 4 categories. If an exchange is categorized as either a Maker or a Taker exchange, it can be assumed that all data we provide is normalized correctly because we have been able to directly confirm from the exchange the perspective from which they record this data.
For all other exchanges, we include notation mapping between their trade direction field and our “taker_side_sell” field. This is necessary for exchanges where we were unable to confirm as either perspective so that researchers who want to further study trade direction can make their own conclusions. For exchanges that classify trade direction differently or exclude the field entirely, we also include the notation mapping and a short explanation for how their variable differs.
Finally, we have made a couple of errors in classifying exchanges as “maker” or “taker,” typically early on in the process of developing “taker_side_sell.” Rather than switch our trade reporting after years of data collection, we have simply marked exchanges where the inverse of the notation statedshould be applied. For these exchanges, researchers should be aware that when “taker_side_sell”:”false,” the opposite is true.
To view the list of misreported, unspecified, not applicable, or alternative notations, please view our documentation.
As this variable is a work in progress, if you have any comments or insights please reach out at hello@kaiko.com.
