# Cboe Titanium Cboe Futures Exchange OOF Multicast Depth of Book (PITCH) Specification

Version 1.0.8 · January 5, 2026

## Introduction

This specification is the standard Multicast PITCH specification for Options to be used for the Cboe US Futures Exchange (CFE) platform. This protocol is essentially the same as the Mulitcast PITCH protocol used by the Cboe US Equities and Options exchanges, with the addition of CFE options specific messages.

CFE participants may use CFE Options Multicast PITCH to receive real-time options depth of book quotations and execution information direct from CFE. The Options Multicast PITCH protocol is more timely than the Options Multicast TOP protocol.

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

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

Options Multicast PITCH Feed Descriptions:

**Table 1. CFE OOF PITCH Feed Descriptions**

| Exchange | Shaping | Served From Data Center (Primary/Secondary) | Multicast Feed ID |
|---|---|---|---|
| CFE | WAN | Primary | OFC |
| CFE | WAN | Primary | OFD |
| CFE | WAN | Secondary | OFE |

### Feed Hours and System Restart

The PITCH feed starts on Sunday at approximately 10:00 a.m. CT and shuts down on Friday at approximately 4:05 p.m. CT. A daily restart occurs between 4:05 and 4:45 p.m. CT each day at which time sequences will be reset. The daily restart is typically observed between 4:05 and 4:10 p.m. CT, but could occur later if needed for operational reasons. Feed startup and shutdown times may be adjusted without notice.

Under normal operations, it is expected that the order books are cleared (`Delete Order` messages sent for any open orders, including GTC and GTD orders), prior to the daily restart and reset of sequences. Persisted GTC and GTD orders will be added back into the order book starting at approximately 10 minutes prior to the scheduled queuing time for each futures root.

### Feed Connectivity Requirements

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

Participants with sufficient connectivity may choose to take both the OFC and OFD feeds from the CFE's primary datacenter and arbitrate the feeds to recover lost data. Alternatively, participants may choose to arbitrate feeds from both datacenters. It should be noted that feeds from the secondary datacenter will have additional latency for those connected with CFE in the primary datacenter due to proximity and business continuity processing.

CFE Options Multicast PITCH real-time events are delivered using a published range of multicast addresses divided by symbol range units. A TCP/IP connection to one of CFE's Gap Request Proxy (GRP) servers can be used to request dropped messages. Replayed messages are 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 of Multicast PITCH feed message flow between CFE and a participant feed handler that is listening to the A and B instances of two units:

_(Figure)_

### Symbol Ranges, Units, and Sequence Numbers

Products are separated into units by a reserve the right to add multicast addresses or change the product distribution with 48 hours prior notice to participants. Care should be taken to ensure that address changes, address additions, and product distribution changes can be supported easily.

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

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

### Futures Specific Symbol Processing

CFE has implemented a simple symbol mapping mechanism (`OOF Symbol Mapping` message) for the Options Multicast PITCH feed to map a six character feed symbol to a specific options contract.

CFE has also implemented a complex symbol mapping mechanism (`Complex Instrument Definition Expanded` message) for the Options Multicast PITCH feed to map a six character feed Complex Instrument ID (CID) to the complex instrument definition. A complex instrument definition consists of two or more option legs.

This simple and complex symbol mapping significantly reduces the size of the Options Multicast PITCH feed for futures and allows participants to use the same symbol handling mechanisms for the Cboe operated equity, options, and futures exchanges. This symbol mapping is the same as the Options Multicast TOP feed.

Real-time symbol mapping messages are available on each unit's multicast feed. `OOF Symbol Mapping` messages are un-sequenced and `Complex Instrument Definition Expanded` messages can be both sequenced and un-sequenced. Un-sequenced messages are sent from pre-market through the end of trading in a continuous loop. Once the same contract has been seen twice, the user can be certain the full loop has been observed. The rate is variable and will be adjusted as bandwidth allows.

Complex instruments may be occasionally created intra-day. In these cases, the `Complex Instrument Definition Expanded` message will be sent as a sequenced message on the real-time feed and from the Spin Server before any other messages that reference an instrument created intra-day are sent.

In addition to the symbol mapping messages available on the Options Multicast PITCH feed, a downloadable file with current Production and Certification mappings is available via the CFE website.

### Gap Request Proxy and Message Retransmission

Requesting delivery of missed sequenced data is achieved by establishing a TCP connection to a Option Multicast PITCH GRP port. This GRP port is specific to Option Multicast PITCH and is NOT shared with the Option Multicast TOP GRP port. Participants who do not wish to request missed messages do not need to connect to a GRP port for any reason or listen to the multicast addresses reserved for message retransmission. Participants choosing to request missed data will need to connect to their assigned GRP port, log in, and request gap ranges as necessary. All gap requests will be responded to with a `Gap Response` message. A `Gap Response` message Status code of `A`ccepted signals that the replayed messages will be delivered via the appropriate gap response multicast address. Any other `Gap Response` message Status code will indicate the reason that the request cannot be serviced.

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

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

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

Gap 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 participants to connect via TCP and receive a spin of all the current open orders on that unit. By using the spin, a participant can get the current CFE book quickly in the middle of the trading session without worry of gap request limits. The Spin Server for each unit is assigned its own address and/or TCP port.

Upon successful login and periodically thereafter, a `Spin Image Available` message is sent which contains a sequence number indicating the most recent message applied to the book. Using a `Spin Request` message, a participant 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` message submitted does not present a sequence number that matches one of the last ten `Spin Image Available` messages distributed, the spin will return orders up to the next closest sequence number reported through a `Spin Image Available` message that is greater than the sequence number requested.

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

A spin consists only of `Add Order` message (long and/or short)`, OOF Symbol Mapping`, `Complex Instrument Definition Expanded`, `Trading Status`, `Settlement, Time Reference`, `Time,` and `End of Day Summary` messages. `Trading Status` messages will be sent in spins for all symbols that are not in the initial `H`alted state, which results in at least one message for every symbol that has not been `H`alted since system startup. `Complex Instrument Definition Expanded` messages will be sent for all symbols on the unit, so a spin may be used to get the current list of all instrument definitions. 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 participant must buffer multicast messages received. If the `Spin Image Available` message sequence number is the participant's reference point, multicast messages with larger sequence numbers should be buffered. If a non- `Spin Image Available` message sequence number is the participant's reference point which they send in their `Spin Request` message, they should buffer from that point on, but note that the spin they will receive sequence numbers beyond that point which they may disregard. When a `Spin Finished` message is received, the buffered messages must be applied to spun copy of the book to bring it current.

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

Spin Server Usage Example shows an example flow of messages between a participant and CFE's Option Multicast PITCH feed and Spin Server.

Participants are required to send Heartbeat messages to CFE no less than every 5 seconds, even while a spin response is in progress. Failure to do so is the most common cause of Participant difficulties while processing spin responses, especially during periods of high market activity. CFE recommends that Participants send a heartbeat every second in order to stay well within this heartbeat requirement.

## Protocol

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

All orders and executions are reflected via the PITCH feed. All orders and executions are anonymous, and do not contain any participant identity.

### Message Format

The messages that make up the PITCH protocol are delivered using CFE's `Sequenced Unit Header` message header which handles sequencing and delivery integrity. All messages delivered via multicast as well as to/from the GRP or Spin Server will use the `Sequenced Unit Header` message header for handling message integrity.

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

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

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

### Data Types

The following field types are used within the `Sequenced Unit Header` message header, GRP messages, Spin Server messages, and PITCH.

- 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 Price fields are signed Little Endian encoded 8 byte binary fields with 4 implied decimal places (denominator = 10,000).
- Binary Short Price fields are signed Little Endian encoded 2 byte binary fields with 2 implied decimal places (denominator = 100).
- Bit Field fields are fixed width fields with each bit representing a Boolean flag (the 0 bit is the lowest significant bit; the 7 bit is the highest significant bit).
- Printable ASCII fields are left justified ASCII fields that are space padded on the right that may include ASCII values in the range of 0x20 - 0x7e.
- Binary Date fields are 4 byte unsigned Little Endian values where the base-10 representation is the YYYYMMDD representation of that date. For example, October 30, 2023 would be represented as 20,231,030 (20231030).
- Time Offset are 4 byte unsigned Little Endian values that represent the number of nanoseconds since the last `Time` message.

#### Trade Date

Throughout this document, the term "Trade Date" is synonymous with the term "Business Date". The term Trade Date is used within this document to match identically named fields in the Cboe Titanium Cboe Futures Exchange FIX Specification and Cboe Titanium Cboe Futures Exchange BOE Version 3 Specification.

### 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 CFE `Sequenced Unit Header` message header. Framing will be determined by the server for each unit and site. The content of the multicast across feeds (e.g. A/B) will be identical, but framing will not be consistent across feeds. Receiving processes that receive and arbitrate multiple feeds cannot use frame level arbitration to fill gaps.

### CFE Sequenced Unit Header

The CFE `Sequenced Unit Header` message header is used for all CFE Option Multicast PITCH messages as well as messages to and from the GRP and Spin Servers.

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

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

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

**Table 1. Sequenced Unit Header**

| Field | Offset | Length | Value/Type | Description |
|---|---|---|---|---|
| Hdr Length | 0 | 2 | Binary | Length of entire block of messages. Includes this header and Hdr Count messages to follow. |
| Hdr Count | 2 | 1 | Binary | Number of messages to follow this header. |
| Hdr Unit | 3 | 1 | Binary | Unit that applies to messages included in this header. |
| Hdr Sequence | 4 | 4 | Binary | Sequence of first message to follow this header. |
| `Total Length` = 8 bytes |  |  |  |  |

### Heartbeat Messages Message Fields

The CFE `Sequenced Unit Header` message header with a count field set to `0` will be used for `Heartbeat` messages. During trading hours `Heartbeat` messages will be sent from the GRP, Spin Server, and all multicast addresses if no data has been delivered within 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 an Hdr Sequence value equal to the sequence of the next sequenced message to be sent for the unit. `Heartbeat` messages on gap multicast addresses will always have the Hdr Sequence field set to 0. All `Heartbeat` messages sent to and from the GRP and Spin Server are considered un-sequenced and should have sequence and unit fields set to 0.

Outside of trading hours CFE sends `Heartbeat` messages on all real-time and gap channels with a sequence of `0` to help users validate multicast connectivity. `Heartbeat` messages might not be sent from 4:00 PM CST - 4:45 PM CST or during maintenance windows.

CFE expects `Heartbeat` messages to be sent to the GRP on live connections no less than every 5 seconds. Failure to receive two consecutive heartbeat messages will result in the GRP or Spin Server terminating the client connection. This also applies when the participant is receiving a spin from the Spin Server, the `Heartbeat` messages must continue to be sent from the participant to the Spin Server. With the exception of `Time` messages, each message reflects the order addition, order deletion, order modification or execution of an order in the system.

## PITCH Messages

PITCH messages generally reflect the order addition, order deletion, order modification or execution of an order in the system. In addition, PITCH messages also provide symbol status and time information.

### Time Reference Message Fields

The `Time Reference` message is used to provide a midnight reference point for recipients of the feed. It is sent whenever the system starts up and when the system crosses a midnight boundary. All subsequent `Time` messages for the same unit will the use the last Midnight Reference until another `Time Reference` message is received for that unit. The `Time Reference` message includes the Trade Date, so most other sequenced messages will not include that information.

`Time Reference` messages will be included in a spin response.

**Table 1. Time Reference**

| Field Name | Offset | Length | Type/(Value) | Description |
|---|---|---|---|---|
| Length | 0 | 1 | Binary | Length of this message including this field. |
| Message Type | 1 | 1 | 0xB1 | `Time Reference` message. |
| Midnight Reference | 2 | 4 | Binary | Midnight Central Time reference time for subsequent `Time` messages, expressed as number of whole seconds since the Epoch (Midnight January 1, 1970 UTC). |
| Time | 6 | 4 | Binary | Number of whole seconds elapsed since the start of the current Central Time calendar day, derived by converting the current Central wall clock time (HH:MM:SS) to seconds. On Daylight Saving Time transition days, Time reflects wall clock seconds and does not adjust for the UTC offset change. On a DST spring-forward day, the maximum value will be 82,799 (23 hours). On a DST fall-back day, values between 3,600 and 7,199 will appear twice. Recipients requiring unambiguous absolute timestamps should use Epoch Time (where available) or Midnight Reference in the `Time Reference` message. |
| Time Offset | 10 | 4 | Binary | Nanosecond offset from last unit timestamp. |
| Trade Date | 14 | 4 | Binary Date | Current Trade Date |
| `Total Length` = 18 bytes |  |  |  |  |

### Time Message Fields

A `Time` message is immediately generated and sent when there is a 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. All subsequent Time Offset fields for the same unit will use the new `Time` message value as the base until another `Time` message is received for the same unit. The Time field is the number of seconds relative to midnight Central Time, which is provided in the `Time Reference` message. The `Time` message also includes the Epoch Time field, which is the current time represented as the number of whole seconds since the Epoch (Midnight January 1, 1970).

**Table 1. Time**

| Field Name | Offset | Length | Type/(Value) | Description |
|---|---|---|---|---|
| Length | 0 | 1 | Binary | Length of this message including this field. |
| Message Type | 1 | 1 | 0x20 | `Time` message. |
| Time | 2 | 4 | Binary | Number of whole seconds elapsed since the start of the current Central Time calendar day, derived by converting the current Central wall clock time (HH:MM:SS) to seconds. On Daylight Saving Time transition days, Time reflects wall clock seconds and does not adjust for the UTC offset change. On a DST spring-forward day, the maximum value will be 82,799 (23 hours). On a DST fall-back day, values between 3,600 and 7,199 will appear twice. Recipients requiring unambiguous absolute timestamps should use Epoch Time (where available) or Midnight Reference in the `Time Reference` message. |
| Epoch Time | 6 | 4 | Binary | Number of whole seconds since the Epoch (Midnight January 1, 1970 UTC). |
| `Total Length` = 10 bytes |  |  |  |  |

### Unit Clear Message Fields

The `Unit Clear` message instructs feed recipients to clear all orders for the CFE book in the unit specified in the `Sequenced Unit Header` message header. It would be distributed in rare recovery events such as a data center fail-over.

**Table 1. Unit Clear**

| Field Name | Offset | Length | Type/(Value) | Description |
|---|---|---|---|---|
| Length | 0 | 1 | Binary | Length of this message including this field. |
| Message Type | 1 | 1 | 0x97 | `Unit Clear` message. |
| Time offset | 2 | 4 | Binary | 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. One example of where this might be used is when a single aggressive order executes against several resting orders. All PITCH messages corresponding to such an event would be included between a `Transaction Begin` message and `Transaction End` message. 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. In the prior example of a single aggressive order executing against multiple resting orders, a top of book feed would be able to publish a single trade message and quote update resulting from multiple `Order Executed` messages once it finished processing all of the messages within 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 | Binary | 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 | Binary | Nanosecond offset from last unit timestamp. |
| `Total Length` = 6 bytes |  |  |  |  |

### OOF Symbol Mapping Message Fields

An `OOF Symbol Mapping` message is used to map the 6 character multicast feed symbol field and options on futures name to the option contract and future underlying. The option contract is comprised of the strike price, put/call flag, options expiration date, and future underlying. The future underlying is comprised of the futures product and futures expiration date, which map to a futures symbol.

This message can be sent either as a sequenced message or as an unsequenced message. It is sent as a sequenced message at system startup upon the beginning of a trading session or if an instrument is created or modified during a trading day. A new sequenced message may also be sent for a symbol that does not visibly change any attribute. A continuous loop of unsequenced symbol mapping messages (sequence = 0) is sent throughout the day at variable rates as bandwidth allows. The Time Offset field should be ignored on unsequenced messages.

`OOF Symbol Mapping` messages are included in a spin response and will be disseminated before `Complex Instrument Definition Expanded` messages.

**Table 1. OOF Symbol Mapping**

| Field Name | Offset | Length | Type/(Value) | Description |
|---|---|---|---|---|
| Length | 0 | 1 | Binary | Length of this message including this field. |
| Message Type | 1 | 1 | 0xF9 | `OOF Symbol Mapping` message. |
| Time Offset | 2 | 4 | Binary | Nanosecond offset from last unit timestamp. |
| Feed Symbol | 6 | 6 | Printable ASCII | Option symbol. Six character, base 62. |
| Futures Product | 12 | 8 | Printable ASCII | Underlying futures contract product name. |
| Futures Expiration | 20 | 4 | Binary Date | Underlying futures contract expiration date. |
| Futures Symbol | 24 | 6 | Printable ASCII | Underlying Cboe-formatted futures contract symbol. Six character, base 62. |
| Strike Price | 30 | 8 | Binary Price | Option contract strike price. |
| Call Put Indicator | 38 | 1 | Alphanumeric | `C` = Call `P` = Put |
| Options Expiration | 39 | 4 | Binary Date | Options contract expiration date. |
| Options on Futures Name | 43 | 16 | Alphanumeric | Textual symbol description comprising options product symbol, underlying futures expiration, put/call and the option strike price with two digits to the right of the decimal point. For example "UX1A/X4 C2000" represents the 20.00 strike Call option on the UX1A product with underlying futures expiration X4". |
| Symbol Condition | 59 | 1 | Alphanumeric | `N` = Normal `C` = Closing Only |
| `Total Length` = 60 bytes |  |  |  |  |

### Complex Instrument Definition Expanded Message Fields

A `Complex Instrument Definition Expanded` message represents a complex instrument that is available to place orders.

This message can be sent either as a sequenced message or as an unsequenced message. It is sent as a sequenced message at system startup upon the beginning of a trading session or if an instrument is created or modified during a trading day. A new sequenced message may also be sent for a symbol that does not visibly change any attribute. A continuous loop of unsequenced symbol mapping messages (sequence = 0) is sent throughout the day at variable rates as bandwidth allows. The Time Offset field should be ignored on unsequenced messages.

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

`Complex Instrument Definition Expanded` messages are included in a spin response.

**Table 1. Complex Instrument Definition Expanded**

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

### Trading Status Message Fields

The `Trading Status` message is used to indicate the current trading status of a symbol. A `Trading Status` message will be sent for all symbols as they transition through various trading states. If a `Trading` `Status` message has not been received for a symbol, then the Trading Status for the symbol should be assumed to be `H` = Halted. The following summarizes the Trading Status values for options in the CFE system:

- `H` = Halted state. This state is used for Supervisory Halts initiated by the Trade Desk. Orders are not being accepted in this state.
- `Q` = Queuing state. This state is used when orders are being accepted for queuing. The Queuing state is used during the pre-open for all symbols. It is also used for spread instruments that may not be tradeable due to Threshold Width.
- `T` = Trading state. This state is used when the symbol is available for trading.

CFE will send a Trading Status of `Q` once orders can be accepted for queuing in preparation for the open. At or after the opening time, CFE will send a Trading Status of `T` as symbols are opened for trading. Once trading is done for the day CFE will send a Trading Status of `H` indicating the symbol is Halted.

**Table 1. Trading Status Message Fields**

| 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 | Binary | Nanosecond offset from last unit timestamp. |
| Symbol | 6 | 6 | Printable ASCII | Six character, base 62. |
| Reserved1 | 12 | 2 | Binary | Reserved |
| Trading Status | 14 | 1 | Alpha | `H` = Halted `Q` = Queuing `T` = Trading |
| Reserved2 | 15 | 3 | Binary | Reserved |
| `Total Length` = 18 bytes |  |  |  |  |

### Add Order Message Fields

An `Add Order` message represents a newly accepted visible order on the CFE book. It includes a day-specific Order Id assigned by CFE to the 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 | Binary | 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 | Number of contracts being added to the book (may be less than the number entered). |
| Symbol | 19 | 6 | Printable ASCII | Six character, base 62 symbol. |
| Price | 25 | 8 | Binary Price | The limit order price. |
| `Total Length` = 33 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 | Binary | 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 | Number of contracts being added to the book (may be less than the number entered). |
| Symbol | 17 | 6 | Printable ASCII | Six character, base 62 symbol. |
| Price | 23 | 2 | Binary Short Price | The limit order price. |
| `Total Length` = 25 bytes |  |  |  |  |

### Order Modification Messages

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

#### Order Executed Message Fields

`Order Executed` messages are sent when an order on the CFE 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.

**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 | Binary | 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 | Number of contracts executed. |
| Execution Id | 18 | 8 | Binary | CFE generated day-unique execution identifier of this execution. Execution Id is also referenced in the `Trade Break` message. |
| Trade Condition | 26 | 1 | Alphanumeric | (Space) = Normal trade `O` = Opening trade 1 `S` = Spread trade 1 1 Sent for simple (non-spread) symbols only. |
| `Total Length` = 27 bytes |  |  |  |  |

#### Reduce Size Message Fields

`Reduce Size` messages are sent when a visible order on the CFE 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 | Binary | 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 | Number of contracts 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 | Binary | 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 | Number of contracts canceled. |
| `Total Length` = 16 bytes |  |  |  |  |

#### Modify Order Message Fields

The `Modify Order` message is sent whenever an open 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 | Binary | 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 | Number of contracts associated with this order after this modify (may be less than the number entered). |
| Price | 18 | 8 | Binary Price | The limit order price after this modify. |
| `Total Length` = 26 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 | Binary | 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 | Number of contracts associated with this order after this modify (may be less than the number entered). |
| Price | 16 | 2 | Binary Short Price | The limit order price after this modify. |
| `Total Length` = 18 bytes |  |  |  |  |

#### Delete Order Message Fields

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 | Binary | 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 that occur off of the CFE book (such as Block trades). `Trade` messages are necessary to calculate CFE execution data. `Trade` messages do not alter the book and can be ignored if messages are being used solely to build a book. The Order Id sent in a `Trade` message is obfuscated and will not tie back to any real Order Id sent back via a FIX or BOE order entry session.

**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 | Binary | Nanosecond offset from last unit timestamp. |
| Order Id | 6 | 8 | Binary | Obfuscated Order ID or Order Id of the executed order. |
| Side Indicator | 14 | 1 | Alphanumeric | Always `B` = Buy Order regardless of resting side. |
| Quantity | 15 | 4 | Binary | Incremental number of contracts executed. |
| Symbol | 19 | 6 | Printable ASCII | Six character, base 62 symbol. |
| Price | 25 | 8 | Binary Price | The execution price of the order. |
| Execution Id | 33 | 8 | Binary | CFE generated day-unique execution identifier of this trade. Execution Id is also referenced in the `Trade Break` message. |
| Trade Condition | 41 | 1 | Alphanumeric | (Space) = Normal trade `O` = Opening trade 1 `S` = Spread trade 1 `B` = Block trade 1 Sent for simple (non-spread) symbols only. |
| `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 | Binary | Nanosecond offset from last unit timestamp. |
| Order Id | 6 | 8 | Binary | Obfuscated Order ID or Order Id of the executed order. |
| Side Indicator | 14 | 1 | Alphanumeric | `Always B` = Buy Order regardless of resting side. |
| Quantity | 15 | 2 | Binary | Incremental Number of contracts executed. |
| Symbol | 17 | 6 | Printable ASCII | Six character, base 62 symbol. |
| Price | 23 | 2 | Binary Short Price | The execution price of the order. |
| Execution Id | 25 | 8 | Binary | CFE generated day-unique execution identifier of this trade. Execution Id is also referenced in the `Trade Break` message. |
| Trade Condition | 33 | 1 | Alphanumeric | (Space) = Normal trade `O` = Opening trade 1 `S` = Spread trade 1 `B` = Block trade 1 Sent for simple (non-spread) symbols only. |
| `Total Length` = 34 bytes |  |  |  |  |

### Trade Break Message Fields

The `Trade Break` message is sent whenever an execution on CFE is broken. Trade breaks are rare and only affect applications that rely upon CFE execution-based data. A `Trade` `Break` message followed immediately be a new `Trade` message with the same Execution Id indicates that a trade correction has occurred. Applications that simply build a CFE book can ignore `Trade Break` messages.

**Table 1. Trade Break**

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

### Settlement Message Fields

`Settlement` messages are used to provide information concerning indicative, approved, or corrected daily and final settlement prices for CFE products. An indicative daily settlement price (Issue = I) is calculated by the system and sent immediately after an instrument closes trading but before the settlement price is approved. An approved settlement price (Issue = S) is sent once the CFE Trade Desk approves a settlement price for an instrument. If there is an error in the approved settlement price, then it may be re-issued (Issue = R).

**Table 1. Settlement**

| Field Name | Offset | Length | Type/(Value) | Description |
|---|---|---|---|---|
| Length | 0 | 1 | Binary | Length of this message including this field. |
| Message Type | 1 | 1 | 0xB9 | `Settlement` message. |
| Time Offset | 2 | 4 | Binary | Nanosecond offset from last unit timestamp. |
| Symbol | 6 | 6 | Printable ASCII | Six character, base 62 symbol. |
| Trade Date | 12 | 4 | Binary Date | Trade Date for the settlement. |
| Settlement Price | 16 | 8 | Binary Price | Settlement Price |
| Issue | 24 | 1 | Alphanumeric | `I` = Indicative Settlement `S` = Initial Settlement `R` = Re-issued Settlement |
| `Total Length` = 25 bytes |  |  |  |  |

### End of Day Summary Message Fields

The `End of Day Summary` message is sent out right after trading ends for a symbol. No more markdate data update messages will follow an `End of Day Summary` message for a particular symbol. A value of zero in the Total Volume field means that no volume traded on that symbol for the day. The Total Volume field reflects all contracts traded during the day. Block trades are included in the Total Volume field, but they are also reported separately to provide more detail.

The Summary Flags field provides additional information on how to interpret the High Price and Low Price fields, especially in instruments that had no volume for the day and/or where 0 is a valid price (e.g. complex instruments). There are flags that indicate whether or not the High Price and Low Price fields are valid. If they are not valid, then there was no High (and/or Low) Price for the day. There are also flags that indicate whether the High Price was set by the highest bid and the Low Price was set by the lowest offer rather than a trade.

All `End` `of` `Day` `Summary` message values will span the full trading day, including all extended hours trading and all trading segments.

**Table 1. End of Day Summary**

| Field Name | Offset | Length | Type/(Value) | Description |
|---|---|---|---|---|
| Length | 0 | 1 | Binary | Length of this message including this field. |
| Message Type | 1 | 1 | 0xBA | `End of Day Summary` message. |
| Time Offset | 2 | 4 | Binary | Nanosecond offset from last unit timestamp. |
| Symbol | 6 | 6 | Printable ASCII | Six character, base 62 symbol. |
| Trade Date | 12 | 4 | Binary Date | Trade Date for the message. |
| Open Interest | 16 | 4 | Binary | Prior Trade Date Open Interest for this symbol. |
| High Price | 20 | 8 | Binary Price | The higher of highest bid price and highest trade price for the day. Block trades (Trade Condition = B or E) do not update High Price. |
| Low Price | 28 | 8 | Binary Price | The lower of lowest offer price and lowest trade price for the day. Block trades (Trade Condition = B or E) do not update Low Price. |
| Open Price | 36 | 8 | Binary Price | The first trade on the day (in any session) will set the Open Price for the day (valid only if Total Volume > 0). Block trades (Trade Condition = B or E) do not update Open Price. |
| Close Price | 44 | 8 | Binary Price | The last trade on the day (in any session) will set the Close Price for the day (valid only if Total Volume > 0). Block trades (Trade Condition = B or E) do not update Close Price. |
| Total Volume | 52 | 4 | Binary | Total number of contracts traded for the day, including block trades. |
| Block Volume | 56 | 4 | Binary | Total number of block contracts traded for the day. |
| ECRP Volume | 60 | 4 | Binary | Always zero. |
| Summary Flags | 64 | 1 | Bit Field | `Bit 0` = High Price Valid - Set if High Price is a valid value. `Bit 1` = High Price is bid- Set if High Price was set by the highest bid (rather than a trade). `Bit 2` = Low Price Valid - Set if Low Price is a valid value. `Bit 3` = Low Price is offer - Set if Low Price was set by the lowest offer (rather than a trade). `Bit 4` = Open/Close Valid - Set if both Open Price and Close Price fields contain valid values. `Bit 5-7` = Reserved |
| `Total Length` = 65 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 GRP and to request message retransmissions. Participants 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 CFE. |
| Username | 6 | 4 | Alphanumeric | Username supplied by CFE. |
| Filler | 10 | 2 | Alphanumeric | (space filled) |
| Password | 12 | 10 | Alphanumeric | Password supplied by CFE. |
| `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 |  |  |  |  |

**Table 2. Login Response Status Codes**

| 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 CFE'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

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

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.

### Heartbeat

Heartbeat messages must be sent once every 5 seconds in order to keep the client's connection to the spin server alive. Heartbeat messages are sent using the `Sequenced Unit Header` message header as described in CFE Sequenced Unit Header and Heartbeat Messages 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 participant. |
| `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 participant. |
| 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` message was not rejected. Upon receipt of a `Spin Finished` message, any buffered multicast messages should be applied to the participant'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 to request transmission of this unit's OOF Symbol Mappings and Complex Instrument Definitions. All `OOF Symbol Mapping` messages will be sent before `Complex Instrument Definition Expanded` messages. Refer to Spin Servers for more complete details regarding Sequence specification as well as buffering requirements.

**Table 1. Instrument Definition Request**

| Field Name | Offset | Length | Type/(Value) | Description |
|---|---|---|---|---|
| Length | 0 | 1 | Binary | Length of this message including this field. |
| Message Type | 1 | 1 | 0x84 | `Instrument Definition Request` message. |
| Sequence | 2 | 4 | Binary | Must be 0. Only the current Symbol 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 Message Fields**

| 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 `OOF Symbol Mapping` and `Complex Instrument Definition Expanded` messages (if applicable) which will be contained in this spin. |
| Status | 10 | 1 | Alphanumeric | Accepted or reason for reject. |
| `Total Length` = 11 bytes |  |  |  |  |
| Instrument Definition Response - Status Codes |  |  |  |  |
| ‘A’ | Accepted |  |  |  |
| ‘O’ | Out of Range (Sequence must be 0) |  |  |  |
| ‘S’ | Spin already in progress (only one spin can be running at a time) |  |  |  |

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

### Instrument Definition Finished Message Fields

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

**Table 1. Instrument Definition Finished**

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

### Spin Server Usage Example

The following diagram shows the exchange of messages over time between a participant and CFE's Options Multicast PITCH feed and Spin Server. Note that while the example alone may seem to imply `Add Order` messages only would be sent on a spin, this is not the case. `OOF Symbol Mapping, Complex Instrument Definition Expanded,Trading Status,` and `Settlement` messages may be sent at the beginning of the spin and `Time` and `Time Reference` messages may be found mixed between `Add Order` messages according to their timestamps. `End Of Day Summary` messages are sent after `Add Order` messages.

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

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

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

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

At time 11, the participant sends a `Spin Request` message 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 three open orders will be sent.

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

Notes:

- Spin Servers are available for each unit. Participants may need to employ multiple Spin Servers depending upon their architecture.

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

```
    0x20        Time
    0x21        Add Order - Long
    0x22        Add Order - Short
    0x23        Order Executed
    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
    0x2C        Trade Break
    0x2D        End of Session
    0x31        Trading Status
    0x97        Unit Clear
    0x9A        Complex Instrument Definition Expanded
    0xB1        Time Reference
    0xB9        Settlement
    0xBA        End of Day Summary
    0xBC        Transaction Begin
    0xBD        Transaction End
    0xF9        OOF Symbol Mapping
```

## Message Examples

Each of the following message types must be wrapped by a sequenced or unsequenced unit header as described in CFE 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 | 08 | 8 bytes |
|---|---|---|
| Type | 04 | Gap Response |
| Unit | 01 | Unit 1 |
| Sequence | 3B 10 00 00 | First message: 4155 |
| 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 Example

**Table 1. Instrument Definition Request Example**

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

### Instrument Definition Response Example

**Table 1. Instrument Definition Response 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 Example

**Table 1. Instrument Definition Finished Example**

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

### Time Reference Example

**Table 1. Time Reference Example**

| Length | 12 | 18 bytes |
|---|---|---|
| Type | B1 | Time Reference |
| Midnight Reference | E0 50 92 5A | 2018-02-25 00:00:00 Central (1519538400 seconds since the Epoch) |
| Time | 00 E1 00 00 | 16:00:00 |
| Time Offset | 00 00 00 00 | Exactly 16:00:00 |
| Trade Date | 02 ED 33 01 | 20180226 February 26, 2018 |

### Time Message Example

**Table 1. Time Message Example**

| Length | 0A | 10 bytes |
|---|---|---|
| Type | 20 | Time |
| Time | 98 85 00 00 | 34,200 seconds = 09:30 AM Eastern |
| Epoch Time | F8 27 94 5A | 1519659000 = February 26, 2018 9:30:00 AM Central |

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

### Transaction Begin Message Example

**Table 1. Transaction Begin Message Example**

| Length | 06 | 6 bytes |
|---|---|---|
| Type | BC | Transaction Begin |
| Time Offset | 08 5C 44 25 | 625,237,000 ns since Last Time Message |

### Transaction End Message Example

**Table 1. Transaction End Message Example**

| Length | 06 | 6 bytes |
|---|---|---|
| Type | BD | Transaction End |
| Time Offset | 08 5C 44 25 | 625,237,000 ns since Last Time Message |

### OOF Symbol Mapping Message Example

**Table 1. OOF Symbol Mapping Message Example**

| Length | 3C | 60 bytes |
|---|---|---|
| Type | F9 | Symbol Mapping Message |
| Time Offset | 18 D2 06 00 | 447,000 ns since last Time Message |
| Feed Symbol | 41 42 43 31 32 33 | ABC123 |
| Futures Product | 56 58 20 20 20 20 20 20 | VX |
| Futures Expiration | 8A D8 34 01 | 20240522 |
| Futures Symbol | 44 45 46 34 35 36 | DEF456 |
| Strike Price | 2C 40 02 00 00 00 00 00 00 | 14.7500 |
| Call Put Ind | 50 | P = Put |
| Options Expiration | 7A D8 34 01 | 20240506 |
| Options on Futures Name | 55 58 21 41 2F 4B 34 20 50 31 34 37 35 20 20 20 20 20 | UX1A/K4 P1475 |
| Symbol Condition | 4E | N = Normal |

### Complex Instrument Definition Expanded Message Example

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

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

### 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 |
| Symbol | 5A 56 5A 5A 54 20 20 20 | ZVZZT |
| Trading Status | 54 | T = Trading |
| Reserved | 30 20 20 |  |

### Add Order - Long Message Example

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

| Length | 21 | 33 bytes |
|---|---|---|
| Type | 21 | Add Order - Long |
| Time Offset | 08 5C 44 25 | 625,237,000 ns since Last Time Message |
| Order ID | 96 95 94 93 92 91 00 00 |  |
| Side Indicator | 42 | Buy |
| Quantity | 20 4E 00 00 | 20,000 contracts |
| Symbol | 33 34 35 33 32 31 | 345321 |
| Price | 00 00 32 00 00 00 00 00 | $327.68 |

### Add Order - Short Message Example

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

| Length | 19 | 25 bytes |
|---|---|---|
| Type | 22 | Add Order - Short |
| Time Offset | 08 5C 44 25 | 625,237,000 ns since Last Time Message |
| Order ID | 98 97 96 D3 22 5A 0E 0E |  |
| Side Indicator | 42 | Buy |
| Quantity | 20 4E | 20,000 contracts |
| Symbol | 33 34 35 33 32 31 | 345321 |
| Price | FF 7F | $327.67 |

### Order Executed Message Example

**Table 1. Order Executed Message Example**

| Length | 1B | 27 bytes |
|---|---|---|
| Type | 23 | Order Executed |
| Time Offset | 08 5C 44 25 | 625,237,000 ns since Last Time Message |
| Order Id | 96 95 94 93 92 91 00 00 |  |
| Executed Quantity | 2C 01 00 00 | 300 contracts |
| Execution ID | 56 55 54 53 52 51 00 00 |  |
| Trade Condition | 53 | S – Spread Trade |

### Reduce Size - Long Message Example

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

| Length | 12 | 18 bytes |
|---|---|---|
| Type | 25 | Reduce Size - Long |
| Time Offset | 08 5C 44 25 | 625,237,000 ns since Last Time Message |
| Order Id | 05 40 5B 77 8F 56 1D 0B |  |
| Canceled Quantity | 00 00 01 00 | 65,536 contracts |

### Reduce Size - Short Message Example

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

| Length | 10 | 16 bytes |
|---|---|---|
| Type | 26 | Reduce Size - Short |
| Time Offset | 08 5C 44 25 | 625,237,000 ns since Last Time Message |
| Order Id | 05 40 5B 77 8F 56 1D 0B |  |
| Canceled Quantity | 64 00 | 100 contracts |

### Modify Order - Long Message Example

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

| Length | 1A | 26 bytes |
|---|---|---|
| Type | 27 | Modify Order – Long |
| Time Offset | 08 5C 44 25 | 625,237,000 ns since Last Time Message |
| Order Id | 05 40 5B 77 8F 56 1D 0B |  |
| Quantity | FF FF 00 00 | 65,535 contracts |
| Price | 2C 33 32 00 00 00 00 00 | $328.99 |

### Modify Order - Short Message Example

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

| Length | 12 | 18 bytes |
|---|---|---|
| Type | 28 | Modify Order – Short |
| Time Offset | 08 5C 44 25 | 625,237,000 ns since Last Time Message |
| Order Id | 05 40 5B 77 8F 56 1D 0B |  |
| Quantity | FF FF | 65,535 contracts |
| Price | 0A 28 | $102.50 |

### Delete Order Message Example

**Table 1. Delete Order Message Example**

| Length | 0E | 14 bytes |
|---|---|---|
| Type | 29 | Delete Order |
| Time Offset | 08 5C 44 25 | 625,237,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 | 2A | 42 bytes |
|---|---|---|
| Type | 2A | Trade - Long |
| Time Offset | 08 5C 44 25 | 625,237,000 ns since Last Time Message |
| Order Id | 05 40 5B 77 8F 56 1D 0B |  |
| Side | 42 | Buy |
| Quantity | F8 24 01 00 | 75,000 contracts |
| Symbol | 33 34 35 33 32 31 | 345321 |
| Price | E8 A3 0F 00 00 00 00 00 | $102.50 |
| Execution Id | 34 2B 46 E0 BB 00 00 00 | 0AAP09VEC |
| Trade Condition | 20 | (space) Normal |

### Trade - Short Message Example

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

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

### Trade Break Message Example

**Table 1. Trade Break Message Example**

| Length | 0E | 14 bytes |
|---|---|---|
| Type | 2C | Trade Break |
| Time Offset | 08 5C 44 25 | 625,237,000 ns since Last Time Message |
| Execution Id | 34 2B 46 E0 BB 00 00 00 | 0AAP09VEC |

### Settlement Message Example

**Table 1. Settlement Message Example**

| Length | 19 | 25 bytes |
|---|---|---|
| Type | B9 | Settlement |
| Time Offset | 60 84 8E 00 | 9,340,000 ns since last Time Message |
| Symbol | 36 35 34 33 32 31 | 654321 |
| Trade Date | 03 ED 33 01 | 20180227 February 27, 2018 |
| Settlement Price | 4C F8 06 00 00 00 00 00 | $45.67 |
| Issue | 53 | S – Initial Settlement |

### End of Day Summary Message Example

**Table 1. End of Day Summary Message Example**

| Length | 41 | 65 bytes |
|---|---|---|
| Type | BA | End of Day Summary |
| Time Offset | 18 D2 06 00 | 447,000 ns since last Time Message |
| Symbol | 39 38 37 36 35 34 | 987654 |
| Open Interest | B1 68 DE 3A | 987,654,321 contracts |
| High Price | DC FB 09 00 00 00 00 00 | $65.43 |
| Low Price | 08 E2 01 00 00 00 00 00 | $12.34 |
| Open Price | E0 49 08 00 00 00 00 00 | $54.32 |
| Close Price | F8 A9 08 00 00 00 00 00 | $56.78 |
| Total Volume | 15 CD 5B 07 | 123,456,789 contracts |
| Block Volume | 88 13 00 00 | 5,000 block contracts |
| ECRP Volume | 00 00 00 00 | Always zero |
| Summary Flags | 15 | High Price Valid 0x01 Low Price Valid 0x04 Has Open/Close 0x10 |

### End of Session Message Example

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

| Length | 06 | 6 bytes |
|---|---|---|
| Type | 2D | End of Session |
| Time Offset | 08 5C 44 25 | 625,237,000 ns since Last Time Message |

### Sequenced Unit Header with 2 Messages

**Table 1. Sequenced Unit Header with 2 Messages**

| 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 |
| Message 1: Add Order (Short) |  |  |
| Length | 19 | 25 bytes |
| Type | 22 | Add Order - Short |
| Time Offset | 08 5C 44 25 | 625,237,000 ns since Last Time Message |
| Order ID | 98 97 96 D3 22 5A 0E 0E |  |
| Side Indicator | 42 | Buy |
| Quantity | 20 4E | 20,000 contracts |
| Symbol | 33 34 35 33 32 31 | 345321 |
| Price | FF 7F | $327.67 |
| Message 2: Reduce Size (Short) |  |  |
| Length | 10 | 16 bytes |
| Type | 26 | Reduce Size - Short |
| Time Offset | 08 5C 44 25 | 625,237,000 ns since Last Time Message |
| Order | 98 97 96 D3 22 5A 0E 0E |  |
| Canceled Quantity | 64 00 | 100 contracts |

## Multicast Configuration

### Production Environment Configuration

Production Environment Configuration contains Limitations/Configurations, CFE OOF Unit/Product Distribution, Multicast Routing Parameters, and Address/Unit Distribution information.

#### Limitations/Configurations

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

**Table 1. Production Environment - Network and Gap Request Limitations/Configurations**

| Period/Type | Limit/Setting | Notes |
|---|---|---|
| MTU | 1500 | CFE will send UDP messages up to 1500 bytes. Participants should ensure that their infrastructure is configured accordingly. |
| WAN-Shaped Throttle | 100 Mb/s | The real-time and gap multicast head ends are configured to shape their output to this level to minimize packet loss. |
| Gap Response Delay | 2 ms | The Gap Server will delay resending sequenced messages via multicast for the specified limit in order to satisfy multiple GRP gap requests with one multicast response. |
| Count | 100 | Any single gap request may not be for more than this number of dropped messages. |
| 1 Second | 320 Requests | This is the maximum number of retransmission requests allowed per second for each session. This is renewed every clock second. |
| 1 Minute | 1,500 Requests | This is the maximum number of retransmission requests allowed per minute for each session. This is renewed every clock minute. |
| Day | 100,000 Requests | This is the maximum number of retransmission requests allowed per day for each session. |
| Within Range | 1,000,000 Messages | Users' retransmission requests must be within this many messages of the most recent sequence sent by the real-time feed per session. |

#### CFE OOF Unit/Product Distribution

The following table describes the CFE Options on Futures symbol distribution across units based on underlying futures product:

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

**Table 1. CFE OOF Production/Certification Environment - Unit/Product Distribution**

| Underlying Futures | Unit |
|---|---|
| VX | 1 |
| IBHY, IBIG | 2 |
| N/A | 3 |
| N/A | 4 |

#### Multicast Routing Parameters

**Table 1. Production Environment - Multicast Routing Parameters**

| Data Center | Rendezvous Point |
|---|---|
| Primary Data Center C feed | 74.115.128.164 |
| Primary Data Center D feed | 74.115.128.165 |
| Secondary Data Center E feed | 170.137.16.128 |

#### Address/Unit Distribution

The following tables describe the unit distribution across the CFE OOF Multicast PITCH feeds.

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

**Table 1. Production Environment - Address/Unit Distribution (Primary Datacenter)**

| Primary Datacenter | WAN-Shaped [OFC] 74.115.133.96/29 | WAN-Shaped [OFD] 74.115.133.104/29 |  |  |  |
|---|---|---|---|---|---|
| Unit | IP Port | Real-time MC | Gap Resp. MC | Real-time MC | Gap Resp. MC |
| 1 | 30001 | 224.0.62.16 | 224.0.62.17 | 224.0.73.16 | 224.0.73.17 |
| 2 | 30002 | 224.0.62.224 | 224.0.73.224 |  |  |
| 3 | 30003 | 224.0.62.225 | 224.0.73.225 |  |  |
| 4 | 30004 | 224.0.62.226 | 224.0.73.226 |  |  |

**Table 2. Production Environment - Address/Unit Distribution (Secondary Datacenter)**

| Secondary Datacenter | WAN-Shaped [OFE] 170.137.16.80/29 |  |  |
|---|---|---|---|
| Unit | IP Port | Real-time MC | Gap Resp. MC |
| 1 | 31001 | 233.19.3.0 | 233.19.3.1 |
| 2 | 31002 |  |  |
| 3 | 31003 |  |  |
| 4 | 31004 |  |  |

### US Futures Certification Environment Configuration

Production Environment Configuration contains CFE OOF Unit/Product Distribution, Certification Multicast Routing Parameters, and Address/Unit Distribution information.

#### CFE OOF Unit/Product Distribution

The following table describes the CFE Options on Futures symbol distribution across units based on underlying futures product:

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

**Table 1. CFE OOF Production/Certification Environment - Unit/Product Distribution**

| Underlying Futures | Unit |
|---|---|
| VX | 1 |
| IBHY, IBIG | 2 |
| N/A | 3 |
| N/A | 4 |

#### Certification Multicast Routing Parameters

**Table 1. Certification Environment - Multicast Routing Parameters**

| Data Center | Rendezvous Point |
|---|---|
| Primary Data Center | 74.115.128.130 |

#### Address/Unit Distribution

The following table describes the unit distribution across the certification CFE Multicast PITCH feeds.

**Table 1. Certification Environment - Address/Unit Distribution**

| Primary Datacenter | WAN-Shaped [Cert] 174.136.160.16/28 |  |  |
|---|---|---|---|
| Unit | IP Port | Real-time MC | Gap Resp. MC |
| 1 | 32001 | 224.0.74.248 | 224.0.74.249 |
| 2 | 32002 |  |  |
| 3 | 32003 |  |  |
| 4 | 32004 |  |  |

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

## Connectivity

### Supported Extranet Carriers

The WAN-Shaped feed will be made available to participants through extranet carriers that have completed their multicast implementation and registered with CFE for receipt of market data. CFE has certified a number of carriers defined in the Cboe Titanium Cboe Futures Exchange Connectivity Manual with respect to distribution of CFE multicast data feeds. For more information on receiving Multicast PITCH through any of these providers, reach out to the vendor contact noted in the Extranet Providers section of the Connectivity Manual.

### Bandwidth Recommendation

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

## Support

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

## Revision History

| Document Version | Date | Description |
|---|---|---|
| 1.0.0 | 07/29/22 | Initial version. |
| 1.0.1 | 09/09/22 | Updated Production and Certification Environment Configuration sections. Updated `OOF Symbol Mapping` message, OOF Symbol Mapping Message Type, and OOF Symbol Mapping Example Message sections. |
| 1.0.2 | 10/20/22 | Added Time Offset to `OOF Symbol Mapping` message. `OOF Symbol Mapping` messages are included in spin responses and will be disseminated before `Complex Instrument Definition Expanded` messages. `OOF Symbol Mapping` and `Complex Instrument Definition Expanded` messages can be sent as a sequenced or unsequenced message. |
| 1.0.3 | 01/19/23 | Updated effective date for Options on Futures (effective 07/10/23). |
| 1.0.4 | 06/28/24 | Updated OOF Symbol Mapping Options on Futures Name description example and OOF Symbol Mapping example message. |
| 1.0.5 | 11/04/24 | Updated Unit/Product distribution based on underlying futures product. Clarified Options on Futures Name field description in `OOF Symbol Mapping` message. Added two new Matching Units, plus new port and IP information for Matching Units 2-4 (effective 02/03/25)​. |
| 1.0.6 | 01/15/25 | Updated with Cboe Titanium branding. |
| 1.0.7 | 01/05/26 | Noted in Spin Servers : a `Time` message will be sent as the last message in a Spin if the last `Time` message sent on a Spin is older than the last received time from the internal market data producers. |
| 1.0.8 | 01/05/26 | Updated Feed Hours and System Restart to reflect the new time that persisted orders are added back into the order book. |
| 1.0.9 | x/x/26 | Updated Time description in `Time` and `Time Reference` messages. |