
Coinbase – Exchange API - mericsson
https://docs.exchange.coinbase.com/
======
clarkmoody
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
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
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
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
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).

------
minimax
(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.

~~~
benjaminjackman
I have not rwad the article but from what you are describing it sounds like
they probably should just use itch.

I think anonymity in markets might be something we should experiment with
getting rid of. Doing that right is hard because it is difficult to prevent
sock-puppetry-spoofing which would require regulations and penalties for rat
hole order shredding.

So order anonymity is 'easier'. But now the exchange has to deal with
spoofers. Or not. but they must be explicit about their policy with regards to
spoofing and rigoursly and rapidly enforce that policy. If they are not they
create a syatem where some participants will break the rules to gain advantage
and others will follow them and suffer. And allowing spoofing might be a
violation of dodd-frank (i am not sure if this exchange implicitly falls under
its scope or not) so again, some participants might feel to play it safe while
others wont have such qualms.

Atleast using an order based feed makes it easier to track bogus orders which
increases the difficulty for spoofers vs motivated play by the rules dont
commit hundreds of felonies per day liquidity providers.

Trading ...ugh

~~~
minimax
Orders should be anonymous or explicitly attributed. What I'm taking issue
with is the grey zone coinbase has created where you are mostly anonymous but
you might be leaking some identifying information via public client order ids.
If they want identities to be public they could make it explicit via explicit
market participant IDs.

~~~
benjaminjackman
I understand, I am just pointing out the ultimate situation the exchange
arrives in once they (hopefully) patch up the vulnerability you described.

Making parties known via explicit market ids leaves them open to spoofers
gaming that process and finding other people to sign up and shred their orders
across a pool of ids the spoofer controls. (what I refer to as rat-holing and
has been done here [1]). Note that even if a participant doesn't rat-
hole/shred their orders doesn't preclude them from spoofing, it just makes it
less profitable to do so, and easier for advanced counterparty's to track and
recognize bad reputation of a spoofer.

Not making it explicit allows spoofers to trivially run their algorithms
without having to rat-hole/shred so it lowers the barrier to entry for
spoofers and blends their orders in among the non-spoof orders resting in the
book making their strategies more effective.

In any case spoofing is a felony because of dodd-frank. [2]

The only question that remains is does this exchange fall under the scope of
dodd-frank's provisions against disruptive practices? What will they do to
ensure that spoofing doesn't take place on their exchange? The law doesn't
contemplate an exchanges ability to opt-out of this provision. If they are
running an exchange that allows people to spoof they could be seen as allowing
those felonies to occur through indifference because it generates volume and
hence makes them more money, making them an accessory to the crime. In any
case someone will need to enforce the provision on their exchange otherwise a
perverse moral hazard is created where some participants are willing to risk
breaking the law because the worst they will expect is a slap on the wrist,
while those that do follow the law are at a severe informational disadvantage.

1: [http://www.fbi.gov/chicago/press-releases/2014/high-
frequenc...](http://www.fbi.gov/chicago/press-releases/2014/high-frequency-
trader-indicted-for-manipulating-commodities-futures-markets-in-first-federal-
prosecution-for-spoofing)

2:
[http://www.cftc.gov/ucm/groups/public/@newsroom/documents/fi...](http://www.cftc.gov/ucm/groups/public/@newsroom/documents/file/disruptive_factsheet.pdf)

------
Animats
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.

~~~
tlrobinson
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
> could imagine

I imagine they are already thinking about it. Affinity and HFT go hand in
hand.

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

------
ceejayoz
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
They should collapse the subsections until you go to them.

------
jsprogrammer
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
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
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
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
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.

------
artursapek
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
heroku ? are they using rails here ?

really interested to see what stack would somebody use to build a financial
exchange and websockets

------
aristidb
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.)

