Introduction
These are the messages that can be sent and received for market data. For a reference for all FIX tags, see FIXimate
Survey
Please complete our API Use Survey to help us improve your experience using the Gemini APIs.
FIX Dictionary
Gemini uses FIX 4.4 with the 20030618 errata.
Of particular note if you may be using an older dictionary:
Tag | Field | Value | Notes |
---|---|---|---|
234 | StipulationValue |
FIX enum but should allow other values. Compatible with Errata 20030618 Vol 6 - see p. 86. |
Custom tags
Tag | Field | Type | Notes |
---|---|---|---|
9000 | RiskLiquidityFlag |
Boolean | Used in NewOrderSingle <D> Indicates whether or not the order should match against Liquidation Orders sent from the Liquidation Engine. Only allowed from permissioned Market Makers. |
9001 | CancelOnDisconnect |
Boolean | Used in Logon <A> to enable or disable session-level cancel on disconnect. |
9002 | MDEntryMakerSide |
Char | Used in Market Data - Incremental Refresh <X> MDEntry groups when MDEntryType had the value 2 = Trade to indicate the maker side of a trade. See Examples: Request to enable maker side on trades. |
9003 | EnableMDEntryMakerSide |
Boolean | Used in Market Data Request <V> to optionally enable showing custom field 9002 MDEntryMakerSide in Market Data - Incremental Refresh <X> messages when MDEntryType had the value 2 = Trade . See Examples: Showing Maker Side For Trades. |
9009 | MDEntryFundingIsRealized |
Boolean | Used in Market Data - Incremental Refresh <X> MDEntry groups when MDEntryType had the value S = Funding Amount to indicate the IsRealized field of Funding Amount. |
9008 | EventId |
Int | Used in Market Data - Incremental Refresh <X> to specify the event associated with the update. This is for information only and may not be used to form a business logic. See Examples: market data responses send to clients. |
Download
For your convenience, Gemini maintains our custom dictionary in QuickFIX XML form:
Environment | File |
---|---|
Production | https://docs.gemini.com/files/gemini-fix-dictionary.xml.zip |
Sandbox | https://docs.sandbox.gemini.com/files/gemini-fix-dictionary.xml.zip |
Connecting
Gemini's primary trading platform and network point of presence (PoP) is housed in the Equinix NY5 data center in Secaucus, New Jersey. Customers can cross connect from their NY2/NY4/NY5 infrastructure or leverage an approved extranet provider to access Gemini production Market Data feeds, Drop Copy, and Order Entry sessions.
We are also nearing completion of a PoP in Equinix CH3 which will be available via cross connects from the Equinix family of data centers in Chicago and approved extranet providers.
Steps to get connected to our FIX infrastructure:
Complete Account Verification
If your firm has not done so already, please complete the Institutional Account Verification Process
Get connected
Once on-boarded as a Gemini customer, email connectivity@gemini.com with a brief description of your business and your preferred connectivity method. There are 3 options for production FIX connectivity to Gemini:
Cross-connect
For customers with applications in the same data center as Gemini. If you would like to cross-connect, please include the legal entity name that we should include in our LOA (letter of authorization).
Extranet connectivity
Customers who are not in the Equinix family of data centers can leverage an extranet provider to connect to Gemini. If your firm wishes to leverage an extranet provider or third party to connect, please specify that in your email including the providers name.
Third Party Order Management System Provider
There are a number of Service providers that allow Gemini customers to leverage their trading platforms to connect to Gemini for trading. If you would like to cross-connect, please include the legal entity name that we should include in our LOA (letter of authorization). If your firm wishes to leverage an extranet provider or third party to connect, please specify that in your email including the providers name.
Sandbox and Testing
Gemini operates a Sandbox environment which acts as a replica of our production environment. Gemini strongly recommends that all FIX customers create a Sandbox account to test their workflows. Please follow these steps to get a FIX Sandbox environment setup:
Setup a Sandbox Account
Create a Sandbox account by going to: https://sandbox.gemini.com
Permission Your Test IP
E-mail connectivity@gemini.com and specify the email address used to setup your Sandbox account and the Source IP that you will be using to connect to the FIX Sandbox. We will respond back once the IP addresses have been enabled. We will also provide you with the Sender and Target CompId that should be used to connect to the test environment.
Test Your Workflow Thoroughly
Test all messaging workflows specified in our FIX API documentation. (Gemini currently only supports FIX 4.4)
Workflow
After connecting and logging on, the client can either request a symbol list or subscribe to market data.
Gemini does not resend messages on a market data channel. Instead, Gemini will send a Sequence Reset <4> message with GapFillFlag <123> field set to Y
and the new sequence number in the MsgSeqNum <34> field.
Symbol list
Optional: Gemini offers a symbol list that supplies the definitive list of symbols traded on the exchange.
- Client sends a Symbol List Request <x>
- Gemini responds with a Symbol List <y>
Market data subscription
After connecting to the market data channel, the client subscribes to market data by sending a Market Data Request <V> message.
When a client disconnects for any reason, the market data subscription is terminated. Upon reconnecting, the client needs to send another Market Data Request <V> message.
- Client sends a Market Data Request <V>
- Gemini responds by sending one Market Data - Snapshot/Full Refresh <W>
- As bids, offers, and trades happen on the exchange, Gemini sends Market Data - Incremental Refresh <X> messages
Precision on the exchange
Quantity and price on incoming orders are strictly held to the minimums and increments on the table shown above.
However, once on the exchange, quantities and notional values may exhibit additional precision down to two decimal places past the "minimum order increment" listed above. For instance, it is possible that a btcusd
trade could execute for a quantity of 0.0000000001 (1e-10) BTC. This is due to:
- incoming market orders that may result in partial fills
- fees
- holds
This additional precision is marketable once on the exchange.
Your account balances are maintained to full fractional precision in each currency.
Understanding price and quantity
In a Market Data - Incremental Refresh <X> message, the MDEntryPx <270> field is denominated in USD and the MDEntrySize <271> field is denominated in BTC.
RAW
8=FIX.4.4|9=122|35=X|34=41|49=GEMINI|52=20160217-18:07:26.581|56=CLIENT|262=TestMDReqID_1|268=1|279=0|269=0|55=BTCUSD|270=300.43|271=0.57|10=070|
HEADER
8 BeginString: FIX.4.4
9 BodyLength: 122
34 MsgSeqNum: 41
35 MsgType: MarketDataIncrementalRefresh (X)
49 SenderCompID: GEMINI
52 SendingTime: 20160217-18:07:26.581
56 TargetCompID: CLIENT
BODY
262 MDReqID: TestMDReqID_1
NoMDEntries: count = 1
55 Symbol: BTCUSD
269 MDEntryType: BID (0)
270 MDEntryPx: 419.02
271 MDEntrySize: 9.50
279 MDUpdateAction: NEW (0)
TRAILER
10 CheckSum: 070
Currency-based messages and fields
-
- Message
- Fields denominated in price currency
- Fields denominated in quantity currency
Identifiers
Client supplied FIX identifier field values must contain between at least one and up to one hundred allowed characters.
Any exchange-bound message containing an invalid identifier will be rejected.
Allowed characters
Client supplied identifier values should match against this PCRE regular expression: [:\-_\.#a-zA-Z0-9]{1,100}
.
Characters | Description | ASCII Codes (Dec) |
---|---|---|
A-Z |
Uppercase A-Z | 65 - 90 |
a-z |
Lowercase a-z | 97 - 122 |
0-9 |
Digits | 48 - 57 |
# |
Hash, octothorpe, number sign | 35 |
- |
Hyphen | 45 |
. |
Period | 46 |
: |
Colon | 58 |
_ |
Underscore | 95 |
Client supplied identifiers
-
- Tag
- Name
- Defined in
- Echoed back
- Description
-
- 320
- SecurityReqID
- Symbol List Request <x>
- Symbol List <y>
- The client's symbol list request identifier. Gemini does not enforce uniqueness although the FIX protocol recommends it.
-
- 262
- MDReqID
- Market Data Request <V>
-
The client's market data request identifier. Gemini requires uniqueness per active FIX session.
A Market Data Request <V> messages with a duplicate MDReqID <262> value during the current active FIX session will be rejected using a Market Data Request Reject <Y> with the MDReqRejReason <281> field set to1
= Duplicate MDReqID <262>.
Identifiers assigned by Gemini
Market data messages do not have any identifiers assigned by Gemini.
Standard header
The Standard Header is required on every message.
PossResend <97> is not supported. Gemini will report the last sequence number that the exchange received in the header of the Logon <A> message. The client should assume that any events that the server requests to be replayed have not been acted upon: see Beginning a session for details.
-
- Tag
- Name
- Req
- Description
-
- 8
- BeginString
- Y
- Identifies the beginning of new message and protocol version. Always the first tag in the message.
Valid value:- FIX.4.4
-
- 9
- BodyLength
- Y
- Message length, in bytes, forward to the CheckSum <10> field. Always the second tag in the message.
-
- 35
- MsgType
- Y
- Defines message type. Always the third tag in the message.
-
- 34
- MsgSeqNum
- Y
-
- 49
- SenderCompID
- Y
- Assigned value used to identify the firm sending the message.
-
- 43
- PossDupFlag
- N*
- Indicates possible retransmission of message with this sequence number.
Valid values:- Y = Possible duplicate
- N = Original transmission
*Required for a re-transmitted message.
-
- 52
- SendingTime
- Y
- Time of message transmission (always expressed in UTC).
-
- 56
- TargetCompID
- Y
- Assigned value used to identify the firm receiving the message.
-
- 115
- OnBehalfOfCompID
- N*
- Assigned value used to identify firm originating message if the message was delivered by a third party such as an OMS or OEMS: required when an OMS/OEMS submits or cancels orders on behalf of another Gemini account.
- Not used or supported in Market Data or single party Order Entry or Drop Copy
- Third party order entry header usage as follows:
- the customer's Gemini account identifier is used in the OnBehalfOfCompID <115> field
- the third party firm identifier is used in the SenderCompID <49> field
- See Order Entry: Third Party Support for further details.
- Third party support for Drop Copy does not use OnBehalfOfCompID <115> in the header - see Drop Copy: Third Party Support for details.
-
- 128
- DeliverToCompID
- N*
- Used in Execution Reports only.
- Not used or supported in Market Data or single party Order Entry or Drop Copy
- The customer's Gemini account identifier is returned in the DeliverToCompID <128> field on Execution Reports
- Third party support for Drop Copy does not use DeliverToCompID <128> in the header - see Drop Copy: Third Party Support for details.
-
- 122
- OrigSendingTime
- N*
- Original time of message transmission (always expressed in UTC) when transmitting orders as the result of a resend request.
*Required for a re-transmitted message.
Standard Trailer
The Standard Trailer is required on every message.
-
- Tag
- Name
- Req
- Description
-
- 10
- CheckSum
- Y
- Three byte, simple checksum. Always the last tag in the message.
Session-Level Messages
Establishing a connection
- Client sends server → Logon <A> message
- Is client ResetSeqNumFlag <141> to
Y
?- Yes, reset sequence numbers and proceed
- server resets next expected client sequence number
- server resets its own sequence number
- server responds with ← Logon <A> message with reset sequence number
- client sends server → Heartbeat <0>
- No, negotiate sequence numbers on both sides
- Is client MsgSeqNum <34> value what the server is expecting?
- No, value is greater than expected
- server responds with ← Logon <A> message
- server sends client ← Resend Request <2>
- client sends server → Sequence Reset <4> (GapFillFlag <123> =
Y
)
- No, value is less than expected
- server disconnects
- after checking what happened, client re-sends Logon <A> message with ResetSeqNumFlag <141> field set to
Y
- Otherwise
- server sends client ← Heartbeat <0>
- No, value is greater than expected
- Is server MsgSeqNum <34> value what the client is expecting?
- No, value is greater than expected
- server responds with ← Logon <A> message
- client sends server → Resend Request <2>
- replay from server to client proceeds
- server responds with ← message PossDupFlag <43> =
Y
- …
- server responds with ← message PossDupFlag <43> =
Y
- replay from server to client is complete
- server responds with ← Heartbeat <0>
- No, value is less than expected
- client disconnects or sends server → Logout <5>
- Gemini coordinates with the client to triage so the FIX connection can be re-established
- Otherwise
- client sends server → Heartbeat <0>
- No, value is greater than expected
- Is client MsgSeqNum <34> value what the server is expecting?
- Yes, reset sequence numbers and proceed
- Success! Your FIX connection is established.
When can sequence numbers be reset?
Gemini runs the server side of the FIX connection ("acceptor"). Gemini never resets sequence numbers on the server side during the logon workflow unless the client explicitly requests it.
The client ("initiator") can reset sequence numbers during Logon <A> by setting ResetSeqNumFlag <141> to Y
.
Gemini recommends that client consider configuring the FIX initiator to automatically reset sequence numbers under the following conditions:
- logon
- logout
- disconnect
- error
While synchronizing sequence numbers after a replay, the client may send a Sequence Reset <4> with GapFillFlag <123> = Y
in lieu of a replay.
Ending a connection
The client may send the server an optional Logout <5> message but the exchange will not interpret its absence as being an abnormal condition.
Under certain conditions, the server may send the client a Logout <5> message where the Text <58> field contains the reason, such as scheduled maintenance.
Logon <A>
The Logon <A> message must be the first message sent by the application requesting to initiate a FIX session. The Logon <A> message authenticates an institution establishing a connection to Gemini.
Upon receipt of a Logon <A> message, Gemini will authenticate the institution requesting connection by validating the source IP Address, SenderCompID <49>, and TargetCompID <56> identifying the institution. The server will then issue a Logon <A> message as acknowledgment that the connection request has been accepted. The acknowledgment Logon <A> can also be used by the institution to validate that the connection was established with the correct party. If validation fails, the connection will be dropped without a Reject <3>.
-
- Tag
- Name
- Req
- Description
-
- Standard Header
- Y
- MsgType = A
-
- 141
- ResetSeqNumFlag
- N
- Should be set to
Y
when the client wants to indicates that the both sides of the FIX session should reset sequence numbers.
-
- 98
- EncryptMethod
- Y
- Gemini does not support encryption.
Valid value:- 0 = None
- 108
- HeartBtInt
- Y
Heartbeat interval in seconds. Valid value:
- 30 = 30 seconds
- 9001
- CancelOnDisconnect
- N
Only used for Order Entry. When present and true, orders will be cancelled on disconnect. When present and false, orders will not be cancelled on disconnect. When absent, orders will not be cancelled on disconnect. Valid value:
- Y = Enable cancel on disconnect for this session
- N = Disable cancel on disconnect for this session
Heartbeat <0>
The Heartbeat <0> monitors the status of the communication link and identifies when the last of a string of messages was not received. The only supported heartbeat interval, as specified by the Logon <A> message, is 30 seconds.
When either end of a FIX connection has not sent any data for HeartBtInt <108> seconds, it will transmit a Heartbeat <0> message. When either end of the connection has not received any data for (HeartBtInt <108> + "some reasonable transmission time") seconds, it will transmit a Test Request <1> message. If there is still no Heartbeat <0> message received after (HeartBtInt <108> + "some reasonable transmission time") seconds then the connection should be considered lost and corrective action be initiated.
Note that a Test Request <1> message can still be sent independent of the value of the HeartBtInt <108>, which will force a Heartbeat <0> message.
Heartbeats issued as the result of Test Request <1> must contain the TestReqID <112> transmitted in the Test Request <1> message. This is useful to verify that the Heartbeat <0> is the result of the Test Request <1> and not as the result of a regular timeout.
-
- Tag
- Name
- Req
- Description
-
- Standard Header
- Y
- MsgType = 0
-
- 112
- TestReqID
- N*
- Required when the heartbeat is the result of a Test Request (1) message
Test Request <1>
The Test Request <1> message forces a heartbeat from the opposing application. The Test Request <1> message checks sequence numbers or verifies communication line status. The opposite application responds to the Test Request <1> with a Heartbeat <0> containing the TestReqID <112>.
The TestReqID <112> verifies that the opposite application is generating the heartbeat as the result of Test Request <1> and not a normal timeout. The opposite application includes the TestReqID <112> in the resulting Heartbeat <0>. Any string can be used as the TestReqID <112> (one suggestion is to use a timestamp string).
-
- Tag
- Name
- Req
- Description
-
- Standard Header
- Y
- MsgType = 1
- 112
- TestReqID
- Y
- Identifier included in Test Request <1> message to be returned in resulting Heartbeat <0>
Resend Request <2>
The resend request is sent by the receiving application to initiate the retransmission of messages. This function is utilized if a sequence number gap is detected, if the receiving application lost a message, or as a function of the initialization process.
The resend request can be used to request a single message, a range of messages or all messages subsequent to a particular message.
Note: the sending application may wish to consider the message type when resending messages; e.g. if a new order is in the resend series and a significant time period has elapsed since its original inception, the sender may not wish to retransmit the order given the potential for changed market conditions. (The Sequence Reset <4> - Gap Fill message is used to skip messages that a sender does not wish to resend.)
Note: it is imperative that the receiving application process messages in sequence order, e.g. if message number 7 is missed and 8-9 received, the application should ignore 8 and 9 and ask for a resend of 7-9, or, preferably, 7-0 (0 represents infinity). This latter approach is strongly recommended to recover from out of sequence conditions as it allows for faster recovery in the presence of certain race conditions when both sides are simultaneously attempting to recover a gap.
- To request a single message: BeginSeqNo <7> = EndSeqNo <16>
- To request a range of messages: BeginSeqNo <7> = first message of range, EndSeqNo <16> = last message of range<
- To request all messages subsequent to a particular message: BeginSeqNo <7> = first message of range, EndSeqNo <16> = 0 (represents infinity) .
-
- Tag
- Name
- Req
- Description
-
- Standard Header
- Y
- MsgType = 2
-
- 7
- BeginSeqNo
- Y
-
- 16
- EndSeqNo
- Y
Reject <3>
Gemini sends a Reject <3> message when a message is received but cannot be properly processed due to a session-level rule violation. A reject is typically a serious error in the trading application's session logic. A session reject would also be generated if client message rate has exceeded the allocated throttle.
-
- Tag
- Name
- Req
- Description
-
- Standard Header
- Y
- MsgType = 3
-
- 45
- RefSeqNum
- Y
- MsgSeqNum <34> of the rejected message.
-
- 58
- Text
- N
- Explanation for rejection
-
- 371
- RefTagID
- N
- The tag number of the FIX field being referenced.
-
- 372
- RefMsgType
- N
- The MsgType <35> of the rejected message.
-
- 373
- SessionRejectReason
- N
- Code to identify the reason for the Reject <3> message.
Valid values:- 0 = Invalid tag number
- 1 = Required tag missing
- 2 = Tag not defined for this message type
- 3 = Undefined Tag
- 4 = Tag specified without a value
- 5 = Value is incorrect (out of range) for this tag
- 6 = Incorrect data format for value
- 10 = SendingTime <52> accuracy problem
- 11 = Invalid MsgType <35>
- 99 = Other
Sequence Reset <4>
The Sequence Reset <4> message is used in response to a Resend Request <2> message when one or more messages must be skipped over for the following reasons:
- During normal resend processing, the sending application may choose not to send a message (e.g. an aged order).
- During normal resend processing, a number of administrative messages are skipped and not resent (such as Heartbeat <0> and Test Request <1>).
Gemini does not support Reset mode (GapFillFlag <123> not present or equal to N
).
-
- Tag
- Name
- Req
- Description
-
- Standard Header
- Y
- MsgType = 4
-
- 36
- NewSeqNo
- Y
- New sequence number. The receiver should expect this to be the sequence number of the following message.
-
- 123
- GapFillFlag
- Y
- Indicates that the sender is skipping messages rather than resending them.
Valid value:- Y = Gap Fill message
Logout <5>
The Logout <5> message initiates or confirms the termination of a FIX session.
-
- Tag
- Name
- Req
- Description
-
- Standard Header
- Y
- MsgType = 5
-
- 58
- Text
- N
- Reason for logging out.
Business Message Reject <j>
Gemini sends Business Message Reject <j> when the exchange receives a valid FIX message which cannot be processed.
Examples include:
- receiving a market data request on an order entry channel, or vice versa
Gemini does not use Business Message Reject <j> to handle invalid New Order Single <D> messages. Rejected orders are handled with an Execution Report <8> message with an OrdStatus <39> field with a value of 8 - Rejected
.
-
- Tag
- Name
- Req
- Description
-
- Standard Header
- Y
- MsgType = j
-
- 45
- RefSeqNum
- Y
- MsgSeqNum <34> of the rejected message.
-
- 58
- Text
- N
- Explanation for rejection.
-
- 372
- RefMsgType
- N
- MsgType <35> of the rejected message.
-
- 379
- BusinessRejectRefID
- N
- The value of the business level ID field being referenced.
-
- 380
- BusinessRejectReason
- Y
- Code to identify the reason for the Business Message Reject <j> message
Valid values:- 0 = Other
- 1 = Unknown ID
- 2 = Unknown Security
- 3 = Unsupported Message Type
- 4 = Application not available
- 5 = Conditionally Required Field Missing
Exchange-Bound Messages
Symbol List Request <x>
A Symbol List Request <x> returns a Symbol List <y> response containing the symbols traded on the exchange.
See Examples: Request for the symbol list for sample requests and responses.
-
- Tag
- Name
- Req
- Description
-
- Standard Header
- Y
- MsgType = x
-
- 320
- SecurityReqID
- Y
- Unique identifier of this request.
-
- 559
- SecurityListRequestType
- Y
- The type/criteria of the request.
Valid value:- 0 = Symbol
Market Data Request <V>
Subscribes the current session to a Market Data - Snapshot/Full Refresh <W> followed by zero or more Market Data - Incremental Refresh <X> messages.
See Examples: Market Data Requests for sample requests and responses.
-
- Tag
- Name
- Req
- Description
-
- Standard Header
- Y
- MsgType = V
-
- 262
- MDReqID
- Y
- Unique identifier of the market data request. Uniqueness must be guaranteed by the institution for the duration of the connection to the market data channel.
-
- 263
- SubscriptionRequestType
- Y
- Indicates what type of response is expected.
Valid value:- 1 = Snapshot + Updates (Subscribe)
-
- 264
- MarketDepth
- Y
- Depth of the book to receive snapshot and updates for.
Valid values:- 0 = Full Book
- 1 = Top of Book
-
- 267
- NoMDEntryTypes
- Y
- Number of MDEntryType <269> fields requested
-
- => 269
- MDEntryType
- Y
- Type of market data entry to receive snapshots and updates for.
Valid values:- 0 = Bid
- 1 = Offer
- 2 = Trade
- R = MarkPrice
- S = FundingAmount
-
- 146
- NoRelatedSym
- Y
- Number of symbols requested.
-
- => 55
- Symbol
- Y
- Market data symbol requested.
See Security List <y> for a list of supported symbols.
-
- 9003
- EnableMDEntryMakerSide
- N
- Optional custom field to enable showing MDEntryMakerSide <9002> in Market Data - Incremental Refresh
messages when MDEntryType <269> had the value 2 = Trade
. See Examples: Request to enable maker side on trades.
-
- 9009
- MDEntryFundingIsRealized
- N
- Optional custom field used in Market Data - Incremental Refresh <X> MDEntry groups when MDEntryType had the value
S = Funding Amount
to indicate the IsRealized field of Funding Amount.
Client-Bound Messages
Symbol List <y>
A Symbol List <y> is the response containing the list of symbols specified in a Symbol List Request <x>.
See Examples: Request for the symbol list for sample requests and responses.
-
- Tag
- Name
- Req
- Description
-
- Standard Header
- Y
- MsgType = y
-
- 320
- SecurityReqID
- Y
- Unique identifier of the Symbol List Request <x> that solicited this response.
-
- 322
- SecurityResponseID
- Y
- Identifier for this message.
- 560
- SecurityRequestResult
- Y
The result of this request. Valid values:
- 0 = Valid Request
- 1 = Invalid Request
- 146
- NoRelatedSym
- Y
- Specifies the number of returned symbols.
- => 55
- Symbol
- Y
- Symbol of exchange-traded order book pair.
Market Data - Snapshot / Full Refresh <W>
The initial response to a Market Data Request <V> is a full snapshot of current state followed by multiple Market Data - Incremental Refresh <X> messages.
-
- Tag
- Name
- Req
- Description
-
- Standard Header
- Y
- MsgType = W
-
- 262
- MDReqID
- Y
- Unique identifier of the Market Data Request <V> this message is in response to.
-
- 55
- Symbol
- Y
- Symbol of market data entry.
-
- 268
- NoMDEntries
- Y
- Number of entries in this message.
-
- => 269
- MDEntryType
- Y
- Type of market data update.
Valid values:- 0 = Bid
- 1 = Offer
- 2 = Trade
-
- => 270
- MDEntryPx
- Y
- Price of market data entry.
-
- => 271
- MDEntrySize
- Y
- Quantity of market data entry.
-
- => 273
- MDEntryTime
- N*
- The time that the most recent indicative price has been published.
Market Data - Incremental Refresh <X>
The initial response to a Market Data Request <V> is a full snapshot of current state followed by multiple incremental update messages.
See Examples: Market Data Responses for examples of bids, offers, and trade events.
-
- Tag
- Name
- Req
- Description
-
- Standard Header
- X
- MsgType = X
-
- 262
- MDReqID
- Y
- Unique identifier of the Market Data Request <V> this message is in response to.
-
- 9008
- EventId
- N
- event id of te event causing the generation of update in this message
-
- 268
- NoMDEntries
- Y
- Number of entries in this message.
-
- => 279
- MDUpdateAction
- Y
- Type of market data update.
Valid values:- 0 = New
- 1 = Change
- 2 = Delete
-
- => 269
- MDEntryType
- Y
- Type of market data entry.
Valid values:- 0 = Bid
- 1 = Offer
- 2 = Trade
- R = MarkPrice
- S = FundingAmount
-
- => 55
- Symbol
- N
- Symbol of market data entry.
Required when MDEntryType is not3 = Index Value
-
- => 270
- MDEntryPx
- Y
- Price of market data entry.
-
- => 271
- MDEntrySize
- N*
- Quantity of market data entry.
* Required when MDEntryType is not3 = Index Value
-
- => 273
- MDEntryTime
- N*
- The time that the most recent indicative price has been published.
-
- => 9002
- MDEntryMakerSide
- N*
- Custom field indicating the maker side of a trade. Enabled by sending a Market Data Request <V> with custom field EnableMDEntryMakerSide <9003> set to
TRUE
. Appears when MDEntryType <269> has value2 = Trade
.
Valid values:- 1 = Buy
- 2 = Sell
See Examples: Showing Maker Side For Trades.
-
- => 9009
- MDEntryFundingIsRealized
- N*
- Custom field used in Market Data - Incremental Refresh <X> MDEntry groups when MDEntryType had the value
S = Funding Amount
to indicate the IsRealized field of Funding Amount.
Valid values:- Y = Yes
- N = No
Market Data Request Reject <Y>
-
- Tag
- Name
- Req
- Description
-
- Standard Header
- Y
- MsgType = Y
-
- 262
- MDReqID
- Y
- Unique identifier of the market data request being rejected.
-
- 281
- MDReqRejReason
- N
- Reason why Market Data Request <V> was rejected.
Valid values:- 0 = Unknown Symbol
- 1 = Duplicate MDReqID <262>
- 4 = Unsupported SubscriptionRequestType <263>
- 5 = Unsupported MarketDepth <264>
- 8 = Unsupported MDEntryType <269>
Examples
Market Data Requests
These are some examples of FIX market data requests. These requests only need to be made once per session to setup a FIX connection for market data.
Notes:
- SubscriptionRequestType <263> =
1 SNAPSHOT_PLUS_UPDATES
allows the sender to subscribe to the data feed and receive updates.
Request for Top of Book (bids)
This is a request for the Top of Book BTCUSD bids:
RAW
8=FIX.4.4|9=114|35=V|34=2|49=TRADEBOTMD002|52=20180425-17:51:40.000|56=GEMINI|262=2|263=1|264=1|146=1|55=BTCUSD|267=1|269=0|10=016|
HEADER
8 BeginString: FIX.4.4
9 BodyLength: 114
34 MsgSeqNum: 2
35 MsgType: MarketDataRequest (V)
49 SenderCompID: TRADEBOTMD002
52 SendingTime: 20180425-17:51:40.000
56 TargetCompID: GEMINI
BODY
262 MDReqID: 2
263 SubscriptionRequestType: SNAPSHOT_PLUS_UPDATES (1)
264 MarketDepth: TOP_OF_BOOK (1)
NoRelatedSym: count = 1
55 Symbol: BTCUSD
NoMDEntryTypes: count = 1
269 MDEntryType: BID (0)
TRAILER
10 CheckSum: 016
and the corresponding response:
RAW
8=FIX.4.4|9=108|35=W|34=2|49=GEMINI|52=20180425-17:51:40.787|56=TRADEBOTMD002|55=BTCUSD|262=2|268=1|269=0|270=8490.07|271=1|10=075|
HEADER
8 BeginString: FIX.4.4
9 BodyLength: 108
34 MsgSeqNum: 2
35 MsgType: MarketDataSnapshotFullRefresh (W)
49 SenderCompID: GEMINI
52 SendingTime: 20180425-17:51:40.787
56 TargetCompID: TRADEBOTMD002
BODY
55 Symbol: BTCUSD
262 MDReqID: 2
NoMDEntries: count = 1
269 MDEntryType: BID (0)
270 MDEntryPx: 8490.07
271 MDEntrySize: 1
TRAILER
10 CheckSum: 075
Request for Trades
This is a request for all ETHBTC trades:
RAW
8=FIX.4.4|9=114|35=V|34=2|49=TRADEBOTMD002|52=20180425-17:55:30.000|56=GEMINI|262=2|263=1|264=0|146=1|55=ETHBTC|267=1|269=2|10=009|
HEADER
8 BeginString: FIX.4.4
9 BodyLength: 114
34 MsgSeqNum: 2
35 MsgType: MarketDataRequest (V)
49 SenderCompID: TRADEBOTMD002
52 SendingTime: 20180425-17:55:30.000
56 TargetCompID: GEMINI
BODY
262 MDReqID: 2
263 SubscriptionRequestType: SNAPSHOT_PLUS_UPDATES (1)
264 MarketDepth: FULL_BOOK (0)
NoRelatedSym: count = 1
55 Symbol: ETHBTC
NoMDEntryTypes: count = 1
269 MDEntryType: TRADE (2)
TRAILER
10 CheckSum: 009
Request for Multiple Symbols
This is a request for the Top of Book BTCUSD, ETHUSD, and ETHBTC bids:
RAW
8=FIX.4.4|9=134|35=V|34=2|49=TRADEBOTMD002|52=20180425-17:55:38.000|56=GEMINI|262=2|263=1|264=1|146=3|55=BTCUSD|55=ETHUSD|55=ETHBTC|267=1|269=0|10=246|
HEADER
8 BeginString: FIX.4.4
9 BodyLength: 134
34 MsgSeqNum: 2
35 MsgType: MarketDataRequest (V)
49 SenderCompID: TRADEBOTMD002
52 SendingTime: 20180425-17:55:38.000
56 TargetCompID: GEMINI
BODY
262 MDReqID: 2
263 SubscriptionRequestType: SNAPSHOT_PLUS_UPDATES (1)
264 MarketDepth: TOP_OF_BOOK (1)
NoRelatedSym: count = 3
55 Symbol: BTCUSD
----
55 Symbol: ETHUSD
----
55 Symbol: ETHBTC
NoMDEntryTypes: count = 1
269 MDEntryType: BID (0)
TRAILER
10 CheckSum: 246
and the corresponding responses:
RAW
8=FIX.4.4|9=108|35=W|34=2|49=GEMINI|52=20180425-17:55:39.151|56=TRADEBOTMD002|55=BTCUSD|262=2|268=1|269=0|270=8490.07|271=1|10=072|
HEADER
8 BeginString: FIX.4.4
9 BodyLength: 108
34 MsgSeqNum: 2
35 MsgType: MarketDataSnapshotFullRefresh (W)
49 SenderCompID: GEMINI
52 SendingTime: 20180425-17:55:39.151
56 TargetCompID: TRADEBOTMD002
BODY
55 Symbol: BTCUSD
262 MDReqID: 2
NoMDEntries: count = 1
269 MDEntryType: BID (0)
270 MDEntryPx: 8490.07
271 MDEntrySize: 1
TRAILER
10 CheckSum: 072
and:
RAW
8=FIX.4.4|9=107|35=W|34=3|49=GEMINI|52=20180425-17:55:39.151|56=TRADEBOTMD002|55=ETHUSD|262=2|268=1|269=0|270=587.35|271=1|10=032|
HEADER
8 BeginString: FIX.4.4
9 BodyLength: 107
34 MsgSeqNum: 3
35 MsgType: MarketDataSnapshotFullRefresh (W)
49 SenderCompID: GEMINI
52 SendingTime: 20180425-17:55:39.151
56 TargetCompID: TRADEBOTMD002
BODY
55 Symbol: ETHUSD
262 MDReqID: 2
NoMDEntries: count = 1
269 MDEntryType: BID (0)
270 MDEntryPx: 587.35
271 MDEntrySize: 1
TRAILER
10 CheckSum: 032
and:
RAW
8=FIX.4.4|9=115|35=W|34=4|49=GEMINI|52=20180425-17:55:39.152|56=TRADEBOTMD002|55=ETHBTC|262=2|268=1|269=0|270=0.06896|271=0.004008|10=152|
HEADER
8 BeginString: FIX.4.4
9 BodyLength: 115
34 MsgSeqNum: 4
35 MsgType: MarketDataSnapshotFullRefresh (W)
49 SenderCompID: GEMINI
52 SendingTime: 20180425-17:55:39.152
56 TargetCompID: TRADEBOTMD002
BODY
55 Symbol: ETHBTC
262 MDReqID: 2
NoMDEntries: count = 1
269 MDEntryType: BID (0)
270 MDEntryPx: 0.06896
271 MDEntrySize: 0.004008
TRAILER
10 CheckSum: 152
Request to enable Maker Side on Trades
To enable showing the maker side of trades, create a Market Data Request <V> with custom field EnableMDEntryMakerSide <9003> enabled.
When trades occur, custom field MDEntryMakerSide <9002> will appear in the MDEntry group with the market side of the trade. See Examples: Showing Maker Side For Trades.
RAW
8=FIX.4.4|9=121|35=V|34=2|49=TRADEBOTMD002|52=20180809-15:59:14.000|56=GEMINI|262=2|263=1|264=1|9003=Y|146=1|55=BTCUSD|267=1|269=2|10=128|
HEADER
8 BeginString: FIX.4.4
9 BodyLength: 121
34 MsgSeqNum: 2
35 MsgType: MarketDataRequest (V)
49 SenderCompID: TRADEBOTMD002
52 SendingTime: 20180809-15:59:14.000
56 TargetCompID: GEMINI
BODY
262 MDReqID: 2
263 SubscriptionRequestType: SNAPSHOT_PLUS_UPDATES (1)
264 MarketDepth: TOP_OF_BOOK (1)
9003 EnableMDEntryMakerSide: Y
NoRelatedSym: count = 1
55 Symbol: BTCUSD
NoMDEntryTypes: count = 1
269 MDEntryType: TRADE (2)
TRAILER
10 CheckSum: 128
Market Data Responses
These are some examples of FIX market data sent from GEMINIMKT to TESTMKT001 with price, liquidity, and trade information. Note that this is public data, so no assumption about the trade’s counterparty should be made.
Full snapshot
The initial response to a Market Data Request <V> is a Market Data - Snapshot / Full Refresh <W> message containing a full snapshot of current state.
HEADER
8 BeginString: FIX.4.4
9 BodyLength: 19924
34 MsgSeqNum: 4
35 MsgType: MarketDataSnapshotFullRefresh (W)
49 SenderCompID: GEMINIMKT
52 SendingTime: 20180121-03:48:39.102
56 TargetCompID: TESTMKT001
BODY
55 Symbol: ETHBTC
262 MDReqID: 39
NoMDEntries: count = 685
269 MDEntryType: BID (0)
270 MDEntryPx: 0.00001
271 MDEntrySize: 10111
----
...
----
269 MDEntryType: BID (0)
270 MDEntryPx: 0.08989
271 MDEntrySize: 8.918
----
269 MDEntryType: BID (0)
270 MDEntryPx: 0.0899
271 MDEntrySize: 8.8828
----
269 MDEntryType: OFFER (1)
270 MDEntryPx: 0.09032
271 MDEntrySize: 45.134
----
269 MDEntryType: OFFER (1)
270 MDEntryPx: 0.09049
271 MDEntrySize: 1.2
----
...
----
269 MDEntryType: OFFER (1)
270 MDEntryPx: 1000.00000
271 MDEntrySize: 3
TRAILER
10 CheckSum: 084
Adding quantity for a given price
This message shows a new bid for 2.8749 ETH priced at 988.88 USD.
HEADER
8 BeginString: FIX.4.4
9 BodyLength: 125
34 MsgSeqNum: 5696449
35 MsgType: MarketDataIncrementalRefresh (X)
49 SenderCompID: GEMINIMKT
52 SendingTime: 20180123-04:07:42.101
56 TargetCompID: TESTMKT001
BODY
262 MDReqID: 40
9008 EventId: 123456789
NoMDEntries: count = 1
55 Symbol: ETHUSD
269 MDEntryType: BID (0)
270 MDEntryPx: 988.88
271 MDEntrySize: 2.8749
279 MDUpdateAction: NEW (0)
TRAILER
10 CheckSum: 187
Changing quantity for a given price
This message shows a new offer for 0.20503505 BTC available at price 10949.04 USD.
HEADER
8 BeginString: FIX.4.4
9 BodyLength: 131
34 MsgSeqNum: 5696384
35 MsgType: MarketDataIncrementalRefresh (X)
49 SenderCompID: GEMINIMKT
52 SendingTime: 20180123-04:07:40.057
56 TargetCompID: TESTMKT001
BODY
262 MDReqID: 38
9008 EventId: 123456789
NoMDEntries: count = 1
55 Symbol: BTCUSD
269 MDEntryType: OFFER (1)
270 MDEntryPx: 10949.04
271 MDEntrySize: 0.20503505
279 MDUpdateAction: CHANGE (1)
TRAILER
10 CheckSum: 199
Removing quantity for a given price
This message shows an ETHBTC bid priced at 0.09156 BTC being removed.
HEADER
8 BeginString: FIX.4.4
9 BodyLength: 115
34 MsgSeqNum: 5696454
35 MsgType: MarketDataIncrementalRefresh (X)
49 SenderCompID: GEMINIMKT
52 SendingTime: 20180123-04:07:42.279
56 TargetCompID: TESTMKT001
BODY
262 MDReqID: 39
9008 EventId: 123456789
NoMDEntries: count = 1
55 Symbol: ETHBTC
269 MDEntryType: BID (0)
270 MDEntryPx: 0.09156
279 MDUpdateAction: DELETE (2)
TRAILER
10 CheckSum: 197
Trades
This message provides information about a new trade and a corresponding offer deletion. This message implies that the incoming order was a bid because the standing offer priced at 10907.54 USD was deleted.
HEADER
8 BeginString: FIX.4.4
9 BodyLength: 166
34 MsgSeqNum: 5696411
35 MsgType: MarketDataIncrementalRefresh (X)
49 SenderCompID: GEMINIMKT
52 SendingTime: 20180123-04:07:40.740
56 TargetCompID: TESTMKT001
BODY
262 MDReqID: 38
9008 EventId: 123456789
NoMDEntries: count = 2
55 Symbol: BTCUSD
269 MDEntryType: TRADE (2)
270 MDEntryPx: 10907.54
271 MDEntrySize: 0.00059578
279 MDUpdateAction: NEW (0)
----
55 Symbol: BTCUSD
269 MDEntryType: OFFER (1)
270 MDEntryPx: 10907.54
279 MDUpdateAction: DELETE (2)
TRAILER
10 CheckSum: 209
Showing Maker Side For Trades
To enable showing the maker side of trades, create a Market Data Request <V> with custom field EnableMDEntryMakerSide <9003> enabled - see Examples: Request to enable maker side on trades.
This example shows a trade where an incoming offer hit a standing bid at for 0.001 BTC at 7544.94 USD.
RAW
8=FIX.4.4|9=125|35=X|34=3|49=GEMINI|52=20180809-15:59:16.698|56=TRADEBOTMD002|262=2|9008=123456789|268=1|279=0|269=2|55=BTCUSD|270=7544.94|271=0.001|9002=1|10=107|
HEADER
8 BeginString: FIX.4.4
9 BodyLength: 125
34 MsgSeqNum: 3
35 MsgType: MarketDataIncrementalRefresh (X)
49 SenderCompID: GEMINI
52 SendingTime: 20180809-15:59:16.698
56 TargetCompID: TRADEBOTMD002
BODY
262 MDReqID: 2
9008 EventId: 123456789
NoMDEntries: count = 1
55 Symbol: BTCUSD
269 MDEntryType: TRADE (2)
270 MDEntryPx: 7544.94
271 MDEntrySize: 0.001
279 MDUpdateAction: NEW (0)
9002 MDEntryMakerSide: BUY (1)
TRAILER
10 CheckSum: 107
This example shows a trade where an incoming bid lifted a standing offer at for 0.001 BTC at 7549.89 USD.
RAW
8=FIX.4.4|9=125|35=X|34=3|49=GEMINI|52=20180809-15:59:22.882|56=TRADEBOTMD002|262=2|9008=123456789|268=1|279=0|269=2|55=BTCUSD|270=7549.89|271=0.001|9002=2|10=109|
HEADER
8 BeginString: FIX.4.4
9 BodyLength: 125
34 MsgSeqNum: 3
35 MsgType: MarketDataIncrementalRefresh (X)
49 SenderCompID: GEMINI
52 SendingTime: 20180809-15:59:22.882
56 TargetCompID: TRADEBOTMD002
BODY
262 MDReqID: 2
9008 EventId: 123456789
NoMDEntries: count = 1
55 Symbol: BTCUSD
269 MDEntryType: TRADE (2)
270 MDEntryPx: 7549.89
271 MDEntrySize: 0.001
279 MDUpdateAction: NEW (0)
9002 MDEntryMakerSide: SELL (2)
TRAILER
10 CheckSum: 109
Rejected Symbol
RAW
8=FIX.4.4|9=67|35=Y|34=2|49=GEMINIMKT|52=20180511-21:37:57.971|56=TESTMKT001|262=badsym|281=0|10=038|
HEADER
8 BeginString: FIX.4.4
9 BodyLength: 67
34 MsgSeqNum: 2
35 MsgType: MarketDataRequestReject (Y)
49 SenderCompID: GEMINIMKT
52 SendingTime: 20180511-21:37:57.971
56 TargetCompID: TESTMKT001
BODY
262 MDReqID: badsym
281 MDReqRejReason: UNKNOWN_SYMBOL (0)
TRAILER
10 CheckSum: 03
Rejected MD Entry Type
RAW
8=FIX.4.4|9=70|35=Y|34=2|49=GEMINIMKT|52=20180511-21:44:14.765|56=TESTMKT001|262=badmd|281=8|10=121|
HEADER
8 BeginString: FIX.4.4
9 BodyLength: 70
34 MsgSeqNum: 2
35 MsgType: MarketDataRequestReject (Y)
49 SenderCompID: GEMINIMKT
52 SendingTime: 20180511-21:44:14.765
56 TargetCompID: TESTMKT001
BODY
262 MDReqID: badmd
281 MDReqRejReason: UNSUPPORTED_MDENTRYTYPE (8)
TRAILER
10 CheckSum: 121
Rejected Subscription Request
RAW
8=FIX.4.4|9=67|35=Y|34=2|49=GEMINIMKT|52=20180514-13:59:56.187|56=TESTMKT001|262=badsub|281=4|10=048|
HEADER
8 BeginString: FIX.4.4
9 BodyLength: 67
34 MsgSeqNum: 2
35 MsgType: MarketDataRequestReject (Y)
49 SenderCompID: GEMINIMKT
52 SendingTime: 20180514-13:59:56.187
56 TargetCompID: TESTMKT001
BODY
262 MDReqID: badsub
281 MDReqRejReason: UNSUPPORTED_SUBSCRIPTIONREQUESTTYPE (4)
TRAILER
10 CheckSum: 048
Request for the symbol list
This is a request for the list of symbols:
RAW
8=FIX.4.4|9=74|35=x|34=2|49=TRADEBOTMD002|52=20180425-17:51:27.000|56=GEMINI|320=1|559=0|10=099|
HEADER
8 BeginString: FIX.4.4
9 BodyLength: 74
34 MsgSeqNum: 2
35 MsgType: SymbolListRequest (x)
49 SenderCompID: TRADEBOTMD002
52 SendingTime: 20180425-17:51:27.000
56 TargetCompID: GEMINI
BODY
320 SecurityReqID: 1
559 SecurityListRequestType: SYMBOL (0)
TRAILER
10 CheckSum: 099
and the associated response:
RAW
8=FIX.4.4|9=146|35=y|34=2|49=GEMINI|52=20200425-17:51:27.544|56=TRADEBOTMD002|320=1|322=1|560=0|146=6|55=BTCUSD|55=ETHBTC|55=ETHUSD|55=BCHUSD|55=BCHBTC|55=BCHETH|55=LTCUSD|55=LTCBTC|55=LTCETH|55=LTCBCH|55=BATUSD|55=DAIUSD|55=LINKUSD|55=OXTUSD|55=LINKBTC|55=LINKETH|10=054|
HEADER
8 BeginString: FIX.4.4
9 BodyLength: 146
34 MsgSeqNum: 2
35 MsgType: SecurityList (y)
49 SenderCompID: GEMINI
52 SendingTime: 20200425-17:51:27.544
56 TargetCompID: TRADEBOTMD002
BODY
320 SecurityReqID: 1
322 SecurityResponseID: 1
560 SecurityRequestResult: VALID_REQUEST (0)
NoRelatedSym: count = 3
55 Symbol: BTCUSD
----
55 Symbol: ETHBTC
----
55 Symbol: ETHUSD
----
55 Symbol: BCHUSD
----
55 Symbol: BCHBTC
----
55 Symbol: BCHETH
----
55 Symbol: LTCUSD
----
55 Symbol: LTCBTC
----
55 Symbol: LTCETH
----
55 Symbol: LTCBCH
----
55 Symbol: BATUSD
----
55 Symbol: DAIUSD
----
55 Symbol: LINKUSD
----
55 Symbol: OXTUSD
----
55 Symbol: LINKBTC
----
55 Symbol: LINKETH
TRAILER
10 CheckSum: 054
Revision History
Date | Notes |
---|---|
2016/03/23 | Initial FIX Market Data API documentation |
2017/07/27 | New Feature Top of book: Market Data Request <V> adds support for MarketDepth <264> value of 1 = Top Of Book Documentation bugfix: clarified that market data subscription with duplicate MDReqID <262> value will be rejected in Client supplied identifiers. |
2017/08/30 | Documentation bugfix: clarified description of MDEntryType <269> in Market Data - Snapshot / Full Refresh <W>. |
2017/12/01 | API Change added MDEntryType <269> value 3 = INDEX_VALUE to Market Data - Incremental Refresh <X> to support reporting the auction collar price. |
2018/01/22 | Documentation bugfix: fixed ExpireTime <126> tag number in documentation for Market Data - Incremental Refresh <X> and Market Data - Snapshot / Full Refresh <W> Documentation improvement: added examples of Market Data Request <V>, Market Data - Incremental Refresh <X>, and Market Data - Snapshot / Full Refresh <W> messages. |
2018/03/09 | Documentation bugfix: correct MsgType <35> tag number in documentation for Symbol List Request <x> Documentation improvement: added examples of Symbol List Request <x> and Symbol List <y> messages. |
2018/04/06 | New Feature: Document block trading support. |
2018/05/18 | Add additional examples of Market Data requests and responses. |
2018/08/07 | API Change Added support for maker side using custom tags 9002 MDEntryMakerSide and EnableMDEntryMakerSide . |
2020/08/28 | Removing DAIBTC and DAIETH trading pairs |
2020/09/11 | Documentation for new token support: AMP , COMP , PAXG |
2020/09/24 | Documentation for new token support: MKR , ZRX , KNC , MANA , STORJ , SNX , CRV , BAL , UNI , REN , UMA , YFI |
2020/10/05 | Documentation for new order book support: BTCDAI and ETHDAI |
2020/03/22 | Documentation for new token support: SKL , GRT , BNT , 1INCH , ENJ , LRC , SAND |
2021/04/27 | Documentation for new token support: CUBE , LPT , BOND , MATIC , INJ , SUSHI |
2021/05/05 | Documentation for new token support: DOGE |
2021/06/16 | Documentation for new token support: ALCX , MIR , FTM , ANKR |
2021/07/14 | Documentation for new token support: CTX |
2021/07/21 | Documentation for new token support: XTZ |
2021/09/15 | Documentation for new token support: AXS , SLP , LUNA , UST , MCO2 |
2021/11/13 | Documentation for new token support: WCFG , RARE , RAD , QNT , NMR , MASK , FET , ASH , AUDIO , API3 , USDC , SHIB |
2021/12/20 | Documentation for new token support: RNDR , MC , GALA , ENS , KP3R , CVC , ELON , MIM , SPELL |
2022/02/01 | Documentation for new token support: TOKE , LDO , RLY |
2022/02/28 | Documentation for new token support: SOL |
2022/03/01 | Documentation for new token support: RAY , SBR |
2022/03/16 | Documentation for new token support: APE |
2022/03/29 | Documentation for new token support: RBN , FXS , DPI , LQTY , LUSD , FRAX , INDEX , MPL |
2022/04/26 | Documentation for new token support: GUSDSGD |
2022/04/27 | Documentation for new token support: METIS , QRDO , ZBC , CHZ , REVV , JAM , FIDA , GMT |
2022/05/17 | Documentation for new token support: GFI , ORCA |
2022/06/14 | Documentation for new token support: ALI , TRU |
2022/06/14 | Documentation for new token support: GUSDGBP |
2022/06/23 | Deprecating documentation for Auction and Block trading support |
2022/07/06 | Documentation for new token support: DOT , ERN |
2022/08/01 | Documentation for new token support: GAL , EUL , SAMO |
2022/08/23 | Documentation for new token support: BICO , IMX , PLA , IOTX |
2022/09/07 | Documentation for new token support: BUSD |
2022/10/11 | Documentation for new token support: AVAX |
2023/01/10 | Documentation for new token support: ATOM , USDT |
2023/02/16 | New Feature: Add MarkPrice support |
2024/03/04 | New Feature: Add FundingAmount support |
2023/05/08 | Corrected documentation (symbol) for BTC-GUSD-PERP |
2023/08/04 | Documentation for token delist: ENJ |
2023/08/10 | Documentation for new token support: XRP |
2023/09/11 | Documentation for new token support: HNT |
2023/09/18 | Removed Documentation for new token support: MPL , MC , METIS , RBN , GFI , LQTY , and LUSD |
2023/11/15 | Remove Documentation for delisted token: MIR , UST , FXS , FRAX , BUSD |
2024/04/23 | Remove Documentation for delisted token: ZEC |
2024/09/20 | Remove Documentation for delisted token: LUNA ,SNX ,QRDO ,ZBC |
- Trust is Our Product™
- For trademarks and patents, please see the Legal Notice.
- NMLS #1518126
- © Copyright 2022 Gemini Trust Company, LLC.