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

CFE participants may use CFE Multicast PITCH to receive real-time depth of book quotations and execution information direct from CFE. The Multicast PITCH protocol is more timely than the 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 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 Multicast PITCH feeds depending on their location and connectivity to CFE.

The PITCH feed starts on Sunday at approximately 10:30 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.

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 FC and FD 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 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 Multicast PITCH feed message flow between CFE and a participant feed handler that is listening to the A and B instances of two units:

Products are separated into units by a published distribution. Product distribution will not change intra-day. CFE does, however, 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.

CFE has implemented a symbol mapping mechanism (Futures Instrument Definition message) which maps each specific simple futures contract or spread instrument to a six character, ASCII Symbol. For example, the weekly VX11 contract expiring March 14, 2017 might be represented by the Symbol 0ab123. This symbol mapping significantly reduces the size of the 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 Multicast TOP feed.

Mapping occurs on a continuous basis on each unit's multicast feed. Futures Instrument Definition messages can be both un-sequenced and sequenced. Un-sequenced messages are sent from pre-market through the end of trading in a continuous loop that will complete approximately once every minute. 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.

Spread instruments may be occasionally created intra-day. In these cases, the Futures Instrument Definition 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 events available on the Multicast TOP feed, a downloadable file with current mappings is available via the CFE website.

Requesting delivery of missed sequenced data is achieved by establishing a TCP connection to a Multicast PITCH GRP port. This GRP port is specific to Multicast PITCH and is NOT shared with the 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=Accepted signals that the replayed messages will be delivered via the appropriate gap response multicast address. Any other Gap Response message Status code will indicate the reason that the request cannot be serviced.

Gap requests are limited in message count, frequency, and age by the GRP. Gap requests will only be serviced if they are within a defined sequence range of the current multicast sequence number for the requested unit. 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 acknowledgements or rejects will be delivered to users for every gap request received by the GRP. Users should be prepared to see replayed multicast data before or after the receipt of the gap response acknowledgement from the GRP.

A Spin Server is available for each unit. The server allows participants to connect via TCP and receive a spin of the inside book and symbols with limited trading conditions 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 (expanded, long and/or short), End of Day Summary, Futures Instrument Definition, Futures Variance Symbol Mapping, Trading Status, Settlement,Price Limits, Time Reference, and Time messages. Trading Status messages will be sent in spins for all symbols that are not S=Suspended, which results in at least one message for every symbol that has not been Suspended since system startup. Futures Instrument Definition 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.

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

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.

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 Gap Request Proxy (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 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.

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.

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 CFE FIX and BOE specs.

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.

The CFE Sequenced Unit Header message header is used for all CFE 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 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.

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. With the exception of Time messages, each PITCH message reflects the order addition, order deletion, order modification or execution of an order in the system.

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

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. It may also be sent on system startup (after daily restart) when there are no persisted GTCs or GTDs.

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

The Futures Instrument Definition message can be sent as a sequenced message or an un-sequenced message. It is sent as a sequenced message when the system starts up at the beginning of a trading session or an the instrument is created or modified during a trading day. A new sequenced message may be sent for a Symbol that does not visibly change any attribute. One un-sequenced Futures Instrument Definition message for each Symbol is also sent in a continuous loop, which completes approximately once every minute as part of the Periodic Refresh mechanism.

If the instrument is a spread (Leg Count > 0) then the message contains one or more repeating groups of leg definitions beginning at the field indicated by Leg Offset. There is a limit of 4 leg definitions.

The Leg Offset field is provided to support adding additional fields to this message preceding the Leg definitions.

The Report Symbol field will contain either the weekly (e.g. VX01) or the monthly (e.g. VX) symbol for any simple futures contract. The Report Symbol will always contain the standard futures root symbol (e.g. VX) for all spread instruments.

The Futures Variance Symbol Mapping message is used to disseminate symbol reference data for S&P 500 Variance Futures (VA Futures) symbols. VA Futures symbol reference data are disseminated with both the Futures Instrument Definition and Futures Variance Symbol Mapping messages. The purpose of the Futures Variance Symbol message is to disseminate product-specific supplemental information for VA Futures symbols (i.e., Accrued Day Variance, Num Final Returns, and Num Elapsed Returns).

The Futures Variance Symbol Mapping message can be sent as a sequenced message or an un-sequenced message. It is sent as a sequenced message when the system starts up at the beginning of a trading session or if an instrument is created or modified during a trading day. A new sequenced message may be sent for a symbol that does not visibly change any attribute. One un-sequenced Futures Variance Symbol Mapping message for each symbol is also sent in a continuous loop, which completes approximately once every minute as part of the Periodic Refresh mechanism.

Futures Variance Symbol Mapping messages are included in a spin response.

The Price Limits message is sent out at the start of a session for products subject to price limits per the contract specifications. The Price Limits message does not signal whether price limits are in effect for that symbol; it simply provides those values for when they are in effect. If multiple Price Limits messages are received for the same Symbol, the most recent values will override the previous values.

Price Limits messages are included in a spin response.

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.

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

Reduce Size messages are sent when a visible order on the CFE book is partially reduced.

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.

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.

The Trade message provides information about executions that occur off of the CFE book (such as ECRP/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.

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 and Transaction End messages. 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.

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.

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.

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). For VX and VXM futures products, the system will begin disseminating an intermediate indicative price update (Issue=i) at 2:59:05 p.m. CT (following the first interval of the VWAP calculation) that will be sent every five seconds, leading up to the receipt of the indicative daily settlement price (Issue=I).

The Open Interest message is sent to communicate a symbol's open interest, usually for the prior trading date. This message will be sent when open interest information is made available to CFE and may be sent multiple times if there are changes to the open interest for a symbol. The open interest is also populated in the End of Day Summary message.

The End of Day Summary message is sent immediately after trading ends for a symbol. No more Market 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, ECRP, and Derived 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. Trade At Settlement products). 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.

The Trading Status message is used to indicate the current trading status of a Futures contract. A Trading Status message will be sent whenever a security's trading status changes. If a Trading Status message has not been received for a symbol, then the Trading Status for the symbol should be assumed to be S=Suspended. The following summarizes the Trading Status values in the CFE system:

• S = Suspended. A contract is in a suspended state when the associated product is closed and not accepting orders.
• Q = Accepting orders for queuing. Queuing state is used during the Pre-Open for all products. It is also used for spread instruments that may not be tradeable due to Threshold Width.
• T = Trading. Used for both Extended and Regular Hours trading.
• H = Halt state. This state is used for Supervisory Halts initiated by the Trade Desk. Orders are not being accepted in this state.

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.

The following messages are used for initializing a TCP/IP connection to the Gap Request Proxy (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.

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.

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.

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.

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.

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

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 previously in Login 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 previously in Login Response Message Fields.

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

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 Gap Request Proxy and Message Retransmission for more complete details regarding Sequence specification as well as buffering requirements.

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

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

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.

The following diagram shows the exchange of messages over time between a participant and CFE's 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. Trading Status message may be sent at the beginning of the spin.

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

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

Each of the following message types must be wrapped by a sequenced or unsequenced unit header as described in CFE Sequenced Unit Header Message Fields. Note that in the following examples, each byte is represented by two hexadecimal digits.

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.

The following table describes the CFE symbol distribution across units.

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.

The following tables describe the unit distribution across the CFE 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.

The following table describes the CFE symbol distribution across units.

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.

The following table describes the unit distribution across the certification CFE 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.

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 redistribution 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 CFE Connectivity Manual under Extranet Providers.

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.

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

Customers are strongly encouraged to capture their own test data from the Certification environment to ensure that their systems can correctly decode the PITCH feed and all available message types. To assist firms with their own testing a PITCH sample (taken from the Certification environment) is made available at the link below. Cboe does not guarantee that all message types will appear in test data and cautions that canned test data will be updated infrequently and may not fully reflect the current specification.

CFE PITCH Test Data (last updated 04/02/2020)