# Cboe Titanium Cboe One Options Feed Specification

Version 1.1.15 · August 10, 2026

## Introduction

The Cboe Titanium Cboe One Options feed delivers consolidated quote and trade information for the Cboe Options (C1), C2 Options (C2), EDGX Options (EDGX), and BZX Options (BZX) Exchanges simple books via UDP using the binary Cboe One protocol. The feed consists of `Symbol Summary`, `Best Quote Update`, `Market Status`, `Trade`, `Trade Break`, and `Trading Status` messages.

The UDP delivered feed is sourced from the Cboe One Feed Server (FS). The FS generates the multicast events for the Cboe One Options feed and performs throttling of events to ensure the bandwidth requirements of the feed are not exceeded. The FS does not receive messages from users and no login is necessary. Users may also connect to the Cboe One Gap Request Proxy (GRP) for retransmission of missed packets on the UDP feed by the Cboe One Gap Server (GS).

It is important to note the Cboe One Options feed is an aggregated feed. Symbol updates are sent as feed capacity allows. The image for a symbol will be current at the time of delivery, but multiple updates may be combined into a single update. The interval between updates is dependent on the market conditions and the capacity configuration of the Cboe One Options feed.

The maximum output bandwidth of the Cboe One Options feed will not exceed 5 Gb/s. Users may choose to take the feed from the Primary or Secondary data centers, depending on the user's location and connectivity to Cboe.

### Feed Hours

The Cboe One Options feed will cover the RTH session only for all products, beginning at approximately 7:30 a.m. ET and ending at 4:15 p.m. ET. GTH-enabled classes will receive RTH only coverage beginning at that time.

For more information about Cboe options exchanges trading hours, please refer to Hours & Holidays.

### Feed Connectivity Requirements

The Cboe One Options feed is available to users who meet the minimum bandwidth requirements to receive the feed via cross-connect, dedicated circuit, or a supported carrier.

Cboe One Options 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 One’s GRP servers with replayed messages being delivered on a separate set of multicast ranges reserved for packet retransmission. Intraday, a spin of the current aggregated book, may be requested from a Spin Server.

Multicast addresses and ports for the Cboe One Options feed are listed in Multicast Configuration.

### Symbol Ranges, Units, and Sequence Numbers

Symbols will be separated into units and symbol distribution (see Limitations/Configurations) will not change intraday. However, Cboe reserves the right to add multicast addresses or change the symbol distribution with 48 hours prior notice to users. Care should be taken to ensure that address changes, address additions, and symbol 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 intraday 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.

### Options Specific Symbol Processing

Cboe has implemented a symbol mapping mechanism ( `Symbol Mapping` message) for the Cboe One Options feed. Each OSI symbol is mapped to a unique six-character, base-62 compressed ASCII encoded Symbol. This symbol mapping mechanism significantly reduces the size of the Cboe One Options feed and allows users to use the same symbol handling mechanisms for the Cboe-operated equity, options, and futures exchanges. See Cboe Titanium U.S. Symbology Reference for further details.

Symbol mapping information is available via the Spin Servers (see Spin Servers for further details). `Symbol Mapping` messages will be un-sequenced and are available from pre-market through the end of trading.

In addition to the `Symbol Mapping` messages available via the multicast feed Spin Servers, a downloadable file with current mappings is available via the Cboe website.

### Gap Request Proxy and Message Retransmission

Requesting delivery of missed sequenced data is achieved by establishing a TCP connection to a GRP port. This GRP port is specific to Cboe One Options and is NOT shared with the GRP port of any other Cboe multicast market data feed. Users 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. Users choosing to request missed data will need to connect to their assigned GRP port, log in, and request gap ranges as necessary. All gap requests will be responded to with a `Gap Response` message. A `Gap Response` message Status code of `A` (Accepted) signals that the replayed messages will be delivered via the appropriate gap response multicast address. Any other `Gap Response` message Status code will indicate the reason that the request cannot be serviced.

Gap requests are limited in message count, frequency, and age by the GRP. Gap requests will only be serviced if they are within a defined sequence range of the current multicast sequence number for the requested unit. Users will receive a total daily allowance of gap-requested messages. In addition, each user is given renewable 1-second and 1-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 timeframe, the gap server will only send the union of the sequence ranges across grouped gap requests. Users 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 users to connect via TCP and receive a spin of the aggregated book and symbols and market centers with limited trading conditions on that unit. By using the spin, a user can quickly get the current state of the book 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 user 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.

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

A spin will consist of `Cboe Market Status`, `Trading Status`, `Short Symbol Summary`, `Long Symbol Summary` and `Trade` messages. `Trade` messages will contain only the last trade for each symbol that was received by the spin server at the time of the spin image. While receiving the spin, the user must buffer multicast messages received. If the `Spin Image Available` message sequence number is the user’s reference point, multicast messages with larger sequence numbers should be buffered. If a non- `Spin Image Available` message sequence number is the user’s reference point which they send in their `Spin Request` message, they should buffer from that point on, but note that within the spin they may receive sequence numbers beyond that point which they may disregard. When a `Spin Finished` message is received, the buffered messages must be applied to a spun copy of the book to bring it current.

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

Spin Server Usage Example shows an example flow of messages between a user and Cboe One Options multicast feed and Spin Server.

### Cboe One Options Disaster Recovery

Users of Cboe One Options who are interested in disaster recovery must maintain connectivity to the Cboe Disaster Recovery (DR) site in Chicago, IL. To establish new connectivity to the DR site, contact the Cboe NOC.

The Cboe One Options feed that is disseminated from the DR site takes the Cboe Multicast Top services sourced in the DR site for C1, C2, EDGX, and BZX Options. It serves the same data as is distributed from the Cboe One Primary site in Secaucus, NJ all day long, so Cboe One Options customers can fail-over to or utilize the Cboe One Options feed out of the DR site at any time. However, note that sequence numbers are not guaranteed to be the same between the Primary and DR sites.

The Cboe DR site is designed to support Cboe One Options inter data center resiliency in the following DR scenarios:

1. Hardware failure in the primary Cboe One Options system. Customers always have the option to switch to the DR site at will if they don't want to wait for remediation of failed hardware in the Primary data center to take place.
2. Failover of one or more of Cboe’s options platforms to their respective DR site. The Cboe One Options feed in the Primary site currently only connects to market data for Cboe One Options within the Primary site. If one of the exchanges fails over to the DR site, then the Cboe One Options feed out of Primary site will not be able to disseminate updates from that exchange’s market data feed in the DR site. In this scenario, customers should take the Cboe One Options feed out of the DR site to regain full coverage.
3. Loss of any of the Cboe One Options input feeds. Similar to scenario #2, if Cboe experiences a market data (Multicast Top) dissemination issue for any Cboe One Options exchange at the Primary site, but Multicast Top market data is valid for the problem exchange at the DR site, then Cboe One Options customers have the option to switch over to the DR Cboe One Options feed to regain full coverage.

## Protocol

Cboe users may use the Cboe One Options protocol over multicast to receive the Cboe One Options feed direct from Cboe.

Cboe One Options cannot be used to enter orders. For order entry, refer to the Cboe FIX or BOE specifications.

### Message Format

The messages that make up the Cboe One Options protocol are delivered using `Sequenced Unit Header` message header which handles sequencing and delivery integrity. All messages delivered via multicast, and messages to and from the GRP or Spin Server, will use the `Sequenced Unit Header` message header for handling message integrity.

All UDP-delivered events will be self-contained. Developers can assume that UDP-delivered data will not cross frame boundaries and a single Ethernet frame will contain only one `Sequenced Unit Header` message 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 Cboe One Options 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. Cboe One Options users should develop their decoders to deal with unknown message types and messages that grow beyond the expected length. Messages will only be grown to add additional data to the end of a message.

### Data Types

The following field types are used within the `Sequenced Unit Header` message header, GRP messages, and Cboe One Options feed.

- 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).
- Binary 4.4 Price fields are unsigned Little Endian encoded 4 byte binary fields with 4 implied decimal places ( `denominator` = 10,000).
- Binary 8.4 Price fields are unsigned Little Endian encoded 8 byte binary fields with 4 implied decimal places ( `denominator` = 10,000).
- 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.

### Message Framing

Cboe One Options messages will be combined into a 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 `Sequenced Unit Header` message header. Framing will be determined by the server for each unit and site. The content of the multicast across feeds (i.e., Primary and DR) will be identical, but framing will not be consistent across feeds. Receiving processes that receive and arbitrate multiple feeds cannot use frame level arbitration.

### Cboe Sequenced Unit Header Message Fields

The `Sequence Unit Header` message header is used for all Cboe One Options messages and messages to and from the GRP and Spin Servers.

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

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

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

**Table 1. Sequenced Unit Header**

| Field | Offset | Length | Value/Type | Description |
|---|---|---|---|---|
| Hdr Length | 0 | 2 | Binary | Length of entire block of messages. Includes this header and 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` message header with a Hdr 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 but can be used to detect gaps on the real-time multicast channels during low update rate periods.

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

## Cboe One Options Update Messages

The messages described in this section are delivered from the Cboe One Feed Server (UDP), and the Cboe One Gap Server (UDP gap responses).

### Short Symbol Summary Message Fields

The `Short Symbol Summary` message delivers the Cboe consolidated best bid/offer and total executed volume across all applicable Cboe One Options books.

**Table 1. Short Symbol Summary**

| Field | Offset | Length | Value/Type | Description |
|---|---|---|---|---|
| Length | 0 | 1 | Binary | Length of this message including this field. |
| Message Type | 1 | 1 | 0xA4 | `Short Symbol Summary` message |
| Last Update Timestamp | 2 | 8 | Binary | Timestamp of the last matching engine message that updated the quote information for this symbol in the Cboe One Options server’s cache. Encoded as the number of nanoseconds since midnight. |
| Symbol | 10 | 8 | Alphanumeric | Symbol right padded with spaces. |
| Cboe Cumulative Executed Volume | 18 | 4 | Binary | Cumulative number of shares traded today across all applicable Cboe books. |
| Consolidated Best Bid Price | 22 | 4 | Binary 4.4 Price | Cboe Consolidated best bid price. |
| Consolidated Best Bid Quantity | 26 | 4 | Binary | Cboe Consolidated number of buy-side shares available for this symbol. |
| Consolidated Best Ask Price | 30 | 4 | Binary 4.4 Price | Cboe Consolidated best ask price. |
| Consolidated Best Ask Quantity | 34 | 4 | Binary | Cboe Consolidated number of sell-side shares available for this symbol. |
| Reserved | 38 | 5 |  | Reserved |
| `Total Length` = 43 bytes |  |  |  |  |

### Long Symbol Summary Message Fields

The `Long Symbol Summary` message delivers the Cboe consolidated best bid/offer and total executed volume across all applicable Cboe One Options books.

**Table 1. Long Symbol Summary**

| Field | Offset | Length | Value/Type | Description |
|---|---|---|---|---|
| Length | 0 | 1 | Binary | Length of this message including this field. |
| Message Type | 1 | 1 | 0xA3 | `Long Symbol Summary` message |
| Last Update Timestamp | 2 | 8 | Binary | Timestamp of the last matching engine message that updated the quote information for this symbol in the Cboe One Options server’s cache. Encoded as the number of nanoseconds since midnight. |
| Symbol | 10 | 8 | Alphanumeric | Symbol right padded with spaces. |
| Cboe Cumulative Executed Volume | 18 | 8 | Binary | Cumulative number of shares traded today across all applicable Cboe books. |
| Consolidated Best Bid Price | 26 | 8 | Binary 8.4 Price | Cboe Consolidated best bid price. |
| Consolidated Best Bid Quantity | 34 | 8 | Binary | Cboe Consolidated number of buy-side shares available for this symbol. |
| Consolidated Best Ask Price | 42 | 8 | Binary 8.4 Price | Cboe Consolidated best ask price. |
| Consolidated Best Ask Quantity | 50 | 8 | Binary | Cboe Consolidated number of sell-side shares available for this symbol. |
| Reserved | 58 | 9 |  | Reserved |
| `Total Length` = 67 bytes |  |  |  |  |

### Best Quote Update Message Fields

The `Best Quote Update` message is used to update one side of the Cboe consolidated quote information for a symbol. Since the message only updates one side of the quote, the previous value for the other side of the quote remains in effect.

This message does not affect the executed volume of the symbol.

**Table 1. Best Quote Update**

| Field | Offset | Length | Value/Type | Description |
|---|---|---|---|---|
| Length | 0 | 1 | Binary | Length of this message including this field. |
| Message Type | 1 | 1 | 0xA5 | `Best Quote Update` message |
| Last Update Timestamp | 2 | 8 | Binary | Timestamp of the last matching engine message that updated the quote information for this symbol in the Cboe One Options server’s cache. Encoded as the number of nanoseconds since midnight. |
| Symbol | 10 | 8 | Alphanumeric | Symbol right padded with spaces. |
| Side Indicator | 18 | 1 | Alphanumeric | `B` = Buy Side `S` = Sell Side |
| Consolidated Best Quote Price | 19 | 8 | Binary 8.4 Price | Cboe Consolidated best price. |
| Consolidated Quote Quantity | 27 | 8 | Binary | Cboe Consolidated number of shares available for this symbol. |
| `Total Length` = 35 bytes |  |  |  |  |

### Cboe Market Status Message Fields

The `Cboe Market Status` message is disseminated to reflect a change in the status of a market. All markets should be assumed to be `Normal`unless otherwise indicated by a `Cboe Market Status` message.

An `Incomplete`Market Status indicates the feed has not delivered updates for all of a market center’s symbols and that the feed is transitioning to `Normal`. If a market center transitions from `Normal`to `Excluded`, the feed will deliver updates of symbol quote information to properly reflect the state of the combined book. At the start of a market center’s transition from `Excluded`to `Normal`, a `Cboe Market Status` message will be sent with `Incomplete`for the market center’s status. Symbol quote information will then be sent for all applicable symbols. Once the market center’s symbol information has been disseminated, a `Cboe Market Status` message will be delivered with a `Normal`market status.

**Table 1. Cboe Market Status**

| Field | Offset | Length | Value/Type | Description |
|---|---|---|---|---|
| Length | 0 | 1 | Binary | Length of this message including this field. |
| Message Type | 1 | 1 | 0xA6 | `Cboe Market Status` message |
| Timestamp | 2 | 8 | Binary | Timestamp of when the Market Status changed for the specified Market Center. Encoded as the number of nanoseconds since midnight. |
| Market Center | 10 | 1 | Alphanumeric | `B` = C1 `W` = C2 `X` = EDGX `Z` = BZX |
| Market Status | 11 | 1 | Alphanumeric | `N` = Normal `E` = Excluded from Symbol Summary updates `I` = Incomplete |
| Reserved | 12 | 1 |  | Reserved |
| `Total Length` = 13 bytes |  |  |  |  |

### Trade Message Fields

`Trade` messages are sent when an order is executed in whole or in part on a Cboe exchange.

**Table 1. Trade**

| Field | Offset | Length | Value/Type | Description |
|---|---|---|---|---|
| Length | 0 | 1 | Binary | Length of this message including this field. |
| Message Type | 1 | 1 | 0xA9 | `Trade` message |
| Transaction Time | 2 | 8 | Binary | The time the trade occurred on the specified Market Center. Encoded as the number of nanoseconds since midnight. |
| Symbol | 10 | 8 | Alphanumeric | Symbol right padded with spaces. |
| Market Center | 18 | 1 | Alphanumeric | Market Center on which the last trade was executed: `B` = C1 `W` = C2 `X` = EDGX `Z` = BZX |
| Market Center Execution ID | 19 | 8 | Binary | Market center specific execution identifier of this Execution. Execution ID is also referenced in the `Trade Break` message. |
| Last Price | 27 | 8 | Binary 8.4 Price | Last trade price. |
| Last Quantity | 35 | 8 | Binary | Last trade quantity. |
| Cboe Cumulative Executed Volume | 43 | 8 | Binary | Cumulative number of shares traded today across all applicable books. |
| Trade Condition | 51 | 1 | Alphanumeric | See Options Trade Condition Codes for details. |
| Reserved | 52 | 8 |  | Reserved |
| `Total Length` = 60 bytes |  |  |  |  |

### Trade Break Message Fields

The `Trade Break` message is sent whenever an execution on a Cboe exchange is broken. Trade breaks are rare and only affect applications that rely upon Cboe execution based data.

**Table 1. Trade Break**

| Field | Offset | Length | Value/Type | Description |
|---|---|---|---|---|
| Length | 0 | 1 | Binary | Length of this message including this field. |
| Message Type | 1 | 1 | 0xAA | `Trade Break` message |
| Transaction Time | 2 | 8 | Binary | The time the trade break occurred on the specified Market Center. Encoded as the number of nanoseconds since midnight. |
| Symbol | 10 | 8 | Alphanumeric | Symbol right padded with spaces. |
| Market Center | 18 | 1 | Alphanumeric | Market Center on which the last trade was executed: `B` = C1 `W` = C2 `X` = EDGX `Z` = BZX |
| Market Center Execution ID | 19 | 8 | Binary | Market center specific execution identifier of trade to be broken. |
| Cboe Cumulative Executed Volume | 27 | 8 | Binary | Cumulative number of shares traded today across all applicable Cboe books. |
| Reserved | 35 | 9 |  | Reserved |
| `Total Length` = 44 bytes |  |  |  |  |

### Trading Status Message Fields

The `Trading Status` message is used to indicate the current trading status of an options contract on a Cboe exchange. A `Trading Status` message will be sent whenever a security’s trading status changes. The following summarizes the Trading Status values in the Cboe system:

- H = Halt state.
- Q = Queuing. Sent starting at 7:30 a.m. ET once orders can be accepted for queuing in preparation for the RTH open.
- T = RTH Trading. Sent when symbol is open for trading, at or after 9:30 a.m. ET.

A `Trading Status` message will also be sent:

- For a Regulatory Halt `Q` (Queuing) period in any symbol where the underlying has experienced a Regulatory Halt as well as the `T` (Trading) resumption for the same instrument. Table 1. Trading Status Field Offset Length Value/Type Description Length 0 1 Binary Length of this message including this field. Message Type 1 1 0xAB `Trading Status` message Timestamp 2 8 Binary Timestamp of the matching engine trading status message emitted by the specified Market Center. Encoded as the number of nanoseconds since midnight. Symbol 10 8 Alphanumeric Symbol right padded with spaces. Market Center 18 1 Alphanumeric `B` = C1 `W` = C2 `X` = EDGX `Z` = BZX Halt Status 19 1 Alphanumeric `H` = Halted `Q` = Quote-Only `R` = Opening Rotation `T` = Trading Reserved 20 1 Reserved `Total Length` = 21 bytes

## Gap Request Proxy Messages

Gap Request Proxy messages are used for initializing a TCP/IP connection to the GRP and to request message retransmissions. Users only need to implement the following messages if gap requests will be made. Each of the message types must be wrapped by an unsequenced unit header as described in Cboe Sequenced Unit Header Message Fields. Gap Request Proxy messages will not be delivered using multicast.

### GRP Login Message Fields

The `GRP 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. GRP Login**

| Field | Offset | Length | Value/Type | Description |
|---|---|---|---|---|
| Length | 0 | 1 | Binary | Length of this message including this field. |
| Message Type | 1 | 1 | 0x01 | `GRP 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.

The `Gap Request` message for Cboe One Options is identical to the Multicast Pitch `Gap Request` message. The Unit field should be set to 0 since the Cboe One Options feed is not unitized.

**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 (0 for Cboe One Options implementation). |
| 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 Message Fields**

| 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 (0 for Cboe One Options implementation). |
| 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

Spin message types must be wrapped by an unsequenced unit header as described in Cboe Sequenced Unit Header Message Fields.

### Login

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

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

### Login Response

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

The format of the `Login Response` message for the Spin Server is identical to that of the GRP described 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 additional details regarding Spin messaging 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 user. |
| `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 user. |
| 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` message was not rejected. Upon receipt of a `Spin Finished` message, any buffered multicast messages should be applied to the user’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. Refer to Spin Servers for additional details regarding Spin messaging 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 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.

**Table 1. 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` 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` messages for this unit have been sent. An `Instrument Definition Finished` message is only sent if an `Instrument Definition Request` message 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 |  |  |  |  |

### Symbol Mapping Message Fields

`Symbol Mapping` messages are sent in response to an Accepted `Instrument Definition Request` message.

**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. |
| `Total Length` = 38 bytes |  |  |  |  |

### Trade Replay Request Message Fields

The `Trade Replay Request` message is used by a user’s process to request transmission of all `Trade` and `Trade Break` messages previously emitted by this unit prior to receiving the user’s `Trade Replay Request` message. Refer to Spin Servers for additional details regarding Spin messaging as well as buffering requirements.

**Table 1. Trade Replay Request**

| Field Name | Offset | Length | Type/(Value) | Description |
|---|---|---|---|---|
| Length | 0 | 1 | Binary | Length of this message including this field |
| Message Type | 1 | 1 | 0x87 | `Trade Replay Request` message |
| Sequence | 2 | 4 | Binary | Must be 0. All `Trade` and `Trade Break` messages available at the time of the request are sent. |
| `Total Length` = 6 bytes |  |  |  |  |

### Trade Replay Response Message Fields

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

**Table 1. Trade Replay Response Message Fields**

| Field Name | Offset | Length | Type/(Value) | Description |
|---|---|---|---|---|
| Length | 0 | 1 | Binary | Length of this message including this field |
| Message Type | 1 | 1 | 0x88 | `Trade Replay Response` message |
| Sequence | 2 | 4 | Binary | Will always be 0. |
| Message Count | 6 | 8 | Binary | Number of `Trade` and `Trade Break` messages which will be contained in this spin. |
| Status | 10 | 1 | Alphanumeric | Accepted or reason for reject |
| `Total Length` = 15 bytes |  |  |  |  |
| Trade Replay Response - Status Codes |  |  |  |  |
| ‘A’ | Accepted |  |  |  |
| ‘O’ | Out of Range (Sequence must be 0) |  |  |  |
| ‘U’ | Trade Replay functionality is not available on this unit. |  |  |  |
| ‘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.

### Trade Replay Finished Message Fields

The `Trade Replay Finished` message is sent to indicate that all `Trade` and `Trade Break` messages for this unit have been sent. A `Trade Replay Finished` message is only sent if a `Trade Replay Request` message was not rejected.

**Table 1. Trade Replay Finished**

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

### Spin Server Usage Example

The following diagram shows the exchange of messages over time between a user and Cboe One Options multicast feed and Spin Server.

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

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

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

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

At time 11, the user sends a `Spin Request` message for all messages up to and including 310175 and continues to cache Cboe One Options messages received.

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

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

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

_(Figure)_

## Production Environment Multicast Configuration

### Limitations/Configurations

The following table defines Cboe’s current 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. Cboe One Options users should ensure that their infrastructure is configured accordingly. |
| 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 | 1500 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.

### Cboe One Options Multicast Routing Parameters

| Data Center | Rendezvous Point |
|---|---|
| Primary Data Center (NY5) | 74.115.128.156 |
| Secondary Data Center (CH4) | 174.136.181.252 |

### Production Address/Unit Distribution

The following tables describe the unit distribution across the production Cboe One Options multicast feeds.

| Primary Datacenter | Production 170.137.114.240/28 |  |  |
|---|---|---|---|
| Unit | IP Port | Real-time MC | Gap Resp. MC |
| 1 | 32801 | 233.65.120.0 | 233.65.120.9 |
| 2 | 32802 |  |  |
| 3 | 32803 |  |  |
| 4 | 32804 |  |  |
| 5 | 32805 | 233.65.120.1 | 233.65.120.10 |
| 6 | 32806 |  |  |
| 7 | 32807 |  |  |
| 8 | 32808 |  |  |
| 9 | 32809 | 233.65.120.2 | 233.65.120.11 |
| 10 | 32810 |  |  |
| 11 | 32811 |  |  |
| 12 | 32812 |  |  |
| 13 | 32813 | 233.65.120.3 | 233.65.120.12 |
| 14 | 32814 |  |  |
| 15 | 32815 |  |  |
| 16 | 32816 |  |  |
| 17 | 32817 | 233.65.120.4 | 233.65.120.13 |
| 18 | 32818 |  |  |
| 19 | 32819 |  |  |
| 20 | 32820 |  |  |
| 21 | 32821 | 233.65.120.5 | 233.65.120.14 |
| 22 | 32822 |  |  |
| 23 | 32823 |  |  |
| 24 | 32824 |  |  |
| 25 | 32825 | 233.65.120.6 | 233.65.120.15 |
| 26 | 32826 |  |  |
| 27 | 32827 |  |  |
| 28 | 32828 |  |  |
| 29 | 32829 | 233.65.120.7 | 233.65.120.16 |
| 30 | 32830 |  |  |
| 31 | 32831 |  |  |
| 32 | 32832 |  |  |
| 33 | 32833 | 233.65.120.8 | 233.65.120.17 |
| 34 | 32834 |  |  |

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.

| Secondary Datacenter | Production 170.137.124.240/28 |  |  |
|---|---|---|---|
| Unit | IP Port | Real-time MC | Gap Resp. MC |
| 1 | 32801 | 233.65.120.128 | 233.65.120.137 |
| 2 | 32802 |  |  |
| 3 | 32803 |  |  |
| 4 | 32804 |  |  |
| 5 | 32805 | 233.65.120.129 | 233.65.120.138 |
| 6 | 32806 |  |  |
| 7 | 32807 |  |  |
| 8 | 32808 |  |  |
| 9 | 32809 | 233.65.120.130 | 233.65.120.139 |
| 10 | 32810 |  |  |
| 11 | 32811 |  |  |
| 12 | 32812 |  |  |
| 13 | 32813 | 233.65.120.131 | 233.65.120.140 |
| 14 | 32814 |  |  |
| 15 | 32815 |  |  |
| 16 | 32816 |  |  |
| 17 | 32817 | 233.65.120.132 | 233.65.120.141 |
| 18 | 32818 |  |  |
| 19 | 32819 |  |  |
| 20 | 32820 |  |  |
| 21 | 32821 | 233.65.120.133 | 233.65.120.142 |
| 22 | 32822 |  |  |
| 23 | 32823 |  |  |
| 24 | 32824 |  |  |
| 25 | 32825 | 233.65.120.134 | 233.65.120.143 |
| 26 | 32826 |  |  |
| 27 | 32827 |  |  |
| 28 | 32828 |  |  |
| 29 | 32829 | 233.65.120.135 | 233.65.120.144 |
| 30 | 32830 |  |  |
| 31 | 32831 |  |  |
| 32 | 32832 |  |  |
| 33 | 32833 | 233.65.120.136 | 233.65.120.145 |
| 34 | 32834 |  |  |

## Certification Environment Multicast 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.

### Cboe One Options Certification Multicast Routing Parameters

| Data Center | Rendezvous Point |
|---|---|
| Certification Data Center (NY5) | 74.115.128.129 |

### Certification Address/Unit Distribution

The following tables describe the unit distribution across the production Cboe One Options multicast feeds.

| Primary Datacenter | Certification 170.137.126.32/28 |  |  |
|---|---|---|---|
| Unit | IP Port | Real-time MC | Gap Resp. MC |
| 1 | 32801 | 224.0.74.252 | 224.0.74.254 |
| 2 | 32802 |  |  |
| 3 | 32803 |  |  |
| 4 | 32804 |  |  |
| 5 | 32805 |  |  |
| 6 | 32806 |  |  |
| 7 | 32807 |  |  |
| 8 | 32808 |  |  |
| 9 | 32809 |  |  |
| 10 | 32810 |  |  |
| 11 | 32811 |  |  |
| 12 | 32812 |  |  |
| 13 | 32813 |  |  |
| 14 | 32814 |  |  |
| 15 | 32815 |  |  |
| 16 | 32816 |  |  |
| 17 | 32817 |  |  |
| 18 | 32818 | 224.0.74.253 | 224.0.74.255 |
| 19 | 32819 |  |  |
| 20 | 32820 |  |  |
| 21 | 32821 |  |  |
| 22 | 32822 |  |  |
| 23 | 32823 |  |  |
| 24 | 32824 |  |  |
| 25 | 32825 |  |  |
| 26 | 32826 |  |  |
| 27 | 32827 |  |  |
| 28 | 32828 |  |  |
| 29 | 32829 |  |  |
| 30 | 32830 |  |  |
| 31 | 32831 |  |  |
| 32 | 32832 |  |  |
| 33 | 32833 |  |  |
| 34 | 32834 |  |  |

## Options Trade Condition Codes

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

| Type | Field Value |
|---|---|
| a | Single Leg Auction Non ISO Cboe auction types include AIM, SAM |
| b | Single Leg Auction ISO Cboe auction types include AIM ISO, SAM ISO |
| c | Single Leg Cross Non ISO Cboe auction types include Cust to Cust AIM, QCC |
| d | Single Leg Cross ISO Cboe order type is Cust to Cust AIM ISO |
| e | Single Leg Floor Trade |
| 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 |
| i | Complex Floor Trade This value will be deprecated and all complex floor executions will be reported as condition ‘m’. |
| 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 will be 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" |
| u | Multilateral Compression Trade of Proprietary Products |
| v | Extended Hours Trade. Transaction represents a trade executed during the Curb session. |
| I | Electronic Trade |
| K* | Cabinet Order |
| O* | Opening Trade |
| S | ISO |

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

## 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 | 02/15/23 | Initial version. |
| 1.0.1 | 02/27/23 | Updated section 1.7 to clarify that `Trade` messages in a spin will contain only the last trade for each symbol that was received by the spin server at the time of the spin image. |
| 1.0.2 | 03/30/23 | Clarified RUT is on BZX and C2 Unit 31. |
| 1.0.3 | 11/22/24 | Added CBTX, CBTXW, MBTX, and MBTXW to the unit 31 Unit/Product Distribution tables (effective 12/02/24). |
| 1.0.4 | 12/13/24 | Added new Unit/Product Distribution for Units 1-30 (effective 03/31/25). |
| 1.0.5 | 01/15/25 | Updated with Cboe Titanium branding. |
| 1.0.6 | 03/25/25 | Added SPEQX to C1 unit 31 unit/product distribution (effective 04/14/25). |
| 1.0.7 | 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 12/08/25 TBD 11/17/25). |
| 1.0.8 | 11/06/25 | Updated MGTN and MGTNW effective dates to TBD. |
| 1.0.9 | 11/18/25 | Updated MGTN and MGTNW effective dates to 12/08/25. |
| 1.0.10 | 04/01/26 | Removed references to MXEA, MXEF, MXACW, MXUSA, and MXWLD. Added XSPBW to C1 unit 32 Unit/Product Distribution tables (effective 06/15/26 06/01/26 ). |
| 1.0.11 | 04/15/26 | Updated Feed Hours 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.12 | 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.13 | 06/12/26 | Updated planned expansion of C1 trading hours for select equity options to 08/17/26. |
| 1.1.14 | 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.15 | 08/10/26 | Updated planned expansion of C1 trading hours for select equity options to TBD. |