Coinbase – Exchange API
docs.exchange.coinbase.com
docs.exchange.coinbase.com
The only other respectable API out there belongs to Kraken [1].
That said, they're better than say BTC-e and OKCoin :)
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.
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).
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?)
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 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.
So it's not really a polled API, for serious clients.
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.
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.
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/SB100014241278873237981045784550...
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.
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
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...
2: http://www.cftc.gov/ucm/groups/public/@newsroom/documents/fi...
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.
(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)
I imagine they are already thinking about it. Affinity and HFT go hand in hand.
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.
fee = desired_profit / (expected_transaction_volume * expected_average_transaction_value)
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.
really interested to see what stack would somebody use to build a financial exchange and websockets
(This is my personal and not my employer's opinion.)