# Cboe Titanium U.S. Options Complex Multicast TOP Specification

Version 1.1.59 · August 10, 2026

## Introduction

Note that this specification will be the standard Complex top of book specification to be used for all Cboe-affiliated Options exchanges.

Cboe customers may use the Complex Multicast TOP protocol to receive real-time top of book quotations from Cboe.

The quotations received via Complex Multicast TOP provide an aggregated size and do not indicate the size or number of individual orders at the best bid or ask. The Complex 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 US Options Multicast PITCH protocol.

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

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

### Complex Multicast TOP Feed Descriptions

| Exchange | Shaping | Served From Data Center (Primary/Secondary) | Multicast Feed ID |
|---|---|---|---|
| C1 Complex | WAN | Primary | CCD |
| C1 Complex | WAN | Primary | CDD |
| C1 Complex | WAN | Secondary | CED |
| C2 Complex | WAN | Primary | WCD |
| C2 Complex | WAN | Primary | WDD |
| C2 Complex | WAN | Secondary | WED |
| EDGX Complex | WAN | Primary | ECD |
| EDGX Complex | WAN | Primary | EDD |
| EDGX Complex | WAN | Secondary | EED |
| BZX Complex | WAN | Primary | OCD |
| BZX Complex | WAN | Primary | ODD |
| BZX Complex | WAN | Secondary | OED |

### 24x5 Feed Hours and System Restart (C1 Only)

For C1 Options operating in 24x5 mode, the Top feed starts on Sunday at approximately 1:00 p.m. ET and shuts down on Friday at approximately 5:30 p.m. ET. A daily restart occurs between 5:30 and 7:00 p.m. ET each day at which time sequences will be reset. The daily restart is typically observed between 5:30 p.m. and 6:00 p.m. ET, 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 are cleared (Delete Order messages sent for any open orders, including GTC and GTD orders), prior to the daily restart and reset of sequences. Persisted GTC and GTD orders will be added back onto the order books starting at approximately 10 minutes prior to the scheduled queuing time for each underlying symbol.

### Feed Connectivity Requirements

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

Customers with sufficient connectivity may choose to take more than one WAN-shaped feed from the Cboe’s primary datacenter and arbitrate the feeds to recover lost data. Alternatively, customers 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 Cboe in the primary datacenter due to proximity.

Cboe Complex 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 Cboe’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. 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 Complex Multicast TOP feed message flow between Cboe and a customer feed handler that is listening to the `C` and `D` instances of two units:

_(Figure)_

### Symbol Ranges, Units, and Sequence Numbers

Products will be separated by Underlying into units and product distribution will not change intra-day. Cboe does, however, reserve the right to add multicast addresses or change the product distribution with 48 hours prior notice to customers. 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.

### Complex Options Specific Symbol Processing

Cboe has implemented a Complex Instrument Creation (CIC) process which enables the dynamic creation of new complex instruments. As a result, new symbol IDs associated with dynamically created instruments may appear on the feed intraday.

Real-time CIC messages are available on each unit’s multicast feed. `Complex Instrument Definition Expanded` messages are used to map the 6 character feed Complex Instrument ID (CID) to the complex instrument definition. A complex instrument definition consists of two or more option legs. The complex instrument is valid only for the current trading date on which it was created. Once a complex instrument is created, it cannot be deleted or modified for the remainder of the trading day.

Complex instruments can be created from pre-market through the end of trading. When a complex instrument is created, a sequenced `Complex Instrument Definition Expanded` message is disseminated at the time of creation and is sent in a background loop as an unsequenced message for the reminder of the trading day as bandwidth allows.

### Gap Request Proxy and Message Retransmission

Requesting delivery of missed sequenced data is achieved by establishing a TCP connection to a Cboe Gap Request Proxy (GRP) port. This GRP port is specific to Complex Multicast TOP and is NOT shared with the Multicast PITCH GRP or Complex Multicast PITCH GRP ports. Customers 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. Customers 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` Status code of `A` (Accepted) signals that the replayed messages will be delivered via the appropriate gap response multicast address. Any other `Gap Response` 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. Customers will receive a total daily allowance of gap requested messages. In addition, each customer 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. Customers 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 customers 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 customer can get the current book for multicast TOP 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 customer 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` 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 customer sends a sequence number in a `Spin Request` 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 of `Two Side Update, Single Side Update, TOP Trade, Trading Status`, `Complex Instrument Definition Expanded`, `Exchange Designated Complex Instrument Definition,` and `Time` messages. 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 customer must buffer multicast messages received. If the `Spin Image Available` message sequence number is the customer’s reference point, multicast messages with larger sequence numbers should be buffered. If a non- `Spin Image Available` sequence number is the customer’s reference point from which they send in their `Spin Request`, 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.

Customers can also use the Spin Server to request a spin of all `Symbol Mapping`, `Complex Instrument Definition Expanded,` and `Exchange Designated Complex Instrument Definition` messages by sending an `Instrument Definition Request.`The Spin Server can only process one spin at a time. Customers will need to wait for a `Spin Finished` or `Instrument Definition Finished` message before submitting another request.

Spin Messages shows an example flow of messages between a customer and Cboe’s Multicast TOP feed and Spin Server.

## Protocol

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

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

### Message Format

The messages that make up the TOP protocol are delivered using the Cboe `Sequenced Unit 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` 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. Cboe reserves the right to add message types and grow the length of any message without notice. Customers 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`, 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 Long 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 fields are 4 byte unsigned Little Endian values that represent the number of nanoseconds since the last `Time` message. These fields are populated to nanosecond precision. For example, a nano time of 1,737,580,407,123,456,789 ("Wednesday, January 22, 2025 9:13:27.123456789") would return value = 123456789.

### 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 Cboe `Sequenced Unit 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.

### Cboe Sequenced Unit Header

The Cboe `Sequenced Unit Header` is used for all Cboe Complex 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`. 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`, 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 `Heartbeats`.

**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 Hdr Count messages to follow. |
| 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 Messages

The `Sequenced Unit 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.

`Heartbeats` 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. `Heartbeats` 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 Cboe 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.

Cboe expects `Heartbeat` messages to be sent to the GRP and Sprin Servers 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 Reference` and `Time` messages, each TOP message reflects the update of the top of book or execution of an order in the system.

### Time Reference Message Fields (C1 Only)

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 Eastern 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 Eastern Time calendar day, derived by converting the current Eastern 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 | Time Offset | Nanosecond offset from last unit timestamp. |
| Trade Date | 14 | 4 | Binary Date | Current Trade Date |
| `Total Length`=18 bytes |  |  |  |  |

### 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 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. On C1 only, the `Time` message will also include the Epoch Time field, which is the current time represented as the number of whole seconds since the Epoch (midnight January 1, 1970).

For C1 only, a given trading day may span multiple calendar days. C1 options market data recipients must prepare for a crossing of the midnight ET boundary. At such time, a new `Time Reference` message will be sent and the Time field in subsequent `Time` messages will reset to reflect the number of seconds from the most recent midnight ET time.

**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 Eastern Time calendar day, derived by converting the current Eastern 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 | C1 Options Only Number of whole seconds since the Epoch (midnight January 1, 1970 UTC). |
| `Total Length` = 6 bytes, 10 bytes on C1 Options Only |  |  |  |  |

### Unit Clear Message Fields

The `Unit Clear` message instructs feed recipients to clear all Cboe complex books in the unit specified in the `Sequenced Unit Header`. This message will be sent at startup each day. It would also be distributed in certain recovery events such as a data center fail-over.

**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 | Time Offset | Nanosecond offset from last unit timestamp. |
| `Total Length`=6 bytes |  |  |  |  |

### Complex Instrument Definition Expanded Message Fields

A `Complex Instrument Definition Expanded` message represents a complex instrument that is available to place orders. It is sent as a sequenced message. `Complex Instrument Definition Expanded` messages will be sent in a continuous loop through the day at variable rates as bandwidth allows.

The `Complex Instrument Definition Expanded` message will contain two or more repeating groups of leg definitions. There is a limit of 16 leg definitions.

**Table 1. Complex Instrument Definition Expanded**

| Field Name | Offset | Length | Type/(Value) | Description |
|---|---|---|---|---|
| Length | 0 | 1 | Binary | Length of this message including this field. |
| Message Type | 1 | 1 | 0x9A | `Complex Instrument Definition Expanded` Message |
| Time Offset | 2 | 4 | Time Offset | Nanosecond offset from last unit timestamp. |
| Complex Instrument Id | 6 | 6 | Printable ASCII | Complex Instrument Id right padded with spaces. |
| Complex Instrument Underlying | 12 | 8 | Printable ASCII | Complex Instrument Underlying right padded with spaces. |
| Complex Instrument Type | 20 | 4 | Alphanumeric | character field; each field describes a characteristic. Character 1: Complex Option Type `O` = All legs are options `E` = One leg is an equity leg Characters 2-4: Reserved |
| Leg Count | 24 | 1 | Binary | The number of legs in the complex instrument. The maximum number of legs is 16. |
| The following fields repeat Leg Count times for multi-leg strategies. Leg Index is zero-based. |  |  |  |  |
| Leg Symbol | 25 + Leg Index * 13 | 8 | Printable ASCII | Option or Equity Symbol of leg, right padded with spaces. |
| Leg Ratio | 33 + Leg Index * 13 | 4 | Signed Binary | Leg ratio (positive for buy-side, negative for sell-side). For options this is the number of contracts, for equities this is the number of shares. |
| Leg Security Type | 37 + Leg Index * 13 | 1 | Alphanumeric | `O` = Leg is an Option instrument `E` = Leg is an Equity instrument |
| `Total Length`=25 + (Leg Count * 13) bytes |  |  |  |  |

### Exchange Designated Complex Instrument Definition Message Fields (C1 Only)

The `Exchange Designated Complex Instrument Definition` (EDCID) message represents supplemental information associated with an exchange-designated complex instrument and is sent as a sequenced message the first time it is sent. These messages are also sent continuously throughout the day as an unsequenced message (sequence = 0) at variable rates as bandwidth allows. The Time offset field should be ignored on unsequenced EDCID messages.

This message is sent in addition to a `Complex Instrument Definition Expanded` message for each exchange-designated complex instrument. All complex instruments, including exchange designated complex instruments, will be represented with standard `Complex Instrument Definition Expanded` messages. The purpose of the EDCID messages is to associate complex instruments with dependent Cboe products and services through the EDCI Type and Subtype fields.

Note that the same complex instrument can be associated with more than one dependent product, resulting in more than one EDCID message sharing the same Complex Instrument Id field value.

The EDCID message contains two or more repeating groups of leg definitions. There is a limit of 16 leg definitions.

**Table 1. Exchange Designated Complex Instrument Definition**

| Field Name | Offset | Length | Type/(Value) | Description |
|---|---|---|---|---|
| Length | 0 | 1 | Binary | Length of this message including this field. |
| Message Type | 1 | 1 | 0x9F | `Exchange Designated Complex Instrument Definition` message. |
| Time Offset | 2 | 4 | Time Offset | Nanosecond offset from last unit timestamp. |
| Complex Instrument Id | 6 | 6 | Printable ASCII | Complex Instrument Id right padded with spaces. |
| Complex Instrument Underlying | 12 | 8 | Printable ASCII | Complex Instrument Underlying right padded with spaces. |
| EDCI Type | 20 | 20 | Printable ASCII | Exchange Designated Complex Instrument type right padded with spaces. |
| EDCI Subtype | 40 | 20 | Printable ASCII | Exchange Designated Complex Instrument subtype right padded with spaces. |
| Reserved | 60 | 2 | Reserved | Reserved |
| Leg Count | 62 | 1 | Binary | The number of legs in the complex instrument. The maximum number of legs is 16. |
| The following fields repeat Leg Count times for multi-leg strategies. Leg Index is zero-based. |  |  |  |  |
| Leg Symbol | 63 + Leg Index * 10 | 6 | Printable ASCII | Option symbol of leg, right padded with spaces. |
| Leg Ratio | 69 + Leg Index * 10 | 4 | Signed Binary | Leg ratio (positive for buy-side, negative for sell-side). |
| `Total Length`=63 + (Leg Count * 10) bytes |  |  |  |  |

### Symbol Mapping Message Fields

A `Symbol Mapping` message is used to map the 6 character simple instrument multicast feed symbol field to an OSI symbol and Underlying. These messages are not sequenced (sequence = 0) and are sent continuously through the day at variable rates as bandwidth allows.

**Table 1. Symbol Mapping**

| Field Name | Offset | Length | Type/(Value) | Description |
|---|---|---|---|---|
| Length | 0 | 1 | Binary | Length of this message including this field |
| Message Type | 1 | 1 | 0x2E | `Symbol Mapping` Message |
| Feed Symbol | 2 | 6 | Printable ASCII | Symbol right padded with spaces. |
| OSI Symbol | 8 | 21 | Printable ASCII | OSI Symbol |
| Symbol Condition | 29 | 1 | Alphanumeric | `N` = Normal `C` = Closing Only |
| Underlying | 30 | 8 | Alphanumeric | Symbol of underlying equity right padded with spaces. All spaces if not available or not applicable. |
| `Total Length` = 38 bytes |  |  |  |  |

### Market Update Messages

Market Update messages reflect real-time events that update 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

`Single Side Update` messages provide an updated price and size for a single side of a Complex Instrument ID. 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 Expanded (Short`) and `Single Side Update Expanded (Long)`. The `Single Side Update Expanded (Short)` message is used whenever possible, but the `Single Side Update Expanded(Long)` message is used when the Price cannot be represented by a Binary Short Price or the Quantity cannot be represented by an unsigned 16-bit integer.

##### Single Side Update Expanded (Short) Message Fields

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

| Field Name | Offset | Length | Type/(Value) | Description |
|---|---|---|---|---|
| Length | 0 | 1 | Binary | Length of this message including this field. |
| Message Type | 1 | 1 | 0xD4 | `Single Side Update Expanded (Short)` Message |
| Time Offset | 2 | 4 | Time Offset | Nanosecond offset from last unit timestamp. |
| Complex Instrument ID | 6 | 6 | Printable ASCII | Complex Instrument Id right padded with spaces. |
| Side | 12 | 1 | Alphanumeric | `B` = Bid Side `S` = Ask Side |
| Bit Fields | 13 | 1 | Bit Field | Bits 0-7 - Reserved There are no Bit Fields for Complex Multicast TOP. |
| Price | 14 | 2 | Binary Short Price | Price (may be a zero or negative price for some instruments). |
| Quantity | 16 | 2 | Binary | Total number of contracts on the inside book (customer and non-customer). A zero value denotes there is no Bid/Ask. |
| Customer Quantity | 18 | 2 | Binary | Number of customer contracts on the inside book. A zero value denotes that there are no customer contracts at the inside price. |
| `Total Length`=20 bytes |  |  |  |  |

##### Single Side Update Expanded (Long) Message Fields

**Table 1. Single Side Update Expanded (Long)**

| Field Name | Offset | Length | Type/(Value) | Description |
|---|---|---|---|---|
| Length | 0 | 1 | Binary | Length of this message including this field. |
| Message Type | 1 | 1 | 0xD5 | `Single Side Update Expanded (Long)` Message |
| Time Offset | 2 | 4 | Time Offset | Nanosecond offset from last unit timestamp. |
| Complex Instrument ID | 6 | 6 | Printable ASCII | Complex Instrument Id right padded with spaces. |
| Side | 12 | 1 | Alphanumeric | `B` = Bid Side `S` = Ask Side |
| Bit Fields | 13 | 1 | Bit Field | Bits 0-7 - Reserved There are no Bit Fields for Complex Multicast TOP. |
| Price | 14 | 8 | Binary Long Price | Price (may be a zero or negative price for some instruments). |
| Quantity | 22 | 4 | Binary | Total number of contracts on the inside book (customer and non-customer). A zero value denotes there is no Bid/Ask. |
| Customer Quantity | 26 | 4 | Binary | Number of customer contracts on the inside book. A zero value denotes that there are no customer contracts at the inside price. |
| `Total Length`=30 bytes |  |  |  |  |

#### Two Side Update Message

`Two Side Update` messages provide an updated price and size for both sides of a Complex Instrument ID. 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 Expanded (Long)` and `Two Side Update Expanded (Short)`. The `Two Side Update Expanded(Short)` message is used whenever possible, but the `Two Side Update Expanded(Long)` message is used when the Price cannot be represented by a Binary Short Price or the Quantity cannot be represented by an unsigned 16-bit integer.

##### Two Side Update Expanded (Short) Message Fields

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

| Field Name | Offset | Length | Type/(Value) | Description |
|---|---|---|---|---|
| Length | 0 | 1 | Binary | Length of this message including this field. |
| Message Type | 1 | 1 | 0xD6 | `Two Side Update Expanded (Short)` Message |
| Time Offset | 2 | 4 | Time Offset | Nanosecond offset from last unit timestamp. |
| Complex Instrument ID | 6 | 6 | Printable ASCII | Complex Instrument Id right padded with spaces. |
| Bit Fields | 12 | 1 | Bit Field | Bits 0-7 - Reserved There are no Bit Fields for Complex Multicast TOP. |
| Bid Price | 13 | 2 | Binary Short Price | Bid Price (may be a zero or negative price for some instruments). |
| Bid Quantity | 15 | 2 | Binary | Total number of contracts on the inside bid (customer and non-customer). A zero value denotes there is no bid. |
| Bid Customer Quantity | 17 | 2 | Binary | Number of customer contracts on the inside bid. A zero value denotes that there are no customer contracts at the inside price. |
| Ask Price | 19 | 2 | Binary Short Price | Ask Price (may be a zero or negative price for some instruments). |
| Ask Quantity | 21 | 2 | Binary | Total number of contracts on the inside ask (customer and non-customer). A zero value denotes there is no ask. |
| Ask Customer Quantity | 23 | 2 | Binary | Number of customer contracts on the inside ask. A zero value denotes that there are no customer contracts at the inside price. |
| `Total Length`=25 bytes |  |  |  |  |

##### Two Side Update Expanded (Long) Message Fields

**Table 1. Two Side Update Expanded (Long)**

| Field Name | Offset | Length | Type/(Value) | Description |
|---|---|---|---|---|
| Length | 0 | 1 | Binary | Length of this message including this field. |
| Message Type | 1 | 1 | 0xD7 | `Two Side Update Expanded (Long)` Message |
| Time Offset | 2 | 4 | Time Offset | Nanosecond offset from last unit timestamp. |
| Complex Instrument ID | 6 | 6 | Printable ASCII | Complex Instrument Id right padded with spaces. |
| Bit Fields | 12 | 1 | Bit Field | Bits 0-7 - Reserved There are no Bit Fields for Complex Multicast TOP. |
| Bid Price | 13 | 8 | Binary Long Price | Bid Price (may be a zero or negative price for some instruments). |
| Bid Quantity | 21 | 4 | Binary | Total number of contracts on the inside bid (customer and non-customer). A zero value denotes there is no bid. |
| Bid Customer Quantity | 25 | 4 | Binary | Number of customer contracts on the inside bid. A zero value denotes that there are no customer contracts at the inside price. |
| Ask Price | 29 | 8 | Binary Long Price | Ask Price (may be a zero or negative price for some instruments). |
| Ask Quantity | 37 | 4 | Binary | Total number of contracts on the inside ask (customer and non-customer). A zero value denotes there is no ask. |
| Ask Customer Quantity | 41 | 4 | Binary | Number of customer contracts on the inside ask. A zero value denotes that there are no customer contracts at the inside price. |
| `Total Length`=45 bytes |  |  |  |  |

#### TOP Trade Message Fields

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

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

The `TOP Trade` message sends the trade price, trade quantity, and trade condition of a trade as well as the cumulative volume for the business day. A `TOP Trade` message will be sent after every execution, but not every `TOP Trade` message indicates a trade. A `Top Trade` message can also be sent when an auction executes against a non-displayed order, such as a contra response.

**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 | Time Offset | Nanosecond offset from last unit timestamp. |
| Complex Instrument ID | 6 | 6 | Printable ASCII | Complex Instrument Id right padded with spaces. |
| Quantity | 12 | 4 | Binary | Incremental quantity executed or cancelled (see Trade Condition). |
| Price | 16 | 8 | Binary Long Price | The execution price of the order. |
| Execution Id | 24 | 8 | Binary | Cboe generated day-unique execution identifier of this trade. Execution Id is also referenced in the `Trade Break` message. |
| Total Volume | 32 | 4 | Binary | Total quantity traded on the current business day (may decrease if the Trade Condition field indicates a cancelled trade). |
| Trade Condition | 36 | 1 | Alphanumeric | See Options Trade Condition Codes for details. |
| `Total Length`=37 bytes |  |  |  |  |

### Options Auction Update Message Fields

`Options Auction Update` messages are used to disseminate price and size information during Opening and Re-Opening (halt) auctions for complex instruments. The `Options Auction Update` messages are sent every five seconds during an opening period. See the Cboe Titanium U.S. Options Complex Book Process for more information.

**Table 1. Options Auction Update**

| Field Name | Offset | Length | Type/(Value) | Description |
|---|---|---|---|---|
| Length | 0 | 1 | Binary | Length of this message including this field. |
| Message Type | 1 | 1 | 0xD1 | `Options Auction Update` Message |
| Time Offset | 2 | 4 | Time Offset | Nanosecond offset from last unit timestamp. |
| Complex Instrument ID | 6 | 8 | Printable ASCII | Complex Instrument right padded with spaces. |
| Auction Type | 14 | 1 | Alphanumeric | `G` = GTH Opening (C1 Only) `O` = RTH Opening (C1 Only) `H` = Halt Re-Opening |
| Reference Price | 15 | 8 | Binary Long Price | Not used for complex series. Will contain zero value. |
| Buy Contracts | 23 | 4 | Binary | Cumulative Buy interest at the Indicative Price. |
| Sell Contracts | 27 | 4 | Binary | Cumulative Sell interest at the Indicative Price. |
| Indicative Price | 31 | 8 | Binary Signed Long Price | SNBBO Collared Volume Maximizing Imbalance Minimizing Price computed on combined Auction-Only and Continuous Book (if any). |
| Auction Only Price | 39 | 8 | Binary Signed Long Price | Not used for complex series. Will contain zero value. |
| Opening Condition | 47 | 1 | Alphanumeric | Not used for Complex series. Will contain zero value. |
| Composite Market Bid Price | 48 | 8 | Binary Signed Long Price | Not used for Complex series. Will contain zero value. |
| Composite Market Offer Price | 56 | 8 | Binary Signed Long Price | Not used for complex series. Will contain zero value. |
| `Total Length`=64 bytes |  |  |  |  |

### Auction Summary Message Fields

`Auction Summary` messages are used to disseminate the results of an auction of a complex instrument. An Opening or Re-Opening `Auction Summary` message for each complex instrument is sent at the conclusion of its Opening or Re-Opening auction and represents the Cboe opening price. See the Cboe Titanium U.S. Options Complex Book Process for more information.

**Table 1. Auction Summary**

| Field Name | Offset | Length | Type/(Value) | Description |
|---|---|---|---|---|
| Length | 0 | 1 | Binary | Length of this message including this field. |
| Message Type | 1 | 1 | 0x96 | `Auction Summary` Message |
| Time Offset | 2 | 4 | Time Offset | Nanosecond offset from last unit timestamp. |
| Complex Instrument Id | 6 | 8 | Printable ASCII | Complex Instrument Id right padded with spaces. |
| Auction Type | 14 | 1 | Alphanumeric | `G` = GTH Opening (C1 Only) `O` = RTH Opening (C1 Only) `H` = Halt Re-Opening |
| Price | 15 | 8 | Binary Long Price | Auction price |
| Quantity | 23 | 4 | Binary | Cumulative instrument quantity executed during the auction |
| `Total Length`=27 bytes |  |  |  |  |

### Trading Status Message Fields

The `Trading Status` message is used to indicate the current trading status of a complex instrument. A `Trading Status` message will be sent whenever a complex instrument trading status changes.

A `Trading Status` message will be sent for all complex instruments as they transition through various trading states.

Starting at 7:30 a.m. ET, Cboe will send a Trading Status of `Q` once complex orders can be accepted for queuing in preparation for the RTH open. At or after 9:30 a.m. ET, Cboe will send a Trading Status of `T` as complex instruments are open for trading. Cboe will send a Trading Status of `L` as Curb-eligible Products transition from RTH trading to Curb trading.

A `Trading Status` message will also be sent:

- for a Regulatory Halt `Q`uoting period in any complex instrument where the underlying has experienced a Regulatory Halt as well as the `T`rading resumption for the same instrument.

The Trading Status field will be used to represent the status of the RTH and Curb sessions. The GTH Trading Status field will be used to represent the status of series that trade during the GTH session.

**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 | Time Offset | Nanosecond offset from last unit timestamp |
| Complex Instrument ID | 6 | 6 | Printable ASCII | Complex Instrument Id right padded with spaces. |
| Reserved | 12 | 2 | Reserved | Reserved |
| Trading Status | 14 | 1 | Alpha | `H` = Halted `L` = Curb Trading (C1 Only) `Q` = Quote-Only `T` = RTH Trading |
| Reserved | 15 | 1 | Reserved | Reserved |
| GTH Trading Status (C1 Only) | 16 | 1 | Alpha | `H` = Halted `Q` = Quote-Only `T` = Trading |
| Reserved2 | 17 | 1 | Alpha | Reserved |
| `Total Length`=18 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. Each of the following message types must be wrapped by an unsequenced unit header as described in Sequenced Unit Header. Customers 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 Cboe. |
| Username | 6 | 4 | Alphanumeric | Username supplied by Cboe. |
| Filler | 10 | 2 | Alphanumeric | (space filled) |
| Password | 12 | 10 | Alphanumeric | Password supplied by Cboe. |
| `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 Cboe’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 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

Each of the following message types must be wrapped by an unsequenced unit header as described in Cboe Sequenced Unit Header.

### Login Message

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 in Login Message Fields.

### Login Response Message

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 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 customer. |
| `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 customer. |
| Order Count | 6 | 4 | Binary | Always zero. |
| 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` was not rejected. Upon receipt of a `Spin Finished` message, any buffered multicast messages should be applied to the customer’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 |  |  |  |  |

### Instrument Definition Request Message Fields

The `Instrument Definition Request` message is used by a user’s process to request transmission of this unit’s Symbol Mappings and Complex Instrument Definitions. All `Symbol Mapping` messages will be sent before `Complex Instrument Definition Expanded` and `Exchange Designated Complex Instrument Definition` messages. Refer to Spin Servers for more details regarding Sequence specification as well as buffering requirements.

**Table 1. Instrument Definition Request**

| Field Name | Offset | Length | Type/(Value) | Description |
|---|---|---|---|---|
| Length | 0 | 1 | Binary | Length of this message including this field |
| Message Type | 1 | 1 | 0x84 | `Instrument Definition Request` Message |
| Sequence | 2 | 4 | Binary | Must be 0. Only the current Symbol Mappings and Complex Instrument Definitions are available. |
| `Total Length`=6 bytes |  |  |  |  |

### Instrument Definition Response Message Fields

The `Instrument Definition Response` message is sent in response to a user’s `Instrument Definition Request` message indicating whether a spin will be sent.

| Instrument Definition Response |  |  |  |  |
|---|---|---|---|---|
| Field Name | Offset | Length | Type/(Value) | Description |
| Length | 0 | 1 | Binary | Length of this message including this field |
| Message Type | 1 | 1 | 0x85 | `Instrument Definition Response` Message |
| Sequence | 2 | 4 | Binary | Will always be 0. |
| Instrument Count | 6 | 4 | Binary | Number of `Symbol Mapping` and `Complex Instrument Definition Expanded` (if applicable) messages which will be contained in this spin |
| Status | 10 | 1 | Alphanumeric | Accepted or reason for reject |
| `Total Length` = 11 bytes |  |  |  |  |
| Instrument Definition Response - Status Codes |  |  |  |  |
| ‘A’ | Accepted |  |  |  |
| ‘O’ | Out of Range (Sequence must be 0) |  |  |  |
| ‘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.

### Instrument Definition Finished Message Fields

The `Instrument Definition Finished` message is sent to indicate that all `Symbol Mapping` and `Complex Instrument Definition Expanded` messages for this unit have been sent. An `Instrument Definition Finished` message is only sent if an `Instrument Definition Request` was not rejected.

**Table 1. Instrument Definition Finished**

| Field Name | Offset | Length | Type/(Value) | Description |
|---|---|---|---|---|
| Length | 0 | 1 | Binary | Length of this message including this field |
| Message Type | 1 | 1 | 0x86 | `Instrument Definition Finished` Message |
| `Total Length` = 2 bytes |  |  |  |  |

### Spin Server Usage Example

The diagram below shows the exchange of messages over time between a customer and Cboe’s Multicast TOP feed and Spin Server.

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

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

At time 7, the customer 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 customer does not have all messages cached after 310169 (they are missing 310170 and 310171), so this spin is not useful to the customer.

At time 10, the customer 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 customer has all messages after 310175 cached.

At time 11, the customer sends a `Spin Request` 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` and indicates that three symbols will be sent.

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

Note: Spin Servers are available for each unit. Customers 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
    0x84        Instrument Definition Request
    0x85        Instrument Definition Response
    0x86        Instrument Definition Finished
```

### TOP Messages

```
    
    0xB1        Time Reference (C1 Only)
    0x20        Time
    0x97        Unit Clear     
    0x9A        Complex Instrument Definition Expanded
    0x9F        Exchange Designated Complex Instrument Definition (C1 Only)
    0x2F        Symbol Mapping
    0xD4        Single Side Update Expanded (Short)
    0xD5        Single Side Update Expanded (Long)
    0xD6        Two Side Update Expanded (Short)
    0xD7        Two Side Update Expanded (Long)
    0xB8        TOP Trade
    0xD1        Options Auction Update
    0x96        Auction Summary
    0x31        Trading Status
    0x2D        End of Session
```

## Example Messages

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

### Login Message

**Table 1. Login Message**

| 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

**Table 1. Login Response Message**

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

### Gap Request Message

**Table 1. Gap Request Message**

| 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

**Table 1. Gap Response Message**

| Length | 10 | 10 bytes |
|---|---|---|
| Type | 04 | Gap Response |
| Unit | 01 | Unit 1 |
| Sequence | 3B 10 00 00 | First message: 4155 |
| Count | 32 00 | 50 messages |
| Status | 41 | Accepted |

### Spin Image Available Message

**Table 1. Spin Image Available Message**

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

### Spin Request Message

**Table 1. Spin Request Message**

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

### Spin Response Message

**Table 1. Spin Response Message**

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

### Spin Finished Message

**Table 1. Spin Finished Message**

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

### Instrument Definition Request

**Table 1. Instrument Definition Request**

| Length | 06 | 6 bytes |
|---|---|---|
| Type | 84 | Instrument Definition Request |
| Sequence | 00 00 00 00 | Sequence: 0 |

### Instrument Definition Response

**Table 1. Instrument Definition Response**

| Length | 0B | 11 bytes |
|---|---|---|
| Type | 85 | Instrument Definition Response |
| Sequence | 00 00 00 00 | Sequence: 0 |
| Instrument Count | B8 0B 00 00 | 3000 Instruments |
| Status | 41 | Accepted |

### Instrument Definition Finished

**Table 1. Instrument Definition Finished**

| Length | 02 | 2 bytes |
|---|---|---|
| Type | 86 | Instrument Definition Finished |

### Time Reference (C1 Only)

**Table 1. Time Reference (C1 Only)**

| Length | 12 | 18 bytes |
|---|---|---|
| Type | B1 | Time Reference |
| Midnight Reference | D0 8B 34 60 | 2021-02-23 00:00:00 Eastern (1614056400 seconds since the Epoch) |
| Time | 00 E1 00 00 | 16:00:00 |
| Time Offset | 00 00 00 00 | Exactly 16:00:00 |
| Trade Date | 2F 62 34 01 | 20210223 February 23, 2021 |

### Time Message

**Table 1. Time Message**

| Length | 06 | 6 bytes |
|---|---|---|
| Type | 20 | Time |
| Time | 98 85 00 00 | 34,200 seconds = 09:30 AM Central |

### Time Message (C1 Only)

**Table 1. Time Message (C1 Only)**

| Length | 0A | 10 bytes |
|---|---|---|
| Type | 20 | Time |
| Time | 98 85 00 00 | 34,200 seconds = 09:30 AM Eastern |
| Epoch Time (C1 Only) | 68 11 35 60 | 1,614,090,600 seconds since the Epoch |

### Unit Clear

**Table 1. Unit Clear**

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

### Single Side Update Expanded (Short)

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

| Length | 14 | 20 bytes |
|---|---|---|
| Type | D4 | Single Side Update Expanded (Short) |
| Time Offset | 30 FA D3 29 | 701,758,000 ns since last Time Message |
| CID | 30 31 32 33 34 35 | 012345 |
| Side | 42 | B (Buy) |
| Bit Fields | 00 | Always Zero |
| Price | 7B 00 | $1.23 |
| Quantity | 64 00 | 100 Contracts |
| Customer Quantity | 64 00 | 100 Contracts |

### Single Side Update Expanded (Long)

**Table 1. Single Side Update Expanded (Long)**

| Length | 1E | 30 bytes |
|---|---|---|
| Type | D5 | Single Side Update Expanded (Long) |
| Time Offset | 30 FA D3 29 | 701,758,000 ns since last Time Message |
| CID | 30 31 32 33 34 35 | 012345 |
| Side | 42 | B (Buy) |
| Bit Fields | 00 | Always Zero |
| Price | E0 F4 8F 04 00 00 00 00 | $7654.3200 |
| Quantity | 64 00 | 100 Contracts |
| Customer Quantity | 00 00 | 0 Customer Contracts |

### Two Side Update Expanded (Short)

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

| Length | 19 | 25 bytes |
|---|---|---|
| Type | D6 | Two Side Update Expanded (Short) |
| Time Offset | 30 FA D3 29 | 701,758,000 ns since last Time Message |
| CID | 30 31 32 33 34 35 | 012345 |
| Bit Fields | 00 | Always Zero |
| Bid Price | 41 01 | $3.21 |
| Bid Quantity | 64 00 | 100 |
| Bid Customer Quantity | 32 00 | 50 |
| Ask Price | 43 01 | $3.23 |
| Ask Quantity | C8 00 | 200 |
| Ask Customer Quantity | 64 00 | 100 |

### Two Side Update Expanded (Long)

**Table 1. Two Side Update Expanded (Long)**

| Length | 2D | 45 bytes |
|---|---|---|
| Type | D7 | Two Side Update Expanded (Long) |
| Time Offset | 30 FA D3 29 | 701,758,000 ns since last Time Message |
| CID | 30 31 32 33 34 35 | 012345 |
| Bit Fields | 00 | Always Zero |
| Bid Price | 64 7D 00 00 00 00 00 00 | $3.2100 |
| Bid Quantity | 00 00 01 00 | 65536 |
| Bid Customer Quantity | 64 00 | 100 |
| Ask Price | 2C 7E 00 00 00 00 00 00 | $3.2300 |
| Ask Quantity | C8 00 00 00 | 200 |
| Ask Customer Quantity | 64 00 | 100 |

### Options Auction Update

**Table 1. Options Auction Update**

| Length | 40 | 64 bytes |
|---|---|---|
| Type | D1 | Options Auction Update |
| Time Offset | 18 D2 06 00 | 447,000 ns since last Time Message |
| CID | 43 30 30 30 31 32 20 20 | C00012 |
| Auction Type | 4F | RTH Opening |
| Reference Price | 00 00 00 00 00 00 00 00 | always zero |
| Buy Contracts | 64 00 00 00 | 100 Contracts |
| Sell Contracts | C8 00 00 00 | 200 Contracts |
| Indicative Price | E8 A3 0F 00 00 00 00 00 | $102.50 |
| Auction Only Price | 00 00 00 00 00 00 00 00 | always zero |
| Opening Condition | 00 | always zero |
| Composite Market Bid Price | 00 00 00 00 00 00 00 00 | always zero |
| Composite Market Offer Price | 00 00 00 00 00 00 00 00 | always zero |

### Auction Summary

**Table 1. Auction Summary**

| Length | 1B | 27 bytes |
|---|---|---|
| Type | 96 | Auction Summary |
| Time Offset | 18 D2 06 00 | 447,000 ns since last Time Message |
| CID | 43 30 30 30 31 32 20 20 | C00012 |
| Auction Type | 4F | RTH Opening |
| Price | E8 A3 0F 00 00 00 00 00 | $102.50 |
| Quantity | 4B 00 00 00 | 75 |

### TOP Trade

**Table 1. TOP Trade**

| Length | 25 | 37 bytes |
|---|---|---|
| Type | B8 | TOP Trade |
| Time Offset | 10 84 D4 23 | 601,130,000 ns since last Time Message |
| CID | 36 35 34 33 32 31 | 654321 |
| Quantity | BC 02 00 00 | 700 |
| 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 | 1,000,000 |
| Trade Condition | 20 | Normal Trade (space) |

### Complex Instrument Definition Expanded Message

**Table 1. Complex Instrument Definition Expanded Message**

| Length | 33 | 51 bytes |
|---|---|---|
| Type | 9A | Complex Instrument Definition Expanded |
| Time Offset | 18 D2 06 00 | 447,000 ns since last Time Message |
| CID | 43 30 30 30 31 32 | C00012 |
| Complex Instrument | 5A 56 5A 5A 54 20 20 20 | ZVZZT |
| Underlying Complex Instrument | 4F 00 00 00 | O = All Legs are Options |
| Type Leg Count | 02 | 2 Legs |
| Leg Symbol | 30 30 30 30 30 31 20 20 | 000001 |
| Leg Ratio | FF FF FF FF | -1 = Sell 1 |
| Leg Security Type | 4F | Option Leg |
| Leg Symbol | 30 30 30 30 30 32 20 20 | 000002 |
| Leg Ratio | 01 00 00 00 | 1 = Buy 1 |
| Leg Security Type | 4F | Option Leg |

### Exchange Designated Complex Instrument Definition (C1 Only)

**Table 1. Exchange Designated Complex Instrument Definition (C1 Only)**

| Length | 51 | 81 bytes |
|---|---|---|
| Type | 9F | Exchange Designated Complex Instrument Definition |
| Time Offset | 18 D2 06 00 | 447,000 ns since last Time Message |
| CID | 44 44 43 49 30 31 | EDCI01 |
| Complex Instrument Underlying | 5A 56 5A 5A 54 20 20 20 | ZVZZT |
| EDCI Type | 51 53 42 20 20 20 20 20 | QSB |
| EDCI Subtype | 4A 45 4C 4C 59 5F 52 4F 4C 4C 20 20 20 20 20 20 20 | JELLY_ROLL |
| Reserved | 00 00 | Reserved |
| Leg Count | 02 | 2 Legs |
| Leg Symbol | 30 30 30 30 30 31 | 000001 |
| Leg Ratio | FF FF FF FF | -1 = Sell 1 |
| Leg Symbol | 30 30 30 30 30 32 | 000002 |
| Leg Ratio | 01 00 00 00 | 1 = Buy 1 |

### Symbol Mapping Message

**Table 1. Symbol Mapping Message**

| Length | 26 | 38 bytes |
|---|---|---|
| Type | 2E | Symbol Mapping Message |
| Feed Symbol | 30 30 6D 45 56 4F | 00mEVO |
| OSI Symbol | 4D 53 46 54 20 20 31 39 | MSFT 190920C00150000 |
| Symbol Condition | 43 | ‘C’ - Closing Only |
| Underlying | 4D 53 46 54 20 20 20 20 | MSFT |

### Trading Status Message

**Table 1. Trading Status Message**

| Length | 12 | 18 bytes |
|---|---|---|
| Type | 31 | Trading Status |
| Time Offset | 18 D2 06 00 | 447,000 ns since last Time Message |
| CID | 39 39 38 38 37 37 | 998877 |
| Reserved | 20 20 | Reserved |
| Trading Status | 54 | T = Trading |
| Reserved | 20 | Reserved |
| Global Trading Hours Status | 48 | H = Halted |
| Reserved | 20 | Reserved |

### End of Session Message

**Table 1. End of Session Message**

| Length | 06 | 6 bytes |
|---|---|---|
| Type | 2D | End of Session |
| Time Offset | 18 D2 06 00 | 447,000 ns since last Time Message |

## Multicast Configuration

### Production Environment Configuration

#### Limitations/Configurations

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

| Period/Type | Limit/Setting | Notes |
|---|---|---|
| MTU | 1500 | Cboe will send UDP messages up to 1500 bytes. Customers 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. |

#### U.S. Options Unit/Product Distribution

| Unit | BZX/C1/C2/EDGX Symbol Range | Exceptions |
|---|---|---|
| 1 | A - AIPA~ |  |
| 2 | AIPB - AO~ |  |
| 3 | AP - AVGO~ |  |
| 4 | AVGP - BOIL~ |  |
| 5 | BOIM - CMPR~ | Excludes CBTX, CBTXW |
| 6 | CMPS - CSIQ~ |  |
| 7 | CSIR - DJTA~ |  |
| 8 | DJTB - FARO~ | Excludes DJX, DJXW |
| 9 | FARP - GLC~ |  |
| 10 | GLD - HAYW~ |  |
| 11 | HAYX - IYWA~ | Excludes IWM |
| 12 | IYWB - LMTA~ |  |
| 13 | LMTB - MES~ | Excludes MBTX, MBTXW |
| 14 | MET - MRM~ | Excludes MGTN, MGTNW |
| 15 | MRN - MSTR~ | Excludes MRUT |
| 16 | MSTS - NKEA~ | Excludes NANOS |
| 17 | NKEB - PDC~ | Excludes NVDA, OEX |
| 18 | PDD - RDDS~ | Excludes QQQ |
| 19 | RDDT - SEAA~ | Excludes RLG, RLV, RUI, RUT/RUTW |
| 20 | SEAB - SMHA~ | Excludes SIXB, SIXC, SIXE, SIXI, SIXR, SIXRE, SIXT, SIXU, SIXV, SIXY |
| 21 | SMHB - TEQ~ | Excludes SPEQX, SPESG, SPX/SPXW, SPY |
| 22 | TER - TTC~ | Excludes TSLA |
| 23 | TTD - VB~ | Excludes UKXM |
| 24 | VC - WYNN~ | Excludes VIX, VIXW |
| 25 | WYNO - Z~ | Excludes XEO, XSP, XSPBW |
| 26 | NVDA |  |
| 27 | TSLA |  |
| 28 | QQQ |  |
| 29 | IWM |  |
| 30 | SPY |  |

**Table 1. Units 31-35**

| Unit | BZX/C2 Symbol Range | C1 Symbol Range |
|---|---|---|
| 31 | DJX (C2 Only), DJXW (C2 Only), RUT (BZX and C2 Only), RUTW (C2 Only) | CBTX, CBTXW, DJX, DJXW, MBTX, MBTXW, MGTN, MGTNW, MRUT, OEX, RLG, RLV, RUI, RUT, RUTW, SIXB, SIXC, SIXE, SIXI, SIXR, SIXRE, SIXT, SIXU, SIXV, SIXY, SPEQX, SPESG, UKXM, XEO |
| 32 | N/A | NANOS, VIX, VIXW, XSP, XSPBW |
| 33 | N/A | SPX |
| 34 | N/A | SPXW |
| 35 | N/A | SPX/SPXW, Cross Product Spreads |

Note - Cboe 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.

#### BZX Options Multicast Routing Parameters

| Data Center | Rendezvous Point |
|---|---|
| Primary Data Center C feed | 74.115.128.34 |
| Primary Data Center D feed | 74.115.128.37 |
| Secondary Data Center E feed | 174.136.181.246 |

#### C1 Options Multicast Routing Parameters

| Data Center | Rendezvous Point |
|---|---|
| Primary Data Center C feed | 74.115.128.183 |
| Primary Data Center D feed | 74.115.128.184 |
| Secondary Data Center E feed | 174.136.181.249 |

#### C2 Options Multicast Routing Parameters

| Data Center | Rendezvous Point |
|---|---|
| Primary Data Center C feed | 74.115.128.176 |
| Primary Data Center D feed | 74.115.128.177 |
| Secondary Data Center E feed | 170.137.16.134 |

#### EDGX Options Multicast Routing Parameters

| Data Center | Rendezvous Point |
|---|---|
| Primary Data Center C feed | 74.115.128.162 |
| Primary Data Center D feed | 74.115.128.163 |
| Secondary Data Center E feed | 174.136.181.240 |

#### BZX Options Address/Unit Distribution

The following tables describe the unit distribution across the BZX Options Complex Multicast TOP feeds.

| Primary Datacenter | WAN-Shaped [OCD] 174.136.164.192/28 | WAN-Shaped [ODD] 174.136.164.208/28 |  |  |  |
|---|---|---|---|---|---|
| Unit | IP Port | Real-time MC | Gap Resp. MC | Real-time MC | Gap Resp. MC |
| 1 | 30901 | 224.0.73.236 | 224.0.73.238 | 233.65.120.28 | 233.65.120.30 |
| 2 | 30902 |  |  |  |  |
| 3 | 30903 |  |  |  |  |
| 4 | 30904 |  |  |  |  |
| 5 | 30905 |  |  |  |  |
| 6 | 30906 |  |  |  |  |
| 7 | 30907 |  |  |  |  |
| 8 | 30908 |  |  |  |  |
| 9 | 30909 |  |  |  |  |
| 10 | 30910 |  |  |  |  |
| 11 | 30911 |  |  |  |  |
| 12 | 30912 |  |  |  |  |
| 13 | 30913 |  |  |  |  |
| 14 | 30914 |  |  |  |  |
| 15 | 30915 |  |  |  |  |
| 16 | 30916 |  |  |  |  |
| 17 | 30917 | 224.0.73.237 | 224.0.73.239 | 233.65.120.29 | 233.65.120.31 |
| 18 | 30918 |  |  |  |  |
| 19 | 30919 |  |  |  |  |
| 20 | 30920 |  |  |  |  |
| 21 | 30921 |  |  |  |  |
| 22 | 30922 |  |  |  |  |
| 23 | 30923 |  |  |  |  |
| 24 | 30924 |  |  |  |  |
| 25 | 30925 |  |  |  |  |
| 26 | 30926 |  |  |  |  |
| 27 | 30927 |  |  |  |  |
| 28 | 30928 |  |  |  |  |
| 29 | 30929 |  |  |  |  |
| 30 | 30930 |  |  |  |  |
| 31 | 30931 |  |  |  |  |
| 32 | 30932 |  |  |  |  |
| 33 | 30933 |  |  |  |  |

Note - Cboe 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. Addresses in the gray area are pre-assigned but not available. Customers should not configure their networks or systems for these addresses.

| Secondary Datacenter | WAN-Shaped [OED] 174.136.181.128/28 |  |  |
|---|---|---|---|
| Unit | IP Port | Real-time MC | Gap Response MC |
| 1 | 31351 | 234.170.137.28 | 234.170.137.30 |
| 2 | 31352 |  |  |
| 3 | 31353 |  |  |
| 4 | 31354 |  |  |
| 5 | 31355 |  |  |
| 6 | 31356 |  |  |
| 7 | 31357 |  |  |
| 8 | 31358 |  |  |
| 9 | 31359 |  |  |
| 10 | 31360 |  |  |
| 11 | 31361 |  |  |
| 12 | 31362 |  |  |
| 13 | 31363 |  |  |
| 14 | 31364 |  |  |
| 15 | 31365 |  |  |
| 16 | 31366 |  |  |
| 17 | 31367 | 234.170.137.29 | 234.170.137.31 |
| 18 | 31368 |  |  |
| 19 | 31369 |  |  |
| 20 | 31370 |  |  |
| 21 | 31371 |  |  |
| 22 | 31372 |  |  |
| 23 | 31373 |  |  |
| 24 | 31374 |  |  |
| 25 | 31375 |  |  |
| 26 | 31376 |  |  |
| 27 | 31377 |  |  |
| 28 | 31378 |  |  |
| 29 | 31379 |  |  |
| 30 | 31380 |  |  |
| 31 | 31381 |  |  |
| 32 | 31382 |  |  |
| 33 | 31383 |  |  |

Note - Cboe 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.

#### C1 Options Address/Unit Distribution

The following tables describe the unit distribution across the C1 Options Complex Multicast TOP feeds.

| Primary Datacenter | WAN-Shaped [CCD] 170.137.114.80/28 | WAN-Shaped [CDD] 170.137.115.80/28 |  |  |  |
|---|---|---|---|---|---|
| Unit | IP Port | Real-time MC | Gap Resp. MC | Real-time MC | Gap Resp. MC |
| 1 | 30251 | 224.0.74.84 | 224.0.74.86 | 233.182.199.212 | 233.182.199.214 |
| 2 | 30252 |  |  |  |  |
| 3 | 30253 |  |  |  |  |
| 4 | 30254 |  |  |  |  |
| 5 | 30255 |  |  |  |  |
| 6 | 30256 |  |  |  |  |
| 7 | 30257 |  |  |  |  |
| 8 | 30258 |  |  |  |  |
| 9 | 30259 |  |  |  |  |
| 10 | 30260 |  |  |  |  |
| 11 | 30261 |  |  |  |  |
| 12 | 30262 |  |  |  |  |
| 13 | 30263 |  |  |  |  |
| 14 | 30264 |  |  |  |  |
| 15 | 30265 |  |  |  |  |
| 16 | 30266 |  |  |  |  |
| 17 | 30267 | 224.0.74.85 | 224.0.74.87 | 233.182.199.213 | 233.182.199.215 |
| 18 | 30268 |  |  |  |  |
| 19 | 30269 |  |  |  |  |
| 20 | 30270 |  |  |  |  |
| 21 | 30271 |  |  |  |  |
| 22 | 30272 |  |  |  |  |
| 23 | 30273 |  |  |  |  |
| 24 | 30274 |  |  |  |  |
| 25 | 30275 |  |  |  |  |
| 26 | 30276 |  |  |  |  |
| 27 | 30277 |  |  |  |  |
| 28 | 30278 |  |  |  |  |
| 29 | 30279 |  |  |  |  |
| 30 | 30280 |  |  |  |  |
| 31 | 30281 |  |  |  |  |
| 32 | 30282 |  |  |  |  |
| 33 | 30283 |  |  |  |  |
| 34 | 30284 |  |  |  |  |
| 35 | 30285 |  |  |  |  |

Note - Cboe 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. Addresses in the gray area are pre-assigned but not available. Customers should not configure their networks or systems for these addresses.

| Secondary Datacenter | WAN-Shaped [CED] 170.137.124.224/28 |  |  |
|---|---|---|---|
| Unit | IP Port | Real-time MC | Gap Response MC |
| 1 | 31251 | 233.19.3.244 | 233.19.3.246 |
| 2 | 31252 |  |  |
| 3 | 31253 |  |  |
| 4 | 31254 |  |  |
| 5 | 31255 |  |  |
| 6 | 31256 |  |  |
| 7 | 31257 |  |  |
| 8 | 31258 |  |  |
| 9 | 31259 |  |  |
| 10 | 31260 |  |  |
| 11 | 31261 |  |  |
| 12 | 31262 |  |  |
| 13 | 31263 |  |  |
| 14 | 31264 |  |  |
| 15 | 31265 |  |  |
| 16 | 31266 |  |  |
| 17 | 31267 | 233.19.3.245 | 233.19.3.247 |
| 18 | 31268 |  |  |
| 19 | 31269 |  |  |
| 20 | 31270 |  |  |
| 21 | 31271 |  |  |
| 22 | 31272 |  |  |
| 23 | 31273 |  |  |
| 24 | 31274 |  |  |
| 25 | 31275 |  |  |
| 26 | 31276 |  |  |
| 27 | 31277 |  |  |
| 28 | 31278 |  |  |
| 29 | 31279 |  |  |
| 30 | 31280 |  |  |
| 31 | 31281 |  |  |
| 32 | 31282 |  |  |
| 33 | 31283 |  |  |
| 34 | 31284 |  |  |
| 35 | 31285 |  |  |

Note - Cboe 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.

#### C2 Options Address/Unit Distribution

The following tables describe the unit distribution across the C2 Complex Options Multicast TOP feeds.

| Primary Datacenter | WAN-Shaped [WCD] 174.136.164.64/28 | WAN-Shaped [WDD] 174.136.164.80/28 |  |  |  |
|---|---|---|---|---|---|
| Unit | IP Port | Real-time MC | Gap Resp. MC | Real-time MC | Gap Resp. MC |
| 1 | 30351 | 224.0.131.252 | 224.0.131.254 | 233.130.124.252 | 233.130.124.254 |
| 2 | 30352 |  |  |  |  |
| 3 | 30353 |  |  |  |  |
| 4 | 30354 |  |  |  |  |
| 5 | 30355 |  |  |  |  |
| 6 | 30356 |  |  |  |  |
| 7 | 30357 |  |  |  |  |
| 8 | 30358 |  |  |  |  |
| 9 | 30359 |  |  |  |  |
| 10 | 30360 |  |  |  |  |
| 11 | 30361 |  |  |  |  |
| 12 | 30362 |  |  |  |  |
| 13 | 30363 |  |  |  |  |
| 14 | 30364 |  |  |  |  |
| 15 | 30365 |  |  |  |  |
| 16 | 30366 |  |  |  |  |
| 17 | 30367 | 224.0.131.253 | 224.0.131.255 | 233.130.124.253 | 233.130.124.255 |
| 18 | 30368 |  |  |  |  |
| 19 | 30369 |  |  |  |  |
| 20 | 30370 |  |  |  |  |
| 21 | 30371 |  |  |  |  |
| 22 | 30372 |  |  |  |  |
| 23 | 30373 |  |  |  |  |
| 24 | 30374 |  |  |  |  |
| 25 | 30375 |  |  |  |  |
| 26 | 30376 |  |  |  |  |
| 27 | 30377 |  |  |  |  |
| 28 | 30378 |  |  |  |  |
| 29 | 30379 |  |  |  |  |
| 30 | 30380 |  |  |  |  |
| 31 | 30381 |  |  |  |  |
| 32 | 30382 |  |  |  |  |
| 33 | 30383 |  |  |  |  |

Note - Cboe 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. Addresses in the gray area are pre-assigned but not available. Customers should not configure their networks or systems for these addresses.

| Secondary Datacenter | WAN-Shaped [WED] 170.137.17.96/29 |  |  |
|---|---|---|---|
| Unit | IP Port | Real-time MC | Gap Response MC |
| 1 | 31351 | 233.182.199.108 | 233.182.199.110 |
| 2 | 31352 |  |  |
| 3 | 31353 |  |  |
| 4 | 31354 |  |  |
| 5 | 31355 |  |  |
| 6 | 31356 |  |  |
| 7 | 31357 |  |  |
| 8 | 31358 |  |  |
| 9 | 31359 |  |  |
| 10 | 31360 |  |  |
| 11 | 31361 |  |  |
| 12 | 31362 |  |  |
| 13 | 31363 |  |  |
| 14 | 31364 |  |  |
| 15 | 31365 |  |  |
| 16 | 31366 |  |  |
| 17 | 31367 | 233.182.199.109 | 233.182.199.111 |
| 18 | 31368 |  |  |
| 19 | 31369 |  |  |
| 20 | 31370 |  |  |
| 21 | 31371 |  |  |
| 22 | 31372 |  |  |
| 23 | 31373 |  |  |
| 24 | 31374 |  |  |
| 25 | 31375 |  |  |
| 26 | 31376 |  |  |
| 27 | 31377 |  |  |
| 28 | 31378 |  |  |
| 29 | 31379 |  |  |
| 30 | 31380 |  |  |
| 31 | 31381 |  |  |
| 32 | 31382 |  |  |
| 33 | 31383 |  |  |

Note - Cboe 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.

#### EDGX Options Address/Unit Distribution

The following tables describe the unit distribution across the EDGX Options Complex Multicast TOP feeds.

| Primary Datacenter | WAN-Shaped [ECD] 174.136.164.32/28 | WAN-Shaped [EDD] 174.136.164.48/28 |  |  |  |
|---|---|---|---|---|---|
| Unit | IP Port | Real-time MC | Gap Resp. MC | Real-time MC | Gap Resp. MC |
| 1 | 30701 | 224.0.131.156 | 224.0.131.158 | 233.130.124.156 | 233.130.124.158 |
| 2 | 30702 |  |  |  |  |
| 3 | 30703 |  |  |  |  |
| 4 | 30704 |  |  |  |  |
| 5 | 30705 |  |  |  |  |
| 6 | 30706 |  |  |  |  |
| 7 | 30707 |  |  |  |  |
| 8 | 30708 |  |  |  |  |
| 9 | 30709 |  |  |  |  |
| 10 | 30710 |  |  |  |  |
| 11 | 30711 |  |  |  |  |
| 12 | 30712 |  |  |  |  |
| 13 | 30713 |  |  |  |  |
| 14 | 30714 |  |  |  |  |
| 15 | 30715 |  |  |  |  |
| 16 | 30716 |  |  |  |  |
| 17 | 30717 | 224.0.131.157 | 224.0.131.159 | 233.130.124.157 | 233.130.124.159 |
| 18 | 30718 |  |  |  |  |
| 19 | 30719 |  |  |  |  |
| 20 | 30720 |  |  |  |  |
| 21 | 30721 |  |  |  |  |
| 22 | 30722 |  |  |  |  |
| 23 | 30723 |  |  |  |  |
| 24 | 30724 |  |  |  |  |
| 25 | 30725 |  |  |  |  |
| 26 | 30726 |  |  |  |  |
| 27 | 30727 |  |  |  |  |
| 28 | 30728 |  |  |  |  |
| 29 | 30729 |  |  |  |  |
| 30 | 30730 |  |  |  |  |
| 31 | 30731 |  |  |  |  |
| 32 | 30732 |  |  |  |  |
| 33 | 30733 |  |  |  |  |

Note - Cboe 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. Addresses in the gray area are pre-assigned but not available. Customers should not configure their networks or systems for these addresses.

| Secondary Datacenter | WAN-Shaped [EED] 174.136.176.144/28 |  |  |
|---|---|---|---|
| Unit | IP Port | Real-time MC | Gap Response MC |
| 1 | 31501 | 233.19.3.140 | 233.19.3.142 |
| 2 | 31502 |  |  |
| 3 | 31503 |  |  |
| 4 | 31504 |  |  |
| 5 | 31505 |  |  |
| 6 | 31506 |  |  |
| 7 | 31507 |  |  |
| 8 | 31508 |  |  |
| 9 | 31509 |  |  |
| 10 | 31510 |  |  |
| 11 | 31511 |  |  |
| 12 | 31512 |  |  |
| 13 | 31513 |  |  |
| 14 | 31514 |  |  |
| 15 | 31515 |  |  |
| 16 | 31516 |  |  |
| 17 | 31517 | 233.19.3.141 | 233.19.3.143 |
| 18 | 31518 |  |  |
| 19 | 31519 |  |  |
| 20 | 31520 |  |  |
| 21 | 31521 |  |  |
| 22 | 31522 |  |  |
| 23 | 31523 |  |  |
| 24 | 31524 |  |  |
| 25 | 31525 |  |  |
| 26 | 31526 |  |  |
| 27 | 31527 |  |  |
| 28 | 31528 |  |  |
| 29 | 31529 |  |  |
| 30 | 31530 |  |  |
| 31 | 31531 |  |  |
| 32 | 31532 |  |  |
| 33 | 31533 |  |  |

Note - Cboe 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.

### Certification Environment Configuration

#### U.S. Options Unit/Product Distribution

| Unit | BZX/C1/C2/EDGX Symbol Range | Exceptions |
|---|---|---|
| 1 | A - AIPA~ |  |
| 2 | AIPB - AO~ |  |
| 3 | AP - AVGO~ |  |
| 4 | AVGP - BOIL~ |  |
| 5 | BOIM - CMPR~ | Excludes CBTX, CBTXW |
| 6 | CMPS - CSIQ~ |  |
| 7 | CSIR - DJTA~ |  |
| 8 | DJTB - FARO~ | Excludes DJX, DJXW |
| 9 | FARP - GLC~ |  |
| 10 | GLD - HAYW~ |  |
| 11 | HAYX - IYWA~ | Excludes IWM |
| 12 | IYWB - LMTA~ |  |
| 13 | LMTB - MES~ | Excludes MBTX, MBTXW |
| 14 | MET - MRM~ | Excludes MGTN, MGTNW |
| 15 | MRN - MSTR~ | Excludes MRUT |
| 16 | MSTS - NKEA~ | Excludes NANOS |
| 17 | NKEB - PDC~ | Excludes NVDA, OEX |
| 18 | PDD - RDDS~ | Excludes QQQ |
| 19 | RDDT - SEAA~ | Excludes RLG, RLV, RUI, RUT/RUTW |
| 20 | SEAB - SMHA~ | Excludes SIXB, SIXC, SIXE, SIXI, SIXR, SIXRE, SIXT, SIXU, SIXV, SIXY |
| 21 | SMHB - TEQ~ | Excludes SPEQX, SPESG, SPX/SPXW, SPY |
| 22 | TER - TTC~ | Excludes TSLA |
| 23 | TTD - VB~ | Excludes UKXM |
| 24 | VC - WYNN~ | Excludes VIX, VIXW |
| 25 | WYNO - Z~ | Excludes XEO, XSP, XSPBW |
| 26 | NVDA |  |
| 27 | TSLA |  |
| 28 | QQQ |  |
| 29 | IWM |  |
| 30 | SPY |  |

**Table 1. Units 31-35**

| Unit | BZX/C2 Symbol Range | C1 Symbol Range |
|---|---|---|
| 31 | DJX (C2 Only), DJXW (C2 Only), RUT (BZX and C2 Only), RUTW (C2 Only) | CBTX, CBTXW, DJX, DJXW, MBTX, MBTXW, MGTN, MGTNW, MRUT, OEX, RLG, RLV, RUI, RUT, RUTW, SIXB, SIXC, SIXE, SIXI, SIXR, SIXRE, SIXT, SIXU, SIXV, SIXY, SPEQX, SPESG, UKXM, XEO |
| 32 | N/A | NANOS, VIX, VIXW, XSP, XSPBW |
| 33 | N/A | SPX |
| 34 | N/A | SPXW |
| 35 | N/A | SPX/SPXW, Cross Product Spreads |

Note - Cboe 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

| Primary Certification Data Center | Rendezvous Point |
|---|---|
| C1 | 74.115.128.131 |
| C2, EDGX, and BZX | 74.115.128.129 |

#### BZX Options Address/Unit Distribution

The following table describes the unit distribution across certification BZX Options Complex Multicast TOP feeds out of the Primary datacenter.

| Primary Datacenter | Certification 174.136.164.224/28 |  |  |
|---|---|---|---|
| Unit | IP Port | Real-time MC | Gap Resp. MC |
| 1 | 32701 | 224.0.62.236 | 224.0.62.238 |
| 2 | 32702 |  |  |
| 3 | 32703 |  |  |
| 4 | 32704 |  |  |
| 5 | 32705 |  |  |
| 6 | 32706 |  |  |
| 7 | 32707 |  |  |
| 8 | 32708 |  |  |
| 9 | 32709 |  |  |
| 10 | 32710 |  |  |
| 11 | 32711 |  |  |
| 12 | 32712 |  |  |
| 13 | 32713 |  |  |
| 14 | 32714 |  |  |
| 15 | 32715 |  |  |
| 16 | 32716 |  |  |
| 17 | 32717 | 224.0.62.237 | 224.0.62.239 |
| 18 | 32718 |  |  |
| 19 | 32719 |  |  |
| 20 | 32720 |  |  |
| 21 | 32721 |  |  |
| 22 | 32722 |  |  |
| 23 | 32723 |  |  |
| 24 | 32724 |  |  |
| 25 | 32725 |  |  |
| 26 | 32726 |  |  |
| 27 | 32727 |  |  |
| 28 | 32728 |  |  |
| 29 | 32729 |  |  |
| 30 | 32730 |  |  |
| 31 | 32731 |  |  |
| 32 | 32732 |  |  |
| 33 | 32733 |  |  |

Note - Cboe 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.

#### C1 Options Address/Unit Distribution

The following table describes the unit distribution across certification C1 Options Complex Multicast TOP feeds out of the Primary datacenter.

| Primary Datacenter | Certification 170.137.126.16/28 |  |  |
|---|---|---|---|
| Unit | IP Port | Real-time MC | Gap Resp. MC |
| 1 | 32251 | 233.103.126.12 | 233.103.126.14 |
| 2 | 32252 |  |  |
| 3 | 32253 |  |  |
| 4 | 32254 |  |  |
| 5 | 32255 |  |  |
| 6 | 32256 |  |  |
| 7 | 32257 |  |  |
| 8 | 32258 |  |  |
| 9 | 32259 |  |  |
| 10 | 32260 |  |  |
| 11 | 32261 |  |  |
| 12 | 32262 |  |  |
| 13 | 32263 |  |  |
| 14 | 32264 |  |  |
| 15 | 32265 |  |  |
| 16 | 32266 |  |  |
| 17 | 32267 | 233.103.126.13 | 233.103.126.15 |
| 18 | 32268 |  |  |
| 19 | 32269 |  |  |
| 20 | 32270 |  |  |
| 21 | 32271 |  |  |
| 22 | 32272 |  |  |
| 23 | 32273 |  |  |
| 24 | 32274 |  |  |
| 25 | 32275 |  |  |
| 26 | 32276 |  |  |
| 27 | 32277 |  |  |
| 28 | 32278 |  |  |
| 29 | 32279 |  |  |
| 30 | 32280 |  |  |
| 31 | 32281 |  |  |
| 32 | 32282 |  |  |
| 33 | 32283 |  |  |
| 34 | 32284 |  |  |
| 35 | 32285 |  |  |

Note - Cboe 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.

#### C2 Options Address/Unit Distribution

The following table describes the unit distribution across certification C2 Complex Options Multicast TOP feeds out of the Primary datacenter.

| Primary Datacenter | Certification 174.136.160.80/28 |  |  |
|---|---|---|---|
| Unit | IP Port | Real-time MC | Gap Resp. MC |
| 1 | 32351 | 224.0.74.168 | 224.0.74.170 |
| 2 | 32352 |  |  |
| 3 | 32353 |  |  |
| 4 | 32354 |  |  |
| 5 | 32355 |  |  |
| 6 | 32356 |  |  |
| 7 | 32357 |  |  |
| 8 | 32358 |  |  |
| 9 | 32359 |  |  |
| 10 | 32360 |  |  |
| 11 | 32361 |  |  |
| 12 | 32362 |  |  |
| 13 | 32363 |  |  |
| 14 | 32364 |  |  |
| 15 | 32365 |  |  |
| 16 | 32366 |  |  |
| 17 | 32367 | 224.0.74.169 | 224.0.74.171 |
| 18 | 32368 |  |  |
| 19 | 32369 |  |  |
| 20 | 32370 |  |  |
| 21 | 32371 |  |  |
| 22 | 32372 |  |  |
| 23 | 32373 |  |  |
| 24 | 32374 |  |  |
| 25 | 32375 |  |  |
| 26 | 32376 |  |  |
| 27 | 32377 |  |  |
| 28 | 32378 |  |  |
| 29 | 32379 |  |  |
| 30 | 32380 |  |  |
| 31 | 32381 |  |  |
| 32 | 32382 |  |  |
| 33 | 32383 |  |  |

Note - Cboe 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.

#### EDGX Options Address/Unit Distribution

The following table describes the unit distribution across certification EDGX Options Complex Multicast TOP feeds out of the Primary datacenter.

| Primary Datacenter | Certification 174.136.174.176/28 |  |  |
|---|---|---|---|
| Unit | IP Port | Real-time MC | Gap Resp. MC |
| 1 | 32701 | 224.0.74.192 | 224.0.74.194 |
| 2 | 32702 |  |  |
| 3 | 32703 |  |  |
| 4 | 32704 |  |  |
| 5 | 32705 |  |  |
| 6 | 32706 |  |  |
| 7 | 32707 |  |  |
| 8 | 32708 |  |  |
| 9 | 32709 |  |  |
| 10 | 32710 |  |  |
| 11 | 32711 |  |  |
| 12 | 32712 |  |  |
| 13 | 32713 |  |  |
| 14 | 32714 |  |  |
| 15 | 32715 |  |  |
| 16 | 32716 |  |  |
| 17 | 32717 | 224.0.74.193 | 224.0.74.195 |
| 18 | 32718 |  |  |
| 19 | 32719 |  |  |
| 20 | 32720 |  |  |
| 21 | 32721 |  |  |
| 22 | 32722 |  |  |
| 23 | 32723 |  |  |
| 24 | 32724 |  |  |
| 25 | 32725 |  |  |
| 26 | 32726 |  |  |
| 27 | 32727 |  |  |
| 28 | 32728 |  |  |
| 29 | 32729 |  |  |
| 30 | 32730 |  |  |
| 31 | 32731 |  |  |
| 32 | 32732 |  |  |
| 33 | 32733 |  |  |

Note - Cboe 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.

## Options Trade Condition Codes

The following table defines valid values for the Trade Condition field.

| Type | Field Value |
|---|---|
| f | Complex to Complex Electronic Trade Cboe auction type is COA |
| g | Complex Auction Trade Cboe order types include C-AIM, C-SAM |
| h | Complex Cross Cboe auction types include Cust to Cust C-AIM, C-QCC |
| j | Complex Electronic Trade Against Single Leg(s) |
| k | Complex with Stock Options Auction Trade Cboe auction types include C-AIM w/ Stock, C-SAM w/ Stock |
| m | Complex Floor Trade Against Single Leg(s) All complex floor executions are reported as condition ‘m’. |
| n | Complex with Stock Electronic Trade Includes COA auctions done electronically |
| o | Complex with Stock Cross Cboe auction types include C-QCC w/ Stock |
| p | Complex with Stock Floor Trade |
| t | Complex Floor Trade of Proprietary Products Marked as "Combo Order" |
| v | Extended Hours Trade. Transaction represents a trade executed during the Curb session. |
| I | Electronic Trade |
| O* | Opening Trade |

*The Trade Condition value of `O=Opening Trade` will continue to be disseminated on the options PITCH and TOP feeds but will not be sent to OPRA.

## Connectivity

### Supported Extranet Carriers

Cboe has certified a number of carriers defined in the Cboe Titanium U.S. Equities/Options Connectivity Manual with respect to redistribution of Cboe Multicast data feeds. For more information on receiving Options Complex Multicast TOP through any of these providers, reach out to the vendor contact noted in the Extranet Providers section of the Connectivity Manual.

### Bandwidth Recommendation

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

## References

For more information on Cboe Symbology, please refer to Cboe Titanium U.S. Symbology Reference.

## Support

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

## Revision History

| Document Version | Date | Description |
|---|---|---|
| 1.0.0 | 05/11/17 | Initial version. |
| 1.0.1 | 05/18/17 | Various minor updates and clarification added. |
| 1.0.2 | 07/28/17 | Added Multicast Ips/Ports for Certification environment. Added Execution Id field to `TOP Trade` message. |
| 1.0.3 | 08/08/17 | Added Multicast Ips/Ports for Production environment. |
| 1.0.4 | 09/01/17 | Added C2 Options references. Updated description of TOP Trade message to describe behavior of Trade Condition field = `X` (Trade Break). |
| 1.0.5 | 10/02/17 | Removed Trade Status code "A". |
| 1.0.6 | 10/17/17 | Cboe branding/logo changes. Fixed incorrect Multicast IP for units 17-32 of EDD feed. |
| 1.0.7 | 11/24/17 | Added C2 Options Certification IP and Port information. Added RUT, RUTW options (C2 Options Only) to distinct unit (unit 33). |
| 1.0.8 | 12/11/17 | Added `Two Side Update Messsage` for C2 Options only. Corrected message type in `Top Trade` example. Added Bit Fields to all Market Update messages and `Market Snapshot` messages. Effective 1/22/2018. |
| 1.0.9 | 02/05/18 | Updated C2 Options IP and Port information. |
| 1.0.10 | 03/08/18 | Updated Unit Distribution ranges |
| 1.0.11 | 03/22/18 | Corrected GR MC Addresses for C2 C feed. |
| 1.0.12 | 03/23/18 | Unit Distribution ranges Effective Date updated to 4/14/18. |
| 1.1.0 | 11/16/18 | Added support for C1 Options. |
| 1.1.1 | 12/06/18 | Feature Pack 4 updates. Addition of new values O, A, C, F to Trade Condition field. |
| 1.1.2 | 12/21/18 | Removed Floor Trade value from `Top Trade` message, Trade Condition field, as this was added in error. Added note indicating a `Top Trade` message can also be sent when an auction executes against a non-displayed order, such as a contra response. |
| 1.1.3 | 02/05/19 | Removed references to cabinet size in messages, as C1 will not have an electronic book for Cabinet orders. |
| 1.1.4 | 02/14/19 | Added certification IP port and unit distribution information. |
| 1.1.5 | 03/05/19 | Added matching engine unit 33 information in support of XSP trading on EDGX Options effective 04/08/19. Added C1 primary data center rendezvous point IP address and C1 certification symbol ranges. Order Count in a spin is always zero for this feed. |
| 1.1.6 | 04/15/19 | Added C1 production IP port and unit distribution. Added DJX to C2 ME 33 in Unit/Product Distribution tables (effective 05/08/19). |
| 1.1.7 | 05/08/19 | Removed Trading Status field value `S` = Exchange Specific Suspension from the `Trading Status` message, as it was added in error. Corrected C1 Production Gig-Shaped [CCD] and [CDD] source network IP addresses. |
| 1.1.8 | 05/14/19 | Added Composite Market Bid Price and Composite Offer Price fields to the `Options Auction Update` message and updated associated example message. Added additional proprietary products to matching unit 31 in C1. |
| 1.1.9 | 06/12/19 | Corrected certification and production C1 symbol range for units 9 and 20. |
| 1.1.10 | 08/02/19 | Corrected Leg Count field description in `Complex Instrument Definition Expanded` message to indicate a total of 12 legs are allowed. Added note indicating `Options Auction Update` message Opening Condition field value will always be zero. Updated example message. |
| 1.1.11 | 09/24/19 | Updated OSI Symbol example values in `Symbol Mapping` message type examples. |
| 1.1.12 | 10/31/19 | Corrected UKXM symbol exclusion entry in Unit Distribution table. Changed instances of `Complex Instrument Definition` to `Complex Instrument Definition Expanded` , as the former was deprecated 02/28/19. Clarified description of `Time` message. Added Options Trade Condition Codes section (effective 01/13/20). |
| 1.1.13 | 11/12/19 | Added note indicating GTH will be applicable for C1 only as GTH is being sunset for C2 and EDGX (effective 11/22/19). |
| 1.1.14 | 12/19/19 | Updated Options Trade Condition Codes by adding ‘O’ =Opening Trade and correcting field value description for ‘p’by removing "Includes Complex Auctions on the Floor". (Effective 01/13/20). |
| 1.1.15 | 01/06/20 | `Updated Options Trade Condition Code t`=Complex Floor Trade of Proprietary Products Marked as "Combo Order" |
| 1.1.16 | 01/08/20 | Removed `l` = Complex Auction Against Single Legs(s) from Options Trade Condition Codes table. Removed `X` = Trade Break from Trade Condition field and table as this value is not disseminated on Complex TOP. |
| 1.1.17 | 01/31/20 | Corrected Unit Symbol Distribution tables to indicate QQQ is an exception for C1 Unit 20 as it has a dedicated location on Unit 28. Updated Trade Condition values. |
| 1.1.18 | 08/27/20 | Added SPESG to the Unit Symbol Distribution tables for C1 unti 31 (effective 09/21/20). |
| 1.1.19 | 10/06/20 | Added SPESG to the Unit Symbol Distribution table Exclusion entries for C1. |
| 1.1.20 | 10/20/20 | Added XSP to the Unit Symbol Distribution tables for BZX and removed it from EDGX (effective 11/2/20). |
| 1.1.21 | 02/01/21 | Added MRUT to the Unit/Product Distribution tables for C1 unit 31 (effective 3/01/21). Added new updated Unit/Product Distribution tables with harmonized symbol ranges (effective 3/22/21). |
| 1.1.22 | 03/11/21 | Updated the Unit Symbols Distribution Exceptions entries. (effective 3/22/21). |
| 1.1.23 | 03/25/21 | Added Binary Date field type to Section 2.2 - Data Types (effective 10/10/21 09/27/21 Q3 2021 ). Added new `Time Reference` message (effective 10/10/21 09/27/21 Q3 2021 ). Added EpochTime field to `Time` message (effective 10/10/21 TBD 09/27/21 Q3 2021 ). Updated description of Auction Type field on `Options Auction Update` and `Auction Summary` messages (effective TBD 09/27/21 Q3 2021). Updated description of GTH Trading Status field on `Trading Status` message (effective 01/24/22 TBD 09/27/21 Q3 2021 ). |
| 1.1.24 | 05/13/21 | Updated Curb session effective date to 02/07/22 TBD 09/27/21 . Added `v` = Extended Hours Trade Trade Condition code (effective 01/24/22 TBD 09/27/21 ). |
| 1.1.25 | 06/08/21 | Noted in `Complex Instrument Definition Expanded` message that a total of 16 legs are allowed (effective 08/25/21 08/09/21). |
| 1.1.26 | 06/15/21 | Updated effective date for expanded GTH session to 11/21/21. |
| 1.1.27 | 08/02/21 | Updated effective date for the `Complex Instrument Definition Expanded` message that a total of 16 legs are allowed (effective 08/25/21). |
| 1.1.28 | 08/30/21 | Updated effective date for Curb session, `v`=Extended Hours Trade Trade Condition code, updates to Auction Type field and GTH Trading Status field to (effective 01/24/22 TBD). |
| 1.1.29 | 09/09/21 | Added Trading Status field value `L` = Curb Trading (C1 Only) for `Trading Status` messages (effective 01/24/22 TBD). GTH Trading Status field will not be used for Curb session. Updated description of Auction Type field on Options Auction Update and Auction Summary messages (effective TBD). |
| 1.1.30 | 09/30/21 | Updated effective date for new `Time Reference` message (C1 Only) , EpochTime field to `Time` message (C1 Options Only) , and Binary Date field type to Section 2.2 - Data Types to 10/10/21. Added new section 1.2 - '24x5 Feed Hours and System Restart (C1 Only) ' (effective 10/10/21). |
| 1.1.31 | 11/04/21 | Corrected example `Time` message values. Updated Curb session effective date to 02/07/22 . Updated effective date for `v` = Extended Hours Trade Trade Condition code to 01/24/22. Updated effective date for Trading Status field value ‘ `L` = Curb Trading' to 01/24/22. Removed note indicating AuctionType value O will be sent prior to Curb session. This value will only be sent for the RTH Opening. |
| 1.1.32 | 01/03/22 | Added `m`=Complex Floor Trade Against Single Leg(s), `p`=Complex with Stock Floor Trade, and " `t`=Complex Floor Trade of Proprietary Products Marked as ‘Combo Order’" Trade Condition Codes. |
| 1.1.33 | 02/02/22 | Added NANOS to the C1 unit 32 Unit/Product Distribution tables (effective 03/14/22). |
| 1.1.34 | 03/01/22 | Removed XSP from the BZX unit 31 Unit/Product Distribustion tables. |
| 1.1.35 | 11/07/22 | Moved XSP to the C1 unit 32 Unit/Production Distribution table (effective 12/04/22). |
| 1.1.36 | 03/30/23 | Clarified RUT is on BZX and C2 Unit 31. |
| 1.1.37 | 01/29/24 | Added MXACW, MXUSA, and MXWLD to the C1 unit 31 Unit/Product Distribution tables (effective 03/18/24). |
| 1.1.38 | 04/02/24 | Added `Exchange Designated Complex Instrument Definition` message (effective 06/24/24). |
| 1.1.39 | 04/08/24 | Added additional detail to `Exchange Designated Complex Instrument Definition` message (effective 06/24/24). |
| 1.1.40 | 04/24/24 | Clarified `Exchange Designated Complex Instrument Definition` message is C1 only (effective 06/24/24). |
| 1.1.41 | 06/07/24 | Added a two-byte Reserve field to the Exchange Designated Complex Instrument Definition example message. |
| 1.1.42 | 07/22/24 | Effective 08/26/24, GTH will be extended until 9:25 a.m. ET (C1 only). |
| 1.1.43 | 11/22/24 | Added CBTX, CBTXW, MBTX, and MBTXW to the C1 unit 31 Unit/Product Distribution tables (effective 12/02/24). |
| 1.1.44 | 12/13/24 | Added new Unit/Product Distribution for Units 1-30 (effective 03/31/25). |
| 1.1.45 | 01/15/25 | Updated with Cboe Titanium branding. |
| 1.1.46 | 03/25/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 SPEQX to C1 unit 31 unit/product distribution (effective 04/14/25). |
| 1.1.47 | 07/08/25 | Updated Time Offset data type. Effective 09/08/25, Time Offset fields will be populated to nanosecond precision. |
| 1.1.48 | 07/24/25 | Specification updated to indicate complex functionality is available for all Cboe Options Exchanges, with BZX Options complex functionality effective on 10/13/25. |
| 1.1.49 | 08/13/25 | Removed unit 35 from `BZX Options Address/Unit Distribution` Secondary Dataset Table. |
| 1.1.50 | 10/20/25 | Added MGTN and MGTNW to unit 31 in US Options Unit/Product Distribution and excluded MGTN and MGTNW from unit 14 (effective 11/17/25). Updated Trading Status Message Fields to remove references to specific products traded during Curb and GTH sessions, replacing it with "Curb-eligible Products" and "GTH-eligible Products", respectively. |
| 1.1.51 | 11/06/25 | Updated MGTN and MGTNW effective date to TBD. |
| 1.1.52 | 11/18/25 | Updated MGTN and MGTNW effective dates to 12/08/25. |
| 1.1.53 | 01/12/26 | Updated 24x5 Feed Hours and System Restart to document the new time at which persisted orders are added back into the order book (effective 02/02/26). |
| 1.1.54 | 04/01/26 | Removed references to MXEA, MXEF, MXACW, MXUSA, and MXWLD. Updated Time description in `Time` and `Time Reference` messages. Added XSPBW to C1 unit 32 Unit/Product Distribution tables (effective 06/15/26 06/01/26 ). |
| 1.1.55 | 04/15/26 | Updated Trading Status Message Fields to reflect planned expansion of C1 trading hours for select equity options, including the addition of a morning Global Trading Hours (GTH) session and afternoon Curb session, subject to regulatory review (effective 07/13/26 08/17/26 TBD). |
| 1.1.56 | 05/14/26 | Updated XSPBW effective date to 06/15/26. Updated U.S. Options Unit/Product Distribution to include DJXW (effective 05/18/26). |
| 1.1.57 | 06/12/26 | Updated planned expansion of C1 trading hours for select equity options to 08/17/26. |
| 1.1.58 | 07/21/26 | Removed VIX and VIXW exclusion from unit 23 and added VIX and VIXW exclusion to unit 24 U.S. Options Unit/Product Distribution tables. |
| 1.1.59 | 08/10/26 | Updated planned expansion of C1 trading hours for select equity options to TBD. |