# Cboe Titanium Cboe One Equities Feed Specification

Version 1.4.15 · June 30, 2026

## Introduction

The Cboe Titanium Cboe One Equities Feed delivers consolidated quote, trade, and Aggregated Depth At Price (ADAP) information for Cboe BYX Equities Exchange (BYX), BZX Equities Exchange (BZX), EDGA Equities Exchange (EDGA), and EDGX Equities Exchange (EDGX) (Cboe One US) via TCP/IP and UDP using the binary Cboe One protocol. The feed consists of `Clear Quote`, `Symbol Summary`, `Best Quote Update`, `Market Status`,`ADAP`, `RPI`, `Trade`, `Trade Break`, `Trading Status`, `Opening/Closing Price`, and `End of Day Summary` messages. Please note that BYX, BZX, EDGA, and EDGX will change the timestamp precision from milliseconds to nanoseconds.

The TCP/IP delivered feed can be used as a standalone product or to augment the UDP feed for recovery and start up purposes. The TCP/IP feed is available from the Cboe One Server and sends a replay of missed trades and refreshes the current state of the Cboe books followed by real-time updates to the books after a connection is established.

The UDP delivered feed is sourced from the Cboe One Feed Server (FS). Users may also connect to the Cboe One Gap Request Proxy for retransmission of missed packets on the UDP feed by the Cboe One Gap Server (GS).

While the TCP/IP and UDP delivered feeds offer equivalent real-time updates with matching sequence numbers, the consumer should assume message framing will be different between the transmission protocols.

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

The Cboe One Feed is available with different combinations of ADAP levels and update rates to meet the needs of our Cboe One users.

**Table 1. Current Cboe One Feed Descriptions**

| Name | Best Quote | ADAP Levels | Bandwidth |
|---|---|---|---|
| Cboe One US Summary | Yes | 0 | 100Mb |
| Cboe One US Premium | Yes | Up to 12 | 400 Mb/sec |

### Cboe One Server (TCP)

The user connects to an assigned host and port using a TCP/IP socket.

Upon connection, the user must send a `Cboe One Login` message. The `Cboe One Login` message Next Sequence field allows Cboe One users to specify the next sequence number they expect to receive. If a Cboe One user logs in after trading begins or after connection loss, the Next Sequence field can be used to tell the server to replay any `Trade` and `Trade Break` messages that have occurred since the last received `Trade` or `Trade Break` message.

If the Next Sequence field is set to `1` (one), then all `Trade` and `Trade Break` messages from the beginning of the day will be replayed after the server sends a successful `Login Response` message. Once the server has replayed any `Trade` and `Trade Break` messages, it will deliver relevant `Market Status` message information, `RPI` message information, `Trading Status` messages, and a spin of `Symbol Summary`, `Opening/Close Price` and `ADAP` messages from its cache for each active symbol. Then the server will send the user a `Replay Complete` message followed by the live stream of `Symbol Summary`, `Best Quote Update`, `ADAP`, `RPI`, `Trade`, `Trade Break`, `Market Status`, `Trading Status`, `Opening/Closing Price`, and `End of Day Summary` messages.

If the Next Sequence field is set to `0` (zero), then no `Trade` or `Trade Break` messages will be replayed after the server sends a successful `Login Response` message. However, Cboe One users may still receive a spin of `Market Status`, `RPI`, `Trading Status`, `Symbol Summary`, `Opening/Close Price`and `ADAP` messages followed by a `Replay Complete` message before receiving the live stream of `Symbol Summary`, `Best Quote Update`, `ADAP`, `RPI`, `Trade`, `Trade Break`, `Market Status`, `Trading Status`, `Opening/Closing Price` , and `End of Day Summary` messages.

If a Cboe One user’s process cannot keep up with the Cboe One feed’s rate of transmission, the connection will be closed by the server. The user should then reconnect and login with the appropriate Next Sequence number to receive any missed trades, and spin of the latest image for all symbols.

### Cboe One Feed Server (UDP)

The UDP delivered Cboe One Feed is sourced by the Cboe One Feed Server (FS). The FS generates the multicast events for the Cboe One 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.

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

### Cboe One Gap Request Proxy and Message Retransmission via Gap Server

Requesting delivery of missed data is achieved by connecting to a Cboe One Gap Request Proxy (Cboe One GRP). Cboe One Users who do not wish to request missed messages do not need to connect to a GRP 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, log in, and request gap ranges as necessary. All gap requests will be responded to with a `Gap Response` message. A `Gap Response` message Status code of `Accepted` signals that the replayed messages will be delivered via the appropriate gap response multicast address. Any other `Gap Response` message Status code will indicate the reason that the request cannot be serviced.

Gap requests are limited in message count, frequency, and age by the GRP. Gap requests will only be serviced if they are within a defined sequence range of the current multicast sequence number. Larger sequence number gaps should be recovered via the Cboe One Server over TCP. Cboe One users will receive a total daily allowance of gap requested messages. In addition, each user is given renewable one second and one minute gap request limits.

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

If overlapping gap requests are received within a short period of time, the gap server will only send the union of the sequence ranges across grouped gap requests. Cboe One users will receive gap responses for their requested 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.

### Cboe One Disaster Recovery

Users of Cboe One that 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 US feed that is disseminated from the DR site takes the incoming SIP trade feeds and connects to Cboe PITCH services sourced in the DR site for BZX, BYX, EDGX, and EDGA. The same data sources are used to distribute Cboe One from both the Cboe Primary site and Cboe DR site, so Cboe One customers can fail-over to or utilize the Cboe One feed out of the DR site at any time. However, message content, packet framing, and sequence numbers are not guaranteed to be the same between the Primary and DR sites due to message coalescing differences.

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

1. Hardware failure in the primary Cboe One 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 equities platforms to their respective DR site. The Cboe One US feed in the Primary site currently only connects to market data for Cboe One US within the Primary site. If one of the exchanges fails over to the DR site, then the Cboe One 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 feed out of the DR site to regain full coverage.
3. Loss of any of the Cboe One input feeds. Similarly to scenario #2, if Cboe experiences a market data (PITCH/NITCH) dissemination issue for any Cboe One US exchange at the Primary site, but PITCH/NITCH market data is valid for the problem exchange at the DR site, then Cboe One customers have the option to switch over to the DR Cboe One feed to regain full coverage. The same situation applies if Cboe experiences an outage at the Primary site with respect to receipt of SIP feed data. If those feeds are still being received at the DR site, then customers have the option to switch over to the DR Cboe One feed to regain full coverage.

## Protocol

Cboe users may use the Cboe One protocol over TCP/IP and/or multicast to receive the Cboe One feed direct from Cboe.

Cboe One 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 protocol are delivered using `Sequenced Unit Header` message header which handles sequencing and delivery integrity. All messages delivered via TCP/IP or multicast 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 Cboe One Server or 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 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 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 Cboe One 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).
- Binary 12.6 fields are unsigned Little Endian encoded 8 byte binary fields with 6 implied decimal places (denominator = 1,000,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.

### Message Framing

Depth of book update 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 feed and site. The content of the multicast across feeds 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 messages delivered via multicast or TCP/IP.

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 unit field.

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

**Table 1. Sequenced Unit Header**

| Field | Offset | Length | Value/Type | Description |
|---|---|---|---|---|
| Hdr Length | 0 | 2 | Binary | Length of entire block of messages. Includes this header and `Hdr Count` messages to follow. |
| Hdr Count | 2 | 1 | Binary | Number of messages to follow this header. |
| Hdr Unit | 3 | 1 | Binary | Unit that applies to messages included in this header (0 for all Cboe One messages). |
| 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 Cboe One Server, GRP and all multicast addresses if no data has been delivered within 1 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.

Heartbeats on the real-time multicast addresses during trading hours will have a Hdr Sequence value equal to the sequence of the next sequenced message to be sent. Heartbeats on gap multicast addresses will always have the Hdr Sequence field set to `0`. All heartbeat messages sent to and from the Cboe One Server and GRP 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 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 Cboe One Server and GRP on live connections no less than every 5 seconds. Failure to receive two consecutive heartbeat messages will result in the termination of the user connection.

## Cboe One Server Session Messages (TCP)

The following messages are used for initializing a TCP/IP connection to the Cboe One Server. Cboe One users only need to implement the following messages if a TCP/IP connection to the Cboe One Server is desired. The following messages will not be delivered using multicast.

See the Cboe One Update Messages section of this document for a description of book and market related messages that are available from the Cboe One Server.

### Cboe One Login Message Fields

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

**Table 1. Cboe One Login**

| Field | Offset | Length | Value/Type | Description |
|---|---|---|---|---|
| Length | 0 | 1 | Binary | Length of this message including this field. |
| Message Type | 1 | 1 | 0xA0 | `Cboe One 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 |
| Next Sequence | 22 | 4 | Binary | Sequence number of the next sequenced message expected by the user. |
| Total Length = 26 bytes |  |  |  |  |

### Login Response Message Fields

The `Login Response` message is sent by the 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.

**Table 1. Login Response Message Fields**

| 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 |  |  |  |
| ‘Q’ | Next Sequence is ahead of sequence |  |  |  |

### Replay Complete Message Fields

The `Replay Complete` message is sent to indicate that messages related to refreshing the state of the Cboe books have been delivered. After receipt of the `Replay Complete` message, message updates will be sent on the session as needed until the user disconnects.

`Market Status`, `RPI`, `Trading Status`, `Symbol Summary`,`Opening/Close Price`, `End of Day Summary`, and `ADAP` messages will be sent as needed to replay the current state of the Cboe books.

During the replay phase of the connection all messages except for `Trade` and `Trade Break` messages will be un-sequenced.

**Table 1. Replay Complete**

| Field | Offset | Length | Value/Type | Description |
|---|---|---|---|---|
| Length | 0 | 1 | Binary | Length of this message including this field. |
| Message Type | 1 | 1 | 0xA1 | `Replay Complete` message |
| Sequence | 2 | 4 | Binary | Sequence number that reflects that last update on the feed. |
| Total Length = 6 bytes |  |  |  |  |

## Cboe One Gap Request Proxy Session Messages (TCP)

The following messages are used for initializing a TCP/IP connection to the Gap Request Proxy (GRP) and to request message retransmissions. Cboe One users only need to implement the following messages if gap requests will be made. The following 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 is identical to the Multicast Pitch `Gap Request` message. The Unit field should be set to `0` since the Cboe One 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 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.

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

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

## Cboe One Update Messages (UDP & TCP)

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

### Clear Quote Message Fields

The `Clear Quote` message instructs feed recipients to clear all quotes and Summary and/or ADAP information for the specified symbol on the specified market(s). This message does not affect the executed volume of the symbol.

**Table 1. Clear Quote**

| Field | Offset | Length | Value/Type | Description |
|---|---|---|---|---|
| Length | 0 | 1 | Binary | Length of this message including this field. |
| Message Type | 1 | 1 | 0xA2 | `Clear Quote` 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 server’s cache. Encoded as the number of nanoseconds since midnight (effective 11/02/26, since epoch) . |
| Symbol | 10 | 8 | Alphanumeric | Symbol right padded with spaces. |
| Market Center | 18 | 1 | Alphanumeric | `*` = All Cboe Markets for this feed `Y` = BYX `Z` = BZX `A` = EDGA `X` = EDGX |
| Total Length = 19 bytes |  |  |  |  |

### Fractional Symbol Summary Message Fields

The `Fractional Symbol Summary` message delivers the Cboe consolidated best bid/offer and total executed volume across all applicable Cboe One US Exchanges.

**Table 1. Fractional Symbol Summary**

| Field | Offset | Length | Value/Type | Description |
|---|---|---|---|---|
| Length | 0 | 1 | Binary | Length of this message including this field. |
| Message Type | 1 | 1 | 0xE7 | `Fractional 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 server’s cache. Encoded as the number of nanoseconds since midnight (effective 11/02/26, since epoch) . |
| Symbol | 10 | 8 | Alphanumeric | Symbol right padded with spaces. |
| Cboe CumulativeExecuted 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. |
| National Cumulative Volume | 58 | 8 | Binary 12.6 | Cumulative number of shares traded today as reported to the CTA and UTP SIPs. |
| Flags | 66 | 1 | Bit Field | `Bit 0` : National Volume Status `0` : National volume data is complete `1` : National volume data may not be complete due to an unrecoverable gap on the incoming feed `Bit 1-7` : 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 server’s cache. Encoded as the number of nanoseconds since midnight (effective 11/02/26, since epoch) . |
| 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.

The `Incomplete` market status is used to indicate that 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/ADAP 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/ADAP 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 (effective 11/02/26, since epoch) . |
| Market Center | 10 | 1 | Alphanumeric | `Y` = BYX `Z` = BZX `A` = EDGA `X` = EDGX |
| Market Status | 11 | 1 | Alphanumeric | `N` = Normal `E` = Excluded from Symbol Summary and ADAP updates `I` = Incomplete |
| Session Indicator | 12 | 1 | Alphanumeric | `R` = Regular trading session `P` = Pre- or post-market session |
| Total Length = 13 bytes |  |  |  |  |

### ADAP Message Fields

Each `ADAP` message delivers one or more updates for a Symbol’s ADAP book. Each `ADAP` message contains one or more `ADAP Block` messages . A receiving process should interpret each `ADAP Block` message as a replacement for any previously delivered `ADAP Block` messages at that price level.

A quantity of `0` indicates that the price level is either no longer available or the price level is not within the number ADAP levels maintained by the feed. In either case a receiving process should delete a price level with a `0` quantity from its cache.

**Table 1. ADAP**

| Field | Offset | Length | Value/Type | Description |
|---|---|---|---|---|
| Length | 0 | 1 | Binary | Length of this message including this field |
| Message Type | 1 | 1 | 0xA7 | `ADAP` 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 server’s cache. Encoded as the number of nanoseconds since midnight (effective 11/02/26, since epoch) . |
| Symbol | 10 | 8 | Alphanumeric | Symbol right padded with spaces. |
| Flags | 18 | 1 | Bit Field | `Bit 0` : Clear ADAP `0` : Keep any ADAP information for this symbol. `1` : Delete any ADAP information for this symbol before applying ADAP Block messages `Bit 1` : ADAP Complete `0` : The ADAP view for this symbol is complete. `1` : More ADAP updates for this symbol to follow in another ADAP message. `Bit 2` : Short/Long Block(s) `0` : Short Update ADAP Block message(s) to follow `1` : Long Update ADAP Block message(s) to follow `Bit 3-7` : Reserved |
| Reserved | 19 | 1 |  | Reserved |
| ADAP Blocks | 20 | 1 | Binary | Number of `ADAP Block` message to follow |
| ADAP Block Size | 21 | 1 | Binary | Size of each `ADAP Block` message |
| Header Length = 22 bytes |  |  |  |  |

**Table 2. Short Update ADAP Block**

| Field | Offset | Length | Value/Type | Description |
|---|---|---|---|---|
| Market Center | 0 | 1 | Alphanumeric | `Y` = BYX `Z` = BZX `A` = EDGA `X` = EDGX |
| Side | 1 | 1 | Alphanumeric | `B` = Buy Side `S` = Sell Side |
| Price | 2 | 4 | Binary 4.4 Price | Price level to add/update for Market Center’s ADAP book. |
| Quantity | 6 | 4 | Binary | Quantity of shares at this price level in the Market Center’s ADAP book. A value of zero implies deletion of this ADAP level. |
| Short ADAP Block Length Indicated by ADAP Block Size in Header |  |  |  |  |

**Table 3. Long Update ADAP Block**

| Field | Offset | Length | Value/Type | Description |
|---|---|---|---|---|
| Market Center | 0 | 1 | Alphanumeric | `Y` = BYX `Z` = BZX `A` = EDGA `X` = EDGX |
| Side | 1 | 1 | Alphanumeric | `B` = Buy Side `S` = Sell Side |
| Price | 2 | 8 | Binary 8.4 Price | Price level to add/update for Market Center’s ADAP book. |
| Quantity | 10 | 8 | Binary | Quantity of shares at this price level in the Market Center’s ADAP book. A value of zero implies deletion of this ADAP level. |
| Long ADAP Block Length Indicated by ADAP Block Size in Header |  |  |  |  |
| Total Length = Variable → (Header Length [22 bytes] + ADAP Blocks x ADAP Block Size) |  |  |  |  |

### Retail Price Improvement (RPI) Message Fields

The `Retail Price Improvement (RPI)` message is a retail liquidity indicator that includes symbol and side, but not price and size. An `RPI` message will be disseminated when there is a retail price improving order present for a symbol on any Cboe Exchange order book OR to indicate a RPI order is no longer available. RPI orders offer price improvement in increments of $.001 to Retail Member Organizations.

**Table 1. RPI**

| Field | Offset | Length | Value/Type | Description |
|---|---|---|---|---|
| Length | 0 | 1 | Binary | Length of this message including this field. |
| Message Type | 1 | 1 | 0xA8 | `RPI` message |
| Timestamp | 2 | 8 | Binary | Timestamp of the matching engine RPI message emitted by the specified Market Center. Encoded as the number of nanoseconds since midnight (effective 11/02/26, since epoch) . |
| Symbol | 10 | 8 | Alphanumeric | Symbol right padded with spaces. |
| Market Center | 18 | 1 | Alphanumeric | `Y` = BYX `Z` = BZX `A` = EDGA `X` = EDGX |
| Retail PriceImprovement | 19 | 1 | Alphanumeric | `B` = Buy Side RPI `S` = Sell Side RPI `A` = Buy & Sell RPI `N` = No RPI |
| Total Length = 20 bytes |  |  |  |  |

### Fractional Trade Message Fields

`Fractional Trade` messages are sent when an order is executed in whole or in part on a Cboe exchange. The last-sale eligible status (Flags field Bit 1) is derived based on four criteria:

1. The Session Indicator (see `Cboe Market Status` message) must be in the regular session.
2. The Last Quantity must be at least one round lot.
3. The Market Status (see `Cboe Market Status` message) for the executing exchange must be Normal.
4. The Transaction Time of the event must be within 10 seconds of the current time. Table 1. Fractional Trade Field Offset Length Value/Type Description Length 0 1 Binary Length of this message including this field. Message Type 1 1 0xE8 `Fractional 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 (effective 11/02/26, since epoch) . Symbol 10 8 Alphanumeric Symbol right padded with spaces. Market Center 18 1 Alphanumeric Market Center on which the last trade was executed: `Y` = BYX `Z` = BZX `A` = EDGA `X` = EDGX 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. National Cumulative Volume 51 8 Binary 12.6 Cumulative number of shares traded today as reported to the CTA and UTP SIPs. Flags 59 1 Bit Field `Bit 0` : National Volume Status `0` : National volume data is complete. `1` : National volume data may not be complete due to an unrecoverable gap on the incoming feed. `Bit 1` : Last-Sale Eligible `0` : Trade is not last-sale eligible `1` : Trade is last-sale eligible `Bit 2-7` : Reserved Total Length = 60 bytes

### Fractional Trade Break Message Fields

The `Fractional 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. Fractional Trade Break**

| Field | Offset | Length | Value/Type | Description |
|---|---|---|---|---|
| Length | 0 | 1 | Binary | Length of this message including this field. |
| Message Type | 1 | 1 | 0xE9 | `Fractional 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 (effective 11/02/26, since epoch) . |
| Symbol | 10 | 8 | Alphanumeric | Symbol right padded with spaces. |
| Market Center | 18 | 1 | Alphanumeric | Market Center on which the last trade was executed: `Y` = BYX `Z` = BZX `A` = EDGA `X` = EDGX |
| Market Center Execution ID | 19 | 8 | Binary | Market center specific execution identifier of trade to be broken. |
| Cboe CumulativeExecuted Volume | 27 | 8 | Binary | Cumulative number of shares traded today across all applicable Cboe books. |
| National Cumulative Volume | 35 | 8 | Binary 12.6 | Cumulative number of shares traded today as reported to the CTA and UTP SIPs. |
| Flags | 43 | 1 | Bit Field | `Bit 0` : SIP Volume Status `0` : SIP volume data is complete. `1` : SIP volume data may not be complete due to an unrecoverable gap on the incoming feed. `Bit 1-7` : Reserved |
| Total Length = 44 bytes |  |  |  |  |

### Trading Status Message Fields

The `Trading Status` message is used to indicate the current trading status of a security on a Cboe exchange. A `Trading Status` message is sent whenever a security’s trading status changes. Sequenced `Trading Status` messages are sent upon system start up for all active securities with Trading Status = 'S' (suspended). `Trading Status` messages will continue to be published upon symbol state changes, such as at the beginning of order acceptance.

A `Trading Status` message will be sent:

- for Regulatory Halts in any security as well as the Trading resumption for the same security.
- for Cboe Listed securities that are in a Quoting period for auctions.
- to indicate a Reg SHO price test is in effect. 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 (effective 11/02/26, since epoch) . Symbol 10 8 Alphanumeric Symbol right padded with spaces. Market Center 18 1 Alphanumeric `Y` = BYX `Z` = BZX `A` = EDGA `X` = EDGX Trading Status 19 1 Alphanumeric `A` = Accepting Orders for Queuing `H` = Halted `Q` = Quote-Only `S` = Exchange Specific Suspension `T` = Trading Reg SHO Action 20 1 Alphanumeric `0` = No price test in effect `1` = Reg SHO price test restriction in effect Total Length = 21 bytes

### Opening/Closing Price Message Fields

The `Opening/Closing Price` message is used to indicate the Opening or Closing price of a security on any of the Cboe markets and the primary listing market. An `Opening/Closing Price` message will be sent whenever the opening or closing price of a security is established. The opening or closing price is established once across all Cboe markets (not per-market). Additionally, an `Opening/Closing Price` message will be sent after it is received from the CTA or UTP SIP once the delay period has expired, currently 15 minutes.

- For Cboe listed securities, the opening and closing prices will be sent when they are received from the listing market and again when received from the SIP feed and the delay period has expired.
- For non-Cboe listed securities, the opening price of a security is defined as the first eligible trade received that occurred on or after 9:30:00 from any Cboe exchange. If no eligible trade is received by 9:35:00, no opening price will be reported from a Cboe exchange. A message will also be sent after the official open from the listing exchange is received and the SIP delay period has expired with Market Center set to `C` or `U`.
- For non-Cboe listed securities, the closing price of a security is the last eligible trade received when any Cboe exchange timestamp exceeds the end of the regular session (normally 16:00:00). If no eligible trade has occurred prior to the close, no closing price will be reported from a Cboe exchange. A message will also be sent after the official close from the listing exchange is received, and the SIP delay period has expired with Market Center set to `C` or `U`.

The Market Center will identify the Cboe market that set the Opening or Closing Price for this security.

**Table 1. Opening/Closing Price**

| Field | Offset | Length | Value/Type | Description |
|---|---|---|---|---|
| Length | 0 | 1 | Binary | Length of this message including this field. |
| Message Type | 1 | 1 | 0xB0 | `Opening/Closing Price` message |
| Timestamp | 2 | 8 | Binary | The time the eligible trade occurred on the specified Market Center. Encoded as the number of nanoseconds since midnight (effective 11/02/26, since epoch) . |
| Symbol | 10 | 8 | Alphanumeric | Symbol right padded with spaces. |
| Market Center | 18 | 1 | Alphanumeric | `Y` = BYX `Z` = BZX `A` = EDGA `X` = EDGX `C` = CTA `U` = UTP |
| Open/Close Indicator | 19 | 1 | Alphanumeric | `O` = Price is the Opening price `C` = Price is the Closing price |
| Price | 20 | 8 | Binary 8.4 Price | Opening/Closing Price. |
| Total Length = 28 bytes |  |  |  |  |

### Fractional End of Day Summary Message Fields

The `Fractional End of Day Summary` message is used to give a consolidated, high-level overview of a security for the day, based on an end of day summary message received from either the US CTA or UTP Securities Information Processor (SIP) feeds. The message will be sent after it is received from the source and the delay period has expired, currently 15 minutes. The system may send more than one `Fractional End of Day Summary` message after the end of a trading session due to multiple CTA/UTP end of day summary spins.

**Table 1. Fractional End of Day Summary**

| Field | Offset | Length | Value/Type | Description |
|---|---|---|---|---|
| Length | 0 | 1 | Binary | Length of this message including this field. |
| Message Type | 1 | 1 | 0xEA | `Fractional End of Day Summary` message |
| Timestamp | 2 | 8 | Binary | The timestamp of the originating SIP summary message. Encoded as the number of nanoseconds since midnight (effective 11/02/26, since epoch) . |
| Symbol | 10 | 8 | Alphanumeric | Symbol right padded with spaces. |
| Data Source | 18 | 1 | Alphanumeric | `C` = CTA `U` = UTP |
| Opening Price | 19 | 8 | Binary 8.4 Price | Opening Price. 0 if the system has not received an opening price for the security. |
| Closing Price | 27 | 8 | Binary 8.4 Price | Closing Price. |
| High Price | 35 | 8 | Binary 8.4 Price | Highest trade price of the day. |
| Low Price | 43 | 8 | Binary 8.4 Price | Lowest trade price of the day. |
| National Cumulative Volume | 51 | 8 | Binary 12.6 | Cumulative volume of shares traded as reported to the national consolidators (SIPs). |
| Total Length = 59 bytes |  |  |  |  |

## Multicast Configuration

### NA Equities Production Environment Configuration

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

**Table 1. Limitations/Configurations**

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

#### Cboe One Multicast Routing Parameters

**Table 1. Cboe One Multicast Routing Parameters - Production**

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

#### Cboe One Multicast Addresses

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

**Table 1. Cboe One Multicast Addresses - NY5 Primary, Production**

| NY5 Primary Data Center | Real-time MC (Src) IP Addr | Gap Resp. MC (Src) IP Addr |
|---|---|---|
| Cboe One US Equities Summary | 224.0.131.130:32201 (174.136.169.12) | 224.0.131.131:32201 (174.136.169.12) |
| Cboe One US Equities Premium (5 Levels) | 224.0.131.128:32200 (174.136.169.12) | 224.0.131.129:32200 (174.136.169.12) |
| Cboe One US Equities Premium (12 Levels) | 224.0.62.26:32300 (174.136.169.12) | 224.0.62.27:32300 (174.136.169.12) |

**Table 2. Cboe One Multicast Addresses - CH4 Secondary, Production**

| CH4 Secondary Data Center | Real-time MC (Src) IP Addr | Gap Resp. MC (Src) IP Addr |
|---|---|---|
| Cboe One US Equities Summary | 233.19.3.34:32201 (174.136.181.150) | 233.19.3.35:32201 (174.136.181.150) |
| Cboe One US Equities Premium (5 Levels) | 233.19.3.36:32200 (174.136.181.150) | 233.19.3.37:32200 (174.136.181.150) |
| Cboe One US Equities Premium (12 Levels) | 233.19.3.6:32300 (174.136.181.150) | 233.19.3.7:32300 (174.136.181.150) |

### North American Equities Certification Environment Configuration

#### Cboe One Certification Multicast Routing Parameters

**Table 1. Cboe One Multicast Routing Parameters - Certification**

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

#### Cboe One Certification Multicast Addresses

The following tables describe the current unit distribution across certification multicast Cboe One feeds.

**Table 1. Cboe One Multicast Addresses - NY5 Primary, Certification**

| NY5 Primary Data Center | Real-time MC (Src) IP Addr | Gap Resp. MC (Src) IP Addr |
|---|---|---|
| Cboe One US Equities Summary | 224.0.74.222:32200 (174.136.174.253) | 224.0.74.223:32200 (174.136.174.253) |
| Cboe One US Equities Premium (5 Levels) | 224.0.74.220:32200 (174.136.174.252) | 224.0.74.221:32200 (174.136.174.252) |
| Cboe One US Equities Premium (12 Levels) | 224.0.74.220:32300 (174.136.174.252) | 224.0.74.221:32300 (174.136.174.252) |

## References

### Symbology

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 | 06/30/14 | Initial version. |
| 1.0.1 | 07/15/14 | Renamed Binary Long Price data type to Binary 8.4 Price. Renamed Binary Short Price data type to Binary 4.4 Price and changed from 2 to 4 bytes. |
| 1.0.2 | 07/23/14 | Added Certification Multicast Addresses. |
| 1.0.3 | 09/11/14 | Added Production (NJ2) Multicast Addresses. |
| 1.0.4 | 09/28/14 | Updated `Trading Status` message to include A Accepting Orders for Queueing and S Exchange Specific Suspension. Also updated section explaining recovery spin processing. |
| 1.0.5 | 11/26/14 | Bats One production systems will now be offered from the NY5 datacenter as opposed to from NJ2. Target availability date pending SEC approval. Bats One certification will be available in NY5 effective 12/01/14 and will be decommissioned in NJ2 effective 12/15/14. |
| 1.1.0 | 05/01/15 | Added SIP Cumulative Volume and Flags fields to `Long Symbol Summary`, `Short Symbol Summary`, `Trade`, and `Trade Break` messages effective 5/15/15. |
| 1.1.1 | 12/29/15 | Added Bats One Disaster Recovery section. |
| 1.2.0 | 02/19/16 | Bats branding/logo changes. |
| 1.3.0 | 05/16/16 | Added Session Indicator to the `Market Status` message, effective 08/01/16. Added last-sale eligible to the Flags on the `Trade` message, effective 08/01/16. `Added Opening/Closing Price` new message, effective 08/01/16. |
| 1.3.1 | 06/14/16 | `Opening/Closing Price` message type changed to 0xB0. |
| 1.3.2 | 06/22/16 | Added Session Indica tor to the `Market Status` message, effective date updated to 08/15/16. Added last-sale eligible to the Flags on the `Trade` message, effective date updated to 08/15/16. Added `Opening/Closing Price` new message, effective date updated to 08/15/16. |
| 1.3.3 | 08/15/16 | Bats formatting updates. Cleanup of old effective date references. |
| 1.3.4 | 10/17/17 | Cboe branding/logo changes. |
| 1.3.5 | 06/09/20 | Added C and U to the Market Center field for the `Opening/Closing Price` message. |
| 1.3.6 | 04/29/21 | Added new `End of Day Summary` message (effective 07/16/21). |
| 1.3.7 | 12/15/21 | Updated hyperlink to Symbology Reference document. |
| 1.4.0 | 09/06/22 | Added Canadian Equities and Long forms of some messages (effective 09/12/22). Added multicast IP addresses and routing parameters for Cboe One Canada (effective 09/12/22). |
| 1.4.1 | 09/07/22 | Updated multicast IP addresses, rendezvous points, and routing parameters for Cboe One Canada (effective 09/12/22). |
| 1.4.2 | 09/09/22 | The DR Cboe One Canada feed takes MATCHNow and NEO Multicast Market Data sourced from their DR sites. |
| 1.4.3 | 04/10/23 | National Cumulative Volume in Canada is the sum of two values: the current Cboe Cumulative Executed Volume and the 15-minute delayed executed volume of other Canadian exchanges as reported by TMX IP. Added National Cumulative Volume to `Expanded Symbol Summary` , `Expanded Trade` , and `Expanded Trade Break` messages. Added Market Center = T, V, S, r, and t. Added Data Source = c. |
| 1.4.4 | 10/18/23 | Added values ‘C’ (US) and ‘U’ (US) to the Market Center field in the `Opening/Closing Price` message. |
| 1.4.5 | 01/31/24 | Minor language updates to reflect amalgamation of MATCHNow into Cboe Canada Inc. exchange. |
| 1.4.6 | 02/15/24 | Clarified that the same data sources are used to distribute Cboe One from both the Cboe Primary site and Cboe DR site. |
| 1.4.7 | 09/06/24 | Removed `r` = NEO-Cross from `Clear Quote` , `Expanded Clear Quote` , `ADAP` , and `Expanded ADAP` messages. Effective 11/13/24, `Trading Status` messages will be sent upon system start up rather than at the start of order acceptance. |
| 1.4.8 | 10/09/24 | Effective 11/13/24, clarified initial `Trading Status` messages will be sent upon system start up in addition to sending at the start of order acceptance. |
| 1.4.9 | 01/15/25 | Updated with Cboe Titanium branding. |
| 1.4.10 | 06/11/25 | Added Halt Status = `F`, `M`, `O`, `P`, and `X` to the `Trading Status` messages (NEO Only) (effective 08/11/25). |
| 1.4.11 | 06/23/25 | Updated Halt Status to Trading Status on `Trading Status` messages. |
| 1.4.12 | 10/06/25 | Added the following messages to Cboe One Update Messages (UDP & TCP) (effective 01/26/26): `Fractional Symbol Summary` , `Expanded Fractional Symbol Summary` (CA Only) , `Fractional Trade` , `Expanded Fractional Trad` e (CA Only) , `Fractional Trade Break` , `Expanded Fractional Trade Break` (CA Only) , `Fractional End of Day Summary,` `Expanded Fractional End of Day Summary` (CA Only) . Sunset the following messages from Cboe One Update Messages (effective 01/26/26): `Short Symbol Summary` , `Long Symbol Summary` , `Expanded Symbol Summary` (CA only) , `Trade` , `Expanded Trade` (CA Only) , `Trade Break` , `Expanded Trade Break` (CA Only) , `End of Day Summary` , `Expanded End of Day Summary` (CA Only) . Added Binary 12.6 to Data Types . |
| 1.4.13 | 03/16/26 | Updated Introduction to state Cboe Summary Depth Feed is available with 12 ADAP levels (effective 05/04/26) and requires bandwidth of up to 400 Mb/sec. Added 12-level multicast addresses to Cboe One Multicast Addresses and Cboe One Certification Multicast Addresses (effective 05/04/26). |
| 1.4.14 | 06/15/26 | Updated Introduction to indicate that BYX, BZX, EDGA, and EDGX will change the timestamp precision from milliseconds to nanoseconds effective 07/20/26. |
| 1.4.15 | 06/30/26 | Removed references to Canada. Last Update Timestamp , Timestamp , and Transaction Time fields will be encoded as the number of nanoseconds since epoch (effective 11/02/26). |