5 ms·

Coinbase – Exchange API

94 points by mericsson 12y ago

mericsson 12y ago
Looks like this is the new Coinbase Lunar project being announced tomorrow. http://www.btcfeed.net/news/coinbases-lunar-announcement-analyzed-will-bitcoins-saviour/ http://www.btcfeed.net/news/coinbases-lunar-announcement-ana...
clarkmoody 12y ago
After having looked at dozens of Bitcoin exchange APIs, this one was a breath of fresh air. The only other respectable API out there belongs to Kraken [1]. [1] https://www.kraken.com/help/api https://www.kraken.com/help/api
- artursapek 12y ago
  Really? I've found Kraken's pretty hard to work with. They're inconsistent in some ways, like their currency pair names (sometimes "XXBTXZEUR", sometimes "XBTEUR"). Also, they are the only ones I've come across who don't just use plain old integers for ids - they have some weird scheme that has string ids formatted like O6W5EU-VY7YF-CS3XNP. That said, they're better than say BTC-e and OKCoin :)
  - clarkmoody 12y ago
    The way Coinbase is doing the streaming WebSocket data looks very good. My frame of reference is Bitstamp and Mt. Gox before that... Keeping a proper copy of the order book on the client side should be fairly straightforward. Bitstamp's API makes it impossible to keep the full order book synced. They broadcast the top 20 rows over the socket, but for many situations that's not good enough.
    - functionCall 12y ago
      Bitstamp has a new websocket channel https://www.bitstamp.net/websocket/ https://www.bitstamp.net/websocket/ where you can get full order book updates.
      - clarkmoody 12y ago
        Excellent! Maybe one day and exchange will create a developer email list where they let people know when the API changes (Bitstamp has had an awful history of breaking the API without warning).
  - drpancake 12y ago
    Kraken's API is pretty good when compared to the industry average. It's just a little bit whacky.
- tlrobinson 12y ago
  After having looked at dozens of Bitcoin exchange APIs For those who don't recognize the name, Clark ran one of the best Bitcoin exchange charts sites at bitcoin.clarkmoody.com (now part of ZeroBlock?)
- drpancake 12y ago
  Having integrated five other cryptocurrency exchanges, I echo this sentiment. I hope it sets the bar.
- michaelgrosner2 12y ago
  No way. Kraken doesn't even have a real-time feed. The best I've ever seen is HitBtc or Coinsetter. Those two are the closest to Wall Street grade APIs out there (demo environments, real-time API agnostic of protocol, colocation, etc). From a brief glance, this Coinbase exchange API is close.
- functionCall 12y ago
  I've just started to work with the Kraken API it is good. Their key signing/hashing auth is a little weird but the example clients are very useful. Is there a way to get real time order book updates from the Kraken? Another good API is Paymium's https://github.com/Paymium/api-documentation https://github.com/Paymium/api-documentation the most frustrating thing I find about exchanges API are race conditions when doing HFT, like submitting an order getting an ID, then asking about the ID to find it doesn't exist yet as the update hasn't be prorated yet.
- mrchicity 12y ago
  Polling is an awful API for market data, especially when the poll rate is limited. People end up gaming the system with multiple accounts and getting additional "peeks" into the order book. Maybe it doesn't matter for Bitcoin but it's a bad design for a serious exchange.
  - clarkmoody 12y ago
    The API specifies how to poll once and use the streaming data feed to keep an accurate state of the order book on the client side. So it's not really a polled API, for serious clients.
    - jzwinck 12y ago
      Indeed. The WebSocket API is described here: https://docs.exchange.coinbase.com/#websocket-feed https://docs.exchange.coinbase.com/#websocket-feed
    - mrchicity 12y ago
      Thanks for the correction. You're right. If one of these guys provided a more traditional fix/itch/ouch setup, they might get more traction with traders who are already active in other currencies/products.
artursapek 12y ago
It looks like it's not running yet. I'm getting a Heroku "No such app" 404. https://api.exchange.coinbase.com/currencies/ https://api.exchange.coinbase.com/currencies/
- sandGorgon 12y ago
  heroku ? are they using rails here ? really interested to see what stack would somebody use to build a financial exchange and websockets
Animats 12y ago
Looks straightforward enough. They note that your trading 'bots should be running on Amazon AWS East for minimum latency. They're encouraging high frequency trading. Since they're coming up with zero fees, they may have huge 'bot volume. Then they can announce they are the biggest exchange.
- zeeshanm 12y ago
  Wouldn't be HFT enough until they pay for flow.
- tlrobinson 12y ago
  Heh, you could imagine Bitcoin HFT shops spinning up EC2 instances until they happen to get one close to Coinbase's. (I don't know AWS networking well enough to know if this would make much of a difference, or even if the overhead of the HTTP API wouldn't make the difference negligible)
  - kordless 12y ago
    > could imagine I imagine they are already thinking about it. Affinity and HFT go hand in hand.
- kasey_junk 12y ago
  Given their maker/taker fee setup, they clearly are trying to attract liquidity providers, who definitely want to be able trade algorithmically. But, other technical choices make it clear that they are not targeting existing HFT firms. For instance, cloud based virtualized servers are unacceptable for HFT firms. Not being located at one of the "major" exchange data centers is a problem for most firms as well. Finally, building an http/json based proprietary api instead of a standards based one or a proprietary binary format is a clear signal that they are not targeting existing HFT firms.
jsprogrammer 12y ago
Why does an exchange, which is based on basic market principles and claims to incorporate a supply and demand (maker vs. taker) model, have a fixed rate vig on half the transactions? Shouldn't the vig float and have a mechanism which drives it towards zero?
- DavidSJ 12y ago
  As I understand it, it's not a fee that the maker receives, it's a fee CoinBase receives, i.e. it's their way of making profit off of this exchange. The mechanism which could drive it to zero is competition from other exchanges.
  - jsprogrammer 12y ago
    I get that it's CoinBase's fee (vig). I'm having a hard time understanding where the fixed 0.25% fee comes from other than: fee = desired_profit / (expected_transaction_volume * expected_average_transaction_value)
    - jzwinck 12y ago
      So you think the fee to remove liquidity should "float" in what way exactly? With per-customer tiered volume discounts like many exchanges offer to customers who trade enough in a given month? Or when you said "float" did you mean it should be variable across the entire exchange over time, but the same for all customers at any given time?
      - jsprogrammer 12y ago
        Like any well functioning market, it should track the actual cost of goods, in this case, the actual cost of facilitating the transaction. I have a hard time believing that a fixed 0.25% has anything to do with the real costs. It doesn't appear that CoinBase is even making that argument.
- nurettin 12y ago
  I don't know much about basic market principles (by the looks of it they aren't very profitable for the host) but constant fee does make it easier to backtest automated trading strategies.
minimax 12y ago
(Thoughts from someone who works in this space) Exposing _all_ order entry traffic on the public market data feed is not great, especially the part where they expose client generated order uuids on the public feed. This allows market participants to potentially identify other market participants' orders based on their client order uuids e.g. if they are using a uuid generator that incorporates the MAC address. I think I understand why they are doing this. They want to have a clean REST order entry interface, but still allow participants to know immediately when they are filled (via the websockets feed). Ultimately, they should implement a websockets order entry interface and stream accepts, fills, cancels, and rejects only to the involved participants. They should not expose any client generated ids on the public feeds, and only non-marketable orders and trades should hit the public feed. This is how it works literally everywhere else. Also it wouldn't hurt to have time-in-force (IOC, etc) and support for non-displayed orders.
- mrchicity 12y ago
  Also if they're charging 25 bps to be a taker vs. 0 to make, people will want a post-only order. I actually like the idea of putting ClOrdIDs on the feed, maybe encrypted with some key only the sender has? Would make excluding one's own orders so much easier and no concerns about who sees what first: http://www.wsj.com/articles/SB10001424127887323798104578455032466082920 http://www.wsj.com/articles/SB100014241278873237981045784550...
  - benjaminjackman 12y ago
    Another option is to include the pricefeed order id in the order submit ack message sent on the order channel to the submitter.
    - mrchicity 12y ago
      Yes that's how things work on itch/ouch. Downside with that is you can see your order hit the feed before you know it's yours. For people who want to exclude their orders from their view of the market, they have to build heuristics to handle this case or risk flashing/chasing their own tail. Also doesn't help the IOC case. If market data dissemination is usually faster than the private order entry/ack/fill channel, it would be better to know that a trade resulted from my IOC by seeing it on the data feed rather than waiting.
ceejayoz 12y ago
I really hate these `position: fixed` left-hand navigations. On my Macbook everything after the "Market Data" section is below the scroll and can't be seen.
- kordless 12y ago
  They should collapse the subsections until you go to them.
claypoolb 12y ago
Ben Horowitz predicted on 11/19/14 that Bitcoin is going to be one (of two) of the next massive disruptors in technology. He compares Bitcoin with the revolutionary impact of the internet. It is gaining momentum. http://ecorner.stanford.edu/authorMaterialInfo.html?mid=3369 http://ecorner.stanford.edu/authorMaterialInfo.html?mid=3369
aristidb 12y ago
Nice to have a ASCII-based REST API, but they should also add a proper binary protocol, which does not involve HTTP. Mainly to reduce parsing and encoding times. (This is my personal and not my employer's opinion.)

94 points by mericsson 12y ago

Looks like this is the new Coinbase Lunar project being announced tomorrow. http://www.btcfeed.net/news/coinbases-lunar-announcement-analyzed-will-bitcoins-saviour/ http://www.btcfeed.net/news/coinbases-lunar-announcement-ana...

clarkmoody 12y ago

After having looked at dozens of Bitcoin exchange APIs, this one was a breath of fresh air. The only other respectable API out there belongs to Kraken [1]. [1] https://www.kraken.com/help/api https://www.kraken.com/help/api

artursapek 12y ago
Really? I've found Kraken's pretty hard to work with. They're inconsistent in some ways, like their currency pair names (sometimes "XXBTXZEUR", sometimes "XBTEUR"). Also, they are the only ones I've come across who don't just use plain old integers for ids - they have some weird scheme that has string ids formatted like O6W5EU-VY7YF-CS3XNP. That said, they're better than say BTC-e and OKCoin :)
- clarkmoody 12y ago
  The way Coinbase is doing the streaming WebSocket data looks very good. My frame of reference is Bitstamp and Mt. Gox before that... Keeping a proper copy of the order book on the client side should be fairly straightforward. Bitstamp's API makes it impossible to keep the full order book synced. They broadcast the top 20 rows over the socket, but for many situations that's not good enough.
  - functionCall 12y ago
    Bitstamp has a new websocket channel https://www.bitstamp.net/websocket/ https://www.bitstamp.net/websocket/ where you can get full order book updates.
    - clarkmoody 12y ago
      Excellent! Maybe one day and exchange will create a developer email list where they let people know when the API changes (Bitstamp has had an awful history of breaking the API without warning).
- drpancake 12y ago
  Kraken's API is pretty good when compared to the industry average. It's just a little bit whacky.
tlrobinson 12y ago
After having looked at dozens of Bitcoin exchange APIs For those who don't recognize the name, Clark ran one of the best Bitcoin exchange charts sites at bitcoin.clarkmoody.com (now part of ZeroBlock?)
drpancake 12y ago
Having integrated five other cryptocurrency exchanges, I echo this sentiment. I hope it sets the bar.
michaelgrosner2 12y ago
No way. Kraken doesn't even have a real-time feed. The best I've ever seen is HitBtc or Coinsetter. Those two are the closest to Wall Street grade APIs out there (demo environments, real-time API agnostic of protocol, colocation, etc). From a brief glance, this Coinbase exchange API is close.
functionCall 12y ago
I've just started to work with the Kraken API it is good. Their key signing/hashing auth is a little weird but the example clients are very useful. Is there a way to get real time order book updates from the Kraken? Another good API is Paymium's https://github.com/Paymium/api-documentation https://github.com/Paymium/api-documentation the most frustrating thing I find about exchanges API are race conditions when doing HFT, like submitting an order getting an ID, then asking about the ID to find it doesn't exist yet as the update hasn't be prorated yet.
mrchicity 12y ago
Polling is an awful API for market data, especially when the poll rate is limited. People end up gaming the system with multiple accounts and getting additional "peeks" into the order book. Maybe it doesn't matter for Bitcoin but it's a bad design for a serious exchange.
- clarkmoody 12y ago
  The API specifies how to poll once and use the streaming data feed to keep an accurate state of the order book on the client side. So it's not really a polled API, for serious clients.
  - jzwinck 12y ago
    Indeed. The WebSocket API is described here: https://docs.exchange.coinbase.com/#websocket-feed https://docs.exchange.coinbase.com/#websocket-feed
  - mrchicity 12y ago
    Thanks for the correction. You're right. If one of these guys provided a more traditional fix/itch/ouch setup, they might get more traction with traders who are already active in other currencies/products.

artursapek 12y ago

It looks like it's not running yet. I'm getting a Heroku "No such app" 404. https://api.exchange.coinbase.com/currencies/ https://api.exchange.coinbase.com/currencies/

sandGorgon 12y ago
heroku ? are they using rails here ? really interested to see what stack would somebody use to build a financial exchange and websockets

Animats 12y ago

Looks straightforward enough. They note that your trading 'bots should be running on Amazon AWS East for minimum latency. They're encouraging high frequency trading. Since they're coming up with zero fees, they may have huge 'bot volume. Then they can announce they are the biggest exchange.

zeeshanm 12y ago
Wouldn't be HFT enough until they pay for flow.
tlrobinson 12y ago
Heh, you could imagine Bitcoin HFT shops spinning up EC2 instances until they happen to get one close to Coinbase's. (I don't know AWS networking well enough to know if this would make much of a difference, or even if the overhead of the HTTP API wouldn't make the difference negligible)
- kordless 12y ago
  > could imagine I imagine they are already thinking about it. Affinity and HFT go hand in hand.
kasey_junk 12y ago
Given their maker/taker fee setup, they clearly are trying to attract liquidity providers, who definitely want to be able trade algorithmically. But, other technical choices make it clear that they are not targeting existing HFT firms. For instance, cloud based virtualized servers are unacceptable for HFT firms. Not being located at one of the "major" exchange data centers is a problem for most firms as well. Finally, building an http/json based proprietary api instead of a standards based one or a proprietary binary format is a clear signal that they are not targeting existing HFT firms.

jsprogrammer 12y ago

Why does an exchange, which is based on basic market principles and claims to incorporate a supply and demand (maker vs. taker) model, have a fixed rate vig on half the transactions? Shouldn't the vig float and have a mechanism which drives it towards zero?

DavidSJ 12y ago
As I understand it, it's not a fee that the maker receives, it's a fee CoinBase receives, i.e. it's their way of making profit off of this exchange. The mechanism which could drive it to zero is competition from other exchanges.
- jsprogrammer 12y ago
  I get that it's CoinBase's fee (vig). I'm having a hard time understanding where the fixed 0.25% fee comes from other than: fee = desired_profit / (expected_transaction_volume * expected_average_transaction_value)
  - jzwinck 12y ago
    So you think the fee to remove liquidity should "float" in what way exactly? With per-customer tiered volume discounts like many exchanges offer to customers who trade enough in a given month? Or when you said "float" did you mean it should be variable across the entire exchange over time, but the same for all customers at any given time?
    - jsprogrammer 12y ago
      Like any well functioning market, it should track the actual cost of goods, in this case, the actual cost of facilitating the transaction. I have a hard time believing that a fixed 0.25% has anything to do with the real costs. It doesn't appear that CoinBase is even making that argument.
nurettin 12y ago
I don't know much about basic market principles (by the looks of it they aren't very profitable for the host) but constant fee does make it easier to backtest automated trading strategies.

minimax 12y ago

(Thoughts from someone who works in this space) Exposing _all_ order entry traffic on the public market data feed is not great, especially the part where they expose client generated order uuids on the public feed. This allows market participants to potentially identify other market participants' orders based on their client order uuids e.g. if they are using a uuid generator that incorporates the MAC address. I think I understand why they are doing this. They want to have a clean REST order entry interface, but still allow participants to know immediately when they are filled (via the websockets feed). Ultimately, they should implement a websockets order entry interface and stream accepts, fills, cancels, and rejects only to the involved participants. They should not expose any client generated ids on the public feeds, and only non-marketable orders and trades should hit the public feed. This is how it works literally everywhere else. Also it wouldn't hurt to have time-in-force (IOC, etc) and support for non-displayed orders.

mrchicity 12y ago
Also if they're charging 25 bps to be a taker vs. 0 to make, people will want a post-only order. I actually like the idea of putting ClOrdIDs on the feed, maybe encrypted with some key only the sender has? Would make excluding one's own orders so much easier and no concerns about who sees what first: http://www.wsj.com/articles/SB10001424127887323798104578455032466082920 http://www.wsj.com/articles/SB100014241278873237981045784550...
- benjaminjackman 12y ago
  Another option is to include the pricefeed order id in the order submit ack message sent on the order channel to the submitter.
  - mrchicity 12y ago
    Yes that's how things work on itch/ouch. Downside with that is you can see your order hit the feed before you know it's yours. For people who want to exclude their orders from their view of the market, they have to build heuristics to handle this case or risk flashing/chasing their own tail. Also doesn't help the IOC case. If market data dissemination is usually faster than the private order entry/ack/fill channel, it would be better to know that a trade resulted from my IOC by seeing it on the data feed rather than waiting.

ceejayoz 12y ago

I really hate these `position: fixed` left-hand navigations. On my Macbook everything after the "Market Data" section is below the scroll and can't be seen.

kordless 12y ago
They should collapse the subsections until you go to them.

claypoolb 12y ago

Ben Horowitz predicted on 11/19/14 that Bitcoin is going to be one (of two) of the next massive disruptors in technology. He compares Bitcoin with the revolutionary impact of the internet. It is gaining momentum. http://ecorner.stanford.edu/authorMaterialInfo.html?mid=3369 http://ecorner.stanford.edu/authorMaterialInfo.html?mid=3369

aristidb 12y ago

Nice to have a ASCII-based REST API, but they should also add a proper binary protocol, which does not involve HTTP. Mainly to reduce parsing and encoding times. (This is my personal and not my employer's opinion.)