# Cboe Titanium U.S. Options FLEX Feed Specification

Version 1.1.35 · August 10, 2026

## Introduction

This specification will be the standard specification used for market data for FLEX Options on the Cboe Options (C1) Exchange platform.

Cboe customers may use the FLEX feed to receive real-time auction updates and execution information.

Options FLEX feed cannot be used to enter orders. For order entry, refer to the US Options FIX Specification.

A WAN-Shaped version of the FLEX feed is available from both of Cboe’s datacenters. Customers may choose to take one or more of the following FLEX feed options depending on their location and connectivity to Cboe.

| Exchange | Shaping (WAN) | Served From Data Center (Primary/Secondary) | Multicast Feed ID |
|---|---|---|---|
| C1 Options | WAN | Primary | CAF |
| C1 Options | WAN | Primary | CBF |
| C1 Options | WAN | Secondary | CEF |

### 24x5 Feed Hours and System Restart

For C1 Options operating in 24x5 mode, the FLEX 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 (between 6:00 p.m. and 7:00 p.m. ET) 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 with a minimum of 100 Mb/s of connectivity to Cboe via cross connect or dedicated circuit.

Customers with sufficient connectivity may choose to take more than one WAN-Shaped feed from the Cboe datacenters. It should be noted that due to proximity, feeds from the secondary datacenter will have additional latency than those co-located with Cboe in the primary datacenter.

Cboe Options FLEX feed real-time events are delivered using a single published multicast address for all symbol ranges.

The following diagram is a logical representation of Options FLEX feed message flow between Cboe and a customer feed handler that is listening to the "A" and "B" instances of two units:

_(Figure)_

### FLEX Specific Symbol Processing

Cboe has implemented a symbol definition mechanism for both simple and complex instruments on the FLEX feed. This significantly reduces the size of the FLEX feed and allows participants to use the same symbol handling mechanisms for the Cboe operated equities, options, and futures exchanges. Refer to the `FLEX Instrument Definition` and `Complex FLEX Instrument Definition` messages for more information.

The `FLEX Instrument Definition` or `Complex FLEX Instrument Definition` messages are sequenced messages that are sent when an instrument is created. If a user misses a definition message, that message can be recovered through either the GRP or SPIN Server.

### Gap Request Proxy and Message Retransmission

Establishing a TCP connection to a Gap Request Proxy (GRP) port allows for delivery of missed sequenced data. This GRP port is specific to FLEX feed and is NOT shared with any other Cboe Options market data feed. Participants who do not wish to request missed messages do not need to connect to a GRP port for any reason or listen to the multicast addresses reserved for message retransmission. Participants choosing to request missed data will need to connect to their assigned GRP port, log in, and request gap ranges as necessary. All gap requests will be responded to with a `Gap Response` message. A `Gap Response` Status code of `A`ccepted 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. Participants will receive a total daily allowance of gap requested messages. In addition, each participant is given renewable one second and one minute gap request limits.

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

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

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

### Spin Servers

A Spin Server is available for each unit. The server allows participants to connect via TCP and receive a spin of all symbol definitions, including `FLEX Instrument Definition,` `Complex FLEX Instrument Definition`, and `Trading Status` messages. By using the spin, a participant can get the current instrument definitions and trading status messages 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. Using a `Spin Request` message, a participant may request a spin for symbol definitions and trading status messages 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 participant 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.

Customers can also use the Spin Server to request a spin of all symbol 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.

## Protocol

### Message Format

The messages that make up the FLEX feed protocol are delivered using Cboe `Sequenced Unit Header` which handles sequencing and delivery integrity. All messages delivered via multicast will also 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.

This FLEX 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 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).
- Signed Binary fields are signed and sized to `Length` bytes and ordered using Little Endian convention (least significant byte first).
- Binary Signed Short Price fields are signed Little Endian encoded 2 byte binary fields with 2 implied decimal places ( `denominator`=100). The short price range is -327.68 to +327.67. Prices outside of this range will use the long price.
- Binary Signed Long Price fields are signed Little Endian encoded 8 byte binary fields with 4 implied decimal places ( `denominator`=10,000).
- 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

Messages will be combined into a single UDP frame when possible to decrease message overhead and total bandwidth. The count of messages in a UDP frame will be communicated using `Sequenced Unit Header`. The server for each site will determine framing. The content of the multicast across feeds (e.g. A/B WAN-Shaped) 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.

### Sequenced Unit Header

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

This feed delivers sequenced and unsequenced data using the `Sequenced Unit Header`. Unsequenced headers will have a 0 value for the sequence field and potentially for the unit field.

**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 all multicast addresses if no data has been delivered within 1 second. `Heartbeat` messages never increment the sequence number.

Outside of trading hours Cboe sends heartbeat messages on all real-time channels with a sequence of `0` to help users validate multicast connectivity. `Heartbeat` messages may not be sent from 12:00 a.m. - 1:00 a.m. ET or during maintenance windows.

Cboe expects `Heartbeat` messages to be sent to the GRP and Spin 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.

## FLEX Feed Messages

### Time Reference

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

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

A 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 | Number of whole seconds since the Epoch (midnight January 1, 1970 UTC). |
| `Total Length` = 10 bytes |  |  |  |  |

### FLEX Instrument Definition

A `FLEX Instrument Definition` message represents an instrument that is available to place orders. It is sent as a sequenced message.

**Table 1. Flex Instrument Definition**

| Field Name | Offset | Length | Type/(Value) | Description |
|---|---|---|---|---|
| Length | 0 | 1 | Binary | Length of this message including this field. |
| Message Type | 1 | 1 | 0x9C | `Flex Instrument Definition` Message |
| Time Offset | 2 | 4 | Time Offset | Nanosecond offset from last unit timestamp. |
| Feed Symbol | 6 | 6 | Printable ASCII | Symbol right padded with spaces. |
| OSI Root | 12 | 6 | Printable ASCII | OSI Root right padded with spaces. |
| Year | 18 | 2 | Alphanumeric | Two digit year |
| Month | 20 | 2 | Alphanumeric | Two digit month |
| Day | 22 | 2 | Alphanumeric | Two digit day |
| Call Put Indicator | 24 | 1 | Alphanumeric | `C` = Call `P` = Put |
| Dollar Strike | 25 | 5 | Alphanumeric | Dollar strike (if not percentage) left padded with zero. If percentage, field is space padded. |
| Decimal Strike | 30 | 3 | Alphanumeric | Decimal strike (if not percentage) left padded with zero. If percentage, field is space padded. |
| Symbol Condition | 33 | 1 | Alphanumeric | `N` = Normal `C` = Closing Only |
| Underlying | 34 | 8 | Printable ASCII | Instrument Underlying right padded with spaces. |
| Exercise Style | 42 | 1 | Alphanumeric | `A` = American `E` = European Exercise style is always European for Asian and Cliquet. |
| Settlement Type | 43 | 1 | Alphanumeric | `A` = AM `P` = PM `S` = Asian `Q` = Cliquet |
| Percentage | 44 | 4 | Binary | Percentage when strike and price is percentage based (implied 4 decimal places). Otherwise zero. |
| Observation Day | 48 | 2 | Alphanumeric | Two digit observation day of month. Valid only for Asian and Cliquet options, otherwise spade padded. |
| Return Cap Percentage | 50 | 4 | Binary | Return cap percentage (implied 2 decimal places). Valid only for Cliquet, otherwise zero. |
| Creation Day | 54 | 2 | Alphanumeric | Two digit creation day of the month. Valid only for Cliquet, otherwise space padded. |
| Bit Fields | 56 | 1 | Bit Field | Bit 0: If set, strike/price in percentage. Bit 1-7: Reserved |
| `Total Length`=57 bytes |  |  |  |  |

### Complex FLEX Instrument Definition

A `Complex FLEX Instrument Definition` message represents a complex instrument that is available to place orders. It is sent as a sequenced message.

The `Complex FLEX Instrument Definition` message will contain two or more repeating groups of leg definitions. There is a limit of 100 leg definitions. Equity legs are allowed on FLEX orders. The limit is 99 option leg definitions and one equity leg. For complex instruments that contain over 17 legs, the complex instrument will be split across multiple messages as indicated by the Message Count.

**Table 1. Complex FLEX Instrument Definition**

| Field Name | Offset | Length | Type/(Value) | Description |
|---|---|---|---|---|
| Length | 0 | 1 | Binary | Length of this message including this field. |
| Message Type | 1 | 1 | 0x9B | `Complex FLEX 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. |
| Underlying | 12 | 8 | Printable ASCII | Complex Instrument Underlying right padded with spaces. |
| Complex Instrument Type | 20 | 4 | Alphanumeric | 4 character field; each field describes a characteristic. Character 1: Complex Option Type `X` = All legs are FLEX options `E` = One leg is an equity leg `B` = FLEX and Listed Option legs `C` = FLEX and Listed Option legs + 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 100. |
| Message Count | 25 | 1 | Binary | Number of messages required to define the complex instrument. |
| Message Number | 26 | 1 | Binary | Message number of the message count, e.g. 1 of 5. |
| Message Leg Count | 27 | 1 | Binary | The number of legs in this message. |
| The following fields repeat Message Leg Count times. The Leg Index is from 0 to Message Leg Count - 1. |  |  |  |  |
| Leg Symbol | 28 + 13 * Leg Index | 8 | Printable ASCII | FLEX Symbol, right padded with spaces. |
| Leg Ratio | 36 + 13 * Leg Index | 4 | Signed Binary | Leg ratio (positive for buy-side, negative for sell-side). |
| Leg Security Type | 40 + 13 * Leg Index | 1 | Alphanumeric | The instrument type of this leg. `X` = FLEX option `E` = Equity `O` = Listed option |
| `Total Length` = 28 + (13 * Leg Count) bytes |  |  |  |  |

### Auction Notification

`Auction Notification` messages are used to disseminate order details of a FLEX Auction. FLEX Auctions will be available for a defined period of time known as the exposure period.

**Table 1. Auction Notification**

| Field Name | Offset | Length | Type/(Value) | Description |
|---|---|---|---|---|
| Length | 0 | 1 | Binary | Length of this message including this field |
| Message Type | 1 | 1 | 0xAD | `Auction Notification` Message |
| Time Offset | 2 | 4 | Time Offset | Nanosecond offset from last unit timestamp. |
| FLEX Instrument ID | 6 | 6 | Printable ASCII | FLEX Instrument ID right padded with spaces. |
| Auction ID | 12 | 8 | Binary | Day specific identifier assigned to this auction. |
| Auction Type | 20 | 1 | Alphanumeric | `B` = AIM `F` = FLEX Auction `S` = Solicitation Auction Mechanism |
| Side | 21 | 1 | Alphanumeric | `B` = Buy `S` = Sell |
| Price | 22 | 8 | Binary Signed Long Price | Auction price. Price will be zero for Auction Type = B and F. Price will be included for Auction Type = S. |
| Quantity | 30 | 4 | Binary | Instrument quantity. |
| Customer Indicator | 34 | 1 | Alphanumeric | `N` = Non-Customer `C` = Customer FLEX Auctions ( Auction Type = F) will always have a blank Customer Indicator value. AIM auctions will have a blank Customer Indicator for simple options while AIM auctions for complex options series will include a Customer Indicator . |
| ParticipantID | 35 | 4 | Alphanumeric | Executing Broker (optional) of firm attributed to this auction. |
| Auction End Offset | 39 | 4 | Binary | Nanosecond offset from last timestamp. |
| Client ID | 43 | 4 | Alphanumeric | User defined identifier for quote attribution. |
| `Total Length`=47 bytes |  |  |  |  |

### Delta Adjusted at Close (DAC) Auction Notification

`DAC Auction Notification` messages are used to disseminate order details of a DAC FLEX Auction.

**Table 1. Delta At Close Auction Notification**

| Field Name | Offset | Length | Type/(Value) | Description |
|---|---|---|---|---|
| Length | 0 | 1 | Binary | Length of this message including this field |
| Message Type | 1 | 1 | 0xDD | `DAC Auction Notification` Message |
| Time Offset | 2 | 4 | Time Offset | Nanosecond offset from last unit timestamp. |
| FLEX Instrument ID | 6 | 6 | Printable ASCII | FLEX Instrument ID right padded with spaces. |
| Auction ID | 12 | 8 | Binary | Day specific identifier assigned to this auction. |
| Auction Type | 20 | 1 | Alphanumeric | `B` = AIM `F` = FLEX Auction `S` = Solicitation Auction Mechanism |
| Side | 21 | 1 | Alphanumeric | `B` = Buy `S` = Sell |
| Price | 22 | 8 | Binary Signed Long Price | Auction price. Price will be zero for Auction Type = B and F. Price will be included for Auction Type = S. |
| Quantity | 30 | 4 | Binary | Instrument quantity. |
| Customer Indicator | 34 | 1 | Alphanumeric | `N` = Non-Customer `C` = Customer FLEX Auctions ( Auction Type = F) will always have a blank Customer Indicator value. AIM auctions will have a blank Customer Indicator for simple options while AIM auctions for complex options series will include a Customer Indicator . |
| ParticipantID | 35 | 4 | Alphanumeric | Executing Broker (optional) of firm attributed to this auction. |
| Auction End Offset | 39 | 4 | Binary | Nanosecond offset from last timestamp. |
| Client ID | 43 | 4 | Alphanumeric | User defined identifier for quote attribution. |
| DAC Reference Price | 47 | 8 | Binary Signed Long Price | Value used as the initial reference price for a delta adjust at close auction. |
| DAC Delta Count | 55 | 1 | Binary | Number of delta values for this auction. A simple DAC auction will have 1 delta value. A complex DAC auction will have a delta value per leg, in the same leg order as the `FLEX Instrument Definition` . |
| The following fields repeat DAC Delta Count times. The Delta Index is from 0 to DAC Delta Count - 1. |  |  |  |  |
| Delta Value | 56 + 2 * Delta Index | 2 | Signed Binary | Delta value, from -1.0000 to 1.0000 (four implied decimal places). |
| `Total Length`=56 + (2* DAC Delta Count) bytes |  |  |  |  |

### Auction Cancel

`Auction Cancel` messages are used to disseminate the cancellation of an earlier `Auction Notification` message as a result of a user cancellation of the original auction, a user modification request to change the auction price or increase the original auction quantity, or to cancel any remaining auction quantity from the original `Auction Notification` following an auction termination.

A user request to modify the auction price or to increase the original auction quantity will result in a cancellation of the auction followed by a new `Auction Notification` message. `Auction Cancel` messages will not be issued for auction quantity decrements.

**Table 1. Auction Cancel**

| Field Name | Offset | Length | Type/(Value) | Description |
|---|---|---|---|---|
| Length | 0 | 1 | Binary | Length of this message including this field |
| Message Type | 1 | 1 | 0xAE | `Auction Cancel` Message |
| Time Offset | 2 | 4 | Time Offset | Nanosecond offset from last unit timestamp |
| Auction ID | 6 | 8 | Binary | Day specific identifier assigned to this auction |
| `Total Length`=14 bytes |  |  |  |  |

### Auction Trade

`Auction Trade` messages are used to disseminate executions resulting from an auction.

**Table 1. Auction Trade**

| Field Name | Offset | Length | Type/(Value) | Description |
|---|---|---|---|---|
| Length | 0 | 1 | Binary | Length of this message including this field |
| Message Type | 1 | 1 | 0xAF | `Auction Trade` Message |
| Time Offset | 2 | 4 | Time Offset | Nanosecond offset from last unit timestamp |
| Auction ID | 6 | 8 | Binary | Day specific identifier assigned to this auction |
| Execution ID | 14 | 8 | Binary | Day specific identifier assigned to this execution |
| Price | 22 | 8 | Binary Signed Long Price | Trade price. If instrument trades in percentage terms, then this represents the traded percentage with four implied decimals. |
| Quantity | 30 | 4 | Binary | Instrument quantity traded |
| `Total Length`=34 bytes |  |  |  |  |

### Trade

The `Trade` message provides information about executions of FLEX orders on the Cboe Options trading floor. `Trade` messages are necessary to calculate Cboe execution-based data.

No `Add Order` message is sent for FLEX Options orders, and thus, no order modification messages may be sent when FLEX Options are executed. Instead, a `Trade` message is sent whenever a FLEX Options order is executed in whole or in part. A complete view of all Cboe FLEX executions can be built by combining all `Auction Trade` and `Trade` messages.

**Table 1. Trade (long)**

| Field Name | Offset | Length | Type/(Value) | Description |
|---|---|---|---|---|
| Length | 0 | 1 | Binary | Length of this message including this field |
| Message Type | 1 | 1 | 0x2A | `Trade` Message (long) |
| Time Offset | 2 | 4 | Time Offset | Nanosecond offset from last unit timestamp |
| Order ID | 6 | 8 | Binary | Order ID of the executed order. |
| Side Indicator | 14 | 1 | Alphanumeric | Always "B" |
| Quantity | 15 | 4 | Binary | Instrument quantity traded |
| FLEX Instrument ID | 19 | 6 | Printable ASCII | FLEX Instrument ID right padded with spaces. |
| Price | 25 | 8 | Binary Signed Long Price | Trade price. If instrument trades in percentage terms, then this represents the traded percentage with four implied decimals. |
| Execution ID | 33 | 8 | Binary | Cboe generated day-unique execution identifier of this trade. Execution ID is also referenced in the `Trade Break` message. |
| Trade Condition | 41 | 1 | Alphanumeric | See Options Trade Condition Codes for details about new codes. |
| `Total Length`=42 bytes |  |  |  |  |

**Table 2. Trade (short)**

| Field Name | Offset | Length | Type/(Value) | Description |
|---|---|---|---|---|
| Length | 0 | 1 | Binary | Length of this message including this field |
| Message Type | 1 | 1 | 0x2B | `Trade` Message (short) |
| Time Offset | 2 | 4 | Time Offset | Nanosecond offset from last unit timestamp |
| Order ID | 6 | 8 | Binary | Order ID of the executed order. |
| Side Indicator | 14 | 1 | Alphanumeric | Always "B" |
| Quantity | 15 | 2 | Binary | Instrument quantity traded |
| FLEX Instrument ID | 17 | 6 | Printable ASCII | FLEX Instrument ID right padded with spaces. |
| Price | 23 | 2 | Binary Signed Short Price | Trade price. If instrument trades in percentage terms, then this represents the traded percentage with two implied decimals. |
| Execution ID | 25 | 8 | Binary | Cboe generated day-unique execution identifier of this trade. Execution ID is also referenced in the `Trade Break` message. |
| Trade Condition | 33 | 1 | Alphanumeric | See Options Trade Condition Codes for details about new codes. |
| `Total Length`=34 bytes |  |  |  |  |

### Delta Adjusted at Close (DAC) Trade

The `DAC Trade` message provides information about executions of Delta Adjusted at Close (DAC) FLEX orders on the Cboe Options trading floor. `DAC Trade` messages are necessary to calculate Cboe execution-based data.

No `Add Order` message is sent for FLEX Options orders, and thus, no order modification messages may be sent when FLEX Options are executed. Instead, a `DAC Trade` message is sent whenever a Delta Adjusted at Close FLEX Options order is executed in whole or in part. A complete view of all Cboe Delta Adjusted at Close FLEX executions can be built by combining all `DAC` `Trade` messages.

Each DAC auction results in both an `Auction Trade` and `DAC Trade` message. Following the close, a `Trade Break` message is disseminated followed by a new `DAC Trade` message with the final pricing for the trade.

**Table 1. Delta Adjusted at Close Trade**

| Field Name | Offset | Length | Type/(Value) | Description |
|---|---|---|---|---|
| Length | 0 | 1 | Binary | Length of this message including this field |
| Message Type | 1 | 1 | 0x36 | `DAC Trade` Message |
| Time Offset | 2 | 4 | Time Offset | Nanosecond offset from last unit timestamp |
| Order ID | 6 | 8 | Binary | Order ID of the executed order. |
| Side Indicator | 14 | 1 | Alphanumeric | Always "B" |
| Quantity | 15 | 4 | Binary | Instrument quantity traded |
| FLEX Instrument ID | 19 | 6 | Printable ASCII | FLEX Instrument ID right padded with spaces. |
| Price | 25 | 8 | Binary Signed Long Price | Trade price. |
| Execution ID | 33 | 8 | Binary | Cboe generated day-unique execution identifier of this trade. Execution ID is also referenced in the `Trade Break` message. |
| Trade Condition | 41 | 1 | Alphanumeric | See Options Trade Condition Codes for details about new codes. |
| DAC Reference Price | 42 | 8 | Binary Signed Long Price | Reference price of the DAC trade. |
| DAC Closing Price | 50 | 8 | Binary Signed Long Price | Price used as the closing price for DAC trade repricing. $0 unless repricing a DAC trade after the close. |
| DAC Delta Value | 58 | 2 | Signed Binary | The delta value applied to this DAC trade (within the range -1.0000 through 1.0000; 0 if a complex instrument) |
| `Total Length`=60 bytes |  |  |  |  |

### Trade Break

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

**Table 1. Trade Break**

| Field Name | Offset | Length | Type/(Value) | Description |
|---|---|---|---|---|
| Length | 0 | 1 | Binary | Length of this message including this field |
| Message Type | 1 | 1 | 0x2C | `Trade Break` Message |
| Time Offset | 2 | 4 | Time Offset | Nanosecond offset from last unit timestamp |
| Execution ID | 6 | 8 | Binary | Cboe execution identifier of the execution that was broken. Execution ID refers to previously sent `Auction Trade` or `Trade` message. |
| `Total Length`=14 bytes |  |  |  |  |

### Symbol Mapping

A `Symbol Mapping` message is used to map the 6 character multicast feed symbol field to an OSI symbol and Underlying. These messages are not sequenced (sequence = 0).

`Symbol Mapping` messages only refer to Listed option symbols and will appear before `Complex FLEX Instrument Definition` messages as necessary. FLEX instruments will still receive `FLEX Instrument Definition` messages.

**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 |  |  |  |  |

### Trading Status

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

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

Starting at 7:30 a.m. ET, Cboe will send a Trading Status of `Q` once 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 series 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 series where the underlying has experienced a Regulatory Halt as well as the `T`rading resumption for the same series.
- For instruments that are in a `Q`uoting period for auctions.

The Trading Status field is 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 |
| Symbol | 6 | 6 | Printable ASCII | Symbol right padded with spaces. |
| Reserved | 12 | 2 | Reserved | Reserved |
| Trading Status | 14 | 1 | Alpha | `H` = Halted `L` = Curb Trading `Q` = Quote-Only `T` = RTH Trading |
| Reserved | 15 | 1 | Reserved | Reserved |
| GTH Trading Status | 16 | 1 | Alpha | `H` = Halted `Q` = Quote-Only `T` = Trading |
| Reserved | 17 | 1 | Reserved | Reserved |
| `Total Length`=18 bytes |  |  |  |  |

### End of Session

The `End of Session` message is sent for each unit when the unit shuts down. No more 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. Customers only need to implement the following messages if gap requests will be made. The following messages will not be delivered using multicast.

### Login

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

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

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

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

### 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 log in 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.

### 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.

### Spin Image Available

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

**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

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

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

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

The `Instrument Definition Request` message is used by a user’s process to request transmission of this unit’s symbol definitions. See Spin Servers for more complete 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 definitions are available. |
| `Total Length`=6 bytes |  |  |  |  |

### Instrument Definition Response

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 definition 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

The `Instrument Definition Finished` message is sent to indicate that all symbol definition 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 |  |  |  |  |

## 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
```

### FLEX Feed Messages

```
    0xB1        Time Reference 
    0x20        Time
    0x9C        FLEX Instrument Definition    
    0x9B        Complex FLEX Instrument Definition
    0xAD        Auction Notification
    0xDD        DAC Auction Notification
    0xAE        Auction Cancel
    0xAF        Auction Trade
    0x2A        Trade (long)
    0x2B        Trade (short)
    0x36        DAC Trade
    0x2C        Trade Break
    0x2E        Symbol Mapping
    0x31        Trading Status 
    0x2D        End of Session     
```

## Example Messages

Each of the following message types must be wrapped by a sequenced or unsequenced unit header as described in 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

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

### 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 | 108 | 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

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

### Spin Response Message

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

### 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 | 3,000 Instruments |
| Status | 41 | Accepted |

### Instrument Definition Finished

**Table 1. Instrument Definition Finished**

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

### Time Reference

| 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 | 2021-02-23 February 23, 2021 |

### Time Message

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

### FLEX Instrument Definition Message

| Length | 39 | 57 bytes |
|---|---|---|
| Type | 9C | Flex Instrument Definition |
| Time Offset | 18 D2 06 00 | 447,000 ns since last Time Message |
| Feed Symbol | 46 30 30 30 31 32 | F00012 |
| OSI Root | 31 41 41 50 4C 20 | 1AAPL |
| Year | 31 38 | 18 |
| Month | 31 31 | 11 |
| Day | 32 32 | 22 |
| Call/Put | 43 | C = Call |
| Dollar Strike | 00 00 32 30 37 | 00207 = $207 |
| Decimal Strike | 37 35 00 | 750 = $0.750 |
| Symbol Condition | 4E | N = Normal |
| Underlying | 41 41 50 4C 20 20 20 20 | AAPL |
| Exercise Style | 41 | American |
| Settlement Type | 50 | PM |
| Percentage | 00 00 00 00 | Not percentage pricing |
| Observation Day | 20 20 | No Observation Day |
| Return Cap | 00 00 00 00 | 250 = 2.5% Return cap |
| Creation Day | 20 20 | No Creation Day |
| Bit Fields | 00 | Not percentage pricing |

### Complex FLEX Instrument Definition Message

| Length | 43 | 67 bytes |
|---|---|---|
| Type | 9B | FLEX Instrument Definition |
| Time Offset | 18 D2 06 00 | 447,000 ns since last Time Message |
| CID | 43 30 30 30 31 32 | C00012 |
| Underlying | 5A 56 5A 5A 54 20 20 20 | ZVZZT |
| Complex Instrument Type | 58 20 20 20 | X = All Legs are Flex Options |
| Leg Count | 03 | 3 legs |
| Message Count | 01 | Only one message needed to define instrument |
| Message Number | 01 | Message 1 of 1 |
| Message Leg Count | 03 | 3 legs |
| Leg Symbol | 30 30 30 30 30 31 20 20 | 000001 |
| Leg Ratio | FF FF FF FF | -1 = Sell 1 |
| Leg Security Type | 58 | FLEX Option Leg |
| Leg Symbol | 30 30 30 30 30 32 20 20 | 000002 |
| Leg Ratio | FF FF FF FF | -1 = Sell 1 |
| Leg Security Type | 58 | FLEX Option Leg |
| Leg Symbol | 30 30 30 30 30 33 20 20 | 000003 |
| Leg Ratio | 02 00 00 00 | 2 = Buy 2 |
| Leg Security Type | 58 | FLEX Option Leg |

### Auction Notification Message

| Length | 2F | 47 bytes |
|---|---|---|
| Type | AD | Auction Notification |
| Time Offset | 18 D2 06 00 | 447,000 ns since last Time Message |
| CID | 30 30 6d 45 56 4f | 00mEVO |
| Auction ID | 05 40 5B 77 8F 56 1D 0B | 631WC4000005 |
| Auction Type | 53 | S = SAM |
| Side | 42 | B = Buy Side |
| Price | E8 A3 0F 00 00 00 00 00 | $102.50 |
| Quantity | 64 00 00 00 | 100 |
| Customer | 43 | C = Customer |
| Indicator | ParticipantID | 45 46 49 44 |
| Auct. End Offset | 38 73 0E 00 | 947,000 ns since last Time Message |
| ClientID | 41 42 43 44 | ABCD |

### DAC Auction Notification Message

**Table 1. DAC Auction Notification Message**

| Length | 3A | 58 bytes |
|---|---|---|
| Type | DD | DAC Auction Notification |
| Time Offset | 18 D2 06 00 | 447,000 ns since last Time Message |
| FLEX Inst ID | 7A 30 33 32 6B 7A | z032kz |
| Auction ID | 05 40 5B 77 8F 56 1D 0B | 631WC4000005 |
| Auction Type | 42 | B = AIM |
| Side | 53 | S = Sell Side |
| Price | 00 00 00 00 00 00 00 00 | $0.00 (not disclosed) |
| Quantity | FA 00 00 00 | 250 contracts |
| Customer Indicator | 4E | N = Non-Customer |
| Participant ID | 45 46 49 44 | EFID |
| Auct. End Offset | 38 73 0E 00 | 947,000 ns since last Time Message |
| Client ID | 43 4F 4C 45 | COLE |
| DAC Reference Price | FE 82 06 00 00 00 00 00 | $42.6750 |
| DAC Delta Count | 01 | 1 |
| DAC Delta Value | 4C 1D | 0.7500 |

### Auction Cancel Message

**Table 1. Auction Cancel Message**

| Length | 0E | 14 bytes |
|---|---|---|
| Type | AE | Auction Cancel |
| Time Offset | 18 D2 06 00 | 447,000 ns since last Time Message |
| Auction ID | 05 40 5B 77 8F 56 1D 0B | 631WC4000005 |

### Auction Trade Message

**Table 1. Auction Trade Message**

| Length | 22 | 34 bytes |
|---|---|---|
| Type | AF | Auction Trade |
| Time Offset | 18 D2 06 00 | 447,000 ns since last Time Message |
| Auction ID | 05 40 5B 77 8F 56 1D 0B | 631WC4000005 |
| Execution ID | 34 2B 46 E0 BB 00 00 00 | 0AAP09VEC |
| Price | 0A 28 00 00 00 00 00 00 | 1.0250% |
| Quantity | 64 00 00 00 | 100 |

### Trade (long) Message

| Length | 2A | 42 bytes |
|---|---|---|
| Type | 2A | Trade (long) |
| Time Offset | 08 5C 44 25 | 625,237,000 ns since Last Time Message |
| Order Id | 05 40 5B 77 8F 56 1D 0B |  |
| Side | 42 | Buy |
| Quantity | F8 24 01 00 | 75,000 contracts |
| Symbol | 33 34 35 33 32 31 | 345321 |
| Price | E8 A3 0F 00 00 00 00 00 | $102.50 |
| Execution Id | 34 2B 46 E0 BB 00 00 00 | 0AAP09VEC |
| Trade Condition | 53 | S = ISO |

### Trade (short) Message

**Table 1. Trade (short) Message**

| Length | 22 | 33 bytes |
|---|---|---|
| Type | 2B | Trade (short) |
| Time Offset | 08 5C 44 25 | 625,237,000 ns since Last Time Message |
| Order Id | 05 40 5B 77 8F 56 1D 0B |  |
| Side | 42 | Buy |
| Quantity | 64 00 | 100 contracts |
| Symbol | 33 34 35 33 32 31 | 345321 |
| Price | 0A 28 | $102.50 |
| Execution Id | 34 2B 46 E0 BB 00 00 00 | 0AAP09VEC |
| Trade Condition | 53 | S = ISO |

### DAC Trade Message

**Table 1. DAC Trade Message**

| Length | 3C | 60 bytes |
|---|---|---|
| Type | 36 | DAC Trade |
| Time Offset | 08 5C 44 25 | 625,237,000 ns since Last Time Message |
| Order Id | 05 40 5B 77 8F 56 1D 0B |  |
| Side | 42 | B = Buy Side |
| Quantity | FA 00 00 00 | 250 contracts |
| FLEX Inst ID | 7A 30 31 7A 47 46 | z01zGF |
| Price | AC AD 0F 00 00 00 00 00 | $102.7500 |
| Execution Id | 34 2B 46 E0 BB 00 00 00 | 0AAP09VEC |
| Trade Condition | 53 | S = ISO |
| DAC Reference Price | FE 82 06 00 00 00 00 00 | $42.6750 |
| DAC Closing Price | 74 99 06 00 00 00 00 00 | $43.2500 |
| DAC Delta Value | 4C 1D | 0.7500 |

### Trade Break Message

**Table 1. Trade Break Message**

| Length | 0E | 14 bytes |
|---|---|---|
| Type | 2C | Trade Break |
| Time Offset | 18 D2 06 00 | 447,000 ns since last Time Message |
| Execution Id | 34 2B 46 E0 BB 00 00 00 | 0AAP09VEC |

### Symbol Mapping Message

**Table 1. Symbol Mapping Message Example**

| 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 30 39 32 30 43 30 30 31 35 30 30 30 30 | MSFT 190920C00150000 |
| Symbol Condition | 4E | 'N' – Normal |
| 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 |
| Symbol | 39 39 38 38 37 37 | 998877 |
| Reserved | 20 20 | Reserved |
| Trading Status | 54 | T = Trading |
| Reserved | 20 | Reserved |
| Global Trading | 48 | H = Halted |
| Hours Status | Reserved | 20 |
| Reserved | 20 | Reserved |

### End of Session

| 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

Product Environment Configuration contains Limitations/Configurations, C1 Unit/Product Distribution, Cboe Options FLEX Multicast Routing Parameters, and Cboe Options FLEX Multicast Addresses.

#### Limitations/Configurations

The following table defines Cboe 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. Members 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 | 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. |

#### C1 Unit/Product Distribution

| Unit | C1 Symbol Range | C1 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 |  |
| 31 | CBTX, CBTXW, DJX, DJXW, MBTX, MBTXW, MGTN, MGTNW, MRUT, NDX, OEX, RLG, RLV, RUI, RUT, RUTW, SIXB, SIXC, SIXE, SIXI, SIXR, SIXRE, SIXT, SIXU, SIXV, SIXY, SPEQX, SPESG, UKXM, XEO, XND |  |
| 32 | NANOS, VIX, VIXW, XSP, XSPBW |  |
| 33 | SPX |  |
| 34 | SPXW |  |
| 35 | 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 Options FLEX Multicast Routing Parameters

| Data center | Rendezvous Point |
|---|---|
| NY5 Primary Data Center A feed | 74.115.128.183 |
| NY5 Primary Data Center B feed | 74.115.128.184 |
| CH4 Secondary Data Center E feed | 174.136.181.249 |

#### Cboe Options FLEX Multicast Addresses

The following tables describe the multicast address distribution across production multicast Cboe FLEX feeds.

| Primary Datacenter | WAN-Shaped [CAF] 170.137.114.80 /28 | WAN-Shaped [CBF] 170.137.115.80 /28 |  |  |  |
|---|---|---|---|---|---|
| Unit | IP Port | Real-time MC | Gap Resp. MC | Real-time MC | Gap Resp. MC |
| 1 | 30501 | 224.0.74.92 | 224.0.74.93 | 233.182.199.220 | 233.182.199.221 |
| 2 | 30502 |  |  |  |  |
| 3 | 30503 |  |  |  |  |
| 4 | 30504 |  |  |  |  |
| 5 | 30505 |  |  |  |  |
| 6 | 30506 |  |  |  |  |
| 7 | 30507 |  |  |  |  |
| 8 | 30508 |  |  |  |  |
| 9 | 30509 |  |  |  |  |
| 10 | 30510 |  |  |  |  |
| 11 | 30511 |  |  |  |  |
| 12 | 30512 |  |  |  |  |
| 13 | 30513 |  |  |  |  |
| 14 | 30514 |  |  |  |  |
| 15 | 30515 |  |  |  |  |
| 16 | 30516 |  |  |  |  |
| 17 | 30517 |  |  |  |  |
| 18 | 30518 |  |  |  |  |
| 19 | 30519 |  |  |  |  |
| 20 | 30520 |  |  |  |  |
| 21 | 30521 |  |  |  |  |
| 22 | 30522 |  |  |  |  |
| 23 | 30523 |  |  |  |  |
| 24 | 30524 |  |  |  |  |
| 25 | 30525 |  |  |  |  |
| 26 | 30526 |  |  |  |  |
| 27 | 30527 |  |  |  |  |
| 28 | 30528 |  |  |  |  |
| 29 | 30529 |  |  |  |  |
| 30 | 30530 |  |  |  |  |
| 31 | 30531 |  |  |  |  |
| 32 | 30532 |  |  |  |  |
| 33 | 30533 |  |  |  |  |
| 34 | 30534 |  |  |  |  |
| 35 | 30535 |  |  |  |  |

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 | WAN-Shaped [CEF] 170.137.124.224/28 |  |  |
|---|---|---|---|
| Unit | IP Port | Real-time MC | Gap Resp. MC |
| 1 | 31501 | 233.19.3.252 | 233.19.3.253 |
| 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 |  |  |
| 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 |  |  |
| 34 | 31534 |  |  |
| 35 | 31535 |  |  |

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

Certification Environment Configuration contains C1 Unit/Product Distribution, Cboe Options FLEX Certification Multicast Routing Parameters, and Cboe Options FLEX Certification Multicast Addresses.

#### C1 Unit/Product Distribution

| Unit | C1 Symbol Range | C1 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 |  |
| 31 | CBTX, CBTXW, DJX, DJXW, MBTX, MBTXW, MGTN, MGTNW, MRUT, NDX, OEX, RLG, RLV, RUI, RUT, RUTW, SIXB, SIXC, SIXE, SIXI, SIXR, SIXRE, SIXT, SIXU, SIXV, SIXY, SPEQX, SPESG, UKXM, XEO, XND |  |
| 32 | NANOS, VIX, VIXW, XSP, XSPBW |  |
| 33 | SPX |  |
| 34 | SPXW |  |
| 35 | 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 Options FLEX Certification Multicast Routing Parameters

| Data center | Rendezvous Point |
|---|---|
| Primary Data Center | 74.115.128.131 |

#### Cboe Options FLEX Certification Multicast Addresses

The following tables describe the multicast address distribution across production multicast Cboe FLEX feeds.

| Primary Datacenter | WAN-Shaped 170.137.126.16/28 |  |  |
|---|---|---|---|
| Unit | IP Port | Real-time MC | Gap Resp. MC |
| 1 | 32501 | 233.103.126.18 | 233.103.126.19 |
| 2 | 32502 |  |  |
| 3 | 32503 |  |  |
| 4 | 32504 |  |  |
| 5 | 32505 |  |  |
| 6 | 32506 |  |  |
| 7 | 32507 |  |  |
| 8 | 32508 |  |  |
| 9 | 32509 |  |  |
| 10 | 32510 |  |  |
| 11 | 32511 |  |  |
| 12 | 32512 |  |  |
| 13 | 32513 |  |  |
| 14 | 32514 |  |  |
| 15 | 32515 |  |  |
| 16 | 32516 |  |  |
| 17 | 32517 |  |  |
| 18 | 32518 |  |  |
| 19 | 32519 |  |  |
| 20 | 32520 |  |  |
| 21 | 32521 |  |  |
| 22 | 32522 |  |  |
| 23 | 32523 |  |  |
| 24 | 32524 |  |  |
| 25 | 32525 |  |  |
| 26 | 32526 |  |  |
| 27 | 32527 |  |  |
| 28 | 32528 |  |  |
| 29 | 32529 |  |  |
| 30 | 32530 |  |  |
| 31 | 32531 |  |  |
| 32 | 32532 |  |  |
| 33 | 32533 |  |  |
| 34 | 32534 |  |  |
| 35 | 32535 |  |  |

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 |
|---|---|
| a | Single Leg Auction Non ISO Cboe auction types include AIM, SAM |
| b | Single Leg Auction ISO Cboe auction types are 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 |
| 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 |
| K* | Cabinet Order |
| O* | Opening Trade |
| S | ISO |

*The Trade Condition value of `O=Opening Trade` and `K=Cabinet 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 the FLEX feed 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 100 Mbps of bandwidth. Cboe will use 90% of these respective bandwidths for the FLEX feed to allow customers to use the same physical connection for FIX order entry if desired.

## References

For more information on Cboe Symbology, please refer to the 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 | 11/16/18 | Initial draft in support of FLEX Options on Cboe Options Exchange. |
| 1.0.1 | 02/14/19 | Added certification environment IP port and unit distribution information. |
| 1.0.2 | 04/02/19 | Added C1 Certification data center rendezvous point IP address. Corrected C1 Symbol Range. |
| 1.0.3 | 04/17/19 | Added Production IP addresses for C1 Options. |
| 1.0.4 | 05/08/19 | Removed Trading Status field value `S` = Exchange Specific Suspension from `Trading Status` message, as this was added in error. Corrected C1 Production WAN-Shaped [CAF] and [CBF] source network IP addresses. |
| 1.0.5 | 06/12/19 | Added additional proprietary products to matching unit 31 in C1. Corrected certification and production C1 symbol range for units 9 and 20. Corrected example for `FLEX Instrument Definition` message. |
| 1.0.6 | 06/21/19 | Added `Trade(short)` message type and example message. |
| 1.0.7 | 09/06/19 | Clarified Price field in `Auction Notification` message that the field value will be zero when Auction Type = B or F. |
| 1.0.8 | 09/25/19 | Customer Indicator will be blank when Auction Type = F. |
| 1.0.9 | 10/11/19 | Clarified description of `Time` message. Corrected `Auction Notification` Price field description. |
| 1.1.0 | 05/26/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. Added `DAC Auction Notification` and `DAC Trade` messages ( effective 07/20/20 effective 09/14/20 TBD ). Added Options Trade Condition Codes section. |
| 1.1.1 | 07/08/20 | Updated effective date for FLEX DAC to 09/14/20. |
| 1.1.2 | 09/08/20 | Updated effective date for FLEX DAC to TBD. |
| 1.1.3 | 11/5/20 | Added SPESG to Unit Distribution Exception entries. Updated effective date for FLEX DAC to 12/2/20. |
| 1.1.4 | 02/01/21 | Added MRUT to Unit/Symbol Distribution tables for C1 unit 31 (effective 03/01/21). Added new updated Unit/Symbol Distribution tables with harmonized symbol ranges (effective 3/22/21). |
| 1.1.5 | 03/25/21 | Updated the Unit Symbols Distribution Exceptions entries (effective 3/22/21). Added Binary Date field type to Section 2.2 - Data Types (effective 10/10/21 TBD 09/27/21 Q3 2021 ). Added new `Time Reference` message (effective 10/10/21 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.6 | 05/13/21 | Clarified that when the system fails to receive two consecutive heartbeat messages within the specified interval the client connection is terminated. Updated effective date for Curb session 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.7 | 06/15/21 | Updated effective date for extended GTH session to 11/21/21. |
| 1.1.8 | 08/25/21 | Updated Curb session effective date to 02/07/22 TBD. |
| 1.1.9 | 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. |
| 1.1.10 | 10/01/21 | Updated effective date for new `Time Reference` message, EpochTime field to `Time` message, 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' (effective 10/10/21). Updated Cboe Symbology Reference link. |
| 1.1.11 | 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. |
| 1.1.12 | 02/02/22 | Added NANOS to the C1 unit 32 Unit/Product Distribution tables (effective 03/14/22). |
| 1.1.13 | 11/07/22 | Moved XSP to the C1 unit 32 Unit/Production Distribution table (effective 12/04/22). |
| 1.1.14 | 03/30/23 | Removed past effective dates. |
| 1.1.15 | 01/10/24 | Added ‘E’ value to Complex Instrument Type and Leg Security Type fields in the `Complex FLEX Instrument Definition` message (effective 04/29/24 03/11/24). |
| 1.1.16 | 01/29/24 | Added MXACW, MXUSA, and MXWLD to unit 31 Unit/Product Distribution tables (effective 03/18/24). |
| 1.1.17 | 03/08/24 | Updated effective date for ‘E’ value addition to Complex Instrument Type and Leg Security Type fields in the `Complex FLEX Instrument Definition` message to 04/29/24. |
| 1.1.18 | 07/22/24 | Effective 08/26/24, GTH will be extended until 9:25 a.m. ET. |
| 1.1.19 | 09/25/24 | Added NDX and XND to C1 unit 31 symbol range. |
| 1.1.20 | 11/22/24 | Added CBTX, CBTXW, MBTX, and MBTXW to unit 31 Unit/Product Distribution tables (effective 12/02/24). |
| 1.1.21 | 12/13/24 | Added new Unit/Product Distribution for Units 1-30 (effective 03/31/25). |
| 1.1.22 | 01/15/25 | Updated with Cboe Titanium branding. |
| 1.1.23 | 03/25/25 | Added SPEQX to C1 unit 31 unit/product distribution (effective 04/14/25). |
| 1.1.24 | 04/24/25 | Added new message: Symbol Mapping (effective 06/23/25). Added Complex Instrument Type = B and C, and Leg Security Type = O to Complex FLEX Instrument Definition (effective 06/23/25). |
| 1.1.25 | 07/08/26 | Added Time Offset data type. Effective 09/08/25, Time Offset fields will be populated to nanosecond precision. |
| 1.1.26 | 10/20/25 | Added MGTN and MGTNW to unit 31 in C1 Unit/Product Distribution and excluded MGTN and MGTNW from unit 14 (effective 12/08/25 TBD 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.27 | 11/06/25 | Updated MGTN and MGTNW effective date to TBD. |
| 1.1.28 | 11/18/25 | Updated Price to indicate that Trade price. If instrument trades in percentage terms, then this represents the traded percentage with two implied decimals in Auction Trade . Updated Price hexadecimal bytes to 0A 28 00 00 00 00 00 00 in Auction Trade Example messages. Updated Trading Status value to 0x31 in FLEX Feed messages . Updated Price to $0.00 (not disclosed) for DAC Auction Notification messages . Updated Price description to clarify that if instrument trades in percentage terms, then this represents the traded percentage with two implied decimals in Trade (Short) messages. Updated MGTN and MGTNW effective date to 12/08/25. |
| 1.1.29 | 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.30 | 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.31 | 04/15/26 | Updated Trading Status 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.32 | 05/14/26 | Updated XSPBW effective date to 06/15/26. Updated C1 Unit/Product Distribution to include DJXW (effective 05/18/26). |
| 1.1.33 | 06/12/26 | Updated planned expansion of C1 trading hours for select equity options to 08/17/26. |
| 1.1.34 | 07/27/26 | Removed VIX and VIXW exclusion from unit 23 and added VIX and VIXW exclusion to unit 24 C1 Unit/Product Distribution tables. |
| 1.1.35 | 08/10/26 | Updated planned expansion of C1 trading hours for select equity options to TBD. |