# Cboe Titanium U.S. Options Complex Multicast Futures Options Order Type PITCH Specification

Version 1.0.0 · September 16, 2026

## Introduction

Note that this specification is the standard specification to be used for complex options with futures legs on the Cboe Options (C1) Exchange platform.

Cboe customers may use Complex Options/Futures Multicast PITCH to receive real-time depth of book quotations and execution information direct from Cboe. This feed only includes quotations and executions related to orders for complex options with futures legs.

Complex Options/Futures Multicast PITCH cannot be used to enter orders. For order entry, refer to the appropriate U.S. Options FIX or BOE Specifications.

A Gig-Shaped version of the Complex Options/Futures Multicast PITCH feed is available from both of Cboe’s data centers. Customers may choose to take one or more of the following Complex Options/Futures Multicast PITCH feed options depending on their location and connectivity to Cboe.

This feed is also available to CFE market data subscribers at no additional charge through the distribution of CFE market data. There is a small latency difference between direct receipt of that feed and receipt of that feed through CFE market data distribution. CFE market data subscribers may also choose to obtain this feed directly at no additional charge.

### Complex Options/Futures Multicast PITCH Feed Descriptions

**Table 1. Complex Options/Futures Multicast PITCH Feed Descriptions**

| Exchange | Shaping (Gig) | Served From Data Center (Primary/Secondary) | Multicast Feed ID |
|---|---|---|---|
| C1 Options | Gig | Primary | CAI |
| C1 Options | Gig | Primary | CBI |
| C1 Options | Gig | Secondary | CEI |

### Feed Connectivity Requirements

Gig Shaped feeds are available to customers with a minimum of 1 Gb/s of connectivity to Cboe via cross connect or dedicated circuit.

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

Cboe Options/Futures Complex Multicast PITCH real-time events are delivered using a published range of multicast addresses divided by symbol range units. Dropped messages can be requested using a TCP/IP connection to one of Cboe’s Gap Request Proxy (GRP) servers with replayed messages being delivered on a separate set of multicast ranges reserved for packet retransmission. Intraday, a spin of all open orders may be requested from a Spin Server. This allows a client to become current without requesting a gap for all messages up to that point in the day.

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

_(Figure)_

### Symbol Ranges, Units, and Sequence Numbers

Symbols will be separated by underlyer into units by a published distribution. Symbol distribution will not change intra-day. Cboe does, however, reserve the right to add multicast addresses or change the symbol distribution with prior notice to customers. Care should be taken to ensure that address changes, address additions, and symbol distribution changes can be supported easily.

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

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

### Complex Options Specific Symbol Processing

Cboe has implemented a Complex Instrument Creation (CIC) process due to the seemingly infinite number of combinations that can make up a complex instrument. This allows the Complex Options/Futures Multicast PITCH specification to be consistent with the equities, standard and auction options Multicast PITCH specifications. This CIC process significantly reduces the size of the Complex Options/Futures Multicast PITCH feed and allows customers to use the same feed handler for Cboe equity, options, and futures exchanges.

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

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

### Gap Request Proxy and Message Retransmission

Requesting delivery of missed data is achieved by connecting to the Cboe Gap Request Proxy (GRP) for the complex options data feed. Customers 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. Customers 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` Status code of Accepted signals that the replayed messages will be delivered via the appropriate gap response multicast address. Any other `Gap Response` Status code will indicate the reason that the request cannot be serviced.

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

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

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

Gap acknowledgments 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 acknowledgment from the GRP.

### Spin Servers

A Spin Server is available for each unit. The server allows customers to connect via TCP and receive a spin of all complex instrument definitions and currently open orders with limited trading conditions on that unit. By using the spin, a customer can get the current complex book quickly in the middle of the trading session without worry of gap request limits. The Spin Server for each unit listens on its own address and/or TCP port.

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

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

A spin consists only of `Complex Options Futures Instrument Definition Expanded`, `Add Order (long and/or short)`, `Trading Status` and `Time` messages. `Trading Status` messages will be sent in spins for all complex instruments that are not `S`=Suspended, which results in at least two messages for every complex instrument that has not been Suspended since system startup. A `Time` message will be sent as the last message in a spin if the last `Time` message sent on a spin is older than the last received time from the internal market data producers.

Spins will not contain any message for an order which is no longer on the book. While receiving the spin, the customer must buffer multicast messages received. If the `Spin Image Available` message sequence number is the customer’s reference point, multicast messages with larger sequence numbers should be buffered. If a non- `Spin Image Available` sequence number is the customer’s reference point from which they send in their `Spin Request`, they should buffer from that point on, but note that the spin they will receive will contain sequence numbers beyond that point which may be disregarded. When a `Spin Finished` message is received, the buffered messages must be applied to spun copy of the book to bring it current.

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

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

## Protocol

Cboe users may use the PITCH 2.X protocol over multicast to receive real-time full depth of complex book quotations and execution information direct from Cboe.

### Message Format

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

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

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

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

### Data Types

The following field types are used within the `Sequenced Unit Header`, GRP messages, and PITCH 2.X.

- 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 Unsigned Price fields are signed Little Endian encoded 4 byte binary fields with 4 implied decimal places (denominator = 10,000).
- 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. Effective 09/08/25 , these fields will be 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

Depth of book update messages will be combined into single UDP frame where possible to decrease message overhead and total bandwidth. The count of messages in a UDP frame will be communicated using the `Sequenced Unit Header`. Framing will be determined by the server for each unit and site. The content of the multicast across feeds (e.g. A/B & Gig-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 Complex Options/Futures Multicast PITCH messages as well as messages to and from the Gap Request Proxy (GRP) and Spin Servers.

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

Sequenced messages have implied sequences with the first message having the sequence number contained in the header. Each subsequent message will have an implied sequence one greater than the previous message up to a maximum of count messages. Multiple messages can follow a `Sequenced Unit Header` , but a combination of sequenced and un-sequenced messages cannot be sent 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. |
| Hdr Sequence | 4 | 4 | Binary | Sequence of first message to follow this header. |
| Total Length = 8 bytes |  |  |  |  |

### Heartbeat Messages

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

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

Outside of trading hours Cboe sends `Heartbeat` messages on all real-time and gap channels with a sequence of `0` to help users validate multicast connectivity. `Heartbeat` messages 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 2 consecutive `Heartbeat` messages will result in the GRP or Spin Servers terminating the client connection.

## PITCH 2.X Messages

With the exception of `Time Reference` and `Time` messages, each PITCH message reflects the order addition, order deletion, order modification or execution of an order in the system.

### Time Message Fields

A `Time` message is immediately generated and sent when there is a PITCH event for a given clock second. If there is no PITCH 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 will also include the Epoch Time field, which is the current time represented as the number of whole seconds since the Epoch (midnight January 1, 1970).

A given trading day may span multiple calendar days. 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 from midnight Eastern Time |
| Epoch Time | 6 | 4 | Binary | Number of whole seconds since the Epoch (midnight January 1, 1970 UTC). |
| Total Length = 6 bytes, 10 bytes |  |  |  |  |

### Unit Clear Message Fields

The `Unit Clear` message instructs feed recipients to clear all orders for the Cboe complex book in the unit specified in the `Sequenced Unit Header`.

**Table 1. Unit Clear**

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

### Transaction Begin Message Fields

The `Transaction Begin` message indicates any subsequent messages, up to the accompanying `Transaction End` message, are all part of the same transaction block. All PITCH messages corresponding to such an event would be included between a `Transaction Begin` and `Transaction End`. It is important to note that any PITCH Message Type may be included in a transaction block and there is no guarantee that the messages apply to the same price level or even the same Symbol. `Transaction Begin` messages do not alter the book and can be ignored if messages are being used solely to build a book.

Feed processors can use a transaction block as a trigger to postpone publishing a quote update until the end of the transaction block.

**Table 1. Transaction Begin**

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

### Transaction End Message Fields

The `Transaction End` message indicates that a transaction indicated by a previous `Transaction Begin` message has completed. `Transaction End` messages do not alter the book and can be ignored if messages are being used solely to build a book.

**Table 1. Transaction End**

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

### Complex Options Futures Instrument Definition Message Fields

A `Complex Options Futures Instrument Definition` message represents a complex instrument that is available to place orders. It is sent as a sequenced message the first time a `Complex Options Futures Instrument Definition` message is sent for a symbol. These messages will also be sent continuously through the day as an unsequenced message (sequence = 0) at variable rates as bandwidth allows. The Time offset field should be ignored on an unsequenced `Complex Options Futures Instrument Definition`message.

The `Complex Options Futures Instrument Definition` message will contain two or more repeating groups of leg definitions. There is a limit of 16 leg definitions, one of which is a futures leg.

**Table 1. Complex Options Futures Instrument Definition**

| Field Name | Offset | Length | Type/(Value) | Description |
|---|---|---|---|---|
| Length | 0 | 1 | Binary | Length of this message including this field. |
| Message Type | 1 | 1 | 0xFC | `Complex Options Futures Instrument Definition` message |
| Time Offset | 2 | 4 | Time Offset | Nanosecond offset from last unit timestamp. |
| Complex Instrument Id | 6 | 6 | Printable ASCII | Complex Instrument Id right padded with spaces. |
| Complex Instrument Underlying | 12 | 8 | Printable ASCII | Complex Instrument Underlying right padded with spaces. |
| Complex Instrument Type | 20 | 1 | Alphanumeric | Complex Option Type `F` = One leg is a futures leg |
| Reserved | 21 | 3 | Reserved | Reserved |
| Leg Count | 24 | 1 | Binary | The number of legs in the complex instrument. The maximum number of legs is 16. |
| Futures Price Leg Count | 25 | 1 | Binary | The number of futures leg prices. This must match the number of futures legs. |
| The following fields repeat Leg Count times for multi-leg strategies. Leg Index is zero-based. |  |  |  |  |
| Leg Symbol | 26 + Leg Index * 11 | 6 | Printable ASCII | Option or Futures Symbol of leg, right padded with spaces. |
| Leg Ratio | 32 + Leg Index * 11 | 4 | Signed Binary | Leg ratio (positive for buy-side, negative for sell-side). This is the number of contracts. |
| Leg Security Type | 36 + Leg Index * 11 | 1 | Alphanumeric | `O` = Leg is an Option instrument `F` = Leg is an Futures instrument |
| The following fields repeat Futures Leg Price Count times. Futures Price Leg Index is zero-based. |  |  |  |  |
| Leg Index | 26 + (Leg Count * 11) + (Futures Price Leg Index * 9) | 1 | Binary | The Leg Index the future price corresponds to. Leg Index is zero-based. |
| Futures Leg Price | 27 + (Leg Count * 11) + (Futures Price Leg Index * 9) | 8 | Binary Unsigned Price | Futures leg price |
| Total Length = 26 + (Leg Count * 11) + (Futures Price Leg Count * 9) bytes |  |  |  |  |

### Symbol Mapping Message Fields

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) and are sent continuously through the day at variable rates as bandwidth allows.

**Table 1. Symbol Mapping**

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

### Add Order Message Fields

An `Add Order` message represents a newly accepted visible order on the Cboe complex book. It includes a day-specific Order Id assigned by Cboe to the complex order.

**Table 1. Add Order (long)**

| Field Name | Offset | Length | Type/(Value) | Description |
|---|---|---|---|---|
| Length | 0 | 1 | Binary | Length of this message including this field |
| Message Type | 1 | 1 | 0x21 | `Add Order` Message (long) |
| Time Offset | 2 | 4 | Time Offset | Nanosecond offset from last unit timestamp |
| Order Id | 6 | 8 | Binary | Day-specific identifier assigned to this order |
| Side Indicator | 14 | 1 | Alphanumeric | `B` = Buy Order `S` = Sell Order |
| Quantity | 15 | 4 | Binary | Instrument quantity added to the complex book (may be less than the number entered). |
| Complex Instrument Id | 19 | 6 | Printable ASCII | Complex Instrument Id right padded with spaces. |
| Price | 25 | 8 | Binary Signed Long Price | The limit order price. This is the price of the option legs only and does not include the futures leg price. |
| Reserved | 33 | 1 | Reserved | Reserved |
| Total Length = 34 bytes |  |  |  |  |

**Table 2. Add Order (short)**

| Field Name | Offset | Length | Type/(Value) | Description |
|---|---|---|---|---|
| Length | 0 | 1 | Binary | Length of this message including this field |
| Message Type | 1 | 1 | 0x22 | `Add Order` Message (short) |
| Time Offset | 2 | 4 | Time Offset | Nanosecond offset from last unit timestamp |
| Order Id | 6 | 8 | Binary | Day-specific identifier assigned to this order |
| Side Indicator | 14 | 1 | Alphanumeric | `B` = Buy Order `S` = Sell Order |
| Quantity | 15 | 2 | Binary | Instrument quantity being added to the complex book (may be less than the number entered). |
| Complex Instrument Id | 17 | 6 | Printable ASCII | Complex Instrument Id right padded with spaces. |
| Price | 23 | 2 | Binary Signed Short Price | The limit order price. This is the price of the option legs only and does not include the futures leg price. |
| Reserved | 25 | 1 | Reserved | Reserved |
| Total Length = 26 bytes |  |  |  |  |

**Table 3. Add Order (expanded)**

| Field Name | Offset | Length | Type/(Value) | Description |
|---|---|---|---|---|
| Length | 0 | 1 | Binary | Length of this message including this field |
| Message Type | 1 | 1 | 0x2F | `Add Order` Message (expanded) |
| Time Offset | 2 | 4 | Time Offset | Nanosecond offset from last unit timestamp |
| Order Id | 6 | 8 | Binary | Day-specific identifier assigned to this order |
| Side Indicator | 14 | 1 | Alphanumeric | `B` = Buy Order `S` = Sell Order |
| Quantity | 15 | 4 | Binary | Instrument quantity being added to the complex book (may be less than the number entered). |
| Complex Instrument Id | 19 | 8 | Printable ASCII | Complex Instrument Id right padded with spaces. |
| Price | 27 | 8 | Binary Signed Long Price | The limit order price. This is the price of the option legs only and does not include the futures leg price. |
| Reserved | 35 | 1 | Reserved | Reserved |
| Participant ID | 36 | 4 | Alphanumeric | Optionally specified. If specified the Executing Broker of firm attributed to this quote. Space filled otherwise. |
| Customer Indicator | 40 | 1 | Alphanumeric | `N` = Non-Customer `C` = Customer |
| Client ID | 41 | 4 | Alphanumeric | Optional user specified value attributed to this quote. Space filled otherwise. |
| Reserved | 45 | 5 | Reserved | Reserved |
| Total Length = 50 bytes |  |  |  |  |

### Order Modification Messages Message Fields

Order Modification messages refer to an Order ID previously sent with an `Add Order` message. Multiple Order Modification messages may modify a single complex order and the effects are cumulative. Modify messages may update the size and/or the price of a complex order on the book. When the remaining size of a complex order reaches zero, the complex order is dead and should be removed from the book.

#### Order Executed

`Order Executed` messages are sent when a visible complex order on the Cboe complex book is executed in whole or in part. The execution price equals the limit order price found in the original `Add Order` message or the limit order price in the latest `Modify Order` message referencing the Order Id.

Note even if there are single leg to complex order executions, this feed will only contain the order execution for the complex order. Any single leg execution information is available on the standard PITCH feed.

**Table 1. Order Executed**

| Field Name | Offset | Length | Type/(Value) | Description |
|---|---|---|---|---|
| Length | 0 | 1 | Binary | Length of this message including this field |
| Message Type | 1 | 1 | 0x23 | `Order Executed` Message |
| Time Offset | 2 | 4 | Time Offset | Nanosecond offset from last unit timestamp |
| Order Id | 6 | 8 | Binary | Order Id of a previously sent `Add Order` message that was executed |
| Executed Quantity | 14 | 4 | Binary | Instrument quantity executed |
| Execution Id | 18 | 8 | Binary | Cboe generated day-unique execution identifier of this execution. |
| Trade Condition | 26 | 1 | Alphanumeric | `N` = Future Options auto electronic trade - Electronic execution of a multi leg future/options order traded on the complex book `M` = Future Options auction trade - Electronic execution of a multi leg future/options order traded in a two sided auction `P` = Future Options cross - Electronic execution of a multi leg future/options order traded in a two sided crossing mechanism that does not go through an exposure period |
| Total Length = 27 bytes |  |  |  |  |

#### Order Executed at Price/Size

`Order Execution at Price/Size` messages are sent when a complex order on the Cboe complex book is executed in whole or in part at a different price than the limit price on the original `Add Order` message or the limit order price in the latest `Modify Order` message referencing the Order Id. If the Remaining Quantity field contains a 0 the complex order should be completely removed from the complex book.

`Order Execution at Price/Size` messages may also be sent in the event the existing size for Order Id is not equal to Executed Quantity + Remaining Quantity. In this case the complex order should be prioritized the same as a new complex order.

**Table 1. Order Executed at Price/Size**

| Field Name | Offset | Length | Type/(Value) | Description |
|---|---|---|---|---|
| Length | 0 | 1 | Binary | Length of this message including this field |
| Message Type | 1 | 1 | 0x24 | `Order Executed at Price/Size` Message |
| Time Offset | 2 | 4 | Time Offset | Nanosecond offset from last unit timestamp |
| Order Id | 6 | 8 | Binary | Order Id of a previously sent `Add Order` message that was executed |
| Executed Quantity | 14 | 4 | Binary | Instrument quantity executed |
| Remaining Quantity | 18 | 4 | Binary | Number of contracts remaining after the execution |
| Execution Id | 22 | 8 | Binary | Cboe generated day-unique execution identifier of this execution. |
| Price | 30 | 8 | Binary Signed Long Price | The execution price of the order. This is the price of the option legs only and does not include the futures leg price. |
| Trade Condition | 38 | 1 | Alphanumeric | `N` = Future Options auto electronic trade - Electronic execution of a multi leg future/options order traded on the complex book `M` = Future Options auction trade - Electronic execution of a multi leg future/options order traded in a two sided auction `P` = Future Options cross - Electronic execution of a multi leg future/options order traded in a two sided crossing mechanism that does not go through an exposure period See Options Trade Condition Codes for details about new codes. |
| Total Length = 39 bytes |  |  |  |  |

#### Reduce Size

`Reduce Size` messages are sent when a complex order on the Cboe complex book is partially reduced.

**Table 1. Reduce Size (long)**

| Field Name | Offset | Length | Type/(Value) | Description |
|---|---|---|---|---|
| Length | 0 | 1 | Binary | Length of this message including this field |
| Message Type | 1 | 1 | 0x25 | `Reduce Size` Message (long) |
| Time Offset | 2 | 4 | Time Offset | Nanosecond offset from last unit timestamp |
| Order Id | 6 | 8 | Binary | Order Id of a previously sent `Add Order` message that has been reduced |
| Canceled Quantity | 14 | 4 | Binary | Instrument quantity canceled |
| Total Length = 18 bytes |  |  |  |  |

**Table 2. Reduce Size (short)**

| Field Name | Offset | Length | Type/(Value) | Description |
|---|---|---|---|---|
| Length | 0 | 1 | Binary | Length of this message including this field |
| Message Type | 1 | 1 | 0x26 | `Reduce Size` Message (short) |
| Time Offset | 2 | 4 | Time Offset | Nanosecond offset from last unit timestamp |
| Order Id | 6 | 8 | Binary | Order Id of a previously sent `Add Order` message that has been reduced |
| Canceled Quantity | 14 | 2 | Binary | Instrument quantity canceled |
| Total Length = 16 bytes |  |  |  |  |

#### Modify Order

The `Modify Order` message is sent whenever an open complex order is visibly modified. The Order Id refers to the Order Id of the original `Add Order` message.

Note that `Modify Order` messages that appear to be "no ops" (i.e. they do not appear to modify any relevant fields) will still lose priority.

**Table 1. Modify (long)**

| Field Name | Offset | Length | Type/(Value) | Description |
|---|---|---|---|---|
| Length | 0 | 1 | Binary | Length of this message including this field |
| Message Type | 1 | 1 | 0x27 | `Modify Order` message (long) |
| Time Offset | 2 | 4 | Time Offset | Nanosecond offset from last unit timestamp |
| Order Id | 6 | 8 | Binary | Order Id of a previously sent `Add Order` message that has been modified |
| Quantity | 14 | 4 | Binary | Instrument quantity associated with this complex order after this modify (may be less than the number entered) |
| Price | 18 | 8 | Binary Signed Long Price | The limit order price after this modify. This is the price of the option legs only and does not include the futures leg price. |
| Reserved | 26 | 1 | Bit Field | Reserved |
| Total Length = 27 bytes |  |  |  |  |

**Table 2. Modify (short)**

| Field Name | Offset | Length | Type/(Value) | Description |
|---|---|---|---|---|
| Length | 0 | 1 | Binary | Length of this message including this field |
| Message Type | 1 | 1 | 0x28 | `Modify Order` message (short) |
| Time Offset | 2 | 4 | Time Offset | Nanosecond offset from last unit timestamp |
| Order Id | 6 | 8 | Binary | Order Id of a previously sent `Add Order` message that has been modified |
| Quantity | 14 | 2 | Binary | Instrument quantity associated with this complex order after this modify (may be less than the number entered) |
| Price | 16 | 2 | Binary Signed Short Price | The limit order price after this modify. This is the price of the option legs only and does not include the futures leg price. |
| Reserved | 18 | 1 | Bit Field | Reserved |
| Total Length = 19 bytes |  |  |  |  |

#### Delete Order

The `Delete Order` message is sent whenever a booked order is cancelled or leaves the order book. The Order Id refers to the Order Id of the original `Add Order` message. An order that is deleted from the book may return to the book later under certain circumstances. Therefore, a `Delete Order` message does not indicate that a given Order Id will not be sent again on a subsequent `Add Order` message.

**Table 1. Delete**

| Field Name | Offset | Length | Type/(Value) | Description |
|---|---|---|---|---|
| Length | 0 | 1 | Binary | Length of this message including this field |
| Message Type | 1 | 1 | 0x29 | `Delete Order` Message |
| Time Offset | 2 | 4 | Time Offset | Nanosecond offset from last unit timestamp |
| Order Id | 6 | 8 | Binary | Order Id of a previously sent `Add Order` message that has been removed from order book. |
| Total Length = 14 bytes |  |  |  |  |

### Trade Message Fields

The `Trade` message provides information about executions of complex order auctions on the Cboe complex book. A `Trade` message can also be sent when an auction executes against a non-displayed order, such as a contra response. `Trade` messages are necessary to calculate Cboe execution-based data. `Trade` messages do not alter the complex book and can be ignored if messages are being used solely to build a complex book.

No `Add Order` message is sent for complex auction orders, and thus, no order modification messages may be sent when complex auctions are executed. Instead, a `Trade` message is sent whenever a complex auction is executed in whole or in part. A complete view of all Cboe complex executions can be built by combining all `Order Executed` messages 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`=Buy Order regardless of resting side |
| Quantity | 15 | 4 | Binary | Instrument quantity traded |
| Complex Instrument Id | 19 | 6 | Printable ASCII | Complex Instrument Id right padded with spaces. |
| Price | 25 | 8 | Binary Signed Long Price | The execution price of the order. This is the price of the option legs only and does not include the futures leg price. |
| Execution Id | 33 | 8 | Binary | Cboe generated day-unique execution identifier of this trade. |
| Trade Condition | 41 | 1 | Alphanumeric | `N` = Future Options auto electronic trade - Electronic execution of a multi leg future/options order traded on the complex book `M` = Future Options auction trade - Electronic execution of a multi leg future/options order traded in a two sided auction `P` = Future Options cross - Electronic execution of a multi leg future/options order traded in a two sided crossing mechanism that does not go through an exposure period |
| 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`=Buy Order regardless of resting side |
| Quantity | 15 | 2 | Binary | Instrument quantity traded |
| Complex Instrument Id | 17 | 6 | Printable ASCII | Complex Instrument Id right padded with spaces. |
| Price | 23 | 2 | Binary Signed Short Price | The execution price of the order. This is the price of the option legs only and does not include the futures leg price. |
| Execution Id | 25 | 8 | Binary | Cboe generated day-unique execution identifier of this trade. |
| Trade Condition | 33 | 1 | Alphanumeric | `N` = Future Options auto electronic trade - Electronic execution of a multi leg future/options order traded on the complex book `M` = Future Options auction trade - Electronic execution of a multi leg future/options order traded in a two sided auction `P` = Future Options cross - Electronic execution of a multi leg future/options order traded in a two sided crossing mechanism that does not go through an exposure period |
| Total Length = 34 bytes |  |  |  |  |

**Table 3. Trade (Futures Options)**

| Field Name | Offset | Length | Type/(Value) | Description |
|---|---|---|---|---|
| Length | 0 | 1 | Binary | Length of this message including this field |
| Message Type | 1 | 1 | 0xFD | Trade Message (Futures Options) |
| 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 = Buy Order regardless of resting side |
| Quantity | 15 | 4 | Binary | Instrument quantity traded |
| Complex Instrument Id | 19 | 6 | Printable ASCII | Complex Instrument Id right padded with spaces. |
| Total Price | 25 | 8 | Binary Signed Long Price | The total execution price of the order. This is the total execution price of the order including all the option legs and the futures leg. |
| Execution Id | 33 | 8 | Binary | Cboe generated day-unique execution identifier of this trade. |
| Trade Condition | 41 | 1 | Alphanumeric | `N` = Future Options auto electronic trade - Electronic execution of a multi leg future/options order traded on the complex book `M` = Future Options auction trade - Electronic execution of a multi leg future/options order traded in a two sided auction `P` = Future Options cross - Electronic execution of a multi leg future/options order traded in a two sided crossing mechanism that does not go through an exposure period |
| Total Length = 42 bytes |  |  |  |  |

`Order Execution`, `Order Execution At Price/Size`, `Auction Trade`, `Trade (long)`, and `Trade (short)` messages carry the execution price of the order as calculated without the futures leg price. Any of these messages will be immediately followed by a `Trade (futures options)` message for the same execution id and will carry the execution price of the order as calculated including the futures leg price.

### Auction Notification Message Fields

`Auction Notification` messages are used to disseminate order details of a complex auction. 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. |
| Complex Instrument Id | 6 | 6 | Printable ASCII | Complex Instrument Id right padded with spaces. |
| Auction ID | 12 | 8 | Binary | Day specific identifier assigned to this auction. |
| Auction Type | 20 | 1 | Alphanumeric | `C` = Complex Auction (COA) `B` = Complex AIM |
| Side | 21 | 1 | Alphanumeric | `B` = Buy `S` = Sell |
| Price | 22 | 8 | Binary Signed Long Price | Auction price. This is the auction price of the option legs only and does not include the futures leg price. |
| Quantity | 30 | 4 | Binary | Instrument quantity. |
| Customer Indicator | 34 | 1 | Alphanumeric | `N` = Non-Customer `C` = Customer |
| ParticipantID | 35 | 4 | Alphanumeric | Executing Broker (optional) of firm attributed to this quote. |
| Auction End Offset | 39 | 4 | Binary | Nanosecond offset from last timestamp. |
| Client ID | 43 | 4 | Alphanumeric | Optional user specified value attributed to this quote. Space filled otherwise. |
| Total Length = 47 bytes |  |  |  |  |

### Auction Cancel Message Fields

`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 complex auction, a user modification request to change the complex auction price or increase the original complex auction quantity, a fading of the NBBO or to cancel any remaining complex auction quantity from the original `Auction Notification` following the complex auction termination.

A user request to modify the complex auction price or to increase the original complex auction quantity will result in a cancellation of the complex auction followed by a new `Auction Notification` message. `Auction Cancel` messages will not be issued for complex 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 Message Fields

`Auction Trade` messages are used to disseminate executions resulting from a complex 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. This is the trade price of the option legs only and does not include the futures leg price. |
| Quantity | 30 | 4 | Binary | Instrument quantity traded |
| Total Length = 34 bytes |  |  |  |  |

### Trading Status Message Fields

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

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

Starting at 7:30 a.m. ET, Cboe will send a Trading Status of `Q` once 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 SPX or VIX series transition from RTH trading to Curb trading.

A `Trading Status` message will also be sent:

- for a Regulatory Halt `Q`=Quotingperiod in any series where the underlying has experienced a Regulatory Halt as well as the `T`=Trading resumption for the same series.
- for instruments that are in a `Q`=Quoting period for auctions.

The Trading Status field will be used to represent the status of the RTH (9:30 a.m. ET - 4:15 p.m. ET) and Curb sessions. The GTH Trading Status field will be used to represent the status of series that trade during the GTH session. The GTH session runs from 8:15 p.m. to 9:25 a.m. ET for SPX and VIX series.

**Table 1. Trading Status**

| Field Name | Offset | Length | Type/(Value) | Description |
|---|---|---|---|---|
| Length | 0 | 1 | Binary | Length of this message including this field |
| Message Type | 1 | 1 | 0x31 | `Trading Status` message |
| Time Offset | 2 | 4 | Time Offset | Nanosecond offset from last unit timestamp |
| Complex Symbol ID | 6 | 6 | Printable ASCII | Complex 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 |
| Reserved2 | 17 | 1 | Alpha | Reserved |
| Total Length = 18 bytes |  |  |  |  |

### Options Auction Update Message Fields

`Options Auction Update` messages are used to disseminate price and size information during the Opening and Re-Opening (halt) process for complex instruments. The `Options Auction Update` messages are sent every 5 seconds during an opening period. Refer to the Cboe Options Complex Book Process specification for more information.

**Table 1. Options Auction Update**

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

### Auction Summary Message Fields

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

The `Auction Summary` message has the following format:

**Table 1. Auction Summary**

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

### End of Session Message Fields

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

**Table 1. End of Session**

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

## Gap Request Proxy Messages

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

### Login Message Fields

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

**Table 1. Login**

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

### Login Response Message Fields

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

**Table 1. Login Response**

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

### Gap Request Message Fields

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

**Table 1. Gap Request**

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

### Gap Response Message Fields

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

**Table 1. Gap Response**

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

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

## Spin Messages

### Login Message Fields

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

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

### Login Response Message Fields

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

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

### Spin Image Available Message Fields

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

**Table 1. Spin Image Available**

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

### Spin Request Message Fields

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

**Table 1. Spin Request**

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

### Spin Response Message Fields

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

**Table 1. Spin Response**

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

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

### Spin Finished Message Fields

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

**Table 1. Spin Finished**

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

### Instrument Definition Request Message Fields

The `Instrument Definition Request` message is used by a user’s process to request transmission of this unit’s Symbol Mappings and Complex Instrument Definitions. All `Symbol Mapping` messages will be sent before `Complex Options Futures Instrument Definition` messages. Refer to Section 1.6 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 Mappings and Complex Instrument Definitions are available. |
| Total Length = 6 bytes |  |  |  |  |

### Instrument Definition Response Message Fields

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

**Table 1. Instrument Definition Response**

| Field Name | Offset | Length | Type/(Value) | Description |
|---|---|---|---|---|
| Length | 0 | 1 | Binary | `Length` of this message including this field |
| Message Type | 1 | 1 | 0x85 | `Instrument Definition Response` message |
| Sequence | 2 | 4 | Binary | Will always be 0. |
| Instrument Count | 6 | 4 | Binary | Number of `Symbol Mapping` and `Complex Instrument Definition` (if applicable) messages which will be contained in this spin |
| Status | 10 | 1 | Alphanumeric | Accepted or reason for reject |
| Total Length = 11 bytes |  |  |  |  |
| Instrument Definition Response - Status Codes |  |  |  |  |
| ‘A’ | Accepted |  |  |  |
| ‘O’ | Out of Range (Sequence must be 0) |  |  |  |
| ‘S’ | Spin already in progress (only one spin can be running at a time) |  |  |  |

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

### Instrument Definition Finished Message Fields

The `Instrument Definition Finished` message is sent to indicate that all `Symbol Mapping` and `Complex Options Futures Instrument 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 |  |  |  |  |

### Spin Server Usage Example

The following diagram shows the exchange of messages over time between a customer and Cboe’s Multicast PITCH feed and spin server. Note that while the example may seem to imply only `Complex Options Futures Instrument Definition, Time` and `Add Order` messages would be sent on a spin, this is not the case. `Trading Status and Auction Update` messages may also be sent.

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

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

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

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

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

At time 14, the spin server acknowledges the spin request and indicates that five messages will be sent (complex instrument definition and open orders).

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

Notes:

- Spin Servers are available for each unit. Customers may need to employ multiple Spin Servers depending upon their architecture.
- As a rule of thumb, in its Options markets, Cboe typically has ~300,000 complex instruments defined and ~3.2 million open orders across all units, or an average of about 9,375 complex instruments and 100,000 open orders per unit. The actual number per unit varies depending upon activity in individual symbols. Expect this number to increase and plan accordingly.

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

### PITCH 2.X Messages

```
                
    0xB1        Time Reference 
    0x20        Time
    0x97        Unit Clear
    0xBC        Transaction Begin
    0xBD        Transaction End
    0xFC        Complex Options Futures Instrument Definition 
    0x2F        Symbol Mapping
    0x21        Add Order - Long
    0x22        Add Order - Short
    0x2F        Add Order - Expanded
    0x23        Order Executed
    0x24        Order Executed at Price/Size
    0x25        Reduce Size - Long
    0x26        Reduce Size - Short
    0x27        Modify Order - Long
    0x28        Modify Order - Short
    0x29        Delete Order
    0x2A        Trade - Long
    0x2B        Trade - Short
    0xFD        Trade (Futures Options)
    0xAD        Auction Notification
    0xAE        Auction Cancel
    0xAF        Auction Trade
    0x31        Trading Status
    0xD1        Options Auction Update
    0x96        Auction Summary
    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 Example

**Table 1. Login Message Example**

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

### Login Response Message Example

**Table 1. Login Response Message Example**

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

### Gap Request Message Example

**Table 1. Gap Request Message Example**

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

### Gap Response Message Example

**Table 1. Gap Response Message Example**

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

### Spin Image Available Message Example

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

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

### Spin Request Message Example

**Table 1. Spin Request Message Example**

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

### Spin Response Message Example

**Table 1. Spin Response Message Example**

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

### Spin Finished Message Example

**Table 1. Spin Finished Message Example**

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

### Instrument Definition Request Message Example

**Table 1. Instrument Definition Request Message Example**

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

### Instrument Definition Response Message Example

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

### Instrument Definition Finished Message Example

**Table 1. Instrument Definition Finished Message Example**

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

### Time Reference Message Example (C1 Only)

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

| Length | 12 | 18 bytes |
|---|---|---|
| Type | B1 | Time Reference |
| Midnight | D0 8B 34 60 | 2021-02-23 00:00:00 |
| Reference |  | 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 Example

**Table 1. Time Message Example**

| Length | 10 | 0A 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 |

### Unit Clear Message Example

**Table 1. Unit Clear Message Example**

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

### Add Order - Long Message Example

**Table 1. Add Order - Long Message Example**

| Length | 22 | 34 bytes |
|---|---|---|
| Type | 21 | Add Order - Long |
| Time Offset | 18 D2 06 00 | 447,000 ns since last Time Message |
| Order Id | 05 40 5B 77 8F 56 1D 0B | 631WC4000005 |
| Side Indicator | 42 | Buy |
| Quantity | 32 00 00 00 | 50 |
| CID | 43 30 30 30 31 32 | C00012 |
| Price | 28 23 00 00 00 00 00 00 | $0.9000 |
| Reserved | 00 | Reserved |

### Add Order - Short Message Example

**Table 1. Add Order - Short Message Example**

| Length | 1A | 26 bytes |
|---|---|---|
| Type | 22 | Add Order - Short |
| Time Offset | 18 D2 06 00 | 447,000 ns since last Time Message |
| Order Id | 05 40 5B 77 8F 56 1D 0B | 631WC4000005 |
| Side Indicator | 42 | Buy |
| Quantity | 32 00 | 50 |
| CID | 43 30 30 30 31 32 | C00012 |
| Price | 0A 28 | $102.50 |
| Reserved | 00 | Reserved |

### Add Order - Expanded Message Example

**Table 1. Add Order - Expanded Message Example**

| Length | 2D | 45 bytes |
|---|---|---|
| Type | 2F | Add Order - Expanded |
| Time Offset | 18 D2 06 00 | 447,000 ns since last Time Message |
| Order Id | 05 40 5B 77 8F 56 1D 0B | 631WC4000005 |
| Side Indicator | 42 | Buy |
| Quantity | 32 00 | 50 |
| CID | 43 30 30 30 31 32 20 20 | C00012 |
| Price | 28 23 00 00 00 00 00 00 | $0.9000 |
| Reserved | 00 | Reserved |
| Participant ID | 41 42 43 44 | ABCD |
| Customer Indicator | 4E | Non-Customer |
| Client ID | 43 4C 49 44 | CLID |

### Order Executed Message Example

**Table 1. Order Executed Message Example**

| Length | 1A | 26 bytes |
|---|---|---|
| Type | 23 | Order Executed |
| Time Offset | 18 D2 06 00 | 447,000 ns since last Time Message |
| Order Id | 05 40 5B 77 8F 56 1D 0B | 631WC4000005 |
| Executed Quantity | 64 00 00 00 | 100 |
| Execution Id | 34 2B 46 E0 BB 00 00 00 | 0AAP09VEC |

### Order Executed at Price/Size Message Example

**Table 1. Order Executed at Price/Size Message Example**

| Length | 26 | 38 bytes |
|---|---|---|
| Type | 24 | Order Executed at Price/Size |
| Time Offset | 18 D2 06 00 | 447,000 ns since last Time Message |
| Order Id | 05 40 5B 77 8F 56 1D 0B | 631WC4000005 |
| Executed Quantity | 64 00 00 00 | 100 |
| Remaining | 32 00 00 00 | 50 |
| Execution Id | 34 2B 46 E0 BB 00 00 00 | 0AAP09VEC |
| Price | E8 A3 0F 00 00 00 00 00 | $102.50 |

### Reduce Size - Long Message Example

**Table 1. Reduce Size - Long Message Example**

| Length | 12 | 18 bytes |
|---|---|---|
| Type | 25 | Reduce Size - Long |
| Time Offset | 18 D2 06 00 | 447,000 ns since last Time Message |
| Order Id | 05 40 5B 77 8F 56 1D 0B | 631WC4000005 |
| Canceled Quantity | 64 00 00 00 | 100 |

### Reduce Size - Short Message Example

**Table 1. Reduce Size - Short Message Example**

| Length | 10 | 16 bytes |
|---|---|---|
| Type | 26 | Reduce Size - Short |
| Time Offset | 18 D2 06 00 | 447,000 ns since last Time Message |
| Order Id | 05 40 5B 77 8F 56 1D 0B | 631WC4000005 |
| Canceled Quantity | 64 00 | 100 |

### Modify Order - Long Message Example

**Table 1. Modify Order - Long Message Example**

| Length | 1B | 27 bytes |
|---|---|---|
| Type | 27 | Modify Order - Long |
| Time Offset | 18 D2 06 00 | 447,000 ns since last Time Message |
| Order Id | 05 40 5B 77 8F 56 1D 0B | 631WC4000005 |
| Quantity | 4B 00 00 00 | 75 |
| Price | E8 A3 0F 00 00 00 00 00 | $102.50 |
| Reserved | 00 | Reserved |

### Modify Order - Short Message Example

**Table 1. Modify Order - Short Message Example**

| Length | 13 | 19 bytes |
|---|---|---|
| Type | 28 | Modify Order - Short |
| Time Offset | 18 D2 06 00 | 447,000 ns since last Time Message |
| Order Id | 05 40 5B 77 8F 56 1D 0B | 631WC4000005 |
| Quantity | 4B 00 | 75 |
| Price | 0A 28 | $102.50 |
| Reserved | 00 | Reserved |

### Delete Order Message Example

**Table 1. Delete Order Message Example**

| Length | 0E | 14 bytes |
|---|---|---|
| Type | 29 | Delete Order |
| Time Offset | 18 D2 06 00 | 447,000 ns since last Time Message |
| Order Id | 05 40 5B 77 8F 56 1D 0B |  |

### Trade - Long Message Example

**Table 1. Trade - Long Message Example**

| Length | 29 | 41 bytes |
|---|---|---|
| Type | 2A | Trade - Long |
| Time Offset | 18 D2 06 00 | 447,000 ns since last Time Message |
| Order Id | 05 40 5B 77 8F 56 1D 0B | 631WC4000005 |
| Side | 42 | Buy |
| Quantity | 4B 00 00 00 | 75 |
| CID | 43 30 30 30 31 32 | C00012 |
| Price | E8 A3 0F 00 00 00 00 00 | $102.50 |
| Execution Id | 34 2B 46 E0 BB 00 00 00 | 0AAP09VEC |

### Trade - Short Message Example

**Table 1. Trade - Short Message Example**

| Length | 21 | 33 bytes |
|---|---|---|
| Type | FD | Trade - Short |
| Time Offset | 18 D2 06 00 | 447,000 ns since last Time Message |
| Order Id | 05 40 5B 77 8F 56 1D 0B | 631WC4000005 |
| Side | 42 | Buy |
| Quantity | 64 00 | 100 |
| CID | 43 30 30 30 31 32 | C00012 |
| Price | 0A 28 | $102.50 |
| Execution Id | 34 2B 46 E0 BB 00 00 00 | 0AAP09VEC |

### Trade - Futures Options Message Example

**Table 1. Trade - Futures Options Message Example**

| Length | 29 | 41 bytes |
|---|---|---|
| Type | 2A | Trade - Futures Options |
| Time Offset | 18 D2 06 00 | 447,000 ns since last Time Message |
| Order Id | 05 40 5B 77 8F 56 1D 0B | 631WC4000005 |
| Side | 42 | Buy |
| Quantity | 4B 00 00 00 | 75 |
| CID | 43 30 30 30 31 32 | C00012 |
| Price | E8 A3 0F 00 00 00 00 00 | $102.50 |
| Execution Id | 34 2B 46 E0 BB 00 00 00 | 0AAP09VEC |

### Auction Notification Message Example

**Table 1. Auction Notification Message Example**

| Length | 2F | 47 bytes |
|---|---|---|
| Type | AD | Auction Notification |
| Time Offset | 18 D2 06 00 | 447,000 ns since last Time Message |
| CID | 43 30 30 30 31 32 | C00012 |
| Auction ID | 05 40 5B 77 8F 56 1D 0B | 631WC4000005 |
| Auction Type | 4F | O = COA AON |
| Side | 42 | B = Buy Side |
| Price | 00 00 00 00 00 00 00 00 | Price not displayed |
| Quantity | 64 00 00 00 | 100 |
| Customer Indicator | 43 | C = 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 4C 49 44 | CLID |

### Auction Cancel Message Example

**Table 1. Auction Cancel Message Example**

| Length | E | 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 Example

**Table 1. Auction Trade Message Example**

| 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 | E8 A3 0F 00 00 00 00 00 | $102.50 |
| Quantity | 64 00 00 00 | 100 |

### End of Session Message Example

**Table 1. End of Session Message Example**

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

### Trading Status Message Example

**Table 1. Trading Status Message Example**

| Length | 12 | 18 bytes |
|---|---|---|
| Type | 31 | Trading Status |
| Time Offset | 18 D2 06 00 | 447,000 ns since last Time Message |
| CID | 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 |

### Sequenced Unit Header with 2 Messages Example

**Table 1. Sequenced Unit Header**

| Hdr Length | 31 00 | 49 bytes, including header |
|---|---|---|
| Hdr Count | 02 | 2 messages to follow |
| Hdr Unit | 01 | Unit 1 |
| Hdr Sequence | 01 00 00 00 | First message has sequence number 1 |

**Table 2. Message 1: Add Order (Short)**

| Length | 1A | 26 bytes |
|---|---|---|
| Message format | 22 | Add Order - Short |
| Time Offset | 18 D2 06 00 | 447,000 ns since last Time Message |
| Order Id | 05 40 5B 77 8F 56 1D 0B | 631WC4000005 |
| Side Indicator | 42 | Buy |
| Quantity | E1 02 | 737 |
| CID | 43 30 30 30 31 32 | C00012 |
| Price | 01 00 | 0.01 |
| Reserved | 00 | Reserved |

**Table 3. Message 2: Reduce Size (Short)**

| Length | 10 | 16 bytes |
|---|---|---|
| Message format | 26 | Reduce Size - Short |
| Time Offset | E8 D9 06 00 | 449,000 ns since last Time Message |
| Order Id | 05 40 5B 77 8F 56 1D 0B | 631WC4000005 |
| Canceled Quantity | E1 02 | 737 |

### Options Auction Update Message Example

**Table 1. Options Auction Update Message Example**

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

### Auction Summary Message Example

**Table 1. Auction Summary Message Example**

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

### Complex Options Futures Instrument Definition Message Example

**Table 1. Complex Options Futures Instrument Definition Message Example**

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

### Symbol Mapping Message Example

**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 | 43 | ‘C’ - Closing OnlyCondition |
| Underlying | 4D 53 46 54 20 20 20 20 | MSFT |

## Multicast Configuration

### Production Environment Configuration

Production Environment Configuration contains Limitations/Configurations, C1 Unit/Product Distribution, C1 Options Multicast Routing Parameters, and C1 Options Address/Unit Distribution.

#### 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. Customers should ensure that their infrastructure is configured accordingly. |
| Gig-Shaped Throttle | 1 Gb/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. |

#### 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, SIXM, SIXR, SIXRE, SIXT, SIXU, SIXV, SIXY |
| 21 | SMHB - TEQ~ | Excludes SPEQX, SPESG, SPX, SPXO*, 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, SIXM, SIXR, SIXRE, SIXT, SIXU, SIXV, SIXY, SPEQX, SPESG, UKXM, XEO, XND |  |
| 32 | NANOS, VIX, VIXW, XSP, XSPBW |  |
| 33 | SPX, SPXO* |  |
| 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.

*Effective 11/09/26

#### C1 Options Multicast Routing Parameters

**Table 1. C1 Options Multicast Routing Parameters - Production**

| Data Center | Rendezvous Point |
|---|---|
| Primary Data Center A feed | 74.115.128.189 |
| Primary Data Center B feed | 74.115.128.190 |
| Secondary Data Center E feed | 174.136.181.249 |

#### C1 Options Address/Unit Distribution

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

**Table 1. C1 Options Primary Data Center - Production**

| Primary Datacenter | Gig-Shaped [CAI] 170.137.114.80/28 | Gig-Shaped [CBI] 170.137.115.80/28 |  |  |  |
|---|---|---|---|---|---|
| Unit | IP Port | Real-time MC | Gap Resp. MC | Real-time MC | Gap Resp. MC |
| 1 | 30351 | 224.0.74.126 | 224.0.74.127 | 233.182.199.254 | 233.182.199.255 |
| 2 | 30352 |  |  |  |  |
| 3 | 30353 |  |  |  |  |
| 4 | 30354 |  |  |  |  |
| 5 | 30355 |  |  |  |  |
| 6 | 30356 |  |  |  |  |
| 7 | 30357 |  |  |  |  |
| 8 | 30358 |  |  |  |  |
| 9 | 30359 |  |  |  |  |
| 10 | 30360 |  |  |  |  |
| 11 | 30361 |  |  |  |  |
| 12 | 30362 |  |  |  |  |
| 13 | 30363 |  |  |  |  |
| 14 | 30364 |  |  |  |  |
| 15 | 30365 |  |  |  |  |
| 16 | 30366 |  |  |  |  |
| 17 | 30367 |  |  |  |  |
| 18 | 30368 |  |  |  |  |
| 19 | 30369 |  |  |  |  |
| 20 | 30370 |  |  |  |  |
| 21 | 30371 |  |  |  |  |
| 22 | 30372 |  |  |  |  |
| 23 | 30373 |  |  |  |  |
| 24 | 30374 |  |  |  |  |
| 25 | 30375 |  |  |  |  |
| 26 | 30376 |  |  |  |  |
| 27 | 30377 |  |  |  |  |
| 28 | 30378 |  |  |  |  |
| 29 | 30379 |  |  |  |  |
| 30 | 30380 |  |  |  |  |
| 31 | 30381 |  |  |  |  |
| 32 | 30382 |  |  |  |  |
| 33 | 30383 |  |  |  |  |
| 34 | 30384 |  |  |  |  |
| 35 | 30385 |  |  |  |  |

Note - Cboe reserves the right to add multicast addresses with prior notice, but no migration period. Notice will be given that the distribution will change on a certain date. Care should be taken to support mappings in these tables via software configuration. Addresses in the gray area are pre-assigned but not available. Customers should not configure their networks or systems for these addresses.

**Table 2. C1 Options Secondary Datacenter - Production**

| Secondary Datacenter | Gig-Shaped [CEI] 170.137.124.224/28 |  |  |
|---|---|---|---|
| Unit | IP Port | Real-time MC | Gap Response MC |
| 1 | 30601 | 233.19.3.250 | 233.19.3.251 |
| 2 | 30602 |  |  |
| 3 | 30603 |  |  |
| 4 | 30604 |  |  |
| 5 | 30605 |  |  |
| 6 | 30606 |  |  |
| 7 | 30607 |  |  |
| 8 | 30608 |  |  |
| 9 | 30609 |  |  |
| 10 | 30610 |  |  |
| 11 | 30611 |  |  |
| 12 | 30612 |  |  |
| 13 | 30613 |  |  |
| 14 | 30614 |  |  |
| 15 | 30615 |  |  |
| 16 | 30616 |  |  |
| 17 | 30617 |  |  |
| 18 | 30618 |  |  |
| 19 | 30619 |  |  |
| 20 | 30620 |  |  |
| 21 | 30621 |  |  |
| 22 | 30622 |  |  |
| 23 | 30623 |  |  |
| 24 | 30624 |  |  |
| 25 | 30625 |  |  |
| 26 | 30626 |  |  |
| 27 | 30627 |  |  |
| 28 | 30628 |  |  |
| 29 | 30629 |  |  |
| 30 | 30630 |  |  |
| 31 | 30631 |  |  |
| 32 | 30632 |  |  |
| 33 | 30633 |  |  |
| 34 | 30634 |  |  |
| 35 | 30635 |  |  |

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, Multicast Routing Parameters, and C1 Options Address/Unit Distribution

#### 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, SIXM, SIXR, SIXRE, SIXT, SIXU, SIXV, SIXY |
| 21 | SMHB - TEQ~ | Excludes SPEQX, SPESG, SPX, SPXO*, 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, SIXM, SIXR, SIXRE, SIXT, SIXU, SIXV, SIXY, SPEQX, SPESG, UKXM, XEO, XND |  |
| 32 | NANOS, VIX, VIXW, XSP, XSPBW |  |
| 33 | SPX, SPXO* |  |
| 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.

*Effective 11/09/26

#### Multicast Routing Parameters

| Primary Certification Data Center | Rendezvous Point |
|---|---|
| C1 | 74.115.128.131 |

#### C1 Options Address/Unit Distribution

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

**Table 1. C1 Options Address/Unit Distribution - Certification**

| Primary Datacenter | Certification 170.137.126.16/28 |  |  |
|---|---|---|---|
| Unit | IP Port | Real-time MC | Gap Resp. MC |
| 1 | 30601 | 233.103.126.24 | 233.103.126.25 |
| 2 | 30602 |  |  |
| 3 | 30603 |  |  |
| 4 | 30604 |  |  |
| 5 | 30605 |  |  |
| 6 | 30606 |  |  |
| 7 | 30607 |  |  |
| 8 | 30608 |  |  |
| 9 | 30609 |  |  |
| 10 | 30610 |  |  |
| 11 | 30611 |  |  |
| 12 | 30612 |  |  |
| 13 | 30613 |  |  |
| 14 | 30614 |  |  |
| 15 | 30615 |  |  |
| 16 | 30616 |  |  |
| 17 | 30617 |  |  |
| 18 | 30618 |  |  |
| 19 | 30619 |  |  |
| 20 | 30620 |  |  |
| 21 | 30621 |  |  |
| 22 | 30622 |  |  |
| 23 | 30623 |  |  |
| 24 | 30624 |  |  |
| 25 | 30625 |  |  |
| 26 | 30626 |  |  |
| 27 | 30627 |  |  |
| 28 | 30628 |  |  |
| 29 | 30629 |  |  |
| 30 | 30630 |  |  |
| 31 | 30631 |  |  |
| 32 | 30632 |  |  |
| 33 | 30633 |  |  |
| 34 | 30634 |  |  |
| 35 | 30635 |  |  |

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. TODO: Do we need a new trade condition for options with futures?

**Table 1. Options Trade Condition Codes**

| Type | Field Value |
|---|---|
| f | Complex to Complex Electronic Trade. Cboe auction type is COA |
| g | Complex Auction Trade. Cboe order types include C-AIM, C-SAM |
| h | Complex Cross. Cboe auction types include Cust to Cust C-AIM, C-QCC |
| j | Complex Electronic Trade Against Single Leg(s) |
| k | Complex with Stock Options Auction Trade. Cboe auction types include C-AIM w/ Stock, C-SAM w/ Stock |
| m | Complex Floor Trade Against Single Leg(s). All complex floor executions are reported as condition 'm'. |
| n | Complex with Stock Electronic Trade. Includes COA auctions done electronically |
| o | Complex with Stock Cross. Cboe auction types include C-QCC w/ Stock |
| p | Complex with Stock Floor Trade |
| t | Complex Floor Trade of Proprietary Products Marked as "Combo Order" |
| v | Extended Hours Trade. Transaction represents a trade executed during the Curb session. |
| I | Electronic Trade |
| M | Future Options auction trade. Electronic execution of a multi leg future/options order traded in a two sided auction. |
| N | Future Options auto electronic trade. Electronic execution of a multi leg future/options order traded on the complex book. |
| O* | Opening Trade |
| P | Future Options cross. Electronic execution of a multi leg future/options order traded in a two sided crossing mechanism that does not go through an exposure period. |

*The Trade Condition value of `O=Opening Trade` will 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 US Equity/Options Connectivity Manual with respect to redistribution of Cboe Multicast data feeds. For more information on receiving Multicast PITCH through any of these providers, reach out to the vendor contact noted in the Cboe US Equity/Options Connectivity Manual under Extranet Providers.

### Bandwidth Recommendation

The Gig-shaped feeds require 1Gbps of bandwidth. Cboe will use 90% of these respective bandwidths for Multicast PITCH to allow customers to use the same physical connection for FIX order entry if desired.

### Multicast Test Program

The ZIP file located at https://cdn.cboe.com/resources/membership/mcast_pitch.zip contains a sample program that may be used to test Multicast PITCH feed connections and to troubleshoot Multicast issues. Refer to the included README file for build and usage information.

## References

For more information on Cboe Symbology, please see Cboe Symbology Reference.

## Support

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

## Revision History

| Document Version | Date | Description |
|---|---|---|
| 1.0.0 | 09/16/26 | Initial version. |