# Cboe Titanium Cboe Futures Exchange Multicast TOP Specification

Version 1.2.20 · January 5, 2026

## Introduction

This specification is the standard Multicast TOP specification for the Cboe Futures Exchange (CFE) platform.

CFE participants may use the CFE Multicast TOP protocol to receive real-time top of book quotations direct from CFE. Market data received through Multicast TOP is less timely than receiving the same data from the CFE Multicast PITCH Depth of Book feed. The TOP protocol offers approximately 66% reduction in the number of events and 66% reduction in the number of bytes of application data sent, compared to the CFE Multicast PITCH protocol.

The quotations received via Multicast TOP provide an aggregated size and do not indicate the size or number of individual orders at the best bid or ask. The Multicast TOP protocol also provides last trade price and size and cumulative volume data.

Complete depth of book market data can be received via the CFE Multicast PITCH protocol.

TOP cannot be used to enter orders. For order entry, refer to the appropriate CFE FIX or BOE Specification.

All versions of the Multicast TOP feed are WAN-shaped (maximum 100 Mb/s) and are available from one or both of CFE's datacenters. Participants may choose to take one or more of the following Multicast TOP feeds depending on their location and connectivity to CFE.

**Table 1. Multicast TOP Feed Descriptions**

| Exchange | Shaping | Served From Data Center (Primary/Secondary) | Multicast Feed ID |
|---|---|---|---|
| CFE | WAN | Primary | FCT |
| CFE | WAN | Primary | FDT |
| CFE | WAN | Secondary | FET |

### Feed Hours and System Restart

The TOP feed will start up on Sunday at approximately 10:30 a.m. CT and shutdown on Friday at approximately 4:05 p.m. CT. A daily restart occurs between 4:05 and 4:45 p.m. CT each day at which time sequences will be reset. The daily restart is typically observed between 4:05 and 4:10 p.m. CT, but could occur later if needed for operational reasons. Feed startup and shutdown times may be adjusted without notice.

Under normal operations, it is expected that the order books will be cleared (including GTC and GTD orders), prior to the daily restart and reset of sequences. Persisted GTC and GTD orders will be added back into the order book starting at approximately 10 minutes prior to the scheduled queuing time for each futures root.

### Feed Connectivity Requirements

WAN-Shaped feeds are available to participants who meet the minimum bandwidth requirements to CFE via cross-connect, dedicated circuit, or a supported carrier.

Participants with sufficient connectivity may choose to take both the FCT and FDT feeds from the CFE's primary datacenter and arbitrate the feeds to recover lost data. Alternatively, participants may choose to arbitrate feeds from both datacenters. It should be noted that feeds from the secondary datacenter will have additional latency for those connected with CFE in the primary datacenter due to proximity and business continuity processing.

CFE Multicast TOP real-time events are delivered using a published range of multicast addresses divided by symbol range units. Dropped messages can be requested using a TCP/IP connection to one of CFE's Multicast TOP Gap Request Proxy (GRP) servers with replayed messages being delivered on a separate set of multicast ranges reserved for packet retransmission. Intraday, a spin of all open orders may be requested from a Spin Server. Alternatively, the Periodic Refresh mechanism may be used by latency insensitive participants to recover missed messages or gaps. This allows a client to become current without requesting a gap for all messages up to that point in the day.

The following diagram is a logical representation Multicast TOP feed message flow between CFE and a participant feed handler that is listening to the A and B instances of two units:

_(Figure)_

### Symbol Ranges, Units, and Sequence Numbers

Products are separated into units by a published distribution and will not change intra-day. CFE does, however, reserve the right to add multicast addresses or change the product distribution with 48 hours prior notice to participants. Care should be taken to ensure that address changes, address additions, and product distribution changes can be supported easily.

Message sequence numbers are incremented by one for every sequenced message within a particular symbol unit. It is important to understand that one or more units will be delivered on a single multicast address. As with symbol ranges, unit distribution across multicast addresses will not change intra-day, but may change after notice has been given.

Symbol distribution across units as well as unit distribution across multicast addresses are identical for real-time and gap response multicast addresses.

### Futures Specific Symbol Processing

CFE has implemented a symbol mapping mechanism (`Futures Instrument Definition` message) for the Multicast TOP feeds, which maps each specific simple futures contract or spread instrument to a six character, ASCII Symbol. For example, the weekly VX11 contract expiring March 14, 2017 might be represented by the Symbol `0abC12`. This symbol mapping significantly reduces the size of the Multicast TOP feed for futures and allows participants to use the same symbol handling mechanisms for the Cboe operated equity, options, and futures exchanges. This symbol mapping is the same as the Multicast PITCH feed.

Mapping occurs on a continuous basis on each unit's multicast feed. `Futures Instrument Definition` messages can be both un-sequenced and sequenced. Un-sequenced messages are sent from pre-market through the end of trading in a continuous loop that will complete approximately once every minute. Once the same contract has been seen twice, the user can be certain the full loop has been observed. The rate is variable and will be adjusted as bandwidth allows.

Spread instruments may be occasionally created intra-day. In these cases, the `Futures Instrument Definition` message will be sent as a sequenced message on the real-time feed and from the Spin Server before any other messages that reference an instrument created intra-day are sent.

In addition to the symbol mapping events available on the Multicast TOP feed, a downloadable file with current mappings is available via the CFE website.

Production symbol files:

- Simple
- Spread

Certification symbol files:

- Simple

- Spread

### Periodic Refresh

The CFE Multicast TOP feed will periodically broadcast un-sequenced `Futures Instrument Definition, Price Limits,` and `Market Snapshot` messages that participants can use to recover from gaps or that may be used by late joiners to obtain a current state of the top of book for each Symbol. Un-sequenced messages are sent in a continuous loop. The `Price Limits` and `Market Snapshot` messages complete their loop approximately once every 3 seconds. The `Futures Instrument Definition` message completes its loop once a minute.

Participants that are not latency sensitive can use the Periodic Refresh mechanism as a substitute for the sequenced, real-time TOP messages. These participants would process only the un-sequenced `Futures Instrument Definition,` `Price Limits,` and `Market Snapshot` messages to get a periodic view of the top of book quote and volume for each Symbol.

### Gap Request Proxy and Message Retransmission

Requesting delivery of missed sequenced data is achieved by establishing a TCP connection to a CFE Gap Request Proxy (GRP) port. This GRP port is specific to Multicast TOP and is NOT shared with the Multicast PITCH GRP port. Participants who do not wish to request missed messages do not need to connect to a GRP port for any reason or listen to the multicast addresses reserved for message retransmission. Participants choosing to request missed data will need to connect to their assigned GRP port, log in, and request gap ranges as necessary. All gap requests will be responded to with a `Gap Response` message. A `Gap Response` message Status code of `Accepted` signals that the replayed messages will be delivered via the appropriate gap response multicast address. Any other `Gap Response` message Status code will indicate the reason that the request cannot be serviced.

Gap requests are limited in message count, frequency, and age by the GRP. Gap requests will only be serviced if they are within a defined sequence range of the current multicast sequence number for the requested unit. Participants will receive a total daily allowance of gap requested messages. In addition, each participant is given renewable one second and one minute gap request limits.

If more than one gap request is received for a particular unit/sequence/count combination within a short timeframe, all requests will receive a successful `Gap Response` message from the GRP, but only a single replayed message will be sent on the gap response multicast address.

If overlapping gap requests are received within a short period of time, the gap server will only send the union of the sequence ranges across grouped gap requests. Participants will receive gap responses for their requested unit/sequence/count, but receivers should be prepared for the gap responses to be delivered via multicast in non-contiguous blocks.

Gap acknowledgements or rejects will be delivered to users for every gap request received by the GRP. Users should be prepared to see replayed multicast data before or after the receipt of the gap response acknowledgement from the GRP.

### Spin Servers

A Spin Server is available for each unit. The server allows participants to connect via TCP and receive a spin of the inside book and symbols with limited trading conditions on that unit. By using the spin, a participant can get the current CFE book quickly in the middle of the trading session without worry of gap request limits. The Spin Server for each unit is assigned its own address and/or TCP port.

Upon successful login and periodically thereafter, a `Spin Image Available` message is sent which contains a sequence number indicating the most recent message applied to the book. Using a `Spin Request` message, a participant may request a spin for the orders up to a sequence number noted within one of the last ten `Spin Image Available` messages distributed. If the `Spin Request` message submitted does not present a sequence number that matches one of the last ten `Spin Image Available` messages distributed, the spin will return orders up to the next closest sequence number reported through a `Spin Image Available` message that is greater than the sequence number requested.

In the case a participant sends a sequence number in a `Spin Request` message that is higher than the sequence number reported by the most recent `Spin Image Available` message, the next spin image to be generated will be returned when it is available. If the requested sequence number is still higher at that time, an `O` (Out of Range) error will be generated.

A spin consists only of `Market Snapshot`, `End of Day Summary`, `Futures Instrument Definition`, `Futures Variance Symbol Mapping``, Settlement`, `Price Limits`, `Time Reference` and `Time` messages for symbols that have had orders that day or had a limited trading state. A `Time` message will be sent as the last message in a spin if the last `Time` message sent on a spin is older than the last received time from the internal market data producers.

While receiving the spin, the participant must buffer multicast messages received. If the `Spin Image Available` message sequence number is the participant's reference point, multicast messages with larger sequence numbers should be buffered. If a non- `Spin Image Available` message sequence number is the participant's reference point which they send in their `Spin Request` message, they should buffer from that point on, but note that within the spin they may receive sequence numbers beyond that point which they may disregard. When a `Spin Finished` message is received, the buffered messages must be applied to spun copy of the book to bring it current.

Spin Server Usage Example shows an example flow of messages between a participant and CFE's Multicast TOP feed and Spin Server.

## Protocol

CFE users may use the TOP protocol over multicast to receive real-time top of book quotations and execution information direct from CFE.

TOP cannot be used to enter orders. For order entry, refer to Cboe Titanium Cboe Futures Exchange FIX Specification or Cboe Titanium Cboe Futures Exchange BOE Version 3 Specification.

All orders and executions are reflected via the TOP feed. All orders and executions are anonymous, and do not contain any participant identity.

### Message Format

The messages that make up the TOP protocol are delivered using the CFE `Sequenced Unit Header` message header which handles sequencing and delivery integrity. All messages delivered via multicast as well as to/from the Gap Request Proxy (GRP) or Spin Server will use the `Sequenced Unit Header` message header for handling message integrity.

All UDP delivered events will be self-contained. Developers can assume that UDP delivered data will not cross frame boundaries and a single Ethernet frame will contain only one Sequenced Unit Header with associated data.

TCP/IP delivered events from the GRP may cross frames as the data will be delivered as a stream of data with the TCP/IP stack controlling Ethernet framing.

The TOP data feed is comprised of a series of dynamic length sequenced messages. Each message begins with Length and Message Type fields. CFE reserves the right to add message types and grow the length of any message without notice. Participants should develop their decoders to deal with unknown message types and messages that grow beyond the expected length. Messages will only be grown to add additional data to the end of a message.

### Data Types

The following field types are used within the `Sequenced Unit Header` message header, GRP messages, and TOP.

- Alphanumeric fields are left justified ASCII fields and space padded on the right.
- Binary fields are unsigned and sized to Length bytes and ordered using Little Endian convention (least significant byte first).
- Signed Binary fields are signed and sized to Length bytes and ordered using Little Endian convention (least significant byte first).
- Binary Price fields are signed Little Endian encoded 8 byte binary fields with 4 implied decimal places (denominator = 10,000).
- Binary Short Price fields are signed Little Endian encoded 2 byte binary fields with 2 implied decimal places (denominator = 100).
- Bit Field fields are fixed width fields with each bit representing a boolean flag (the 0 bit is the lowest significant bit; the 7 bit is the highest significant bit).
- Printable ASCII fields are left justified ASCII fields that are space padded on the right that may include ASCII values in the range of 0x20 - 0x7e.
- Binary Date fields are 4 byte unsigned Little Endian values where the base-10 representation is the YYYYMMDD representation of that date. For example, October 30, 2023 would be represented as 20,231,030 (20231030).
- Time Offset are 4 byte unsigned Little Endian values that represent the number of nanoseconds since the last `Time` message.

#### Trade Date

Throughout this document, the term "Trade Date" is synonymous with the term "Business Date". The term Trade Date is used within this document to match identically named fields in Cboe Titanium Cboe Futures Exchange FIX Specification and Cboe Titanium Cboe Futures Exchange BOE Version 3 Specification.

### Message Framing

Top of book update messages will be combined into single UDP frame where possible to decrease message overhead and total bandwidth. The count of messages in a UDP frame will be communicated using the CFE `Sequenced Unit Header` message header. Framing will be determined by the server for each unit and site. The content of the multicast across feeds (e.g. A/B) will be identical, but framing will not be consistent across feeds. Receiving processes that receive and arbitrate multiple feeds cannot use frame level arbitration to fill gaps.

### CFE Sequenced Unit Header Message Fields

The CFE `Sequenced Unit Header` message header is used for all CFE Multicast TOP messages as well as messages to and from the Gap Request Proxy (GRP) and Spin Servers.

Sequenced and un-sequenced data may be delivered using the `Sequenced Unit Header` message header. Un-sequenced headers will have a 0 value for the Hdr Sequence field and potentially for the Hdr Unit field. All messages sent to and from the GRP and Spin Server are un-sequenced while multicast may contain both sequenced and un-sequenced messages.

Sequenced messages have implied sequences with the first message having the sequence number contained in the header. Each subsequent message will have an implied sequence one greater than the previous message up to a maximum of count messages. Multiple messages can follow a `Sequenced Unit Header` message header, but a combination of sequenced and un-sequenced messages cannot be sent within one header.

The sequence number for the first message in the next frame can be calculated by adding the Hdr Count field to the Hdr Sequence. This technique will work for sequenced messages and `Heartbeat` messages.

**Table 1. Sequenced Unit Header**

| Field | Offset | Length | Value/Type | Description |
|---|---|---|---|---|
| Hdr Length | 0 | 2 | Binary | Length of entire block of messages. Includes this header and messages following Hdr Count. |
| Hdr Count | 2 | 1 | Binary | Number of messages to follow this header. |
| Hdr Unit | 3 | 1 | Binary | Unit that applies to messages included in this header. |
| Hdr Sequence | 4 | 4 | Binary | Sequence of first message to follow this header. |
| Total Length = 8 bytes |  |  |  |  |

### Heartbeat Message Fields

The CFE `Sequenced Unit Header` message header with a count field set to `0` will be used for `Heartbeat` messages. During trading hours `Heartbeat` messages will be sent from the GRP, Spin Server, and all multicast addresses if no data has been delivered within one second. `Heartbeat` messages never increment the sequence number for a unit, but can be used to detect gaps on the real-time multicast channels during low update rate periods.

`Heartbeat` messages on the real-time multicast addresses during trading hours will have a Hdr Sequence value equal to the sequence of the next sequenced message to be sent for the unit. `Heartbeat` messages on gap multicast addresses will always have the Hdr Sequence field set to `0`. All `Heartbeat` messages sent to and from the GRP and Spin Server are considered un-sequenced and should have sequence and unit fields set to `0`.

Outside of trading hours CFE sends `Heartbeat` messages on all real-time and gap channels with a sequence of `0` to help users validate multicast connectivity. `Heartbeat` messages might not be sent outside of normal trading hours.

CFE expects `Heartbeat` messages to be sent to the GRP on live connections no less than every 5 seconds. Failure to receive two consecutive `Heartbeat` messages will result in the GRP or Spin Server terminating the client connection.

### TOP Messages

With the exception of `Time` messages, each TOP message reflects the update of the top of book or execution of an order in the system.

### Time Message Fields

A `Time` message is immediately generated and sent when there is a TOP event for a given clock second. If there is no new sequenced TOP event for a given clock second, then no `Time` message is sent for that second. All subsequent time offset fields for the same unit will use the new Time value as the base until another `Time` message is received for the same unit. The Time field is the number of seconds relative to midnight Central Time, which is provided in the `Time Reference` message. The `Time` message also includes the Epoch Time field, which is the current time represented as the number of whole seconds since the Epoch (Midnight January 1, 1970).

**Table 1. Time**

| Field Name | Offset | Length | Type/(Value) | Description |
|---|---|---|---|---|
| Length | 0 | 1 | Binary | Length of this message including this field. |
| Message Type | 1 | 1 | 0x20 | `Time` Message. |
| Time | 2 | 4 | Binary | Number of whole seconds elapsed since the start of the current Central Time calendar day, derived by converting the current Central wall clock time (HH:MM:SS) to seconds. On Daylight Saving Time transition days, Time reflects wall clock seconds and does not adjust for the UTC offset change. On a DST spring-forward day, the maximum value will be 82,799 (23 hours). On a DST fall-back day, values between 3,600 and 7,199 will appear twice. Recipients requiring unambiguous absolute timestamps should use Epoch Time (where available) or Midnight Reference in the `Time Reference` message. |
| Epoch Time | 6 | 4 | Binary | Number of whole seconds since the Epoch (Midnight January 1, 1970 UTC). |
| Total Length = 10 bytes |  |  |  |  |

### Unit Clear Message Fields

The `Unit Clear` message instructs feed recipients to clear all market snapshots for the CFE book in the unit specified in the `Sequenced Unit Header` message header. It would be distributed in rare recovery events such as a data center fail-over. It may also be sent on system startup (after daily restart) when there are no persisted GTCs or GTDs.

**Table 1. Unit Clear**

| Field Name | Offset | Length | Type/(Value) | Description |
|---|---|---|---|---|
| Length | 0 | 1 | Binary | Length of this message including this field. |
| Message Type | 1 | 1 | 0x97 | `Unit Clear` message. |
| Time Offset | 2 | 4 | Binary | Nanosecond offset from last unit timestamp. |
| Total Length = 6 bytes |  |  |  |  |

### Time Reference Message Fields

The `Time Reference` message is used to provide a midnight reference point for recipients of the feed. It is sent whenever the system starts up and when the system crosses a midnight boundary. All subsequent `Time` messages for the same unit will the use the last Midnight Reference until another `Time Reference` message is received for that unit. The `Time Reference` message includes the Trade Date, so most other sequenced messages will not include that information.

`Time Reference` messages will be included in a spin response.

**Table 1. Time Reference**

| Field Name | Offset | Length | Type/(Value) | Description |
|---|---|---|---|---|
| Length | 0 | 1 | Binary | Length of this message including this field. |
| Message Type | 1 | 1 | 0xB1 | `Time Reference` message. |
| Midnight Reference | 2 | 4 | Binary | Midnight Central Time reference time for subsequent `Time` messages, expressed as number of whole seconds since the Epoch (Midnight January 1, 1970 UTC). |
| Time | 6 | 4 | Binary | Number of whole seconds elapsed since the start of the current Central Time calendar day, derived by converting the current Central wall clock time (HH:MM:SS) to seconds. On Daylight Saving Time transition days, Time reflects wall clock seconds and does not adjust for the UTC offset change. On a DST spring-forward day, the maximum value will be 82,799 (23 hours). On a DST fall-back day, values between 3,600 and 7,199 will appear twice. Recipients requiring unambiguous absolute timestamps should use Epoch Time (where available) or Midnight Reference in the `Time Reference` message. |
| Time Offset | 10 | 4 | Binary | Nanosecond offset from last unit timestamp. |
| Trade Date | 14 | 4 | Binary Date | Current Trade Date |
| Total Length = 18 bytes |  |  |  |  |

### Futures Instrument Definition Message Fields

The `Futures Instrument Definition` message can be sent as a sequenced message or an un-sequenced message. It is sent as a sequenced message when the system starts up at the beginning of a trading session or if an instrument is created or modified during a trading day. A new sequenced message may be sent for a Symbol that does not visibly change any attribute. One un-sequenced `Futures Instrument Definition` message for each Symbol is also sent in a continuous loop, which completes approximately once every minute as part of the Periodic Refresh mechanism.

If the instrument is a spread (Leg Count > 0) then the message contains one or more repeating groups of leg definitions beginning at the field indicated by Leg Offset. There is a limit of 4 leg definitions.

The Leg Offset field is provided to support adding additional fields to this message preceding the Leg definitions.

The Report Symbol field will contain either the weekly (e.g. VX01) or the monthly (e.g. VX) symbol for any simple futures contract. The Report Symbol will always contain the standard futures root symbol (e.g. VX) for all spread instruments.

`Futures Instrument Definition` messages are included in a spin response. Simple leg `Futures Instrument Definition` messages will be disseminated before complex leg `Futures Instrument Definition` messages sent in a spin response.

**Table 1. Futures Instrument Definition**

| Field Name | Offset | Length | Type/(Value) | Description |
|---|---|---|---|---|
| Length | 0 | 1 | Binary | Length of this message including this field. |
| Message Type | 1 | 1 | 0xBB | `Futures Instrument Definition` message. |
| Time Offset | 2 | 4 | Binary | Nanosecond offset from last unit timestamp or Unit Timestamp in this message if it is non-zero. |
| Symbol | 6 | 6 | Printable ASCII | Six character, base 62 symbol. |
| Unit Timestamp | 12 | 4 | Binary | Unit timestamp expressed as number of whole seconds since the Epoch (Midnight, January 1, 1970 UTC). |
| Report Symbol | 16 | 6 | Alphanumeric | Symbol for product or underlying security. |
| Futures Flags | 22 | 1 | Bit Field | Value will always be zero. |
| Expiration Date | 23 | 4 | Binary Date | Expiration Date of Instrument. |
| Contract Size | 27 | 2 | Binary | Contract size of Instrument. Contract sizes less than 1 are represented with a 0 value; refer to the product specification for the contract size. |
| Listing State | 29 | 1 | Alphanumeric | `A` = Active `I` = Inactive `T` = Test |
| Price Increment | 30 | 8 | Binary Price | Minimum Price Increment. |
| Leg Count | 38 | 1 | Binary | Values greater than 0 indicate this is a spread instrument. |
| Leg Offset | 39 | 1 | Binary | Leg definitions, if any, begin at this offset from the beginning of the message. Possible values are 0 (no legs present) or 45 (spread instrument). Cboe reserves the right to change these values without prior notice. |
| Reserved | 40 | 1 | Binary | Reserved.Value will always be zero. |
| Contract Date | 41 | 4 | Binary Date | Populated for single leg instruments only. Zero-filled for spread instruments. The date that should be used in describing the future's third party symbol and the measurement period of the contract. Set to same value as Expiration Date for futures that have a Contract Date that does not differ from expire date. |
| The following fields repeat Leg Count times (maximum of 4) for spread instruments. |  |  |  |  |
| Leg Ratio | Leg Offset + (10 * Leg Index) | 4 | Signed Binary | Leg ratio (positive for buy, negative for sell). |
| Leg Symbol | Leg Offset + 4 + (10 * Leg Index) | 6 | Alphanumeric | Symbol of leg. |
| Variable Total Length = 45 + (Leg Count * 10) bytes |  |  |  |  |

### Futures Variance Symbol Mapping Message Fields

The `Futures Variance Symbol Mapping` message is used to disseminate symbol reference data for S&P 500 Variance Futures (VA Futures) symbols. VA Futures symbol reference data are disseminated with both the `Futures Instrument Definition` and `Futures Variance Symbol Mapping` messages. The purpose of the `Futures Variance Symbol` message is to disseminate product-specific supplemental information for VA Futures symbols (i.e., Accrued Day Variance, Num Final Returns, and Num Elapsed Returns).

The `Futures Variance Symbol Mapping` message can be sent as a sequenced message or an un-sequenced message. It is sent as a sequenced message when the system starts up at the beginning of a trading session or if an instrument is created or modified during a trading day. A new sequenced message may be sent for a symbol that does not visibly change any attribute. One un-sequenced `Futures Variance Symbol Mapping` message for each symbol is also sent in a continuous loop, which completes approximately once every minute as part of the Periodic Refresh mechanism.

`Futures Variance Symbol Mapping` messages are included in a spin response.

**Table 1. Futures Variance Symbol Mapping Message Fields**

| Field Name | Offset | Length | Type/(Value) | Description |
|---|---|---|---|---|
| Length | 0 | 1 | Binary | Length of this message including this field. |
| Message Type | 1 | 1 | 0xFA | `Futures Variance Symbol Mapping` message. |
| Time Offset | 2 | 4 | Binary | Nanosecond offset from last unit timestamp or Unit Timestamp in this message if it is non-zero. |
| Unit Timestamp | 6 | 4 | Binary | Unit timestamp expressed as number of whole seconds since the Epoch (Midnight, January 1, 1970 UTC). |
| Feed Symbol | 10 | 6 | Printable ASCII | Six character, base 62 symbol. |
| Futures Symbol | 16 | 12 | Alphanumeric | Twelve character textual definition of the symbol where the first six characters contain the product symbol, left justified, and padded on the right with spaces, and the right most six characters are the expiration date in YYMMDD format. |
| Accrued Day Variance | 28 | 8 | Signed Binary | Accrued day variance as of the start of the trading day (signed 64-bit decimal with twelve implied decimal places). |
| Num Final Returns | 36 | 2 | Binary | Number of S&P 500 Index returns used in the Final Settlement Value calculation. |
| Num Elapsed Returns | 38 | 2 | Binary | Number of elapsed S&P 500 Index returns including the current day. |
| Total Length = 40 bytes |  |  |  |  |

### Price Limits Message Fields

The `Price Limits` message can be sent as a sequenced or un-sequenced message. As a sequenced message, it is sent out at the start of the session for products that are subject to price limits per the contract specifications. The `Price Limits` message does not signal whether price limits are in effect for that symbol; it simply provides those values for when they are in effect. If multiple `Price Limits` messages are received for the same Symbol, the most recent values will override the previous values.

As an un-sequenced message, it is sent out with a `Market Snapshot` message as part of the Periodic Refresh mechanism.

`Price Limits` messages are included in a spin response.

**Table 1. Price Limits**

| Field Name | Offset | Length | Type/(Value) | Description |
|---|---|---|---|---|
| Length | 0 | 1 | Binary | Length of this message including this field. |
| Message Type | 1 | 1 | 0xBE | `Price Limits` message. |
| Time Offset | 2 | 4 | Binary | Nanosecond offset from last unit timestamp. |
| Symbol | 6 | 6 | Printable ASCII | Six character, base 62 symbol. |
| Upper Price Limit | 12 | 8 | Binary Price | Upper price limit |
| Lower Price Limit | 20 | 8 | Binary Price | Lower price limit |
| Total Length = 28 bytes |  |  |  |  |

### Refresh and Spin Messages

#### Market Snapshot

A `Market Snapshot` message provides a snapshot of the price and size for the bid and ask, last trade price, total number of contracts traded, and the current trading status of a single symbol. The `Market Snapshot` message will be included during a Spin for all products traded so far this Trade Date. Finally, `Market Snapshot` messages will also be sent in a continuous loop as part of the Periodic Refresh mechanism.

The Unit Timestamp field is provided because the timestamp for a `Market Snapshot` message is the last time an event occurred on that Symbol. Since the Futures market can cross midnight Central Time, the Epoch (midnight, January 1, 1970 UTC) is used as a reference point.

The `Market Snapshot` message comes in two variants: `Market Snapshot (Long)` message and `Market Snapshot (Short)` message. The `Market Snapshot (Short)` message is used whenever possible, but the `Market Snapshot (Long)` message version is used if any of the Price fields cannot be represented by a Binary Short Price (-327.68 to +327.67) or any of the Quantity fields cannot be represented by an unsigned 16-bit value (65536).

**Table 1. Market Snapshot (Short)**

| Field Name | Offset | Length | Type/(Value) | Description |
|---|---|---|---|---|
| Length | 0 | 1 | Binary | Length of this message including this field. |
| Message Type | 1 | 1 | 0xB2 | `Market Snapshot (Short)` message. |
| Time Offset | 2 | 4 | Binary | Nanosecond offset from Unit Timestamp in this message. |
| Symbol | 6 | 6 | Printable ASCII | Six character, base 62 symbol. |
| Unit Timestamp | 12 | 4 | Binary | Last unit timestamp expressed as number of whole seconds since the Epoch (Midnight, January 1, 1970 UTC). |
| Bid Price | 16 | 2 | Binary Short Price | Bid price (may be a zero or negative price for some instruments). |
| Bid Quantity | 18 | 2 | Binary | Number of contracts on the bid side of the inside book (a zero value denotes the Bid Price is invalid). |
| Ask Price | 20 | 2 | Binary Short Price | Ask price (may be a zero or negative price for some instruments). |
| Ask Quantity | 22 | 2 | Binary | Number of contracts on the ask side of the inside book (a zero value denotes the Ask Price is invalid). |
| Last Trade Price | 24 | 2 | Binary Short Price | Price of last execution (this can be zero or negative for some instruments). |
| Last Trade Size | 26 | 2 | Binary | Number of contracts traded on the last trade (if this value is 0 the Last Trade Price is invalid). |
| Last Trade Condition | 28 | 1 | Alphanumeric | Trade Condition for Last Trade `(Space)` = Normal trade `O` = Opening trade `S` = Spread trade `B` = Block trade `E` = ECRP trade `X` = Trade break `D` = Derived |
| Total Volume | 29 | 4 | Binary | Total number of contracts traded on the current business day. |
| Trading Status | 33 | 1 | Alphanumeric | See Trading Status field of `Trading Status` message. |
| Reserved | 34 | 3 | Alphanumeric | Reserved for use in other markets. |
| Total Length = 37 bytes |  |  |  |  |

**Table 2. Market Snapshot (Long)**

| Field Name | Offset | Length | Type/(Value) | Description |
|---|---|---|---|---|
| Length | 0 | 1 | Binary | Length of this message including this field. |
| Message Type | 1 | 1 | 0xB3 | `Market Snapshot (Long)` message. |
| Time Offset | 2 | 4 | Binary | Nanosecond offset from Unit Timestamp in this message. |
| Symbol | 6 | 6 | Printable ASCII | Six character, base 62 symbol. |
| Unit Timestamp | 12 | 4 | Binary | Last unit timestamp expressed as number of whole seconds since the Epoch (Midnight, January 1, 1970 UTC). |
| Bid Price | 16 | 8 | Binary Price | Bid price (may be a zero or negative price for some instruments). |
| Bid Quantity | 24 | 4 | Binary | Number of contracts on the bid side of the inside book (a zero value denotes the Bid Price is invalid). |
| Ask Price | 28 | 8 | Binary Price | Ask price (may be a zero or negative price for some instruments). |
| Ask Quantity | 36 | 4 | Binary | Number of contracts on the ask side of the inside book (a zero value denotes the Ask Price is invalid). |
| Last Trade Price | 40 | 8 | Binary Price | Price of last execution (this can be zero or negative for some instruments). |
| Last Trade Size | 48 | 4 | Binary | Number of contracts traded on the last trade (if this value is 0 the Last Trade Price is invalid). |
| Last Trade Condition | 52 | 1 | Alphanumeric | Trade Condition for Last Trade `(Space)` = Normal trade `O` = Opening trade `S` = Spread trade `B` = Block trade `E` = ECRP trade `X` = Trade break `D` = Derived |
| Total Volume | 53 | 4 | Binary | Total number of contracts traded on the current business day. |
| Trading Status | 57 | 1 | Alphanumeric | See Trading Status field of `Trading Status` message. |
| Reserved | 58 | 3 | Alphanumeric | Reserved for use in other markets. |
| Total Length = 61 bytes |  |  |  |  |

### Market Update Messages

Market Update messages reflect real-time events to the current state of the market. These messages are always sequenced and may be recovered via the Gap Request Proxy (GRP).

#### Single Side Update Message Fields

`Single Side Update` messages provide an updated price and size for a single side of a Symbol. The side is denoted by the Side field. One `Single Side Update` message may reflect one or more updates to the inside book that were processed at the same time, but will only be done so in a way that can be arbitrated between A/B feeds.

`Single Side Update` messages come in two variants: `Single Side Update (Long)` message and `Single Side Update (Short)` message. The `Single Side Update (Short)` message is used whenever possible, but the `Single Side Update (Long)` message is used whenever the Price cannot be represented by a Binary Short Price or the Quantity cannot be represented by an unsigned 16-bit integer.

**Table 1. Single Side Update (Short)**

| Field Name | Offset | Length | Type/(Value) | Description |
|---|---|---|---|---|
| Length | 0 | 1 | Binary | Length of this message including this field. |
| Message Type | 1 | 1 | 0xB4 | `Single Side Update (Short)` message. |
| Time Offset | 2 | 4 | Binary | Nanosecond offset from last unit timestamp. |
| Symbol | 6 | 6 | Printable ASCII | Six character, base 62 symbol. |
| Side | 12 | 1 | Alphanumeric | `B` = Bid side `S` = Ask side |
| Price | 13 | 2 | Binary Short Price | Price (may be a zero or negative price for some instruments). |
| Quantity | 15 | 2 | Binary | Number of contracts on the inside book (a zero value denotes the Price is invalid). |
| Total Length = 17 bytes |  |  |  |  |

**Table 2. Single Side Update (Long)**

| Field Name | Offset | Length | Type/(Value) | Description |
|---|---|---|---|---|
| Length | 0 | 1 | Binary | Length of this message including this field. |
| Message Type | 1 | 1 | 0xB5 | `Single Side Update (Long)` message. |
| Time Offset | 2 | 4 | Binary | Nanosecond offset from last unit timestamp. |
| Symbol | 6 | 6 | Printable ASCII | Six character, base 62 symbol. |
| Side | 12 | 1 | Alphanumeric | `B` = Bid side `S` = Ask side |
| Price | 13 | 8 | Binary Price | Price (may be a zero or negative price for some instruments). |
| Quantity | 21 | 4 | Binary | Number of contracts on the inside book (a zero value denotes the Price is invalid). |
| Total Length = 25 bytes |  |  |  |  |

#### Two Side Update Message Fields

`Two Side Update` messages provide an updated price and size for both sides of a Symbol. One `Two Side Update` message may reflect one or more updates to the inside book that were processed at the same time, but will only be done so in a way that can be arbitrated between A/B feeds.

`Two Side Update` messages come in two variants: `Two Side Update (Long)` message and `Two Side Update (Short)` message. The `Two Side Update (Short)` message is used whenever possible, but the `Two Side Update (Long)` message is used whenever the Price cannot be represented by a Binary Short Price or the Quantity cannot be represented by an unsigned 16-bit integer.

**Table 1. Two Side Update (Short)**

| Field Name | Offset | Length | Type/(Value) | Description |
|---|---|---|---|---|
| Length | 0 | 1 | Binary | Length of this message including this field. |
| Message Type | 1 | 1 | 0xB6 | `Two Side Update (Short)` message. |
| Time Offset | 2 | 4 | Binary | Nanosecond offset from Unit Timestamp in this message. |
| Symbol | 6 | 6 | Printable ASCII | Six character, base 62 symbol. |
| Bid Price | 12 | 2 | Binary Short Price | Bid price (may be a zero or negative price for some instruments). |
| Bid Quantity | 14 | 2 | Binary | Number of contracts on the bid side of the inside book (a zero value denotes the Bid Price is invalid). |
| Ask Price | 16 | 2 | Binary Short Price | Ask price (may be a zero or negative price for some instruments). |
| Ask Quantity | 18 | 2 | Binary | Number of contracts on the ask side of the inside book (a zero value denotes the Ask Price is invalid). |
| Total Length = 20 bytes |  |  |  |  |

**Table 2. Two Side Update (Long)**

| Field Name | Offset | Length | Type/(Value) | Description |
|---|---|---|---|---|
| Length | 0 | 1 | Binary | Length of this message including this field. |
| Message Type | 1 | 1 | 0xB7 | `Two Side Update (Long)` message. |
| Time Offset | 2 | 4 | Binary | Nanosecond offset from Unit Timestamp in this message. |
| Symbol | 6 | 6 | Printable ASCII | Six character, base 62 symbol. |
| Bid Price | 12 | 8 | Binary Price | Bid price (may be a zero or negative price for some instruments). |
| Bid Quantity | 20 | 4 | Binary | Number of contracts on the bid side of the inside book (a zero value denotes the Bid Price is invalid). |
| Ask Price | 24 | 8 | Binary Price | Ask price (may be a zero or negative price for some instruments). |
| Ask Quantity | 32 | 4 | Binary | Number of contracts on the ask side of the inside book (a zero value denotes the Ask Price is invalid). |
| Total Length = 36 bytes |  |  |  |  |

#### TOP Trade Message Fields

The `TOP Trade` message provides information about executions of orders on the CFE book. `TOP Trade` messages are necessary to calculate CFE execution-based data. `TOP Trade` messages do not alter the book. One or more `Single Side Update` or `Two Side Update` messages will follow a `TOP Trade` message to reflect the updated book (for example, an aggressive order may take out one or more price levels and establish a new level on the opposite side).

Any order may be executed in parts. A complete view of all CFE executions can be built from all `TOP Trade` messages.

The `TOP Trade` message sends the trade price, trade quantity, execution id, and trade condition of a trade as well as the cumulative volume for the business day. A `TOP Trade` message will be sent for each execution, but not every `TOP Trade` message indicates a trade. The Trade Condition value of `X` (Trade Break) is sent whenever an execution on CFE is broken. Trade breaks are rare and only affect applications that rely upon CFE execution-based data. Trade breaks will contain the Symbol, Quantity, Price, and Execution Id of the original trade. The Total Volume field will be reduced by the number of shares reported in the Quantity field.

**Table 1. TOP Trade**

| Field Name | Offset | Length | Type/(Value) | Description |
|---|---|---|---|---|
| Length | 0 | 1 | Binary | Length of this message including this field. |
| Message Type | 1 | 1 | 0xB8 | `TOP Trade` message. |
| Time Offset | 2 | 4 | Binary | Nanosecond offset from last unit timestamp. |
| Symbol | 6 | 6 | Printable ASCII | Six character, base 62 symbol. |
| Quantity | 12 | 4 | Binary | Incremental number of contracts executed or corrected (see Trade Condition). |
| Price | 16 | 8 | Binary Price | The execution price of the order. |
| Execution Id | 24 | 8 | Binary | CFE generated day-unique execution identifier of this trade. Execution Id is also referenced in the `Trade Break` message. |
| Total Volume | 32 | 4 | Binary | Total number of contracts traded on the current business day (may decrease if the Trade Condition field indicates a canceled trade). |
| Trade Condition | 36 | 1 | Alphanumeric | `(Space)` = Normal trade `O` = Opening trade 1 `S` = Spread trade 1 `B` = Block trade `E` = ECRP trade `D` = Derived 1 Sent for simple (non-spread) symbols only. |
| Total Length = 37 bytes |  |  |  |  |

### End of Day Messages

Several different message types are sent after the close to signify the end of a Trading Day.

#### Settlement Message Fields

Settlement messages are used to provide information concerning indicative, approved, or corrected daily and final settlement prices for CFE products. An indicative daily settlement price (Issue = I) is calculated by the system and sent immediately after an instrument closes trading but before the settlement price is approved. An approved settlement price (Issue = S) is sent once the CFE Trade Desk approves a settlement price for an instrument. If there is an error in the approved settlement price, then it may be re-issued (Issue = R). For symbols that settle each day using VWAP, the system will begin disseminating an intermediate indicative price update (Issue = i) at 2:59:35 (following the first interval of the VWAP calculation) that will be sent every five seconds leading up to the receipt of the indicative daily settlement price (Issue = I).

`Settlement` messages will be included in a spin response.

**Table 1. Settlement**

| Field Name | Offset | Length | Type/(Value) | Description |
|---|---|---|---|---|
| Length | 0 | 1 | Binary | Length of this message including this field. |
| Message Type | 1 | 1 | 0xB9 | `Settlement` message. |
| Time Offset | 2 | 4 | Binary | Nanosecond offset from last unit timestamp. |
| Symbol | 6 | 6 | Printable ASCII | Six character, base 62 symbol. |
| Trade Date | 12 | 4 | Binary Date | Trade Date for the settlement. |
| Settlement Price | 16 | 8 | Binary Price | Settlement Price |
| Issue | 24 | 1 | Alphanumeric | `i` = Periodic Indicative Settlement `I` = Indicative Settlement `S` = Initial Settlement `R` = Re-issued Settlement |
| Total Length = 25 bytes |  |  |  |  |

#### End of Day Summary Message Fields

The `End of Day Summary` message is sent out right after trading ends for a symbol. No more Market Update messages will follow an `End of Day Summary` message for a particular symbol. A value of zero in the Total Volume field means that no volume traded on that symbol for the day. The Total Volume field reflects all contracts traded during the day. Block, ECRP, and Derived trades are included in the Total Volume field, but they are also reported separately to provide more detail.

The Summary Flags field provides additional information on how to interpret the High Price and Low Price fields, especially in instruments that had no volume for the day and/or where `0` is a valid price (e.g. Trade At Settlement products). There are flags that indicate whether or not the High Price and Low Price fields are valid. If they are not valid, then there was no High (and/or Low) Price for the day. There are also flags that indicate whether the High Price was set by the highest bid and the Low Price was set by the lowest offer rather than a trade.

All `End of Day Summary` message values will span the full trading day, including all extended hours trading and all trading segments.

**Table 1. End of Day Summary**

| Field Name | Offset | Length | Type/(Value) | Description |
|---|---|---|---|---|
| Length | 0 | 1 | Binary | Length of this message including this field. |
| Message Type | 1 | 1 | 0xBA | `End of Day Summary` message. |
| Time Offset | 2 | 4 | Binary | Nanosecond offset from last unit timestamp. |
| Symbol | 6 | 6 | Printable ASCII | Six character, base 62 symbol. |
| Trade Date | 12 | 4 | Binary Date | Trade Date for the message. |
| Open Interest | 16 | 4 | Binary | Prior Trade Date Open Interest for this symbol. |
| High Price | 20 | 8 | Binary Price | The higher of highest bid price and highest trade price for the day. Block and ECRP trades (Trade Condition = B or E) do not update High Price. |
| Low Price | 28 | 8 | Binary Price | The lower of lowest offer price and lowest trade price for the day. Block and ECRP trades (Trade Condition = B or E) do not update Low Price. |
| Open Price | 36 | 8 | Binary Price | The first trade on the day (in any session) will set the Open Price for the day (valid only if Total Volume > 0). Block and ECRP trades (Trade Condition = B or E) do not update Open Price. |
| Close Price | 44 | 8 | Binary Price | The last trade on the day (in any session) will set the Close Price for the day (valid only if Total Volume > 0). Block and ECRP trades (Trade Condition = B or E) do not update Close Price. |
| Total Volume | 52 | 4 | Binary | Total number of contracts traded for the day, including Block, ECRP, and Derived trades. |
| Block Volume | 56 | 4 | Binary | Total number of block contracts traded for the day. |
| ECRP Volume | 60 | 4 | Binary | Total number of contracts traded for the day. |
| Summary Flags | 64 | 1 | Bit Field | `Bit 0` = High Price Valid - Set if High Price is a valid value. `Bit 1` = High Price is bid- Set if High Price was set by the highest bid (rather than a trade). `Bit 2` = Low Price Valid - Set if Low Price is a valid value. `Bit 3` = Low Price is offer - Set if Low Price was set by the lowest offer (rather than a trade). `Bit 4` = Open/Close Valid - Set if both. Open Price and Close Price fields contain valid values `Bit 5-7` = Reserved |
| Total Length = 65 bytes |  |  |  |  |

### Trading Status Message Fields

The `Trading Status` message is used to indicate the current trading status of a Futures contract. A `Trading Status` message will be sent whenever a security's trading status changes. If a `Trading` `Status` message has not been received for a symbol, then the Trading Status for the symbol should be assumed to be `S` = Suspended. The following summarizes the Trading Status values in the CFE system:

- `S` = Suspended. A contract is in a suspended state when the associated product is closed and not accepting orders
- `Q` = Accepting orders for queuing. Queuing state is used during the Pre-Open for all products. It is also used for spread instruments that may not be tradeable due to Threshold Width
- `T` = Trading. Used for both Extended and Regular Hours trading
- `H` = Halt state. This state is used for Supervisory Halts initiated by the Trade Desk. Orders are not being accepted in this state Table 1. Trading Status Field Name Offset Length Type/(Value) Description Length 0 1 Binary Length of this message including this field. Message Type 1 1 0x31 `Trading Status` message. Time Offset 2 4 Binary Nanosecond offset from last unit timestamp. Symbol 6 6 Printable ASCII Six character, base 62 symbol. Reserved1 12 2 Alpha Reserved Trading Status 14 1 Alpha `S` = Suspended `Q` = Queuing `T` = Trading `H` = Halted Reserved2 15 3 Alphanumeric Reserved Total Length = 18 bytes

### Open Interest Message Fields

The `Open Interest` message is sent to communicate a symbol's open interest, usually for the prior trading date. This message will be sent when open interest information is made available to CFE and may be sent multiple times if there are changes to the open interest for a symbol. The open interest is also populated in the `End of Day Summary` message.

**Table 1. Open Interest**

| Field Name | Offset | Length | Type/(Value) | Description |
|---|---|---|---|---|
| Length | 0 | 1 | Binary | Length of this message including this field. |
| Message Type | 1 | 1 | 0xD3 | `Open Interest` message. |
| Time Offset | 2 | 4 | Binary | Nanosecond offset from last unit timestamp. |
| Symbol | 6 | 6 | Printable ASCII | Six character, base 62 symbol. |
| Trade Date | 12 | 4 | Binary Date | Trade Date for the Open Interest data. |
| Open Interest | 16 | 4 | Binary | Open Interest for this symbol. |
| Total Length = 20 bytes |  |  |  |  |

### End of Session Message Fields

The `End of Session` message is sent for each unit when the unit shuts down. No more sequenced messages will be delivered for this unit, but heartbeats from the unit may be received.

**Table 1. End of Session**

| Field Name | Offset | Length | Type/(Value) | Description |
|---|---|---|---|---|
| Length | 0 | 1 | Binary | Length of this message including this field. |
| Message Type | 1 | 1 | 0x2D | `End of Session` message. |
| Timestamp | 2 | 4 | Binary | Nanosecond offset from last unit timestamp. |
| Total Length = 6 bytes |  |  |  |  |

## Gap Request Proxy Messages

The following messages are used for initializing a TCP/IP connection to the Gap Request Proxy (GRP) and to request message retransmissions. Participants only need to implement the following messages if gap requests will be made. The following messages will not be delivered using multicast.

### Login Message Fields

The `Login` message is the first message sent to the GRP by a user's process after the connection to the GRP is established. Failure to login before sending any other message type will result in the connection being dropped by the GRP.

**Table 1. Login**

| Field | Offset | Length | Value/Type | Description |
|---|---|---|---|---|
| Length | 0 | 1 | Binary | Length of this message including this field. |
| Message Type | 1 | 1 | 0x01 | `Login` message. |
| SessionSubId | 2 | 4 | Alphanumeric | SessionSubId supplied by CFE. |
| Username | 6 | 4 | Alphanumeric | Username supplied by CFE. |
| Filler | 10 | 2 | Alphanumeric | (space filled) |
| Password | 12 | 10 | Alphanumeric | Password supplied by CFE. |
| Total Length = 22 bytes |  |  |  |  |

### Login Response Message Fields

The `Login Response` message is sent by the GRP to a user's process in response to a `Login` message. The status field is used to reflect an accepted login or the reason the session was not accepted. If login fails, the connection will be dropped after the `Login Response` message is sent.

**Table 1. Login Response**

| Field | Offset | Length | Value/Type | Description |
|---|---|---|---|---|
| Length | 0 | 1 | Binary | Length of this message including this field. |
| Message Type | 1 | 1 | 0x02 | `Login Response` message. |
| Status | 2 | 1 | Alphanumeric | Accepted or reason for reject. |
| Total Length = 3 bytes |  |  |  |  |
| Login Response - Status Codes |  |  |  |  |
| ‘A’ | Login Accepted |  |  |  |
| ‘N’ | Not authorized (Invalid Username/Password) |  |  |  |
| ‘B’ | Session in use |  |  |  |
| ‘S’ | Invalid Session |  |  |  |

### Gap Request Message Fields

The `Gap Request` message is used by a user's process to request retransmission of a sequenced message (or messages) by one of CFE's gap servers.

**Table 1. Gap Request**

| Field | Offset | Length | Value/Type | Description |
|---|---|---|---|---|
| Length | 0 | 1 | Binary | Length of this message including this field. |
| Message Type | 1 | 1 | 0x03 | `Gap Request` message |
| Unit | 2 | 1 | Binary | Unit that the gap is requested for. |
| Sequence | 3 | 4 | Binary | Sequence of first message (lowest sequence in range). |
| Count | 7 | 2 | Binary | Count of messages requested. |
| Total Length = 9 bytes |  |  |  |  |

### Gap Response Message Fields

The `Gap Response` message is sent by the GRP in response to a `Gap Request` message. The Unit and Sequence fields will match the values supplied in the `Gap Request` message. A `Gap Response` message, with a status of `A` = Accepted or reason for failure, will be sent for each `Gap Request` message received by the GRP.

**Table 1. Gap Response**

| Field | Offset | Length | Value/Type | Description |
|---|---|---|---|---|
| Length | 0 | 1 | Binary | Length of this message including this field. |
| Message Type | 1 | 1 | 0x04 | `Gap Response` message. |
| Unit | 2 | 1 | Binary | Unit the gap was requested for. |
| Sequence | 3 | 4 | Binary | Sequence of first message in request. |
| Count | 7 | 2 | Binary | Count of messages requested. |
| Status | 9 | 1 | Alphanumeric | Accepted or reason for reject*. |
| Total Length = 10 bytes |  |  |  |  |
| Gap Response - Status Codes |  |  |  |  |
| ‘A’ | Accepted |  |  |  |
| ‘O’ | Out of range (ahead of sequence or too far behind) |  |  |  |
| ‘D’ | Daily gap request allocation exhausted |  |  |  |
| ‘M’ | Minute gap request allocation exhausted |  |  |  |
| ‘S’ | Second gap request allocation exhausted |  |  |  |
| ‘C’ | Count request limit for one gap request exceeded |  |  |  |
| ‘I’ | Invalid Unit specified in request |  |  |  |
| ‘U’ | Unit is currently unavailable |  |  |  |

*All non-`A` status codes should be interpreted as a reject.

## Spin Messages

### Login

The `Login` message is the first message sent to the Spin Server by a user's process after the connection to the Spin Server is established. Failure to login before sending any other message type will result in the connection being dropped by the Spin Server.

The format of the `Login` message for the Spin Server is identical to that of the GRP described previously in Login Message Fields.

### Login Response

The `Login Response` message is sent by the Spin Server to a user's process in response to a `Login` message. The status field is used to reflect an accepted login or the reason the session was not accepted. If login fails, the connection will be dropped after the `Login Response` message is sent.

The format of the `Login Response` message for the Spin Server is identical to that of the GRP described previously in Login Response Message Fields.

### Spin Image Available Message Fields

The `Spin Image Available` message is sent once per second and indicates through what sequence number a spin is available.

**Table 1. Spin Image Available**

| Field Name | Offset | Length | Type/(Value) | Description |
|---|---|---|---|---|
| Length | 0 | 1 | Binary | Length of this message including this field. |
| Message Type | 1 | 1 | 0x80 | `Spin Image Available` message. |
| Sequence | 2 | 4 | Binary | Spin is available which is current through this sequence number. |
| Total Length = 6 bytes |  |  |  |  |

### Spin Request Message Fields

The `Spin Request` message is used by a user's process to request transmission of a spin of the unit's order book. Refer to Spin Servers for more complete details regarding Sequence specification as well as buffering requirements.

**Table 1. Spin Request**

| Field Name | Offset | Length | Type/(Value) | Description |
|---|---|---|---|---|
| Length | 0 | 1 | Binary | Length of this message including this field. |
| Message Type | 1 | 1 | 0x81 | `Spin Request` message. |
| Sequence | 2 | 4 | Binary | Sequence number from a `Spin Image Available` message received by the participant. |
| Total Length = 6 bytes |  |  |  |  |

### Spin Response Message Fields

The `Spin Response` message is sent in response to a user's `Spin Request` message indicating whether a spin will be sent.

**Table 1. Spin Response**

| Field Name | Offset | Length | Type/(Value) | Description |
|---|---|---|---|---|
| Length | 0 | 1 | Binary | Length of this message including this field. |
| Message Type | 1 | 1 | 0x82 | `Spin Response` message |
| Sequence | 2 | 4 | Binary | Sequence number from a `Spin Image Available` message received by the participant. |
| Order Count | 6 | 4 | Binary | Number of `Add Order` messages which will be contained in this spin. |
| Status | 10 | 1 | Alphanumeric | Accepted or reason for reject*. |
| Total Length = 11 bytes |  |  |  |  |
| Spin Response - Status Codes |  |  |  |  |
| ‘A’ | Accepted |  |  |  |
| ‘O’ | Out of Range (Sequence requested is greater than Sequence available by the next spin) |  |  |  |
| ‘S’ | Spin already in progress (only one spin can be running at a time). |  |  |  |

*All non-`A` status codes should be interpreted as a reject.

### Spin Finished Message Fields

The `Spin Finished` message is sent to indicate that all messages for the spin requested have been sent. A `Spin Finished` message is only sent if a `Spin Request` message was not rejected. Upon receipt of a `Spin Finished` message, any buffered multicast messages should be applied to the participant's copy of the book to make it current.

**Table 1. Spin Finished**

| Field Name | Offset | Length | Type/(Value) | Description |
|---|---|---|---|---|
| Length | 0 | 1 | Binary | Length of this message including this field. |
| Message Type | 1 | 1 | 0x83 | `Spin Finished` message |
| Sequence | 2 | 4 | Binary | Sequence number from the `Spin Request` message. |
| Total Length = 6 bytes |  |  |  |  |

### Spin Server Usage Example

The following diagram shows the exchange of messages over time between a participant and CFE's Multicast TOP feed and Spin Server. Note that while the example may seem to imply `Market Snapshot` messages only would be sent on a Spin, this is not the case. `Trading Status` message may be sent at the beginning of the spin session and `Time` messages may be found mixed between `Market Snapshot` messages according to their timestamps.

At time 1, the participant has no state of the book and desires to become current. The participant caches the received Multicast TOP messages (sequences 310172 and 310173) for later use. Since the participant has no book, they cannot yet be applied.

At time 5, the participant has successfully logged into the Spin Server and has cached another message, sequence 310174.

At time 7, the participant receives a `Spin Image Available` message which indicates that the spin server is capable of giving them a spin of all symbols as of sequence 310169. The participant does not have all messages cached after 310169 (they are missing 310170 and 310171), so this spin is not useful to the participant.

At time 10, the participant receives a `Spin Image Available` message which is useful since it would be a spin of all orders up to and including sequence 310175 and the participant has all messages after 310175 cached.

At time 11, the participant sends a `Spin Request` message for all messages up to and including 310175 and continues to cache Multicast TOP messages received.

At time 14, the Spin Server acknowledges the `Spin Request` message and indicates that three symbols will be sent.

At time 24, the spin server indicates that it has finished sending all open orders. The participant must then apply the cached messages from sequence number 310176 through current.

Note: Spin Servers are available for each unit. Participants may need to employ multiple Spin Servers depending upon their architecture.

_(Figure)_

## Message Types

### Gap Request Proxy Messages

```
    0x01        Login
    0x02        Login Response
    0x03        Gap Request
    0x04        Gap Response
```

### Spin Server Messages

```
    0x01        Login
    0x02        Login Response
    0x80        Spin Image Available
    0x81        Spin Request
    0x82        Spin Response
    0x83        Spin Finished
```

### TOP Messages

```
    0x20        Time
    0x2D        End of Session
    0x31        Trading Status 
    0xB1        Time Reference
    0xB2        Market Snapshot (Short)
    0xB3         Market Snapshot (Long)
    0xB4        Single Side Update (Short)
    0xB5        Single Side Update (Long)
    0xB6        Two Side Update (Short)
    0xB7        Two Side Update (Long)
    0xB8        TOP Trade
    0xB9        Settlement
    0xBA        End of Day Summary
    0xBB        Futures Instrument Definition
    0xBE        Price Limits
    0xD3        Open Interest
    0xFA        Futures Variance Symbol Mapping
```

## Example Messages

Each of the following message types must be wrapped by a sequenced or un-sequenced unit header as described in CFE Sequenced Unit Header Message Fields. Note that in the following examples, each byte is represented by two hexadecimal digits.

### Login Message Example

**Table 1. Login Message Example**

| Length | 16 | 22 bytes |
|---|---|---|
| Type | 01 | Login |
| SessionSubId | 30 30 30 31 | "0001" |
| Username | 46 49 52 4D | "FIRM" |
| Filler | 20 20 | " " |
| Password | 41 42 43 44 30 30 20 20 20 20 | "ABCD00" |

### Login Response Message Example

**Table 1. Login Response Message Example**

| Length | 03 | 3 bytes |
|---|---|---|
| Type | 02 | Login Response |
| Status | 41 | Login accepted |

### Gap Request Message Example

**Table 1. Gap Request Message Example**

| Length | 09 | 9 bytes |
|---|---|---|
| Type | 03 | Gap Request |
| Unit | 01 | Unit 1 |
| Sequence | 3B 10 00 00 | First message: 4155 |
| Count | 32 00 | 50 messages |

### Gap Response Message Example

**Table 1. Gap Response Message Example**

| Length | 08 | 8 bytes |
|---|---|---|
| Type | 04 | Gap Response |
| Unit | 01 | Unit 1 |
| Sequence | 3B 10 00 00 | First message: 4155 |
| Status | 41 | Accepted |

### Spin Image Available Message Example

**Table 1. Spin Image Available Message Example**

| Length | 06 | 6 bytes |
|---|---|---|
| Type | 80 | Spin Image Available |
| Sequence | 3B 10 00 00 | Sequence: 4155 |

### Spin Request Message Example

**Table 1. Spin Request Message Example**

| Length | 06 | 6 bytes |
|---|---|---|
| Type | 81 | Spin Request |
| Sequence | 3B 10 00 00 | Sequence: 4155 |

### Spin Response Message Example

**Table 1. Spin Response Message Example**

| Length | 0B | 11 bytes |
|---|---|---|
| Type | 82 | Spin Request |
| Sequence | 3B 10 00 00 | Sequence: 4155 |
| Order Count | 42 00 00 00 | 66 orders |
| Status | 41 | Accepted |

### Spin Finished Message Example

**Table 1. Spin Finished Message Example**

| Length | 06 | 6 bytes |
|---|---|---|
| Type | 83 | Spin Finished |
| Sequence | 3B 10 00 00 | Sequence: 4155 |

### Time Message Example

**Table 1. Time Message Example**

| Length | 0A | 10 bytes |
|---|---|---|
| Type | 20 | Time |
| Time | 98 85 00 00 | 34,200 seconds = 09:30 AM Central |
| Epoch Time | F8 27 94 5A | 1519659000 = February 26, 2018 9:30:00 AM Central |

### Unit Clear Message Example

**Table 1. Unit Clear Message Example**

| Length | 06 | 6 bytes |
|---|---|---|
| Type | 97 | Unit Clear |
| Time Offset | 18 D2 06 00 | 447,000 ns since last Time Message |

### Time Reference Message Example

**Table 1. Time Reference Message Example**

| Length | 12 | 18 bytes |
|---|---|---|
| Type | B1 | Time Reference |
| Midnight Reference | E0 50 92 5A | 2018-02-25 00:00:00 Central (1519538400 seconds since the Epoch) |
| Time | 00 E1 00 00 | 16:00:00 |
| Time Offset | 00 00 00 00 | Exactly 16:00:00 |
| Trade Date | 02 ED 33 01 | 20180226 February 26, 2018 |

### Market Snapshot (Short) Message Example

**Table 1. Market Snapshot (Short) Message Example**

| Length | 25 | 37 bytes |
|---|---|---|
| Type | B2 | Market Snapshot (Short) |
| Time Offset | 08 5C 44 25 | 625,237,000 ns |
| Symbol | 30 31 32 33 34 35 | 012345 |
| Unit Timestamp | E6 EB 99 5A | 2018-03-02 12:27:18 Central (1520036838 seconds since the Epoch) |
| Bid Price | 41 01 | $3.21 |
| Bid Size | BC 02 | 700 contracts |
| Ask Price | B0 01 | $4.32 |
| Ask Size | 84 03 | 900 contracts |
| Last Trade Price | 8F 01 | $3.99 |
| Last Trade Size | FE FF | 65,534 contracts |
| Last Trade Condition | 20 | (space) Normal Trade |
| Total Volume | 32 54 76 98 | 2,557,891,634 contracts |
| Trading Status | 54 | T - Trading |
| Reserved | 31 20 20 | Reserved |

### Market Snapshot (Long) Message Example

**Table 1. Market Snapshot (Long) Message Example**

| Length | 2D | 61 bytes |
|---|---|---|
| Type | B3 | Market Snapshot (Long) |
| Time Offset | 08 5C 44 25 | 625,237,000 ns |
| Symbol | 30 31 32 33 34 35 | 012345 |
| Unit Timestamp | E6 EB 99 5A | 2018-03-02 12:27:18 Central (1520036838 seconds since the Epoch) |
| Bid Price | 9C 82 FF FF FF FF FF FF | $-3.21 |
| Bid Size | BC 02 00 00 | 700 contracts |
| Ask Price | E0 F4 8F 04 00 00 00 00 | $7,654.32 |
| Ask Size | 84 03 00 00 | 900 contracts |
| Last Trade Price | DC 9B 00 00 00 00 00 00 | $3.99 |
| Last Trade Size | 64 00 00 00 | 100 contracts |
| Last Trade Condition | 20 | (space) Normal Trade |
| Total Volume | 78 56 34 12 | 305,419,896 contracts |
| Trading Status | 54 | T - Trading |
| Reserved | 31 20 20 | Reserved |

### Single Side Update (Short) Message Example

**Table 1. Single Side Update (Short) Message Example**

| Length | 11 | 17 bytes |
|---|---|---|
| Type | B4 | Single Side Update (Short) |
| Time Offset | 30 FA D3 29 | 701,758,000 ns since last Time Message |
| Symbol | 30 31 32 33 34 35 | 012345 |
| Side | 42 | B (Buy) |
| Price | 0C 30 | $1.23 |
| Quantity | 64 00 | 100 contracts |

### Single Side Update (Short, Negative Price) Message Example

**Table 1. Single Side Update (Short, Negative Price) Message Example**

| Length | 11 | 17 bytes |
|---|---|---|
| Type | B4 | Single Side Update (Short) |
| Time Offset | 30 FA D3 29 | 701,758,000 ns since last Time Message |
| Symbol | 30 31 32 33 34 35 | 012345 |
| Side | 42 | B (Buy) |
| Price | 85 FF | $-1.23 |
| Quantity | C8 00 | 200 contracts |

### Single Side Update (Long) Message Example

**Table 1. Single Side Update (Long) Message Example**

| Length | 1B | 27 bytes |
|---|---|---|
| Type | B5 | Single Side Update (Long) |
| Time Offset | 30 FA D3 29 | 701,758,000 ns since last Time Message |
| Symbol | 30 31 32 33 34 35 | 012345 |
| Side | 42 | B (Buy) |
| Price | 0C 30 00 00 00 00 00 00 | $1.23 |
| Quantity | 64 00 00 00 | 100 contracts |

### TOP Trade Message Example

**Table 1. TOP Trade Message Example**

| Length | 25 | 37 bytes |
|---|---|---|
| Type | B8 | Trade |
| Time Offset | 10 84 D4 23 | 601,130,000 ns since last Time Message |
| Symbol | 36 35 34 33 32 31 | 654321 |
| Quantity | BC 02 00 00 | 700 contracts |
| Price | 08 E2 01 00 00 00 00 00 | $12.34 |
| Execution Id | 34 2B 46 E0 BB 00 00 00 | 0AAP09VEC |
| Total Volume | 40 42 0F 00 00 00 00 00 | 1,000,000 contracts |
| Trade Condition | 20 | Normal Trade (space) |

### TOP Trade (Condition = Trade Break) Message Example

**Table 1. TOP Trade (Condition = Trade Break) Message Example**

| Length | 25 | 37 bytes |
|---|---|---|
| Type | B8 | Trade |
| Time Offset | 10 84 D4 23 | 601,130,000 ns since last Time Message |
| Symbol | 36 35 34 33 32 31 | 654321 |
| Quantity | BC 02 00 00 | 700 contracts |
| Price | 08 E2 01 00 00 00 00 00 | $12.34 |
| Execution Id | 34 2B 46 E0 BB 00 00 00 | 0AAP09VEC |
| Total Volume | 84 3F 0F 00 00 00 00 00 | 999,300 contracts |
| Trade Condition | 58 | X - Trade Break |

### Settlement Message Example

**Table 1. Settlement Message Example**

| Length | 19 | 25 bytes |
|---|---|---|
| Type | B9 | Settlement |
| Time Offset | 60 84 8E 00 | 9,340,000 ns since last Time Message |
| Symbol | 36 35 34 33 32 31 | 654321 |
| Reserved | 20 20 |  |
| Trade Date | 03 ED 33 01 | 20180227 February 27, 2018 |
| Settlement Price | 4C F8 06 00 00 00 00 00 | $45.67 |
| Issue | 53 | S – Initial Settlement |

### Open Interest Message Example

**Table 1. Open Interest Message Example**

| Length | 19 | 20 bytes |
|---|---|---|
| Type | D3 | Open Interest |
| Time Offset | 60 84 8E 00 | 9,340,000 ns since last Time Message |
| Symbol | 36 35 34 33 32 31 | 654321 |
| Trade Date | A9 3C 34 01 | 20200617 June 17, 2020 |
| Open Interest | B1 68 DE 3A | 987,654,321 contracts |

### End of Day Summary Message Example

**Table 1. End of Day Summary Message Example**

| Length | 41 | 65 bytes |
|---|---|---|
| Type | BA | End of Day Summary |
| Time Offset | 18 D2 06 00 | 447,000 ns since last Time Message |
| Symbol | 39 38 37 36 35 34 | 987654 |
| Open Interest | B1 68 DE 3A | 987,654,321 contracts |
| High Price | DC FB 09 00 00 00 00 00 | $65.43 |
| Low Price | 08 E2 01 00 00 00 00 00 | $12.34 |
| Open Price | E0 49 08 00 00 00 00 00 | $54.32 |
| Close Price | F8 A9 08 00 00 00 00 00 | $56.78 |
| Total Volume | 15 CD 5B 07 00 00 00 00 | 123,456,789 contracts |
| Block Volume | 88 13 00 00 | 5,000 Block contracts |
| ECRP Volume | E8 03 00 00 | 1,000 ECRP contracts |
| Summary Flags | 15 | High Price Valid 0x01 |
| Low Price Valid 0x04 |  |  |
| Has Open/Close 0x10 |  |  |

### Futures Instrument Definition (Contract Date Different from Expiration Date) Message Example

**Table 1. Futures Instrument Definition (Contract Date Different from Expiration Date) Message Example**

| Length | 2D | 45 bytes |
|---|---|---|
| Type | BB | Futures Instrument Definition Message |
| Time Offset | E8 61 BF 23 | 599,745,000 ns since Last Time Message |
| Symbol | 30 30 30 33 6C 4E | 0003lN |
| Unit Timestamp | 75 2D 40 5E | 2020-02-09 10:04:05 Central Time (1581264245 seconds since Epoch) |
| Report Symbol | 41 4D 42 33 20 20 | AMB3 |
| Futures Flags | 00 | 0 |
| Expiration Date | D4 3D 34 01 | 20200916 – September 16, 2020 |
| Contract Size | 19 00 | 25 |
| Listing State | 41 | A - Active |
| Price Increment | C4 09 00 00 00 00 00 00 | $0.25 |
| Leg Count | 00 | 0 legs |
| Leg Offset | 00 | 0 – No Legs |
| Reserved | 00 | 0 – Reserved |
| Contract Date | A9 3C 34 01 | 20200617 – June 17, 2020 |

### Futures Instrument Definition (Contract Date Same as Expiration Date) Message Example

**Table 1. Futures Instrument Definition (Contract Date Same as Expiration Date) Message Example**

| Length | 2D | 45 bytes |
|---|---|---|
| Type | BB | Futures Instrument Definition Message |
| Time Offset | 80 A3 14 27 | 655,664,000 ns since Last Time Message |
| Symbol | 30 30 30 33 69 34 | 0003i4 |
| Unit Timestamp | 75 2D 40 5E | 2020-02-09 10:04:05 Central Time (1581264245 seconds since Epoch) |
| Report Symbol | 56 58 20 20 20 20 | VX |
| Futures Flags | 00 | 0 |
| Expiration Date | A9 3C 34 01 | 20200617 – June 17, 2020 |
| Contract Size | E8 03 | 1000 |
| Listing State | 41 | A - Active |
| Price Increment | F4 01 00 00 00 00 00 00 | $0.05 |
| Leg Count | 00 | 0 legs |
| Leg Offset | 00 | 0 – No Legs |
| Reserved | 00 | 0 – Reserved |
| Contract Date | A9 3C 34 01 | 20200617 – June 17, 2020 |

### Futures Instrument Definition w/ 2 Legs(Contract Date Populated with Zero value) Message Example

**Table 1. Futures Instrument Definition w/ 2 Legs (Contract Date Populated with Zero value) Message Example**

| Length | 41 | 65 bytes |
|---|---|---|
| Type | BB | Futures Instrument Definition Message |
| Time Offset | E8 61 BF 23 | 599,745,000 ns since Last Time Message |
| Symbol | 30 30 30 33 6C 52 | 0003lR |
| Unit Timestamp | 75 2D 40 5E | 2020-02-09 10:04:05 Central Time (1581264245 seconds since Epoch) |
| Report Symbol | 41 4D 42 33 20 20 | AMB3 |
| Futures Flags | 00 | 0 |
| Expiration Date | A9 3C 34 01 | 20200617 – Wednesday, June 17, 2020 |
| Contract Size | 19 00 | 25 |
| Listing State | 41 | A - Active |
| Price Increment | C4 09 00 00 00 00 00 00 | $0.25 |
| Leg Count | 02 | 2 legs |
| Leg Offset | 2D | Legs begin at byte 45 |
| Reserved | 00 | 0 – Reserved |
| Contract Date | 00 00 00 00 | 0 |
| Leg #1 Ratio | FF FF FF FF | -1 (1 Sell) |
| Leg #1 Symbol | 30 30 30 33 67 75 | 0003gu |
| Leg #2 Ratio | 01 00 00 00 | 1 (1 Buy) |
| Leg #2 Symbol | 30 30 30 33 6C 4E | 0003lN |

### Futures Variance Symbol Mapping Message Example

**Table 1. Futures Variance Symbol Mapping Message Example**

| Length | 28 | 40 bytes |
|---|---|---|
| Type | FA | Futures Variance Symbol Mapping Message |
| Time Offset | E8 61 BF 23 | 599,745,000 ns since Last Time Message |
| Unit Timestamp | E5 CE 44 66 | 2024-05-14 10:04:05 CT |
| Feed Symbol | 30 30 30 33 6C 52 | 0003lR |
| Futures Symbol | 56 41 20 20 20 20 32 34 30 35 31 37 | VA 240517 |
| Accrued Day Variance | E0 3E 3F 56 32 87 00 00 | 148.650265100000 |
| Num Final Returns | 0F 01 | 271 |
| Num Elapsed Returns | 0D 01 | 269 |

### Trading Status Message Example

**Table 1. Trading Status Message Example**

| Length | 12 | 18 bytes |
|---|---|---|
| Type | 31 | Trading Status |
| Time Offset | 18 D2 06 00 | 447,000 ns since last Time Message |
| Symbol | 39 39 38 38 37 37 | 998877 |
| Halt Status | 54 | T = Trading |
| Reserved | 30 20 20 | Reserved |

### Price Limits Message Example

**Table 1. Price Limits Message Example**

| Length | 1C | 28 bytes |
|---|---|---|
| Type | BE | Price Limits |
| Time Offset | 18 D2 06 00 | 447,000 ns since last Time Message |
| Symbol | 31 32 33 34 35 20 | 12345 |
| Upper Price Limit | 08 E2 01 00 00 00 00 00 | $12.34 |
| Lower Price Limit | 8C 81 01 00 00 00 00 00 | $9.87 |

### Sequenced Unit Header with 2 Messages

**Table 1. Sequenced Unit Header with 2 Messages**

| Sequenced Unit Header Message Example |  |  |
|---|---|---|
| Hdr Length | 3E 00 | 62 bytes, including header |
| Hdr Count | 02 | 2 messages to follow |
| Hdr Unit | 01 | Unit 1 |
| Hdr Sequence | 01 00 00 00 | First message has sequence number 1 |
| Message 1: Trade Message Example |  |  |
| Length | 25 | 37 bytes |
| Type | B4 | Trade |
| Time Offset | 10 84 D4 23 | 601,130,000 ns since last Time Message |
| Symbol | 36 35 34 33 32 31 | 654321 |
| Reserved | 20 20 |  |
| Quantity | BC 02 00 00 | 700 contracts |
| Price | 08 E2 01 00 00 00 00 00 | $12.34 |
| Execution Id | 34 2B 46 E0 BB 00 00 00 | 0AAP09VEC |
|  | 40 42 0F 00 00 00 00 00 | 1,000,000 contracts |
| Trade Condition | 20 | Normal Trade (space) |
| Message 2: Single Side Update Message Example |  |  |
| Length | 11 | 17 bytes |
| Type | B4 | Single Side Update (Short) |
| Time Offset | 30 FA D3 29 | 701,758,000 ns since last Time Message |
| Symbol | 36 35 34 33 32 31 | 654321 |
| Side | 42 | B (Buy) |
| Price | 0C 30 | $1.23 |
| Quantity | 64 00 | 100 contracts |

## Multicast Configuration

### Production Environment Configuration

#### Limitations/Configurations

The following table defines the configuration for network and gap request limitations. These limitations are session based. CFE reserves the right to adjust the gap request limitations to improve the effectiveness of the gap request infrastructure.

**Table 1. CFE Multicast TOP Limitations/Configurations**

| Period/Type | Limit/Setting | Notes |
|---|---|---|
| MTU | 1500 | CFE will send UDP messages up to 1500 bytes. Participants should ensure that their infrastructure is configured accordingly. |
| WAN-Shaped Throttle | 100 Mb/s | The real-time and gap multicast head ends are configured to shape their output to this level to minimize packet loss. |
| Gap Response Delay | 2 ms | The Gap Server will delay resending sequenced messages via multicast for the specified limit in order to satisfy multiple GRP gap requests with one multicast response. |
| Count | 100 | Any single gap request may not be for more than this number of dropped messages. |
| 1 Second | 320 Requests | This is the maximum number of retransmission requests allowed per second for each session. This is renewed every clock second. |
| 1 Minute | 1,500 Requests | This is the maximum number of retransmission requests allowed per minute for each session. This is renewed every clock minute. |
| Day | 100,000 Requests | This is the maximum number of retransmission requests allowed per day for each session. |
| Within Range | 1,000,000 Messages | Users’ retransmission requests must be within this many messages of the most recent sequence sent by the real-time feed per session. |

#### CFE Unit/Product Distribution

The following table describes the CFE symbol distribution across units.

**Table 1. CFE Production/Certification Environment - Unit/Product Distribution**

| Symbol Range | Unit |
|---|---|
| UX, VX, VXT, VXM, VXMT | 1 |
| IBHY, IBIG, IBGO, IBYO, IEMD, MGTN, VA, XBTF | 2 |
| FBT, FET, PBT, PET | 3 |
| N/A | 4 |

Note - CFE reserves the right to add units and/or change symbol distribution with 48 hours of notice and no migration period. Notice will be given that the distribution will change on a certain date. Care should be taken to support mappings in these tables via software configuration.

#### Multicast Routing Parameters

**Table 1. CFE Multicast TOP Routing Parameters - Production**

| Data Center | Rendezvous Point |
|---|---|
| Primary Data Center C feed | 74.115.128.164 |
| Primary Data Center D feed | 74.115.128.165 |
| Secondary Data Center E feed | 170.137.16.128 |

#### Address/Unit Distribution

The following tables describe the unit distribution across the CFE Multicast TOP feeds.

Note - CFE reserves the right to add multicast addresses with prior notice, but no migration period. Notice will be given that the distribution will change on a certain date. Care should be taken to support mappings in these tables via software configuration.

**Table 1. CFE Multicast TOP Address/Unit Distribution - Primary, Production**

| Primary Datacenter | WAN-Shaped [FCT] 74.115.133.96/29 | WAN-Shaped [FDT] 74.115.133.104/29 |  |  |  |
|---|---|---|---|---|---|
| Unit | IP Port | Real-time MC | Gap Resp. MC | Real-time MC | Gap Resp. MC |
| 1 | 30101 | 224.0.131.134 | 224.0.131.135 | 233.130.124.134 | 233.130.124.135 |
| 2 | 30102 |  |  |  |  |
| 3 | 30103 |  |  |  |  |
| 4 | 30104 |  |  |  |  |

**Table 2. CFE Multicast TOP Address/Unit Distribution - Secondary, Production**

| Secondary Datacenter | WAN-Shaped [FET] 170.137.16.80/29 |  |  |
|---|---|---|---|
| Unit | IP Port | Real-time MC | Gap Resp. MC |
| 1 | 31101 | 233.182.199.2 | 233.182.199.3 |
| 2 | 31102 |  |  |
| 3 | 31103 |  |  |
| 4 | 31104 |  |  |

### Certification Environment Configuration

#### CFE Unit/Product Distribution

The following table describes the CFE symbol distribution across units.

**Table 1. CFE Production/Certification Environment - Unit/Product Distribution**

| Symbol Range | Unit |
|---|---|
| UX, VX, VXT, VXM, VXMT | 1 |
| IBHY, IBIG, IBGO, IBYO, IEMD, MGTN, VA, XBTF | 2 |
| FBT, FET, PBT, PET | 3 |
| N/A | 4 |

Note - CFE reserves the right to add units and/or change symbol distribution with 48 hours of notice and no migration period. Notice will be given that the distribution will change on a certain date. Care should be taken to support mappings in these tables via software configuration.

#### Certification Multicast Routing Parameters

**Table 1. CFE Multicast TOP Routing Parameters - Certification**

| Data Center | Rendezvous Point |
|---|---|
| Primary Data Center feed | 74.115.128.130 |

#### Address/Unit Distribution

The following tables describe the unit distribution across the certification CFE Multicast TOP feeds.

Note - CFE reserves the right to add multicast addresses with prior notice, but no migration period. Notice will be given that the distribution will change on a certain date. Care should be taken to support mappings in these tables via software configuration.

**Table 1. CFE Multicast TOP Address/Unit Distribution - Certification**

| Primary Datacenter | WAN-Shaped [Cert] 174.136.160.16/28 |  |  |
|---|---|---|---|
| Unit | IP Port | Real-time MC | Gap Resp. MC |
| 1 | 32101 | 224.0.74.198 | 224.0.74.199 |
| 2 | 32102 |  |  |
| 3 | 32103 |  |  |
| 4 | 32104 |  |  |

## Connectivity

### Supported Extranet Carriers

The WAN-Shaped feed will be made available to participants through extranet carriers that have completed their multicast implementation and certified with CFE on a per-market basis. CFE has certified a number of carriers defined in the Cboe Titanium Cboe Futures Exchange Connectivity Manual with respect to redistribution of CFE Multicast data feeds. For more information on receiving Multicast TOP through any of these providers, reach out to the vendor contact noted in the CFE Connectivity Manual under Extranet Providers.

### Bandwidth Recommendation

The WAN-shaped feeds require 100 Mbps of bandwidth. CFE will use 90% of these respective bandwidths for Multicast TOP to allow participants to use the same physical connection for order entry if desired.

## Support

Please direct questions or comments regarding this specification to cfetradedesk@cboe.com.

### Canned Test Data

Customers are strongly encouraged to capture their own test data from the Certification environment to ensure that their systems can correctly decode the TOP feed and all available message types. To assist firms with their own testing a TOP sample (taken from the Certification environment) is made available at the link below. Cboe does not guarantee that all message types will appear in test data and cautions that canned test data will be updated infrequently and may not fully reflect the current specification.

CFE TOP Test Data (last updated 1/4/18)

## Revision History

| Document Version | Date | Description |
|---|---|---|
| 1.0.0 | 05/01/17 | Initial version. |
| 1.0.1 | 06/28/17 | Updated description for Report Symbol , Leg Offset and Variance Block Offset fields in `Futures Instrument Definition` message. Updated descriptions of Variance Futures fields in `Futures Instrument Definition` message. Added Execution Id field to `TOP Trade` message. `TOP Trade` messages are no longer aggregated; a separate message is generated for every execution. Added `Price Limits` message. |
| 1.0.2 | 07/11/17 | Added Rendevous Points, Source IP addresses, and Multicast IP addresses. |
| 1.0.3 | 08/08/17 | Replaced Binary Long Price with Binary Price. Updated Data Types to include definition of Binary Price. |
| 1.0.4 | 09/21/17 | Renamed Trade Date message to Time Reference. Added Epoch Time field to `Time` message. Fixed discrepancies between Spec and Example Messages. |
| 1.0.5 | 09/26/17 | Corrected feed reference labels in section 8. |
| 1.0.6 | 10/17/17 | Added clarification on `Trading Status` messages for Complex Instruments going in and out of Queuing because of Threshold Width. Cboe branding/logo changes. |
| 1.0.7 | 12/08/17 | Removed LegOffset = 93 value as this value is not possible to be sent. Price limits may apply during any trading hours subject to contract specifications. |
| 1.0.8 | 12/11/17 | Updated `Top Trade` examples to reflect correct message type. |
| 1.0.9 | 12/29/17 | `Trading` `Status` messages for Complex instruments transitioning in and out of Queuing on account of Threshold Width no longer surpressed. Removed associated commentary from `Trading` `Status` message section. Added "I=Inactive" as possible Listing State . Updated Realized Variance, Discount Factor, Previous ARMVM, and Fed Funds Rate to Signed Binary data type. Corrected the offsets for Leg Ratio and Leg Symbol . |
| 1.0.10 | 01/10/18 | Corrected examples for `TOP Trade` . Added Canned Test Data section. |
| 1.0.11 | 01/17/18 | Block and ECRP trades (Trade Condition = B or E) do not update High Price or Low Price. |
| 1.0.12 | 01/25/18 | Updated field description of Symbol to remove "padding" language. The Symbol field is always six characters, base 62. `Price Limits` are included in a spin. Added Feed Hours and System Restart section. Clarified cases where the `Unit` `Clear` message would be sent. More specifics added to how `End of Day Summary` values are determined. If no `Trading Status` has been received for a Symbol , then the Trading Status is "S= Suspended". |
| 1.0.13 | 02/01/18 | Added links to certification and production symbol mapping files. |
| 1.0.14 | 02/21/18 | Fixed discrepancy with the Secondary Data Center listed as CH4 instead of 400 S La Salle. Updated Trade Condition field values to demonstrate that some values are only sent for simple instruments. Additional clarifications added around daily restart based on customer feedback. |
| 1.0.15 | 03/01/18 | Updated description of High Price and Low Price in `End of Day Summary` message. |
| 1.1.0 | 03/22/18 | The `End of Day Summary` message will be enhanced and expanded to 65 bytes: Total Volume will be updated to include Block and ECRP volume, Block Volume field will be added, ECRP Volume field will be added, and Bit Fields field will be added. `End of Day Summary` example was updated. |
| 1.1.1 | 03/23/18 | Updated effective date of `End of Day Summary` message change from 1.1.0 to be effective 06/03/18. |
| 1.1.2 | 05/10/18 | Clarified the cases when sequenced `Futures Instrument Definition` messages are sent. |
| 1.1.3 | 11/08/18 | Updated Overview and and Multicast Routing Parameter sections with new Multicast Feed IDs (A to FC, B to FD, E to FE). Added note clarifying simple leg FID messages come before complex leg FID messages sent in Spin responses. Updated multicast feed ids in section 1.3 to follow standard naming convention. |
| 1.1.4 | 04/08/19 | Updated Multicast Routing Parameter Data Center feed names to align with references in unit distribution table. |
| 1.1.5 | 01/16/20 | Clarified definition of `Time` message. `Time` messages are only sent when there is a new TOP message in a given second. |
| 1.1.6 | 02/14/20 | Added Contract Date field to `Futures Instrument Definition` message. Effective trade date 04/27/20. |
| 1.1.7 | 02/24/20 | Variance Offset and Leg Offset values will be set at 45 as a result of the change to add Contract Date. Refer to `Futures Instrument Definition` message for more details. |
| 1.1.8 | 04/07/20 | Corrected WAN-Shaped feed IDs from "FAT and FBT' to "FCT and FDT" in Feed Connectivity Requirements section. |
| 1.1.9 | 07/27/20 | Updated symbols listed in Unit/Product Distribution tables to include VXT, VXM, and VXMT. |
| 1.1.10 | 01/21/21 | Added new value of `I` = Indicative Settlement to the Issue field on the `Settlement` message (effective 03/22/21). |
| 1.2.0 | 08/17/21 | Added new value of `i` = Periodic Indicative Settlement to the Issue field on the `Settlement` message (effective 10/17/21). Added new `Open Interest` message (effective 10/17/21). |
| 1.2.1 | 10/26/21 | Noted CFE will eliminate the 15 minute trading pause for VX , VXM, and AMERIBOR futures products (effective 12/06/21). |
| 1.2.2 | 11/01/21 | Corrected hyperlinks to Production symbol files and Certification symbol files. |
| 1.2.3 | 12/15/21 | Minor formatting updates. |
| 1.2.4 | 10/09/23 | Added new value of ‘D=Derived’ to Last Trade Condition and Trade Condition fields in the `Top Trade` and `Market Snapshot` messages, and updated section 2.14.2 to indicate Derived trades will be included in the Total Volume field (effective 12/11/23). |
| 1.2.5 | 11/28/23 | Updated hyperlinks to symbol mappings in production and certification environments. |
| 1.2.6 | 12/27/23 | Updated description of `Trading Status` 'Q=Accepting orders for queuing’ to indicate the Queuing state is used for all products, with no exceptions. |
| 1.2.7 | 06/28/24 | Updated section 1.8 to include `Future Variance Symbol Mapping`, added message type `Future Variance Symbol Mapping`, added new message structure for `Futures Instrument Definition` (replacing the current message structure), updated `Variance Block` to Reserved in example messages in section 6.22, 6.23 and 6.24, and added `Future Variance Symbol Mapping` example message (effective 09/23/24). |
| 1.2.8 | 07/15/24 | Noted the `Futures Instrument Definition` message contains general futures contract information and is sent for all futures products, including Variance Futures (effective 09/23/24). |
| 1.2.9 | 08/09/24 | Noted the `Futures Variance Symbol Mapping` message may be sent as a sequenced message intraday if a symbol is modified intraday. Clarified the reason for setting the Futures Flags field of the `Futures Instrument Definition` message to zero. |
| 1.2.10 | 09/05/24 | With the implementation of the new 60 second window for VWAP, the system will begin disseminating an intermediate indicative price update (Issue = i) at 2:59:05 p.m. CT for VX and VXM futures products (effective 09/09/24). |
| 1.2.11 | 11/04/24 | Removed the deprecated `Futures Instrument Definition` message with sunset date 09/23/24. Removed the "effective 09/23/24" annotation on the updated `Futures Instrument Definition` message and the new `Futures Variance Symbol Mapping` message. Added two new Matching Units, plus new port and IP information for Matching Units 2-4 ​(effective 02/03/25)​. |
| 1.2.12 | 01/15/25 | Updated Feed Hours and System Restart to indicate the TOP feed will start up on Sunday at approximately 10:30 a.m. CT. Updated with Cboe Titanium branding. |
| 1.2.13 | 01/27/25 | Updated Contract Size description for Futures Instrument Definition Message Fields . Added FBT and FET to Unit 3 Unit/Product Distribution (effective 06/09/25). |
| 1.2.14 | 04/07/25 | Noted in Spin Servers : a `Time` message will be sent as the last message in a Spin if the last `Time` message sent on a Spin is older than the last received time from the internal market data producers. Added XBTF to Unit 2 CFE Unit/Product Distribution (effective 04/28/25). |
| 1.2.15 | 09/09/25 | Added PBT and PET to Unit 3 CFE Unit/Product Distribution (effective 12/15/25 TBD 11/10/25). |
| 1.2.16 | 10/20/25 | Updated CFE Unit/Product Distribution to include MGTN on Unit 2 (effective 12/08/25) (effective 11/17/25). |
| 1.2.17 | 10/30/25 | Updated Spin Servers to include `End of Day Summary` in list of spin request messages. Updated PBT and PET effective date to 12/15/25 TBD . |
| 1.2.18 | 11/17/25 | Updated PBT and PET effective date to 12/15/25. |
| 1.2.19 | 11/18/25 | Updated MGTN effective date to 12/08/25. |
| 1.2.20 | 01/05/26 | Updated Feed Hours and System Restart to reflect the new time that persisted orders are added back into the order book. |
| 1.2.21 | x/x/26 | Updated Time description in `Time` and `Time Reference` messages. |