Keeping consistent market depth using Mt.Gox API

4

2

I'm trying to write a program using the Mt.Gox API to keep an up-to-date consistent view of their market depth. My current approach is as follows:

  • Connect WebSocket and subscribe to depth updates
  • Wait for 1 minute, collecting updates
  • Request full market depth data via http://data.mtgox.com/api/1/BTCUSD/depth/full
  • Merge the collected updates into the market data by time-stamp (more recent wins)
  • Continue merging all future updates into data

After playing around with this for a while, I noticed that the full depth data download doesn't always match the data generated from updates. That's why I added the 1min delay, thinking that maybe the Mt.Gox server only updates the full depth data periodically, but doesn't generate it on the fly.

But even with this protocol, if I run the program twice in parallel, I end up seeing different data in both instances.

Any idea what I might be doing wrong?

Markus A.

Posted 2013-05-31T02:43:56.967

Reputation: 141

Answers

4

In my experience requesting the full market depth from MtGox, often results in flat out incorrect information. To deal with this I've resorted to constructing my own, in a similar manner as you described above.

What I do is, using the websocket api, I look at all incoming depth events. I then keep two ordered arrays of bids and asks. On depth events if the volume is positive I add the order to the respective array based on the type_str property. If the volume is negative I remove the object from the array.

Make sure to combine objects of the same price, but with different volume. Likewise when removing objects if the negative volume is less then the volume of the same prices object then only deduct from the volume instead of removing. This is how it is done on MtGox's server and it will lead to errors if done differently.

After letting this run for a little while, though not deep, the order book is quite accurate and representative of what the MtGox order book should be.

Loourr

Posted 2013-05-31T02:43:56.967

Reputation: 3 022

Hi! I also tried to manage my own order book and have noticed that after having it run for a while, it accumulates entries that should have long been removed. But, I have so far only used the "depth" events' "total volume" field. Does the information included in the "trade" events actually not show up as "depth" events? Also, have you found the incremental volume information (positive vs. negative) to be more accurate than using the "total volume" field? Thanks! – Markus A. – 2013-06-11T18:27:53.420

so I resized that all trade events will have a corresponding depth event with negative volume. So just using depth events you can construct an order book by adding all depth objects with positive volume and removing objects with negative volume. To make sure they are the same I match the price_int and amount_int fields before removing the object. I dont use total volume at all, and have found this to work quite well. – Loourr – 2013-06-11T19:14:49.997

Hmmm... I also used price_int to match the entries... let me try using amount_int instead of total volume to see if that's more reliable... Have you ever noticed any depth events arriving "out of order", i.e. you receive an event with a "now" timestamp that is earlier than the timestamp of a previously received event? – Markus A. – 2013-06-11T19:56:02.390

No, but I'll be keeping an eye out for it in the future. Also be sure you take the absolute value of the negative volumes before you compare them with existing orders. – Loourr – 2013-06-11T20:16:20.063

Asked: 2013-05-31T02:43:56.967

Viewed: 1 399 times

Active: 2013-06-15T02:24:22.657