BTP Overview

Bitnomial Transfer Protocol (BTP) is the Exchange's low latency, direct market access, binary protocol for order entry and price feeds. Messages are made up of a standardized binary header and body. The header describes how the body is encoded.

Types

Numerical fields are little endian byte order.

  • char: 1 byte ASCII character.
  • byte[]: An array of bytes.
  • uint: Unsigned 2, 4, or 8 byte little endian integer depending on field's byte length.
  • int: Signed 2, 4, or 8 byte little endian integer depending on field's byte length.
Byte OffsetByte LengthTypeNameDescription
02byte[]protocolIdASCII string BT for "Bitnomial Transfer Protocol".
22uint16versionBTP protocol version. See Version
44uint32sequenceIdMonotonically incremented message number per sender. See Sequence ID
82byte[]bodyEncodingASCII string for body encoding. See Body Encoding
102uint16bodyLengthLength, in bytes, of the following message body.
12

Sequence ID

Sequence IDs sequentially identify each message in a single direction of a connection. Sequence IDs are monotonically incremented so repeat sequence IDs identify a duplicate message while a gap identifies missed messages. Sequence IDs start at 1 for disambiguation with NULL. If an invalid Sequence ID fault is detected the connection is disconnected with a Disconnect message.

For example, a Login Request, as the first message in the stream, must have a Sequence ID of 1. Subsequent messages must monotonically increment the Sequence ID.

Body Encoding

The body encoding describes how to parse the body of the BTP message and may have the following values:

Version

  • BTP Version 3

Versions will be updated according to the following guidelines:

  • Breaking Changes
    • Updated or deleted messages
    • Updated/Added fields
    • Any header change
  • Non-Breaking Changes
    • New message types (clients should skip ahead by body length when they find an unexpected message type)

Additionally, all BTP services are versioned together. So, for example, it would not be valid for the Gateway to have version 2 while the Pricefeed is on version 3.

The BTP version can be set to a future version for User Acceptability Testing. Connected sessions cannot mix different versions, the version set in the Login message must be used for all subsequent connection messages. Details of new protocol versions can be read in Upcoming Changes.

Heartbeat Message

Heartbeat messages are sent and expected to be received every heartbeatInterval (See Login Request) if no other messages have been sent within the interval. Connections are disconnected with a Disconnect Message if a heartbeat is not received in the interval period.

All BTP connections must send and receive heartbeat messages. Heartbeat messages must always be of the following form:

FieldValue
sequenceId0
bodyLength0
BodyAlways Empty

Disconnect Message

An order entry gateway or pricefeed may disconnect a connection at any time for the following disconnect Disconnect Reasons.

Byte OffsetByte LengthTypeNameDescription
01uint8disconnectReasonSee Disconnect Reason
14uint32expectedSequenceIdSequence ID expected to see next, NULL if not a sequence ID fault.
54uint32actualSequenceIdSequence ID actually received, NULL if not a sequence ID fault.
9

Disconnect Reason

ValueReason
0x01Sequence ID fault
0x02Heartbeat fault
0x03Unused (reserved)
0x04Messaging rate exceeded (reserved)
0x05Failed to parse message

Start Trading

Trade US Perpetual Futures, Physical Futures, and Options on the Bitcoin Complex®, XRP, ETH, SOL, and more.