FCX FIX Specification v1.0.0

Market data and order entry interfaces of the FCX exchange.

1. Introduction

FCX is an exchange for binary event contracts. A contract normally settles at 0 or 100. If the event is cancelled or cannot be resolved, FCX settles the contract manually at a fair price from 0 to 100, for example the VWAP (6.5).

FCX runs two FIX gateways:

• Market data gateway. Exchange status, instrument discovery, instrument status, order book and trades. The message structure follows the CDNA Fully Collateralized Exchange FIX Specification 4.3, section 5, so a client already integrated with CDNA market data needs few changes. Section 9 lists the differences.
• Order entry gateway. Orders, cancels, replaces, execution reports and positions. This interface is FCX's own.

Every instrument is the "Yes" side of one proposition. There is no "No" instrument: to buy No at price P, sell Yes at 100 − P. A market that can end in a draw has one instrument per outcome: a 3-way moneyline is three instruments (home, draw, away). No instrument settles as a tie.

2. Conventions

3. Gateways and sessions

Each gateway has its own host. Connect over AWS PrivateLink TBD; nothing is on the public internet. FCX gives you the hosts, the CompIDs, and an API key with its secret.

3.1 Standard header

Every message on both gateways starts with this header. On messages from FCX, 49 and 56 are swapped.

Header tags not in this table are not used: 50, 57, 115, 116, 128, 129, 142 to 145, 90, 91, 212, 213, 347, 369, 627 to 630. FCX ignores them and does not send them. Each session is one firm; there is no third-party routing (115, 128).

3.2 Standard trailer

Signature (89) and SignatureLength (93) are not used. A message with a wrong 9 or 10 is dropped without a reply, as in standard FIXT 1.1.

4. Logon and authentication

Both gateways use the CDNA logon signature, which is the Crypto.com FIX digital signature: HMAC-SHA256 over the sequence number, the key and a nonce. A client that already logs on to CDNA can reuse its code.

4.1 Logon tags

4.2 Signature

1. Build the string "public/auth" + MsgSeqNum + ApiKey + Label + Nonce. There are no separators.
2. Label is system_labelFCX on the order entry gateway. It is empty on the market data gateway.
3. MsgSeqNum is tag 34 in decimal. Nonce is tag 96, exactly as sent.
4. Compute HMAC-SHA256 of the UTF-8 string. The key is the UTF-8 bytes of your API secret, as issued.
5. Put the result in tag 554 as lowercase hex (64 characters).

Test vectors (demonstration values only):

ApiKey   fcx-demo-key
Secret   demo-secret
34       1
96       1791469800000

Order entry  signed string  public/auth1fcx-demo-keysystem_labelFCX1791469800000
             554            6531aa33213112601b883adea536eefddfe04b7484f7d39729b54c33c250e76a
Market data  signed string  public/auth1fcx-demo-key1791469800000
             554            4c84678e7484099de725266416ca1cf8427fab02dbd630f2c9851094adffc9b8

Python reference:

import hashlib, hmac, time

def logon_fields(api_key, secret, seq_num, label, heart_bt_int=30):
    nonce = str(int(time.time() * 1000))
    signed = f"public/auth{seq_num}{api_key}{label}{nonce}"
    sig = hmac.new(secret.encode("utf-8"), signed.encode("utf-8"), hashlib.sha256).hexdigest()
    return {553: api_key, 554: sig, 95: len(nonce), 96: nonce, 98: 0, 108: heart_bt_int, 1137: 9}

4.3 Rules

• The nonce must be within 30 seconds of FCX time, ahead or behind. Use NTP.
• FCX refuses a second logon with the same key and nonce inside that window, even with a new sequence number.
• A read-only key can log on to the market data gateway only.

4.4 Refused Logon

FCX replies with Logout (35=5), a 58 text and SessionStatus (1409), then closes the connection. A refused authentication says 58=Logon not authenticated and not which check failed.

A Logon with 1137 missing or not 9, or with 95 missing, also gets Logout (35=5). Its 1409 value is TBD (FCX-107).

A Logon that breaks the dictionary gets Logout (35=5) with no 1409. Its 58 names the tag. For example, 35002 not 0 or 3 gets 58=Invalid Logon message: Value is incorrect (out of range) for this tag, field=35002, and 6867 not Y gets the same text with field=6867.

5. Prices and quantities

6. Market data gateway

A typical session:

1. Log on. FCX sends Trading Session Status (h) at once.
2. Send Security List Request (x) with 559=4, 263=1 and 10300=Y. FCX sends the list (y), subscribes you to status (f) for each instrument, and then sends a Security Definition (d) for each new or changed instrument.
3. Send one Market Data Request (V) for each instrument you want to watch.

6.1 Symbology and instrument blocks

Each instrument has one Symbol(55), its instrument code. The symbol is unique across all instruments, live or settled, and does not change for the life of the instrument. A symbol is never re-used: after the instrument settles, no other instrument gets its symbol. FCX tells you that an instrument has settled with a Security Status 326=50.

• Product code (1151): the type of market, for example ITF_TEN_TW (ITF tennis, tournament winner). Many instruments share one product code.
• Instrument code (55): one outcome of one fixture. It is the product code, then the parts that the product defines, joined by _. Each product sets its template in its product filing.
• Example, ITF_TEN_TW_{YYMMDD}_{DRAWID}_{PLAYERID}: ITF_TEN_TW_261025_D0004567_P01234 is the last scheduled event date, the draw id and the player id.

Structure of ITF_TEN_TW_261025_D0004567_P01234:

One draw with many players gives one instrument per player. The instruments share every part except the last:

• Do not parse the symbol to get its parts. Each product has its own template, and new products add new templates. Only these parts have tags of their own: the product code (1151) and the contract date (200). 60013 is the outcome label, not an id. The event is in the Underlying block (6.1.4) and 871=99. Other parts, such as the draw id and the player id, are only in the symbol.
• Treat the symbol as an opaque string. Its length differs by product; the example has 33 characters.
• Other products (for example a moneyline) get their templates in their own product filings TBD.

6.1.1 Instrument block

6.1.2 Instrument Extension block

Event metadata (871=99). JSON with the same envelope as CDNA event metadata V3.0 (CDNA): eventCode, eventName and an eventMetadata list of codes. The code list is FCX's own. It works for any kind of event, not only sports. For each CDNA code and its FCX code, see 9.1. Each instrument carries its event, market and outcome data. Group events on 458 or eventCode, markets on PREDICT_MARKET_ID.

• Entries sorted by code. Keys exactly eventPropertyTypeCode and eventPropertyValue. All values are trimmed strings. Datetimes YYYY-MM-DDThh:mm:ss+00:00, UTC.
• A required code with no value yet is sent as TBD, for example before the market's event is listed. eventCode and 458 are the event's code as soon as the market names its event.
• eventCode = 458, one per event. eventName is display only, and not unique. The outcome label is in 60013.
• FCX ids: eventCode, PREDICT_MARKET_ID, PREDICT_OUTCOME_ID. FCX generates them when it lists the market. Data provider ids: ID_PROVIDER and PROVIDER_*.

Classification. Four levels place each event in a tree, from broad to narrow. The same codes apply to every category.

Example paths: Sports › TENNIS › ITF M15 › M15 Monastir › Bertrand vs Arce Fernandez. Economics › Interest Rates › US Fed Rate › Dec 2026 FOMC › Rate decision.

Event

Market

Outcome

Two-way markets (ML). One instrument, the Yes = Home. No = sell the Yes (section 9); it has no instrument and no outcome id. The Yes side does not change after listing. Settlement in 6.5.

Example: ITF_TEN_ML, Yes = Robin Bertrand to win.

{"eventCode": "5f1c2d8e-3b4a-4c6f-9a2e-7d1b0c3e4f51",
 "eventName": "Robin Bertrand vs Mario Arce Fernandez",
 "eventMetadata": [
  {"eventPropertyTypeCode": "AWAY_PARTICIPANT",        "eventPropertyValue": "Mario Arce Fernandez"},
  {"eventPropertyTypeCode": "EVENT_DATE",              "eventPropertyValue": "2026-10-21T12:00:00+00:00"},
  {"eventPropertyTypeCode": "FEED_TYPE",               "eventPropertyValue": "SINGLES"},
  {"eventPropertyTypeCode": "HOME_PARTICIPANT",        "eventPropertyValue": "Robin Bertrand"},
  {"eventPropertyTypeCode": "ID_PROVIDER",             "eventPropertyValue": "INFRONT"},
  {"eventPropertyTypeCode": "NAME",                    "eventPropertyValue": "Robin Bertrand vs Mario Arce Fernandez"},
  {"eventPropertyTypeCode": "PARTICIPANT",             "eventPropertyValue": "Robin Bertrand"},
  {"eventPropertyTypeCode": "PREDICT_CATEGORY",        "eventPropertyValue": "Sports"},
  {"eventPropertyTypeCode": "PREDICT_CONTRACT_TYPE",   "eventPropertyValue": "Moneyline"},
  {"eventPropertyTypeCode": "PREDICT_EVENT_TYPE",      "eventPropertyValue": "Game"},
  {"eventPropertyTypeCode": "PREDICT_MARKET_ID",       "eventPropertyValue": "b2e7a9c4-6d13-4f8a-8c5e-1a9f3d7b2c60"},
  {"eventPropertyTypeCode": "PREDICT_MARKET_TYPE",     "eventPropertyValue": "Game Line"},
  {"eventPropertyTypeCode": "PREDICT_OUTCOME_ID",      "eventPropertyValue": "e8d4c1b7-2a96-4e3f-b5d8-9c7a1f2e3d48"},
  {"eventPropertyTypeCode": "PREDICT_OUTCOME_TYPE",    "eventPropertyValue": "Home"},
  {"eventPropertyTypeCode": "PREDICT_PERIOD_TYPE",     "eventPropertyValue": "Full Game"},
  {"eventPropertyTypeCode": "PROVIDER_AWAY_ID",        "eventPropertyValue": "3c9e5a71-8f24-4b6d-a1e3-6b2d8f4c9a17"},
  {"eventPropertyTypeCode": "PROVIDER_EVENT_ID",       "eventPropertyValue": "7a3f1e92-4c58-4d0b-9e6a-2f8c5b1d3e74"},
  {"eventPropertyTypeCode": "PROVIDER_HOME_ID",        "eventPropertyValue": "d41b6c28-9e73-4a5f-b2c8-5e1a7d9f3b06"},
  {"eventPropertyTypeCode": "PROVIDER_PARTICIPANT_ID", "eventPropertyValue": "d41b6c28-9e73-4a5f-b2c8-5e1a7d9f3b06"},
  {"eventPropertyTypeCode": "PROVIDER_TOURNAMENT_ID",  "eventPropertyValue": "9b6d2f40-1a87-4e3c-8d5b-4c7e9a2f1b83"},
  {"eventPropertyTypeCode": "SECTION",                 "eventPropertyValue": "M15 Monastir"},
  {"eventPropertyTypeCode": "SERIES",                  "eventPropertyValue": "ITF M15"},
  {"eventPropertyTypeCode": "TOPIC",                   "eventPropertyValue": "TENNIS"},
  {"eventPropertyTypeCode": "VENUE",                   "eventPropertyValue": "Magic Hotel Skanes Family Monastir, Monastir"},
  {"eventPropertyTypeCode": "VERSION",                 "eventPropertyValue": "1.0"}
 ]}

6.1.3 Trading rules

Sent in each Security List entry and each Security Definition (FCX-179).

The TickRules group is an FCX extension: CDNA has one tick size. Trading opens at the first Open Time (871=500, 6.1.2); there is no separate first trading time.

The bands set the tick of each price. A band holds its start price; the last band also holds its end. A valid order price is a multiple of the tick of its band and strictly between 0 and 100 (section 5); 0 and 100 are band edges only. Default, no fine step: one band, 0 to 100 step 1.00. Example with a fine step within 5 cents of each edge: 0 to 5 step 0.10, 5 to 95 step 1.00, 95 to 100 step 0.10. The width of the fine region is set per instrument.

6.1.4 Underlying block

The underlying of an instrument is its event, for example a match.

6.2 Trading Session Status Request (35=g) and Trading Session Status (35=h)

FCX sends an h after each successful logon, and to every session when the exchange status changes. You do not need to subscribe.

6.3 Security List Request (35=x) and Security List (35=y)

FCX answers with one or more y messages:

The list comes from the FCX database, so it is complete at any time, also just after a gateway restart. An instrument with no valid tick setup cannot take orders, so it is not listed until the setup is fixed. If FCX cannot read the database, you get one y with 560=4 and no entries: send the request again.

An x with 263=1 replaces your x subscription with the same 320, also when the new one matches nothing; 263=2 with that 320 ends it. An x with 263=0 leaves your subscriptions as they are. x and c keep separate 320s: a c never ends an x subscription.

6.4 Security Definition Request (35=c) and Security Definition (35=d)

The d carries 320, 323 SecurityResponseType (1 accepted, 5 rejected, 6 not found), the blocks and trading rules from 6.1, and 15 Currency. With 263=1, you receive a new d when that instrument changes. A c covers one instrument; to receive new instruments, send x with 263=1 (6.3). A c with 263=0 or 1 and no 55 gets Reject (3) with 373=1; an unknown 55, or an instrument with no valid tick setup, gets a d with 323=6. If FCX cannot read the database, the d has 323=5 and 58 Text.

As for x (6.3): a c with 263=1 replaces your c subscription with the same 320, 263=2 ends it, and 263=0 leaves it. An x never ends a c subscription.

6.5 Security Status Request (35=e) and Security Status (35=f)

The f:

FCX maps its instrument states to 326: Open to 17; Halted and Suspended to 2; Inactive to 18; Resolved and settled to 50. A resolved instrument reports 50 from its own state, not only through the settled list of 10302. When an instrument settles, FCX ends the subscription.

6.6 Market Data Request (35=V)

A new request for the same instrument and entry types replaces the old one. Subscriptions end when the instrument settles.

6.7 Market Data Snapshot (35=W) and Incremental Refresh (35=X)

FCX answers a subscribe with one W that holds the current state, then sends X messages for each change.

Trade entries are anonymous: they name no account or order of either party. When your account is a party to the trade, you also get an Execution Report (8) on order entry (7.5). Its 527 SecondaryExecID is the 278 of the trade entry.

If a book has no change for 30 seconds, FCX sends an empty X (268=0) for it, with the 262 of the subscription. Use it to confirm the subscription is alive.

6.8 Market Data Request Reject (35=Y)

The Y carries 262, 281 and 58. It has no 55, as in standard FIX 5.0 SP2; match the reject to your request by 262.

6.9 Limits and recovery

7. Order entry gateway

Each message must carry an Account (1) that FCX has assigned to the session. Use a trading key to log on.

End customers. FCX opens one account for each end customer that an FCM or ISV registers (FCX-124). The FCM or ISV sends that account in 1, and its session can use the accounts of all its end customers. A new order or replace needs the end customer's KYC to be approved. A cancel does not. A revoked approval can still trade for up to 300 seconds. A new approval counts within 5 seconds. FCX does not read a Parties block on orders. A market maker sends its own account.

7.1 Instrument block

Identify the instrument by Symbol (55), as in market data (FCX-193). FCX does not read 311, 202, 541 or 20001 on inbound messages.

Outbound messages carry 55, 48 and 22=8.

7.2 New Order Single (35=D)

7.3 Order Cancel/Replace Request (35=G)

Changes price or quantity of a resting order. Tags as for D, plus 41 OrigClOrdID (Y), the ClOrdID of the order to replace. The replacement gets a new OrderID (37). Track orders by ClOrdID. If FCX refuses a G with an Order Cancel Reject (35=9), the original order is unchanged and keeps working, including when the refusal is a limit (102=99). FCX replaces only an order of the account in 1, as for F (7.4). 37 OrderID (N): as for F, it must be the OrderID of the order that 41 names, else 102=1.

7.4 Order Cancel Request (35=F)

FCX cancels only an order of the account in 1. If 37 or 41 names an order of another account, or no order, FCX sends 35=9 with 102=1 and cancels nothing. The reply is the same in both cases, so it does not show whether the order exists.

An F or G that names an order FCX has received but not yet accepted waits until FCX accepts it and then runs as sent. If FCX refuses the order instead, the F or G gets 35=9 with 102=1. If FCX never learns the order's outcome, it gets 35=9 with 102=99 and 58=Order pending; send again: send it again after the New. A 37 of NONE on the F or G, copied from the pending report, is read as absent: 41 names the order.

7.5 Execution Report (35=8)

Voided trade. FCX can void a single trade, manually, for compliance (FCX-200). Each side gets an 8 with 150=H, 19 ExecRefID = the 17 of the original fill, 527 = the FCX trade id, and the reason in 58. On this report 14 and 6 leave out the voided fill. The voided quantity does not go back into the book: it is in 84 CxlQty, which holds everything that will not trade, voided and cancelled alike, so 38 = 14 + 151 + 84 on it. An order that filled 4, had its residual cancelled and then had that fill voided reads 14=0, 151=0, 84=10. 39 is then 1 if 14 > 0 and 151 > 0, 0 if 14 = 0 and 151 > 0, and 4 if 151 = 0. An order that is still working keeps trading, and its next Execution Report counts the voided fill again, because the matcher's running total is not corrected yet (FCX-100). An Order Status Request (7.10) reads the voided fill out, and is the reliable answer until that lands. FCX also sends an unsolicited AP (7.9) and a market data trade delete (6.7). The three are separate reports, each carrying the whole state it reports, and FCX promises no order between them. A whole market is never voided; see section 1.

7.6 Order Cancel Reject (35=9)

Tags 37, 11, 41, 1, the instrument block (7.1), 39, 434 (1 for F, 2 for G), 102 and 58. If 55 names no instrument, the block is only the 55 of the request, and 102 is 1: such a request names no order either, so the reply is the one an unknown order gets, with 58=Unknown symbol (FCX-282). 39 is the current status of the original order, for example A (Pending New), 0, 1, 2 or 4. With 102=1, 39 is 8, so an order of another account gives nothing away (FCX-185). With 102=0 on the cluster order path, 39 is the last status FCX holds for the order, final or not: A, 0 or 1 when the report that ended the order is still to come. On the legacy order path the reject can arrive before the order's reports, so 39 is the order's final status, or 2 when none is known yet; this rule goes with the legacy path (FCX-77). A 35=F or 35=G whose 55 does not match the order can be refused as too late (102=0) while the order is still live: FCX does not compare 55 with the order. 102 values are in 7.8. After any 35=9, the original order is unchanged. After FCX reloads an order from its stored row, 39 comes from that row, and an order reduced without a fill reads 1.

7.7 Business Message Reject (35=j)

Sent for a price with more than 2 decimal places: 45, 372, 379 (ClOrdID), 380=18, 58. Sent for an unsupported MsgType (section 8): 45, 372, 379 when the request has an id, 380=3, 58.

7.8 Reject reasons

OrdRejReason (103) is on an Execution Report (7.5); CxlRejReason (102) is on an Order Cancel Reject (7.6). Tag 102 has fewer values than 103, so a cause with no 102 of its own is 99, with the detail in 58.

7.9 Positions (35=AN, AO, AP)

Request For Positions (AN): 710 PosReqID, 724 PosReqType (0 positions), 1 Account, 715 ClearingBusinessDate (FCX ignores the value) and 60 TransactTime, required; instrument block optional. With no 55, 48, 311, 202 or 541, FCX reports every instrument; with 55, only that instrument. An unknown 55, a 48 that does not match 55, or a 48, 311, 202 or 541 without 55 gets 728=99 (FCX-193). 1 takes the place of the Parties block. A session sees only its own positions: a market maker its own account, an FCM or ISV the accounts of its end customers (section 7). Positions of other participants are only on the drop copy gateway (FCX-208). FCX answers with AO (710, 721 PosMaintRptID, 727 TotalNumPosReports, 729 PosReqStatus 0 completed or 2 rejected, 728: 0 valid, 2 no positions, 3 not authorized (1 is unknown or not an account of the session; 58 unauthorized account in both cases, so the reply does not show whether the account exists), 99 error; 55, 48 and 22 as the AN sent them), then one AP for each open trade of the account (a position entry), not one per instrument.

On every AP, unsolicited or an answer to an AN, 715 ClearingBusinessDate is the New York date of the posting time, rolled to the next day at 18:00 New York time (America/New_York, EDT in summer and EST in winter).

When an instrument settles, FCX sends an unsolicited AP for each account with a position in it (FCX-195): 325=Y, 721, 715 ClearingBusinessDate, 1, the instrument block, 730 SettlPrice (the same as 31 on 35=f), 731=1 (Final), 702/703 DLV with 704/705 the settled quantity, and 753/707/708 SETL with the cash paid, in USD. One AP per account, not per lot or per side: 704 or 705 is the net quantity just before settlement, and 708 is the cash credited for every settled lot, gross of any settlement fee (a fee is on its own BA, 7.12). The Parties block (453) names the clearing org, the exchange and the account, as on the answer to an AN. FCX also sends an unsolicited AP to each side of a voided trade (FCX-200): the same shape without 730, 731 and the 753 block, because a void pays nothing, and 702/703 TOT with 704/705 the net position the void leaves behind. A void whose position clearing did not state sends the Trade Cancel alone, rather than an AP reading flat. It sends one to each side when operations transfer a position between accounts (FCX-137). A transfer is not a trade: it sends no Execution Report and no market data trade. FCX does not send an AP after each fill; each fill is in an Execution Report (35=8, 7.5). Cash balances are not positions: see 7.12.

7.10 Order Status Request (35=H) and Order Mass Status Request (35=AF)

Use these to rebuild the state of your orders when resend cannot (FCX-198). FCX answers only for orders of the account in 1. 14 and 6 leave out a voided fill, so an order that filled and then had a fill voided reads 39=4 with 151=0, the same as its Trade Cancel (7.5). Only a void does that. An order you reduced and then filled reads 39=2 with 38 the quantity after the reduction, as on its Execution Reports, so 14 equals 38 there.

7.11 Limits and recovery

7.12 Cash balances (35=BB, BG, BA)

Collateral Inquiry (BB): 909 CollInquiryID and 1 Account, required; 263 SubscriptionRequestType absent or 0. A session asks only for the accounts it holds (section 7). The account that holds the collateral reports: a market maker its own account; an FCM or ISV its own account, which holds the collateral for all its end customers (FCX-137). An end customer has no balance of its own, so a BB that names an end-customer account is refused, and 58 names the FCM account to ask for instead. Until FCX-99 books a fill's cash on the collateral account, that FCM figure is short of the margin and fees of its end customers. FCX answers with Collateral Inquiry Ack (BG): 909, 945 CollInquiryStatus 0 accepted or 4 rejected, 946 CollInquiryResult (0 successful; 8 a subscription was asked for; 9 not an account of the session, or an end-customer account; 99 unknown account, 1 missing, or a read error), 911 TotNumReports 1 when accepted, 1, and 58 on a refusal. A refused BB gets no BA.

One Collateral Report (BA) follows an accepted BB: 908 CollRptID, 909, 60 TransactTime, 910=3, 1, 15 Currency, 715 ClearingBusinessDate, and three amounts in that currency with two decimals. The ledger holds USD only (section 5), so 15 is USD; an unsolicited BA names the asset the posting moved. 900 TotalNetValue is everything the account owns: cash, today's unsettled movements and the collateral held. 901 CashOutstanding is the part held as collateral against open positions. 899 MarginExcess is the part free for new orders and withdrawals, so 900 = 901 + 899. 899 and 901 are each rounded half-up to two decimals and 900 is the sum of the two rounded amounts, so the identity holds on the wire. Snapshots only: a client that wants a fresh balance sends another BB.

FCX also sends an unsolicited BA, 325=Y and no 909, when a balance changes outside order flow: a deposit, a withdrawal, a charge, a trading or admin fee, and a reconciliation. One report per account per posting, whatever sub-accounts it moved. A fill sends no BA: the fill is on the Execution Report (7.5), and the margin it posts is not reported on its own. An offline client gets the unsolicited reports by resend (7.11). Settlement (FCX-195) and a trade void (FCX-200) do not send one yet, although both are built: clearing writes the payout and the refund straight to the ledger. A position transfer (FCX-137) will send one when it lands.

8. Not supported

Order types not supported: market, stop, pegged, Day, GTD, iceberg, minimum quantity.

9. Divergence from CDNA

For clients that already connect to CDNA. Market data follows CDNA 4.3 except for these points. Where CDNA gives a tag a meaning other than standard FIX 5.0 SP2, FCX uses the standard meaning. Order entry is FCX's own interface.

9.1 Event metadata codes (871=99)

For clients that parse CDNA event metadata V3.0. Each CDNA code and the FCX code that replaces it. A code not in this table has the same name and meaning in both. The FCX codes are in 6.1.2.

Appendix: open points and build status internal, remove before sending to clients

Decisions still open

Not built yet: the spec states the target

Tickets marked "blocks" must be done before FCX-181 publishes this document.

Sources: epic FCX-116 and tickets FCX-125 to FCX-131, FCX-179 to FCX-182, FCX-192; FCX-77; FCX-99; FCX-101; FCX-107; FCX-110; FCX-124; FCX-132 (merged, #92); FCX-133; FCX-136; FCX-137; FCX-184 to FCX-187; FCX-193 to FCX-200; FCX-206; FCX-217. FCX-186 is fixed on main (FCX-113, #96).