Cryptocurrency Data Dictionary

For all exchange's in our collection, we poll their market data REST API made publicly available in an exchange’s API documentation. We collect every executed transaction on an exchange. We poll every exchange at regular intervals to ensure that we are collecting every trade data point. Immediately after receiving these trades, we de-duplicate and normalize the data into our own schema, to ensure consistency across exchanges.  

ID: this is the unique identifier for each trade, given by the exchange. The format of this ID can vary across exchanges. If an exchange does not include an ID for their trades, we will create our own ID. For those exchanges, we generate the IDs by taking all the values of a trade (timestamp, amount, price, side) and hash those into a new unique value.

Exchange: our internal two-letter symbol for the exchange. For each .CSV that you receive, this symbol corresponds to the exchange name from the filename (so for Binance_BTCUSDT_*.csv, this is 'bn'). The full list of exchanges and their corresponding codes can be found under the field “Kaiko_legacy_slug. The two-letter exchange symbol is only found in our .CSV files sent through our Data Feed. Through our API, the exchange symbols are from our list of codes (“code”) and can be found here.

Symbol: the instrument trading on the exchange

Date: We take the timestamp of the trade from the exchange. Our timestamps are not when Kaiko collected the data, but when the trade was executed as recorded by the exchange.

Price: The price of the asset displayed in the quote currency. For example, the price of a trade of BTC/USD would be $7,750.

Amount: The amount traded of the base asset. For example, the amount of a trade of BTC/USD would be .3, meaning that .3 BTC were traded at a given price.

isSell / Sell/ Taker_Side_Sell: This variable is the same across our Data Feed, API, and WebSocket, but is given different names due to legacy formatting issues. This is the indicator of whether the trade was a sell or a buy order, from the perspective of the taker. If ‘isSell: true': a taker’s sell order was filled by a maker’s buy order, if ‘isSell: false': a taker’s buy order was filled by a maker’s sell order. You can read more about this field on our documentation here or in an extensive blog post here. 

We strive to provide the most complete and qualitative data on the market. However, we partially rely upon the exchanges’ API to ensure this. Due to downtime of these API's (for example, due to maintenance) we sometimes experience gaps in our data and cannot always guarantee 100% coverage. 

We do not create an aggregation when there is not data for a given timespan. If you believe this is not the case for a certain pair, you can send us the request and we will check to see if there is in fact no trade data recorded for the timespan.

Twice per minute, we take a snapshot of the state of the order book at that particular instant. This means that in between snapshots, orders can be put and filled without us recording them. In practice, we take two snapshots per minute, in order to ensure that there is at least 1 state of the order book at any given minute with never more than 60 seconds difference between 2 snapshots.

In our current system, the snapshots are never taken at exactly 1 minute intervals due to timestamp inaccuracies across exchanges. Because there is a slight millisecond inaccuracy, if you look at timestamps from different days or even hours, it might seem random. However, we will always have at least 1 snapshot for every minute that passes. 

Our default order book product is 10%. This means that we include all bids/asks placed within 10% of the mid-price at the time the order book snapshot was taken. We poll each exchange's REST API for order books, and determine the mid-price for that snapshot. Then, we calculate 10% +/- from the midprice. Finally, we remove all bids and asks from the snapshot that fall outside of this 10% range. 

For most top exchanges, we are able to collect the full order book snapshot from the exchange's REST API. For other exchanges, we are only able to collect a certain number of "levels" (such as the best 20, 50, 100, 1,000 levels). For exchanges where we are able to collect the full order book snapshot, we cut the snapshot down into a "10% Snapshot" which includes all bids and asks within 10% of the midprice for that specific snapshot. For exchanges where we are unable to collect the full order book snapshot, we will still cut the snapshot down into a 10% snapshot if the bids and asks are greater than 10% from the midprice. For snapshots with bids/asks less than 10% of the midprice, we leave the snapshot as is.

On some exchanges where we are unable to collect the full snapshot, we are still able to collect the full 10% snapshot because the exchange is low volume.

We have documented each exchange's available market depth here. 

Order books contain bids and asks for a currency pair, essentially giving an "under the hood" look at all orders placed by makers on an exchange before they are executed as trades (which occurs once a taker fills a maker’s bid or ask). Trades are executed transactions and result when a buy and a sell order match on an exchange. Unfortunately, exchanges do not provide order books and trades as one data set--there are no common identifying variables that match a specific trade with a specific bid or ask on the order book as there are no shared ID's. Thus, the two datasets are always collected separately as it is impossible to package them into one dataset.

Unfortunately, exchanges do not store their own order book data. Thus, we are unable to backfill any missing order book data.

Tick-level order book data is the most granular data available in cryptocurrency markets, and can be used for detailed research or simulations of trading strategies. This data type is not for beginners, and requires a thorough understanding of cryptocurrency order books and techniques for working with large data sets.

With this data, traders and researchers can project market demand and support, determine price levels trades will be filled at, simulate entry and exits, train machine learning algorithms, search for arbitrage opportunities, and more. Order book ticks can be applied to order book snapshots to reconstruct historical market states and replay changes to the order book. 

Financial market order book data can be divided into three categories: Level 1, Level 2, and Level 3. In cryptocurrency markets, these categories are often blurred and differ slightly depending on the data formatting provided by the exchange. 

Level 1: L1 data refers to the best bid / best ask of a trading pair's order book. This data is commonly referred to as "quote" data, and is accessed in real-time. Traders subscribing to L1 quote data receive real-time changes to the best bid / best ask of an order book, which includes the price level and order amount.

Level 2: L2 data is more granular than L1 data, and includes bids and asks at all price levels of a trading pair's order book. This data is commonly referred to as "depth of book" data. In cryptocurrency markets, market makers place limit orders at price levels that differ from the current price of an asset. L2 data includes all bids and asks placed by these market makers, aggregated by price level. For example, if 10 traders placed bids of various sizes at $8,000 while the current price of BTC was $8,500, this would appear as an L2 quote of [price: $8,000, amount: 23.4]. The example amount of 23.4 would be the sum of all orders placed by the 10 traders. Because L2 data is aggregated by price level, it can also be referred to as "market by price level" data.

Level 3: L3 data provides even deeper information than L2 data. L3 data refers to non-aggregated bids and asks placed by individual market makers. An L3 data feed would include every individual bid and ask, whereas an L2 data feed would include these bids and asks aggregated by price level. For example, L3 data for the quotes placed by the 10 traders above would result in 10 different data points with each individual order amount, rather than a single data point aggregated by price level. Thus, L3 data can be referred to as "market by order" data.

Each consecutive level of data provides an increased level of granularity. Some traders may find L1 data sufficient for their trading strategies, while others require L2 data. L3 data is the most granular level of order book data, frequently used by the most sophisticated traders.

Only 3 exchanges in the industry provide non-aggregated, L3 data. All other exchanges provide L2 order boook data. 

Yes! We provide L3 data from the 3 exchanges that have this data type, but we will also provide L2 data for all exchanges in our collection. 

We unfortunately cannot backfill L2 tick-level historical order book data as exchanges do not store this data type.

Historical files for both "events" and "snapshots" will be delivered through either AWS or GCP. Live data will be distributed through our WebSocket API.

Collecting derivatives data is uniquely complex due to the variations in formatting and endpoints across exchanges. We poll each exchange's REST API to receive the data, yet most exchanges provide derivatives data through multiple endpoints. Thus, for a single "derivatives data snapshot", we poll multiple endpoints and combine the data into a single data packet. We query each unique derivatives data endpoint once per minute, thus it is possible that the data points returned through our API were not collected at the same exact moment. 
 
This product is in alpha. Changes to the format and update frequency might occur at any time without prior notice. 

This data is available through our REST API through our 'Derivatives Data' endpoints, both live and historical data. You can view our API documentation here. We also provide this data in CSV files with history since August 2020, when we began collection for all exchanges. 

Please reach out to us if you would like a free trial. 

Currently, this data is updated on average once per minute. Not every derivatives measure updates at this frequency. For example, funding rates are only recalculated every few hours, so we will not have this data as frequently as others.

Right now, we do not have a dedicated endpoint to get option chains. However, by concurrently querying all option contract data for an instrument, users can construct an option chain (or option matrix) themselves.

Yes! We are planning to add lending rates, liquidation data, more data on indices and aggregated derivatives data in the future.