Crypto Order Book: Part III, Kraken.

Kraken

Previously we published two articles discussing the details (and the pitfalls) of websocket API about Bitfinex and Bitstamp. What we have seen so far was that it is definitely a non-trivial task to obtain tick level data for order books. If you are a high-frequency professional trader, tick level data apparently are the king. If you are a regular professional trader, you might only need regular-interval order book snapshot data. And this is what we’ll be talking about in this article: order book snapshots (in particular quote snapshots).

There are a handful of crypto market data providers who provide one-minute snapshot data on order books. Generally, they choose one of two different approaches to collect order book snapshot data. Approach 1: establish websocket connection, use the data feed to reconstruct the states of the order book to form a time series, then slice the time series at the desired points to obtain the desired snapshots. For example, Shrimpy used this approach. The advantages of this approach are: the timestamps are very accurate (in fact, they are exact), snapshots can be selected at arbitrary intervals (e.g. every 5 seconds). The disadvantages are: the order book states might become incorrect if the procedure was not done carefully enough, data collection using websocket requires more CPU and memory. Approach 2: directly query on RESTful API endpoints that return order book snapshots from the exchange (e.g. https://www.kraken.com/features/api#get-order-book). For example, Kaiko used this approach. The advantages are: the data collection is stateless thanks to the exchange keeping track of their order book, the process requires little (if not zero) CPU and memory. The disadvantages are: the timestamps are only approximate due to latency in RESTful API endpoints, snapshots cannot be selected at arbitrary intervals due to rate limiting from RESTful API endpoints, the returned data can potentially be incorrect.

The reader might be astonished and shocked when we just said “the returned data can potentially be incorrect”. How come the exchanges might be unable to return the correct state of the order book if they are matching millions of trading orders per day? From our previous experience building a trading order matching engine, we know that taking a snapshot of the order book while it is busy under the hammer of matching engine is in fact a delicate task which requires careful synchronization in different components of the system. Therefore there tend to be more programming errors and bugs in the code for taking order book snapshots and returning them via RESTful API than emitting order book update events into websocket connections. Reputable exchanges have the engineering resources to get it right. But even an exchange as reputable as Kraken sometimes makes obvious mistakes: this time we are going to show you that Kraken’s order book snapshot RESTful API endpoint has an important “rounding” mistake which sometimes can artificially inflate the liquidity of some asset by a factor of 10. :)

Take Bitcoin on Kraken for example (other cryptocurrencies also have the same problem). Open a browser, visit https://trade.kraken.com/markets/kraken/btc/usd, and position the browser in the left half of your screen. Open a terminal, run

while [ true ]
do
curl -s 'https://api.kraken.com/0/public/Depth?pair=xbtusd&count=1'
printf '\n'
sleep 1
done

and position the browser in the right half of your screen. Observe carefully (or record the screen and playback in slow motion). You will find a disturbing detail:

Best bid size and best ask size from Kraken’s website
Best bid size and best ask size from Kraken’s website
Best bid size and best ask size from Kraken’s RESTful API
Best bid size and best ask size from Kraken’s RESTful API

The best bid size and the best ask size are reported back differently between Kraken’s live trading website and its order book snapshot RESTful API endpoint. The difference originates from Kraken’s RESTful API having rounded these numbers up to three decimal places: 5.29728450 becomes 5.298 and 3.51619191 becomes 3.517. The problem is that the round happens regardless of the number: at one point we observed that a website-displayed size of 0.0001 has been rounded up to three decimal places and become 0.001! 10 times larger liquidity reported by the RESTful API compared to the website!!

We are hoping that you aren’t (and weren’t) relying on https://www.kraken.com/features/api#get-order-book for your business. If you are relying on a third party data provider for Kraken’s order book related data, make sure to check for the “size” value of the order book snapshots in their data set: if they always have three decimal places, it is certainly a smoking gun! If you are relying on CryptoChassis (a.k.a us :)) for Kraken’s order book related data, congratulations! Our data are independently verifiable and reproducible. If you are able to spot and prove any defects in our data set, send us an email and we cordially invite you to join our team! :)

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store