Contents


Contact Us

This MVP is designed to be a test of our infrastructure and design, and so we encourage feedback and bug reporting. The MVP was created by Jay Taylor and Rayman Tang, and you can contact us by our emails:

[email protected]

[email protected]

Email us any questions/feedback regarding the MVP or GDA.

Overview

This is a user guide for how to connect to the L3 Atom MVP web socket, as well as how requests should be formatted and how responses should be interpreted. This MVP collects, normalizes, and disseminates data from a variety of different sources, which are:

11 Centralised Exchanges

2 Decentralised Exchanges

Endpoint

Public websocket endpoint: ws://194.233.73.248:30205/

Requests

Request format:

{"op": "<value>", "topic": "<value">}

where "op" is either "subscribe" or "unsubscribe". The topic is either a symbol or an exchange, where the former retrieves the normalized data for all exchanges that provide information for that symbol, and the latter retrieves the raw data from the given exchange.

The topic value is case-sensitive. If you want to subscribe to an exchange, use all lower case e.g: "binance". For a trading pair symbol, use all upper case e.g: "BTCUSD".

For example,

{"op": "subscribe", "topic": "BTCUSD"}

Would subscribe to a channel that receives normalised data for spots trading between BTC and USD, and

{"op": "subscribe", "topic": "binance"}

Would subscribe to a channel that retrieves raw data as provided by Binance. Futures topics are subscribed to in the format

{"op": "subscribe", "topic": "<symbol>-PERPETUAL"}

For example, to subscribe to the BTC/USD perpetual futures channel, the message you would send would be

{"op": "subscribe", "topic": "BTCUSD-PERPETUAL"}

Responses

Raw Data

Raw data from exchanges are structured according to the exchange’s own schemas, and so refer to the individual exchange API documentations for information on how to interpret the raw data.

Normalised Data

Data retrieved via the normalised data sources have a standardised format, which will be outlined below. Wherever data is -1, assume that it means a null value.

Lob Updates

Limit order book updates are sent in the following format:

Response

Sample response from the normalised channels for a limit order book update event:

{
  "quote_no": 12096753,
  "event_no": 14353371,
  "order_id": 11078635,
  "original_order_id": -1,
  "side": 1,
  "price": 44208,
  "size": 0.1193,
  "lob_action": 4,
  "event_timestamp": -1,
  "send_timestamp": 1644965507631,
  "receive_timestamp": 1644965507643,
  "order_type": 0,
  "is_implied": -1,
  "order_executed": 0,
  "execution_price": -1,
  "executed_size": -1,
  "aggressor_side": -1,
  "matching_order_id": -1,
  "old_order_id": -1,
  "trade_id": -1,
  "size_ahead": 374.42,
  "orders_ahead": 1687
}

For rebuilding an aggregated order book, only consider events with lob_update s of 2,3, or 4.

Market Orders

Whenever a market order is recorded, another message is sent with details of that market order.

Response

Sample response from the normalised for a new trade that occurred between two orders (market order):

{
	"order_id": 57394857345,
	"price": 433019,
	"trade_id": 63489534,
	"timestamp": 96780249586704567,
	"side": 2,
	"size": 0.023,
	"msg_original_type": "match"
}

Data is streamed in real-time as updates occur on the exchanges.