# Kronos X Member Technical Handbook Revision 2.22, 21 October 2026, covering Kronos X v2.0 "Pacifica". The trading manual for venue members: what every order type does, exactly when it rests, trades, is rejected or is cancelled, how margin and fees are computed, and what the venue does to your orders without being asked. Companion documents: the member API reference (wire formats), the complete API code reference (every code), and the FIX rules of engagement. This handbook is normative about BEHAVIOUR. Where an example shows a number, it is computed the way the engine computes it: exact integers, no floating point. --- ## 1. The trading model in one page - **You are the member.** The venue knows your firm, not your clients. Every order carries `clientUid`, an opaque reporting identifier you choose, and the venue keeps exact per-client sub-positions for reporting. Risk, margin and liquidation are computed on your MEMBER net position. - **Three market kinds, two modes.** Perpetual futures (`PERP`: margined, funded, no expiry: the crypto perpetuals every 8 hours on a UTC grid, the equity index, gold, silver, oil and FX perpetuals once per day from an index-VWAP window, see the `funding` block on `GET /v1/instruments` and Member API section 7), spot (`SPOT`: fully prefunded delivery, no leverage, no funding) and barrier knock-out contracts (`BARRIER`, section 6). Every market trades in one mode, shown on `GET /v1/instruments`: `ORDER_BOOK` (central limit order book: same order model, same book, same API) or `RFQ` (request-for-quote: no book at all, section 6). Barrier markets are always RFQ. - **Price-time priority.** Best price first; at equal price, earliest accepted first. Fills are exact fixed-point arithmetic on the price and quantity grids; nothing is ever rounded. - **Ack after durable.** Every acknowledgement you receive is post-journal: when you have an ack, the venue cannot forget the order, even on power loss. - **Deterministic.** Same command sequence in, same state out, byte for byte. Every dispute about a figure is answerable by reproducing it from the verified snapshot with the binary version that produced it (Netting and Unsolicited Flow Statement, section 6). ## 2. Instrument mechanics you must respect Read `GET /v1/instruments` at startup; never hard-code these. | Property | Meaning | If violated | |---|---|---| | `mode` | `ORDER_BOOK` or `RFQ`. RFQ markets have no order book (section 6). | 2022 / 2023 | | `tickSize` | Price grid, quoted per base-asset unit. Every price must be an exact multiple. | 2002 | | `qtyStep` | Quantity grid in base-asset units. Every qty must be an exact multiple. | 2002 | | `minQty` | Smallest accepted quantity (equals `qtyStep` on every current listing). | 2002 | | `minNotional` | Smallest accepted order value, `price x qty`. | 2028 | | `priceBandBps` | Max distance from the mark for a LIMIT order's price, checked at placement and on amend against the CURRENT mark. Never applied to a conditional order: the trigger price and the `limitPrice` of a STOP_LIMIT or TAKE_PROFIT_LIMIT are not band-checked at placement, on amend or at activation (section 3.3). Derive resting-order offsets from this field and a live mark at runtime; a hard-coded price drifts out of the band as the mark moves and draws intermittent 2003s. | 2003 | | `marketMaxSlippageBps` | Protection collar for market orders (section 3.2). | see 3.2 | | `maxOrderNotional` | Per-order size cap in settlement-currency notional (decimal string; absent or null where not set). One single message's `price x qty` at its effective price: limit price for priced orders, current mark for market orders and RFQ creation, quoted entry for quotes. `reduceOnly` NOT exempt. Takes precedence over `maxOrderQty` when set. | 2013 | | `maxOrderQty` | Legacy base-unit per-order cap, a fat-finger guard, not a risk capacity limit. Applies only where no `maxOrderNotional` is set; informational otherwise. | 2013 | | `maxPositionNotional` | Position cap in settlement-currency notional (decimal string; absent or null where not set). The worst-case net position (net plus same-direction working orders plus the order) is valued at the CURRENT mark. Takes precedence over `maxPositionQty` when set. | 2011 | | `maxPositionQty` | Legacy base-unit position cap. Applies only where no `maxPositionNotional` is set; informational otherwise. | 2011 | | `riskTiers` | Margin schedule by notional (section 7). | n/a | | `maxLeverage`, `leverageMode` | `FIXED` with a value, or `TIERED`. | n/a | | `fundingIntervalHours`, `funding` | 8 on the crypto perps (`funding.schedule` GRID), 24 on the daily-settled tradfi perps (`funding.schedule` LOCAL_DAILY: zone, snapshot time, VWAP window; Member API section 7). | n/a | | `tradingHours` | `CONTINUOUS` on every listing without an auction schedule: no daily open, close or auction; interruptions are the suspension, halt or removal, the circuit breaker and the reduce-only and post-only sessions (section 8); `SCHEDULED` on a SECURITY market with an auction schedule (Member API section 6j): its hours are the `auction` block of the row and the phase in force is `tradingPhase`. Open set. | n/a | **Trading hours.** Every market on the Platform other than a SECURITY market with an auction schedule (Member API section 6j) trades continuously, 24 hours a day, every calendar day of the year, weekends and public holidays included. There is no daily open, close or auction on those markets. Trading in a market is interrupted only by a suspension, halt or removal under Section 11 of the Rulebook (including a venue-wide suspension), by the circuit breaker under Section 13 of the Rulebook, or by the reduce-only and post-only sessions described in this document (section 8). The Company operates no daily or weekly closure. The only scheduled interruption is the venue's standard maintenance window, Saturday 02:00 to 06:00 UTC, published under this section as a standing exception to the trading hours; maintenance inside it is announced at least 48 hours in advance on the Website and in the member portal. Most releases are rolling and need no window; a release that needs one keeps the restart contract of section 10.7 of the Member API reference (advisory frame, close 1001, 503 with Retry-After, FIX Logout, cursor backfill). A release that requires the venue to stop is announced on the Website at least five Business Days before the window (Business Day as defined in the Rulebook), naming the date, the start time in UTC and the expected duration. A scheduled closure outside that window is published on the Website in advance under this section with the notice the Rulebook requires for a material amendment; an unplanned stop is a suspension under Section 11 of the Rulebook. The current trading state of each market is published at all times on `GET /v1/status`, `GET /v1/instruments` and the `venueEvents` channel. Funding on perpetual contracts settles on the schedule published per market (an 8 hour UTC grid, or one local-time window per calendar day for the daily-settled markets) whether or not the underlying reference market is open. Daily allowances and daily flow statements are kept per UTC calendar day. A connection interruption during a software release (the venue restart advisory) is not a closure: orders, positions and contracts persist and the market resumes in the trading state it had. **Position caps are notional.** Where a market publishes `maxPositionNotional`, the 2011 check values your worst-case net position at the current mark price instead of counting base units, so every market carries the same dollar capacity and smaller markets no longer reach their cap first in a correlated move. Risk-reducing flow (`reduceOnly`, venue-initiated closes) is never blocked by the cap, and a position pushed above the cap by mark drift alone is never forced to reduce: the cap gates increases only, so new risk-increasing orders reject 2011 until the valuation is back under the cap. **Order caps are notional too.** Where a market publishes `maxOrderNotional`, the 2013 size check values each single message at its effective price instead of counting base units. One deliberate asymmetry with the position cap: `reduceOnly` orders are NOT exempt, because a fat-finger guard has to guard closes as well, so closing a large position may take several orders (batch order entry, section 5, sends up to 50 in one signed message). Venue-initiated closes (liquidation, ADL) are exempt. Independently of the published cap, one order's `price x qty` must also stay within the venue's exact-money range, `1000000000000000000` settlement-currency units, or it rejects 2013: an absolute ceiling that applies on every market, is not published per market, and sits orders of magnitude above every `maxOrderNotional` in force. It is what lets the venue represent every trade, fee and position update exactly, since a fill always executes at the RESTING order's own price. Its counterpart on the fill path is the `POSITION_SIZE_LIMIT` cancel reason. Neither is reachable at any tradable size. **Prices, quantities and money are exact decimal strings** on every surface (`"65000.5"`, never `65000.5`). Parse into a decimal type. A float will eventually cost you a reconciliation break. **A grid change is a re-listing (Member API revision 3.83).** The venue never changes the `tickSize` or the `qtyStep` of a listed market in place: every resting order and every open position is held on the market's grid, so the venue's listing controls refuse such a change on every market kind. A grid change is made only by RE-LISTING the market, announced in writing in advance (the market, the new values and the date). On the date the market is delisted (`STOP_TRADING` with reason `DELISTING` on `venueEvents`; every working and pending-trigger order cancelled with `INSTRUMENT_HALT`; new orders and amends `3006` from then on, reduce-only orders included, so close what you do not want final-settled before the date), open positions are final-settled at one close-out price (open barrier contracts within their terms; open RFQs stay but can no longer be quoted or accepted), and the market is listed again with the new values and an empty book, under the symbol and ISIN the announcement names. A resting order is never kept at the old granularity, moved onto the new grid or rounded. Nothing on the wire announces a re-listing before the date and no member surface serves an instrument id: key on the symbol, re-read `GET /v1/instruments` after the announced date and on any unexpected `2001`, `2002`, `3006` or `DELISTED` status, and carry no cached grid or book state across the date. `minNotional` and the other parameters may change in place; a new `minNotional` applies to new orders, amends and RFQs. ### Contract sizing and granularity Every quantity you send or receive is a **decimal number of base-asset units**: on `BTC-USD-PERP`, `"qty": "0.0014"` is 0.0014 BTC. Prices are quoted per base unit, so the notional of an order is exactly `price x qty` in the settlement currency. Integer quantity strings remain valid (`"2"` is 2 base units). Granularity is a property of the LISTING: each market publishes `qtyStep` on `GET /v1/instruments`, and every `qty` must be an exact multiple of it. A misaligned `qty` is not rounded, it is rejected (2002, quantity grid), at any decimal depth. `minQty` equals `qtyStep` on every current listing. The finest exposure any end client can hold is one `qtyStep`, so build your client-facing fractioning on the step, never finer. Every market also publishes `minNotional`, the smallest order value the venue accepts: an order or RFQ whose `price x qty` is below it (5 USD on every current listing except the barrier markets, where it is 100 USD since Member API revision 3.71) rejects with 2028. Priced orders are valued at their limit price, market-type orders at the current mark, and amends re-check the FULL amended quantity. Worked example on `BTC-USD-PERP` (tick 0.5, `qtyStep` 0.0001): buy 0.0014 BTC at 74000 is a 103.60 USD notional, accepted; the same step count at a 3000 mark would be 4.20 USD and reject 2028. Two closing-only exemptions apply: venue-initiated closes (liquidation, ADL) bypass the floor, and your own reduce-only orders within your reducible position bypass it too. To flatten a sub-floor residual yourself, send a reduce-only order of exactly the position size; a reduce-only order larger than your reducible position rejects with 2008, so never oversize the close. Spot markets (BTC-USD, ETH-USD, SOL-USD, BNB-USD, XRP-USD on the sandbox, Member API revision 3.50) trade on the same fractional `qtyStep` as the perpetual of the same underlying (0.0001 BTC, 0.001 ETH and BNB, 0.01 SOL, 1 XRP), so `price x qty` is your exact cash leg and `qty` your exact asset leg with exact math end to end. Barrier markets (Member API revision 3.71) size on the same fractional `qtyStep` as the perpetual of the same underlying (0.0001 BTC on BTC-USD-KO, 0.001 on the ETH, BNB, SP500, NDX100 and XAU knock-out markets, 0.01 on SOL, WTI and BRENT, 1 on XRP, EUR, GBP and JPY, and since Member API revision 3.75 0.001 on ZEC, US500 and US100, 0.01 on HYPE, TAO, XAG and USDJPY, 1 on DOGE and NEAR): the RFQ `qty` is a decimal number of base units on that step (integer strings stay valid), `minNotional` is 100 USD on every barrier market, and the floor applies at create (valued at the mark), on each quote (valued at the quoted entry price, so size with headroom for a quote below the mark) and on a close request (the contract's whole quantity valued at the mark): a contract worth less than 100 USD at the mark ends at its barrier, its take profit or its expiry, not by an early close. Earlier revisions listed the barrier markets in whole units; the sandbox re-lists them on the date venue operations announce, and production lists its barrier markets (as planned today those of BTC, ETH, SOL, BNB, XRP and JPY) so from the first day. The USD/JPY quanto (Member API revision 3.75, sandbox): on USDJPY-USD-PERP and USDJPY-USD-KO the price is the USD/JPY rate in yen per dollar (about 157) and `price x qty` is the USD notional: one unit pays 1 USD for each 1.000 of the rate (0.001 USD per tick of 0.001) at that fixed rate, never converted at the live rate, and quantities are on a `qtyStep` of 0.01 unit. Margin, fees, funding and barrier premiums compute on it exactly as on any other market; it is not the inverse JPY-USD-PERP, which stays listed beside it on 1,000 JPY units. ## 3. Order types Every order needs: `symbol`, `side`, `type`, `tif`, `qty`, `clientUid`, and a `clOrdId` you generate. Unknown fields are REJECTED (2017), never ignored. ### 3.1 LIMIT A price you will not cross. Trades immediately against anything at or better than your price, then the remainder rests in the book. ```json { "symbol": "BTC-USD-PERP", "side": "BUY", "type": "LIMIT", "tif": "GTC", "price": "65000", "qty": "2", "clOrdId": "a1", "clientUid": "CLIENT-A" } ``` - Accepted only at prices inside the price band, at placement and on amend (2003 otherwise). The limit child of a triggered STOP_LIMIT or TAKE_PROFIT_LIMIT is the exception: it can rest and trade outside the band (section 3.3). - Partial fills are normal: the order reads `PARTIALLY_FILLED` on the order reads and the rest works. The WebSocket `order` channel reports no partial fill in a frame of its own (every frame before the terminal one reads `NEW`; the fills arrive on the `execution` channel). ### 3.2 MARKET No price from you; the venue applies a **protection collar** derived from the best eligible opposing price and `marketMaxSlippageBps`. The order behaves like a limit order at the collar price: it will never print worse than the collar, which is what protects you in a thin or gapping book. - Empty or ineligible book: rejected 2007 (no eligible liquidity). - Margin is checked at the COLLAR price, so a market buy needs slightly more free margin than the touch suggests. Size accordingly. - Omit `price` entirely. Sending one is a malformed order. ### 3.3 STOP_MARKET and STOP_LIMIT Conditional orders that are invisible to the book until they trigger. Status is `PENDING_TRIGGER` while waiting. ```json { "symbol": "BTC-USD-PERP", "side": "SELL", "type": "STOP_LIMIT", "tif": "GTC", "qty": "1", "clOrdId": "s1", "clientUid": "CLIENT-A", "trigger": { "source": "LAST", "price": "60000", "direction": "AT_OR_BELOW", "limitPrice": "59900" } } ``` - `source`: `LAST` (last trade print), `MARK` (venue mark, manipulation resistant), `INDEX` (external index). **Prefer MARK for stop-losses**: LAST can be moved by a single small print, MARK cannot. - `direction`: `AT_OR_ABOVE` or `AT_OR_BELOW`. Conventional use is at-or-below for a sell stop and at-or-above for a buy stop. - On trigger, STOP_MARKET becomes a market order (with its collar) and STOP_LIMIT becomes a limit order at `limitPrice`. - No band and no collar on a conditional limit (Member API revision 3.83 states it; kept by venue decision of 20 October 2026): neither the trigger price nor `limitPrice` is checked against the price band, at placement, on amend or at activation, and the triggered limit child is not collared: it trades through the book up to `limitPrice`, however far that lies from the mark, and rests at `limitPrice` even outside the band. Only the children of STOP_MARKET and TAKE_PROFIT_MARKET get the collar. Choose `limitPrice` as the worst price you accept when the trigger fires. - A triggered STOP_LIMIT can fail to fill if the market ran past your `limitPrice`. That is the trade-off against STOP_MARKET's slippage. - Triggers are evaluated in the same command that moves the price, so a single large print can trigger and fill within one deterministic step. ### 3.4 TAKE_PROFIT_MARKET and TAKE_PROFIT_LIMIT Mechanically identical to the stop family; the name documents intent (the direction is typically the profitable side). Same trigger block, same rules. ### 3.5 What the venue deliberately does NOT offer - **No trailing stops.** Any trailing parameter is rejected (2004 for the type, 2017 for a stray field). Implement trailing client-side: watch the mark and amend or replace your stop. This is a deliberate choice: a venue-side trailing stop is a hidden order whose behaviour cannot be reproduced by replay. - **No iceberg or reserve orders (no `displayQty`).** See section 4. - **No good-till-crossing, no pegged orders** in this release; the only auctions are the daily opening and closing calls of a SECURITY market with an auction schedule (Member API section 6j), never on a perpetual, spot, barrier or swap market. ## 4. Iceberg orders: why they are absent and what to do instead Kronos X has no iceberg (hidden-quantity) order type. Sending a `displayQty` field is rejected with 2017. **How much this matters depends entirely on your flow.** Icebergs exist to hide size on a lit book so the market does not fade or front-run a large resting order. They matter most on venues where a single order is a large share of visible depth and where the queue is long-lived. For this venue's members, the practical impact is limited today, because: - Perp order books here are quote-driven and refresh continuously; resting size is usually replaced faster than an iceberg's refill cycle would help. - Most member flow is either aggressive (market/IOC/FOK against the quote) or short-lived passive quoting, neither of which benefits from hidden size. - The venue publishes the FULL book depth to all members, so a large visible order is genuinely visible; but member identity is never published, so the information leak is size, not identity. **The honest engineering position:** an iceberg is straightforward to implement correctly here (a display quantity that refills from a hidden reserve, joining the back of the queue at each refill, which is the standard fair behaviour), and it is genuinely useful once a member routinely rests size that is a large fraction of visible depth. It is not in this release. If you expect to rest blocks materially larger than top-of-book depth, tell venue operations and it will be scheduled; the venue would rather implement it properly than have you simulate it badly. **Until then, the correct client-side substitute** is order slicing: rest a child order of your display size, and on each fill submit the next child. Do it with these rules: - Randomise child size within a band rather than using a constant size, which is trivially detectable. - Do not resubmit faster than your fills arrive; every child costs an order-to-trade ratio message (section 9). - Keep one `clOrdId` per child and track the parent yourself; the venue has no parent-child concept. - Remember the queue reality: a fresh child joins the BACK of the queue at its price, exactly as an iceberg refill would. ## 5. Time in force | TIF | Behaviour | |---|---| | `GTC` | Rests until filled or cancelled. | | `IOC` | Trades what it can immediately; the remainder cancels with reason `IOC_REMAINDER`. | | `FOK` | All or nothing, immediately. If the full quantity cannot trade, NOTHING trades and the order cancels with `FOK_UNFILLABLE`. | | `POST_ONLY` | Must rest. If it would trade on arrival it is rejected (2005). Use it to guarantee maker treatment. | | `GTD` | Rests until `expireTs` (unix ms), then `EXPIRED` with reason `GTD_EXPIRED`. It never trades at or after `expireTs` (member reference revision 3.86), measured against the time the venue sequences each command, never your clock: an order, an amendment or a cancellation (each answered 2014), a trigger or a call auction's uncross that reaches it from that instant expires it instead, and the venue's expiry sweep, about once a second, reports `EXPIRED` for one nothing reaches. Before revision 3.86 that sweep alone expired it, so it could still trade for up to about a second after `expireTs`. The matching engine applies this from its replay-contract line for revision 3.86, the first command of a venue started on the production contract; venue operations announce the date on any environment where that line lies ahead. | **MARKET + FOK** is fully supported and is all-or-none against the liquidity INSIDE the collar. Expect either a complete fill set or a single cancel, never a partial. This combination is the safest way to express "fill my whole size now or not at all". `reduceOnly` (perps only) refuses to increase your MEMBER net position; it is trimmed or rejected (2008) if it would. When your member position shrinks, the venue trims your reduce-only orders, resting ones and untriggered conditional ones alike, newest first, or cancels them (`REDUCE_ONLY_VIOLATION`); a trim arrives unsolicited as `OrderAmended` (FIX `150=5`). **`reduceOnly` is not an end-client close flag.** Its budget is judged against your MEMBER net position for the instrument, and it never reads an end client's sub-position, because venue risk logic never reads client sub-positions at all (sections 1 and 7). The consequence for a broker is sharp: an end client closing its OWN position, while your aggregate book leans the other way, is refused with 2008 even though that client genuinely holds the position. Sharper still, a perfectly netted member book refuses everything. With client A long 10 and client B short 10 your member net is exactly zero, so EVERY reduce-only order on that instrument is rejected, from either client, on either side. What the flag IS for is a venue-enforced guarantee that an order can only SHRINK your own house exposure, for example a risk desk flattening the member book during a margin call. Under that flag nothing else can happen to the order, no matter what your router does with it. **To close for one end client, send a PLAIN order,** with no `reduceOnly`, sized against that client's own position, which you read from `GET /v1/positions/end-clients`. Only the member knows its client-level book, so only the member can gate on it. That is also exactly why `POST /v1/lots/{lotId}/close` defaults `reduceOnly` to false. ## 6. RFQ markets and barrier contracts Every market has a `mode` on `GET /v1/instruments`: `ORDER_BOOK` (everything in sections 3 to 5) or `RFQ` (request-for-quote: no order book at all). Read the mode at startup exactly as you read tick and lot sizes; never assume it. - On an RFQ market, order entry is rejected with 2022 (`RFQ market: no order book, trade via POST /v1/rfq`), on every transport. - RFQ operations on an order-book market are rejected with 2023. Three kinds trade in RFQ mode: | Kind | What an accepted quote does | |---|---| | `PERP` | An off-book perp trade at the quoted price. Margined and netted into your member position exactly like a book fill; flagged `RFQ` in executions. | | `SPOT` | Prefunded delivery at the quoted price, settled exactly like a book spot fill. | | `BARRIER` | Opens a knock-out contract (section 6.3). Barrier markets are always RFQ. | RFQ trading is REST and WebSocket only; it is not available over FIX. ### 6.1 The request, quote, accept flow The requester opens a request; eligible members quote; the requester accepts exactly one quote. Everything else in this handbook still applies: Trader ID gating (2021) on create, quote and accept exactly as on order entry, strict JSON with 2017 on unknown fields, and `clientUid` attribution. **1. Create.** `POST /v1/rfq`: ```json { "symbol": "BTC-USD-KO", "side": "BUY", "qty": "2", "expiresInMs": 60000, "barrier": { "level": "65000" }, "clOrdId": "rq-1", "clientUid": "CLIENT-A", "reg": { "traderId": "TR-12-9F3A21BC" } } ``` - `expiresInMs` is the quoting window: default 60000 ms, minimum 1 second, maximum 24 hours. The ack returns your `rfqId` and echoes the terms. - `barrier` is required on barrier markets and must be absent everywhere else (2027 either way). Section 6.3 covers its meaning, including the optional `barrier.takeProfit` (revision 3.43). - You may hold at most 64 open RFQs at a time. - **The request is idempotent on its `clOrdId`** (member API revision 3.85, from the venue's replay-contract line for that release): a `clOrdId` you already used, on an order, a swap take, a request or a quote, answers 2009 and opens nothing. There is no restatement of the original, so after a timeout resend with the SAME `clOrdId` and, on 2009, read `GET /v1/rfq/mine`. **2. Quote.** Other members discover the request on `GET /v1/rfq/open`, **anonymously**: side, quantity and terms, never who is asking. The board is filtered to what each caller is eligible to trade against, your own RFQs are never on your own board, and discovery is polled REST by design; the venue does not broadcast the board. A maker quotes with `POST /v1/rfq/{rfqId}/quotes`: ```json { "price": "70000", "expiresInMs": 30000, "clOrdId": "mk-1", "clientUid": "HOUSE-1" } ``` - The price is negotiated, but the venue still refuses a quote outside the instrument price band around the mark (2003). - Quote validity defaults to 30000 ms, minimum 1 second, maximum 24 hours. - **Quoting commits you to the request's full size.** It counts against your order-size cap exactly like a book order of that size (2013 when over): `maxOrderNotional` valued at your quoted entry price where published, else the base-unit `maxOrderQty`. - **One live quote per maker per RFQ.** Quoting again replaces your earlier quote, under a NEW `clOrdId` since member API revision 3.85: from the venue's replay-contract line for that release a reference you already used answers 2009 and replaces nothing, so a quote sent again can never bring back a price you have since moved. An RFQ carries at most 64 live quotes. - Quoting your own RFQ is rejected with 2026. An RFQ outside your eligibility set is indistinguishable from one that does not exist (2024). - Track your outstanding quotes on `GET /v1/rfq/quotes/mine`. **3. Accept.** The requester watches `GET /v1/rfq/mine` or the `rfq` WebSocket channel. Quotes are **anonymous toward the requester**: price, size and validity, never the maker's identity. Accept one with `POST /v1/rfq/{rfqId}/accept`: ```json { "quoteId": 7 } ``` The response carries the `tradeId`, price and quantity, and on a barrier market the `contractId`. **Margin is checked on BOTH parties at accept**: if you no longer pass, the accept rejects 3001; if the quoting member no longer passes, it rejects 3007 and nothing trades. A 3007 quote stays on the RFQ until it expires or is withdrawn, but re-accepting it will fail identically until the maker's margin recovers; take the next best quote instead. Two further accept-time re-checks: a quote the mark has since drifted away from is **stale** and rejects 2003 (the price band is re-applied against the CURRENT mark, so a negotiated price can never print far off the market the venue marks against), and both members must still be fit to open new risk at that moment: a reduce-only requester rejects 3002, a reduce-only maker's quote resolves 2025. **4. Cancel.** `POST /v1/rfq/{rfqId}/cancel` (requester) and `POST /v1/rfq/{rfqId}/quotes/{quoteId}/cancel` (maker). Like order cancels, RFQ cancels are never rate-limited: you can always withdraw. Operational rules: - **Rate limits.** Create, quote and accept consume the ORDER bucket (section 9), never the read bucket; the RFQ reads consume the read bucket. - **Expiry.** An RFQ past its window emits `expired`. A quote past its validity expires SILENTLY: the maker gets no event, so watch your own validity clocks. - **Halts and reduce-only.** An RFQ always opens new risk: a member in reduce-only cannot create or quote, and a halted or reduce-only market refuses creates, quotes and accepts. There is no reduce-only RFQ. - **Liquidation.** A member entering liquidation has its open RFQs cancelled and its outstanding quotes withdrawn. A perp position on an RFQ market has no book for the venue to liquidate into, so it is closed AT THE MARK against opposite-side holders in deleveraging order, profitable positions first, in one step; where the profitable side cannot absorb the whole position, the remaining opposite-side positions, including positions not in profit, are closed at the same mark price. If you hold the other side of such a market, that close can reach you as an `ADL`-flagged trade at the mark price even though nobody is bankrupt; it is the RFQ-market equivalent of the liquidation slice. ### 6.2 What an accepted RFQ trade is, and is not On perp and spot RFQ markets an accepted quote is a genuine venue trade: - It prints on the public trades feed and in both members' executions, flagged `RFQ`. The quoting member is the maker, the requester the taker; ordinary maker/taker fees apply. - Perp: margined and netted into your member net position exactly like a book fill, including per-client sub-positions. - Spot: prefunded delivery checked at accept exactly like a book fill: an unfunded requester rejects 3001 (buy) or 3004 (sell); an unfunded maker rejects 3007. Because the price is bilaterally negotiated, it is NOT public book liquidity: - It does not update the last-trade print. - It does not trigger conditional orders. - It does not feed the circuit breaker. ### 6.3 Barrier (knock-out) contracts A barrier contract is a bilateral contract between a HOLDER and a WRITER. The requester is ALWAYS the holder: `BUY` means long with the knock-out barrier BELOW the entry, `SELL` means short with the barrier ABOVE. The maker who quotes writes the contract, and the price it quotes is the ENTRY price. Barrier terms ride the RFQ: `barrier.level`, plus an optional `barrier.expiryTs` (unix ms); omit it for an open-ended contract on a market without `maxContractLifeHours` (a market that publishes that field on `GET /v1/instruments`, revision 3.70, requires the expiry at most that many hours after the request, else 2027). The level must sit on the knock-out side of the mark when you create, and of the entry when the writer quotes and when you accept (2027 otherwise). Since revision 3.43 an optional `barrier.takeProfit` adds a second exit on the PROFIT side of the entry (above mark and entry for BUY, below both for SELL, checked the same way): when the mark reaches it the contract terminates AT the take-profit price, fee-free like the knock-out, and the holder banks `|takeProfit - entry| x qty`. Holder margin is unchanged; the writer's requirement is bounded by the remaining take-profit distance. `GET /v1/barriers` rows carry `takeProfit` and `status`, and `?status=CLOSED` lists your recently settled contracts with their `terminationReason` (`KNOCK_OUT`, `TAKE_PROFIT`, `EXPIRY`, `TEAR_UP`, `FINAL_SETTLEMENT`, `EARLY_CLOSE`). Since revision 3.45 the holder's maximum loss is a PREMIUM, a share of the entry-to-barrier distance rather than the whole of it: every barrier market publishes `knockOutRebateBps` and `strictTakeProfitPremiumBps` on `GET /v1/instruments` (1000 and 5000 on every KO market listed today), and the contract freezes its own `premiumBps` at the open: `10000 - knockOutRebateBps` (9000, so 90 percent of the distance) on a normal contract, `strictTakeProfitPremiumBps` (5000, 50 percent) on a STRICT take-profit contract, 10000 on contracts opened before the revision. The premium is `|entry - barrier| x qty x contract value x premiumBps / 10000` (the contract value = `contractMultiplier`, 1 on every barrier market) and rides every barrier surface as `premium` (money string) and `premiumBps`: the RFQ views (indicative at the current mark until a quote is accepted, since the entry is the quoted price), the accept response, `GET /v1/barriers` rows and every WS `barriers` frame, beside `strictTakeProfit` (bool). A STRICT take-profit contract (`barrier.strictTakeProfit: true`, which requires a `takeProfit`, an `expiryTs` at most 24 hours out and a market whose `strictTakeProfitPremiumBps` is nonzero, else 2027) pays ONLY on a take-profit touch before its expiry: at the expiry without a touch the holder loses the whole strict premium whatever the mark. **Worked example** (the same one as the trading page): `BTC-USD-KO`, holder BUY, qty `2`, quoted entry `70000`, barrier `65000`. **Holder economics.** - Margin is the PREMIUM: the entry-to-barrier distance times quantity times the contract's `premiumBps` share. The distance is (70000 - 65000) x 2 = 10000 USD; on `BTC-USD-KO` (`knockOutRebateBps` 1000, so `premiumBps` 9000 on a normal contract) the premium is **9000 USD**. IM equals MM. (Before revision 3.45, and on contracts opened before it, the premium was the full 10000; a STRICT take-profit contract on the same terms would carry 5000.) - That same 9000 is your maximum possible loss. If the mark touches 65000 the contract terminates AT 65000, even if the mark GAPS from 65400 straight through to 64000: the barrier is a guaranteed stop, and there is no gap risk. You lose exactly the premium (9000): the writer receives it and the rebate share of the distance (1000) is what you recover at that moment. - Equity marks to market continuously: at a 72000 mark the holder shows +4000 unrealized, the writer -4000. - The contract can never liquidate its holder. Your margin requirement is the REMAINING distance from the mark to the barrier less the rebate, that is the premium plus your unrealized P&L floored at 0 (IM equals MM), so as the mark moves against you the unrealized loss and the released requirement cancel exactly: your equity minus MM contribution from the contract is constant from entry to knock-out. A holder funded with exactly the reserved premium rides the contract all the way to the barrier and ends at zero, never in liquidation. The knock-out (and, when set, the take profit) is the only AUTOMATIC holder-side close-out; you can also ask the writer for an early close by RFQ (below). Two consequences worth knowing: unrealized PROFIT on the contract stays reserved (the requirement grows with the distance) and frees up only when the contract closes, and losses on your OTHER positions can still put your whole membership into liquidation, which tears barrier contracts up at the barrier-clamped mark like everything else. **Writer economics.** - The writer is margined like a perp on the market's risk tiers at CURRENT notional, recomputed at every mark. At entry the notional is 2 x 70000 = 140000; on the sandbox tiers (2% IM, 1% MM) that is 2800 IM and 1400 MM. - A member entering liquidation, holder or writer, has its barrier contracts torn up at the current mark. The counterparty gets a fair mark close; a writer in liquidation never leaves the holder with a dangling contract. **Life cycle and settlement.** - Barrier contracts never pay or receive funding. - A knock-out settles AT the barrier price: the holder loses exactly the premium, the writer receives it. - Expiry, if set, settles at the MARK on the first price tick at or past `expiryTs`, floored at minus the premium and capped at the potential profit when a take profit exists; a STRICT take-profit contract that expires without a touch forfeits the whole premium whatever the mark. Tear-up, final settlement and an early close are floored and capped the same way. - Entry is charged ordinary maker/taker fees on the entry notional (holder = taker, writer = maker; on sandbox default rates, 70 USD and 28 USD here). Knock-out and expiry settlements are fee-free. - Settlement P&L lands in the ledger as kind `BARRIERSETTLE`, zero-sum between holder and writer. - **Early close by RFQ (revision 3.44).** The holder can end the contract before any of the above by asking the writer for a price: `POST /v1/rfq` with `symbol` and `closeContractId` (an OPEN contract you HOLD), and NO `side`, `qty` or `barrier` (2013 if sent; the venue derives the closing side, the full quantity and the terms; 2035 if the id is not an open contract you hold on this market or already has a close request open, one at a time). Only the writer sees the request (its board and its `rfq` `created` frame) and only the writer may quote it (2024 to anyone else), at a price STRICTLY INSIDE the terms, `barrier < price < takeProfit` for a long holder and mirrored for a short one (2027). Your accept closes the contract AT that price: the closing trade is flagged `BARRIER_CLOSE` and pays maker/taker fees exactly like the entry (in the worked example, a close at 72000 costs the holder 72 USD taker and the writer 28.8 USD maker on the 144000 closing notional), the settlement books `BARRIERSETTLE` zero-sum ((72000 - 70000) x 2 = +4000 to the holder, -4000 to the writer) with `terminationReason` `EARLY_CLOSE`. Closing releases margin, so the only admission is solvency: a close that costs a party no more than it releases is always admitted, and otherwise the party's available must stay non-negative after the settlement and the fee (`3001` holder, `3007` writer, Member API 6b, revision 3.47). The accept response carries `contractId` (the closed contract), `closeContractId`, `settlePrice` and your `realizedPnl`. If the contract knocks out, hits its take profit, expires or is torn up while the request is open, the venue cancels the request in the same command; cancelling it yourself is free. **Where barrier contracts appear.** - They are bilateral: never in `/v1/positions`, never in end-client sub-positions, never in open interest, and margin is per contract with no netting between contracts. - They live on `GET /v1/barriers`: your role (`HOLDER` or `WRITER`), direction, quantity, entry, barrier, current mark, `barrierDistance` (the mark's fractional distance from the barrier: mark 70000 against barrier 65000 gives `"0.071428"`), your role-signed unrealized P&L and the margin your role carries. - The barrier market is its own instrument with its own mark price feed under its own symbol (`BTC-USD-KO` on the sandbox). Subscribe to ITS mark; do not assume it equals any other market's. ### 6.4 The rfq and barriers channels Two private WebSocket channels: | Channel | Event types | |---|---| | `rfq` | `created`, `quoted` (requester: anonymous price and validity), `myQuote` (the maker's own confirmation), `quoteCanceled`, `accepted`, `canceled`, `expired`; frames of a close request carry `closeContractId`, and its `created` also reaches the contract's writer (role `WRITER`) | | `barriers` | `opened`, `knockOut`, `takeProfit`, `expiry`, `earlyClose`, `liquidation`, `finalSettlement` (closes carry `settlePrice`, role-signed `pnl` and `terminationReason`, incl. `EARLY_CLOSE`) | Both are GUARANTEED delivery: a stalled consumer receives the terminal gap frame and disconnect of section 13. Recovery, however, is STATE-ONLY: these two channels are not cursor-backfillable through `/v1/stream/events`. After any gap or disconnect, re-read `GET /v1/rfq/mine`, `GET /v1/rfq/open` and `GET /v1/barriers`; the live state is authoritative, and it is small. (The RFQ trades themselves are ordinary executions and remain cursor-recoverable like any other execution.) ### 6.5 Replacing CFD-style products: guidance for brokers If you offer clients guaranteed-stop products, the barrier contract is the venue-native replacement, and the mapping is direct: - **The barrier IS the guaranteed stop.** Set the level where the client's stop would be; the venue enforces termination AT that price with no gap risk. That is the exact promise a CFD provider otherwise has to warehouse or insure. - **Client maximum loss equals the margined premium, exactly.** Quote the client "margin = entry-to-barrier distance times quantity times the market's premium share" (`premium` on every RFQ view and on `GET /v1/barriers`; 90 percent of the distance on every KO market listed today, 50 percent for a strict take-profit contract) and the realized loss cannot exceed it, with no funding drift on the contract and no margin calls from the contract itself: the requirement tracks the remaining distance (section 6.3), so a barrier book never breaches maintenance on its own, even funded with nothing beyond the reservation. Losses elsewhere in the member account are the only thing that can force it closed early. - Open-ended (no `expiryTs`) suits rolling products on a market without `maxContractLifeHours`; dated products set `expiryTs` and settle at mark, fee-free. A market that publishes `maxContractLifeHours` lists dated contracts only, the expiry at most that many hours after the request. - Anonymity is structural: your request shows side, size and terms, never your identity, and you never learn which member wrote the contract. - Drive client-facing distance-to-stop displays from `barrierDistance` on `GET /v1/barriers`, and treat the `barriers` channel `knockOut` event as the authoritative close confirmation. - Attribution works exactly as on orders: the `clientUid` you send on the RFQ is carried on the contract and returned on `GET /v1/barriers`. ### 6.6 RFQ and barrier error codes | Code | HTTP | Wire message | When | |---|---|---|---| | 2009 | 400 | `clOrdId already used: an RFQ request or quote is never restated, read GET /v1/rfq/mine or GET /v1/rfq/quotes/mine` | Since member API revision 3.85, from the venue's replay-contract line for that release, a request or a quote whose `clOrdId` you already used (on an order, a swap take, a request or a quote); nothing is opened or replaced and the original is not restated. | | 2022 | 400 | `RFQ market: no order book, trade via POST /v1/rfq` | Order entry on an RFQ market. | | 2023 | 400 | `not an RFQ market: use the order book` | RFQ operation on an order-book market. | | 2024 | 404 | `RFQ not found, closed or expired` | Also returned for RFQs outside your eligibility set. | | 2025 | 404 | `quote not found, withdrawn or expired` | Including an accept that arrives after the quote's validity. | | 2026 | 400 | `cannot quote or accept against your own member` | Self-quoting. | | 2027 | 400 | `barrier level or expiry invalid for this market and side` | Wrong side of mark or entry (level or take profit), expiry in the past, `barrier` missing on a barrier market or sent to any other; a close-request quote not strictly inside the terms (revision 3.44); a strict take profit without `takeProfit`, without `expiryTs`, with an expiry more than 24 h out, or on a market not offering it (revision 3.45). | | 2028 | 400 | `order notional below the instrument minimum` | RFQ create below `minNotional` valued at the current mark, or a quote below it at the quoted entry price (100 USD on the barrier markets since Member API revision 3.71, a close request included at the contract's whole quantity; 5 USD elsewhere). Accepts are not re-checked (the accepted price cannot change). | | 2029 | 400 | `venue client-reference capacity reached: cannot register a new clientUid` | An order or RFQ acceptance that would register a `clientUid` the venue has never seen, once the venue-wide identifier table (1,048,576 distinct identifiers) is full. Identifiers the venue already knows are unaffected, and nothing is deleted to make room: an identifier carries lifetime realized PnL and funding for that end client. | | 2035 | 400 | `closeContractId does not name an OPEN barrier contract you hold on this market, or a close request for it is already open` | Early close by RFQ (revision 3.44): the id is not an open contract you hold on `symbol`, or one close request is already open on it; also at accept when the contract terminated between the steps. | | 3007 | 400 | `quoting member no longer passes margin or limits` | Counterparty failed at accept; your own failure is 3001. | ## 7. Margin, leverage and fees **Margin is member-level.** Initial margin (IM) is charged on positions and on working orders (worst case, as if every order filled); maintenance margin (MM) is what keeps you out of liquidation. **Isolated collateral on request (subaccounts).** All balances in one member account cross-collateralise all of that account's positions. If you want a specific position backed by a dedicated, capped amount of collateral (the rulebook's Position Margin election), ask venue operations for an additional member account under your membership: fund it with exactly the amount you are prepared to commit and trade the position there. Each account is margined, liquidated and reported fully independently, so losses on that position can never touch your main account, and the funded amount is the cap. Additional accounts carry a suffix on the member code and their own credentials; there is no automatic transfer between your accounts (moves go through the normal deposit and withdrawal process). Every limit and parameter under the Rules applies to each account separately; a measure under the Rules applies to all of your accounts. Self-trade prevention does not apply between your accounts: an order from one of your accounts can match an order from another, and a cross between the same end client on two of your accounts is screened by the venue's surveillance like any other same-client cross. - `riskTiers` is a marginal schedule: each notional band charges its own rate, like a tax bracket. Larger positions cost proportionally more margin. - Your account may carry an `imMultiplier` (visible on `GET /v1/account`, normally `"1"`). Effective IM = tier rate x multiplier. - **Per-end-client leverage is YOUR responsibility.** The venue does not model it. If you offer clients fixed leverage, enforce it before submitting. The optional order-level `leverage` field is an ASSERTION: the venue validates it against your effective margin and rejects a false one (2018), but never changes the margin applied. - `POST /v1/margin/preview` answers "what would these orders cost me" before you send them: the `orders` array (up to 50 entries) is priced as one basket, with the same one-sided max(buy, sell) netting per instrument that resting orders receive. **Fees** are maker/taker rates per member, visible as `makerFeeRate` and `takerFeeRate` on `GET /v1/account` (null = the instrument defaults). A NEGATIVE maker rate is a rebate: you are paid to provide liquidity. Fees are charged in the settlement currency at fill time and appear on the `wallet` channel and the ledger. ## 8. What the venue does without being asked You must handle all of this; it is not optional. 1. **Margin call.** Equity below IM raises `riskStatus` to `MARGINCALL` and emits a venueEvents `MARGIN_CALL` with `state: "ACTIVE"` (and `CLEARED` on recovery). Add margin or reduce. 2. **Liquidation.** Equity below MM opens an episode: the venue cancels your ENTIRE order book venue-wide (reason `LIQUIDATION_CANCEL`), then works closing orders per end client with references `KX-LQ-{orderId}`. Your barrier contracts are torn up at mark, and your open RFQs and quotes are withdrawn (section 6.3). While the episode is open, and afterwards while `riskStatus` is `DEFAULTED`, your new orders and amends reject with 3002 on risk status alone; cancels stay accepted. 3. **ADL.** If the book cannot absorb a close at the bankruptcy price, opposite positions are torn up pro-rata across affected end clients at that price, with references `KX-ADL-{tradeId}`. Candidates are drawn one at a time in ranking order; a selected member's position is closed up to the quantity still needed before the next candidate is touched. Auto-deleveraging reaches you only if you hold the opposite side of the defaulter's market; profitable positions are closed first in deleveraging order, and only where they cannot absorb the whole position does the venue close the remaining opposite-side positions, including positions not in profit, at the same bankruptcy price. A client can be deleveraged through no fault of their own; explain this to your clients in advance. 4. **Halts.** Circuit breakers, stale marks, administrative halts and delisting stop trading with a typed reason on venueEvents; orders reject with 3003 (halted) or 3006 (delisted, permanent for that listing). 5. **Suspension.** A suspended member's working orders are cancelled and new flow rejects with 3002. 6. **Re-listing.** A `tickSize` or `qtyStep` change delists the market, cancelling every resting order with `INSTRUMENT_HALT`, final-settles its positions and lists it again on the new grid (section 2). It is announced in advance, never signalled on the wire before the date. Every venue-initiated execution carries `refSource: "VENUE"`. **Key your handling on `refSource`, never on the shape of the reference string.** ## 9. Rate limits and the order-to-trade regime - Per MEMBER, two INDEPENDENT token buckets shared by every API key you hold: **6000 reads per minute** and **40000 order-budget units per minute**. Order placements, batch entries, and amendments all consume the order budget, one unit each; cancels are never throttled. Order-budget traffic does NOT consume a read token, so a burst of orders never eats your read allowance and heavy polling never throttles your order flow. Exceeding either gives 1003. Holding several keys does not multiply the budget: all of a member's keys draw from the same two buckets. - **Repeated engine faults (Member API revision 3.79).** When ten of your commands answer 5005 within 60 seconds, every order-budget message of yours, on every key and transport, answers 1003 with `retryAfterMs` (up to 60 seconds) and the message `rate limit: repeated engine faults (5005)` until the oldest of those ten is 60 seconds old; cancellations are never refused, nor is a request that can only reduce your risk (a reduce-only order, a batch whose every entry is reduce-only, a lot close sent reduce-only, a barrier early close: the close request, the writer's quote on it and its accept), which still consumes its order-budget unit; an amendment, and a batch with one entry that is not reduce-only, stay refused. No other member is affected, and the venue mails your trading contact once. Ten in 60 seconds is a published rule of the venue. A 5005 is a fault of the venue: never resend such a command unchanged. - A batch (`POST /v1/orders/batch` or the WS `orders.batch` op) is charged one unit per entry, up front, all or nothing: a denied batch answers 1003 with `retryAfterMs` and consumes nothing. - **Batch amendment and batch cancellation (Member API revision 3.74).** `POST /v1/orders/batch/amend` (WS `orders.batchAmend`) amends and `POST /v1/orders/batch/cancel` (WS `orders.batchCancel`) cancels 1 to 50 of your orders in one message; every entry the venue submits is the ordinary amendment or cancel (member reference section 6, Manage orders), with exactly its effect on priority, so a size-down at the same price keeps its place and a reprice is cancel+new and re-matches as a taker outside a call auction: a post-only order repriced to cross is rejected 2005 and removed, and your self-trade policy applies against your own resting orders. The batch is non-atomic: entries run in array order, other members' traffic may interleave, and a refused entry never stops a later one. An amendment batch is charged one unit per entry, up front, all or nothing, after the venue's engine-busy check, and the units of entries refused afterwards (an order not found, a blocked market, a grid refusal) stay spent; a cancellation batch is free and never throttled, looks every entry up first (an entry naming no open order of yours answers 2014 and is never submitted), and runs one batch of yours at a time on a venue node. Not offered over FIX. A market maker requoting 24 levels 5 times a second on one market sends 120 order messages a second, 7,200 units a minute: send only the levels that changed. - Both buckets are full-capacity and refill continuously, so after a quiet period the whole minute's allowance is available immediately, within the per-second ceiling your class publishes (STANDARD 1,000 orders/s on production, none on the sandbox; Member API section 4): every order-budget message on every transport counts against it, and a burst above it answers 1003 with `retryAfterMs` under one second even while the minute's allowance is unspent. The order bucket is deliberately sized for a **DMA liquidation burst**: when many of your end clients hit their limits at once you can push the whole wave of risk-reducing orders without being throttled by the venue, and the batch route lets you tag every close with its own `clientUid` in one message. - Cancels consume neither bucket. You can always withdraw liquidity. - A higher allowance is only ever a published class of the rate-limit ladder whose objective criteria you meet (DMA for approved DEA providers, MM for designated Market Making Members, others as the venue publishes; Member API section 4): ask venue operations for the class assignment. A member-specific value is only ever tighter than your class, and your class and the values in force are `account.rateLimits` on `GET /v1/account/parameters`. - **Order-to-trade ratio (RTS 9).** The venue counts order messages (place, amend, cancel, every entry of a placement batch, and every entry of an amendment or cancellation batch that the venue submits: a row answered before anything is submitted for it, such as 2014 or 1004, counts nothing) against trades over a sliding 60-minute window. A warn threshold flags you; a block threshold rejects new orders, batches and amendments with 1004 until the ratio recovers (an amendment batch answers 1004 for each entry on the blocked market and runs its other entries). Cancels are never blocked, a cancellation batch included: you can always withdraw liquidity. Quote-heavy strategies should agree thresholds with venue operations at onboarding. ## 10. Credentials and separation of duties - Credentials are an API key and secret; requests are HMAC signed (recipe in the member API reference section 3). - **A signed write is accepted once** (member API revision 3.85). The venue records every signed request other than a GET and refuses the same signature again with 1002 `request already received`, so a captured request cannot be replayed: sign every send, a retry included, with a fresh `X-TIMESTAMP` and keep its `clOrdId`. `X-RECV-WINDOW` is an integer from 1 to 60000 or the request is refused (it was reduced to the cap), and a timestamp may lead the venue clock by at most 5 seconds whatever the window: keep your clock synchronised. A venue node also refuses a write stamped before it started or became the leader. - **The WebSocket login signs the connection's challenge** (member API revision 3.85, section 10.1, mandatory): the first frame of a private connection carries a nonce, and the `auth` op signs `"GET/ws/private" + expiresMs + nonce` and sends the nonce as its fourth arg, so a login frame works on its own connection only. Keep the frames and the secrets out of your logs. - Credentials carry a **scope**. A `TRADE` credential can do everything. A `READ_ONLY` (drop copy) credential can read and receive the full event stream but is refused on every write, on every transport, with code 1005: order entry, cancel, amend and configuration changes are impossible with it. - Use a READ_ONLY credential for back office, risk, surveillance and reporting systems. A member holds up to 5 keys PER SCOPE at the same time: issuing a key adds it alongside the others and revokes nothing; each key is revoked individually, from the portal keys card or via venue operations. ## 10a. Trading capacity: venue semantics, tagging and your report label The `reg.tradingCapacity` field is spelled in the MiFIR vocabulary but it is NOT MiFIR field 29. It declares the LEGAL NAME OF EXECUTION under the venue's semantics, and your RTS 22 report label derives from your configured per-member mapping, never the other way around: - `DEAL`: dealing on own account. - `MTCH`: execution in your OWN NAME for a client account, INCLUDING commission business (Finanzkommissionsgeschaeft), regardless of how your home regime labels it in transaction reports. - `AOTC`: agency in the name of the identified client. The trap this section exists to close: a commission broker whose home practice reports AOTC will be tempted to tag AOTC on the wire because that is what its transaction report says. Do not. Tag `MTCH`; the venue configures your MTCH-to-AOTC report mapping during onboarding, in the same step as your licensing profile and capacity-tagging attestation, where the venue's compliance function has determined on its one published test that your own-name commission business is not matched principal trading (that is the only report label the venue ever configures; DEAL and AOTC report as themselves, and a member that reports its own transactions under MiFIR Art. 26 carries no label), and your reports then carry the label your regime expects while the venue's prudential statements bucket by the legal name of execution (IFR Article 4(1)(33)): own-name flow accrues to dealing on own account whatever the report label says. Enforcement is staged per member (off, warn, enforce; reject 2033 at enforce). In production the venue additionally runs fail-closed: no licensing profile, no order acceptance (reject 2034), because the profile and the attestation are mandatory onboarding artifacts. The sandbox stays fail-open. On production every member's profile is at the ENFORCE stage before its first order and every DEAL-permitted member, market makers included, has its house reference configured before it (member reference section 6f, Production posture); the OFF and WARN stages are sandbox tooling. Full field rules in the member reference, section 6f. **Monthly IFR data annex and the K-TCD snapshot (revision 2.15).** The monthly IFR data annex you download from the portal (v3, with a detached Ed25519 signature) carries, when the venue captured one for the month-end day, your K-TCD exposure snapshot under the venue's pool methodology: per (member, market) netting set the venue computes RC, the replacement cost (your negative unrealized PnL at the venue mark; a winning position is an obligation of the pool, not an exposure), PFE as the supervisory factor of the venue parameter store times notional (IFR Article 29 shape; crypto perpetuals map to the residual bucket by venue proposal), and EV = max(0, RC + PFE - C); K-TCD = alpha x CVA x the sum over netting sets of EV x RF, with alpha 1.2 (Article 26) and CVA 1.5 (Article 32) applied uniformly to every netting set and to both views; RF is decomposed pro rata over the open interest on the opposite side of each market by the counterparty type of the members holding it (a venue-defined methodology under the pool model, not an IFR-prescribed one); view A recognises no collateral (C = 0), view B recognises your positive balances after the haircuts held in the venue parameter store (Article 30 shape), allocated pro rata by each set's share of RC + PFE; barrier contracts are excluded from the netting sets (the stop is guaranteed at the barrier and margin equals max loss) and reported as the memo column of holder admission premiums held. Every factor, class and haircut is printed from the venue parameter store at the parameter version pinned on the capture, so the note states exactly the inputs the figures used, and an annex generated before a row was signed off or the methodology note put in force keeps its exact bytes and signature. The venue computes no own-funds requirement for you and expresses no view on recognition under the IFR. Full field rules and the column list in the member reference, section 6f. ## 11. Trader IDs and Authorised Users Separate from credentials: a credential says WHICH FIRM is connected, a Trader ID says WHICH PERSON at that firm entered the order (rulebook 5.10 to 5.13). - Venue operations register your **Authorised Users** and issue each one a Trader ID, by default of the form `TR-{memberId}-{8 hex characters}`, for example `TR-12-9F3A21BC`. Treat it as an opaque venue-issued string. A user may additionally be flagged as an Authorised Signatory (may give binding operational instructions, rulebook 3.7). - The order carries it in `reg.traderId`, inside the existing `reg` block: ```json { "symbol": "BTC-USD-PERP", "side": "BUY", "type": "LIMIT", "tif": "GTC", "price": "65000", "qty": "2", "clOrdId": "a1", "clientUid": "CLIENT-A", "reg": { "traderId": "TR-12-9F3A21BC" } } ``` **Enforcement is staged per member**, so nothing breaks on the day your first user is registered: | Your member state | What happens to `reg.traderId` | |---|---| | No Authorised Users registered | Not gated at all. The field is optional; if you send it, it is recorded verbatim. Existing integrations keep working unchanged. | | One or more registered | EVERY order must carry a registered, ACTIVE Trader ID, or it is rejected. | - The rejection is code **2021**, HTTP 400, `reg.traderId missing or not a registered Authorised User`. It is raised before the engine is reached, so nothing is placed. - Enforced **identically on REST, WebSocket and FIX**: all three transports build the order through the same code path, so there is no ungated back door. - On FIX the Trader ID rides **venue tag 9012** on NewOrderSingle. - Margin previews are **never** gated, on either transport: `POST /v1/margin/preview` and the WebSocket `get.marginPreview` op are reads, not order entry, so your risk tooling keeps working whatever your registration state. - Deactivating your last active Authorised User locks order entry (every order then rejects with 2021). Keep at least one active user registered, and tell venue operations before a leaver is removed. Operationally: map each of your dealers, and each algo operator, to a Trader ID at onboarding, carry it through your OMS to order entry, and treat a 2021 as a static-data fault, not a market condition. Retrying the same order without a valid Trader ID will fail identically. Your current list, and whether you are gated yet, are shown in the Member Portal (section 12). ## 12. The Member Portal The Member Portal is a member-facing web application, separate from the API. It is for your operations, risk and back-office staff: it does not place orders, and it is not a substitute for the API. Venue operations issue one portal login per member (your member code plus a password, shown once at issuance). It reads the same numbers your API does, from the same read models. | Area | What you get | |---|---| | Overview | Balances, equity, margin and `riskStatus`, plus member net positions. | | Markets | The live order book per instrument and your own conditional orders on that market. | | Orders | Working orders and conditional (untriggered) orders. | | End clients | Per-end-client sub-positions, the reporting records behind your member net, and funding attributed per end client with CSV export. | | History | Trade, ledger and funding-payment history, filterable, with CSV download. | | Reports | Activity statistics by day, by instrument and by end client. | | API and limits | Your live rate limits, your order-to-trade regime and current window ratio, your engine limits, your credentials (masked) and your registered Authorised Users. | | Kill switch | Cancel every working order across all instruments. | **The kill switch** is member-initiated: cancels reach your API sessions with reason `USER_REQUESTED`, exactly as if you had sent them, and conditional orders are cancelled too. Positions are not touched. A member-wide cancel-all of your own and the cancel on disconnect you armed report `USER_REQUESTED` too: the value does not tell the three apart (`ADMIN_CANCEL` is reserved for cancels by venue operations). **Funding.** Two views, because they answer two different questions. - *History, Funding payments.* One row per funding settlement your member took part in, with the funding rate and the mark the venue used, the amount and your balance after it. The amount is signed from your side: negative means you paid, positive means you received. These are the same ledger entries your balance reconciles to, so this statement is the authority for what funding cost you. CSV download, filterable by instrument and date. - *End clients, Funding per end client.* The lifetime funding attributed to each end-client sub-position, signed from that client's side. This is the attribution record behind the member total: for one market, the per-client figures sum to your member funding for that market. Use it to pass funding through to your own clients. CSV download, filterable by instrument and `clientUid`. Funding is charged on your MEMBER net position, then attributed across your end-client sub-positions in proportion to each one's signed size, so two clients holding opposite sides of the same market can be attributed opposite signs while your member pays or receives only the net. Only clients with an OPEN position in a market are listed: once a client is flat, its funding has already settled into your balance and appears in the Funding payments statement. Every charge is reproducible exactly from the settlement's `fundingRate` and `markPrice` (Member API revision 3.83, section 7, "Reproducing a funding charge"): quantity x `markPrice` x `contractMultiplier` x `fundingRate`, rounded half-even to the micro, on your member net position and on each client sub-position, the member charge minus the sum of the client charges added to the sub-position of the largest absolute size. When your member net position is 0 at the settlement (on a LOCAL_DAILY market, at the snapshot), nothing is booked: no member charge, and no client sub-position is charged, whatever the sub-positions hold. Pass funding through to your clients from that rule or from their booked `accFunding`, never from `fundingPerUnit`: that field is a display figure rounded per lot, so a quantity times it can differ from the booked charge. **The rate is a fraction; the payment is money.** `fundingRate` is a dimensionless fraction of position notional PER INTERVAL, not a currency amount: `0.0001` means 0.01% per interval, so a 100,000 USD long pays 10 USD at each settlement. Every screen and export showing a rate also shows it as a percentage (`fundingRatePct`) and, on the API, annualised (`fundingRateAnnualizedPct`, rate x (365 days / `fundingIntervalHours`) x 100, simple, no compounding). The currency-denominated figure is always the PAYMENT, booked in the instrument's settlement currency; every export carrying a funding amount names that currency in a `settleCcy` column, because settlement is a property of the instrument and not of the venue. Today every listed market settles in USD, and you should still read the column rather than assume it. **Per-lot funding.** `GET /v1/lots` reports what each open lot has been charged. Read it as a presentation of a booked total, never as the total: the venue charges funding on the sub-position NET, so the per-lot number is an attribution. The response says so in three figures, and your reconciliation should use the first one: `accFunding` is what the venue BOOKED on that sub-position, `openLotsFunding` is what the listed lots carry, and `closedLotsFunding` is the financing already paid by quantity that has since been closed. The same caution applies as to per-lot realized PnL. **Self-service credential management.** The portal issues and revokes API credentials for both scopes, `TRADE` and `READ_ONLY` (section 10), up to 5 keys per scope. Treat revocation as a live operation: - The new secret is displayed **exactly once**. It cannot be retrieved later. - Issuing a key changes nothing else: every existing key keeps working. This is the failover pattern, issue the new key, migrate the integration, then revoke the old one. - Revocation takes effect **immediately**, with no grace period: systems signing with the revoked key stop authenticating at once, and live WebSocket and FIX sessions opened with it are cut. Your other keys, in both scopes, keep working. **Portal password.** You can change your portal password yourself, in the portal under Credentials: enter the current password and a new one of 12 to 128 characters (it must differ from the current one), and the change takes effect immediately. The form is throttled: five consecutive wrong entries of the current password lock it for 10 minutes, and after a successful change the next change is accepted no sooner than one minute later. If the password is lost, venue operations can reset it on request; a reset issues a new password shown once, exactly like the original issuance, and the old password stops working at that moment. ## 12a. Verifying the monthly IFR data annex The monthly IFR data annex you download from the Regulatory tab of the Member Portal (section 12; Member Portal Guide section 9) is venue-attributable data for your own IFR monitoring, not a transaction record. This section states what the venue signs, where the verification key is published, how a key is named, which keys have been in force, and how to verify a download without any Kronos X software. **What is signed.** The exact CSV bytes of the annex download (UTF-8, LF line endings, no byte order mark), nothing else. The signature is a DETACHED Ed25519 signature (RFC 8032), 64 bytes, published as base64 in two places: the `X-KronosX-Annex-Signature-Ed25519` response header of the annex download and the `.csv.sig` download beside it (the Signature button). The annex header lines already carry your member code and member id (`# member`), the month, the venue LEI, the parameter version, the engine token and the projection watermark it was generated from, and the venue regenerates the annex byte-identical from those inputs, so the signature is stable across downloads of the same annex. A change of the annex format (an annex header version move, as at revision 3.70) changes the bytes and therefore the signature of a fresh download; a copy you archived earlier still verifies as downloaded. **Where the key is.** The Regulatory tab shows the key beside the Signature button as `Verification key: Ed25519, key id , public key `, and the portal's signing-key read answers `{enabled, algorithm, publicKeyBase64, keyId}`: `publicKeyBase64` is the 32 raw public-key bytes in base64; `enabled` is false and both key fields are null while the venue has not configured signing (the portal says so and offers no `.sig`). The portal you are signed in to is authoritative for the key in force. **Key id.** The first 8 lowercase hex characters of SHA-256 over the 32 raw public-key bytes. It is a label for your key table, nothing else: every annex and `.sig` download also carries it as the `X-KronosX-Annex-Key-Id` response header (both headers reach an HTTP client through the portal; a browser download stores the body only), so a file you archived can be matched later to the key that signed it. **Key table.** The venue does not rotate the key on a calendar. A rotation happens only on suspicion or confirmed compromise of a system holding the key, a personnel change among the people who can read it, or an adverse annual algorithm review; it is announced on the venue events channel and in this table, and an old public key stays listed with its validity window for as long as a download signed under it can exist, so an earlier annex still verifies against the key that signed it. | Key id | Environment | Valid from | Valid to | Status | | --- | --- | --- | --- | --- | | `775faab7` | Sandbox (the development venue) | 2026-08-11 | open | in force | | published at go-live | Production | published at go-live | open | pending | The sandbox key's `publicKeyBase64` is `xN+BBFnwbuxNxYHNGCz9tv7lJbZ44GXnzENJrfS2M5w=` (raw key `c4df810459f06eec4dc581cd182cfdb6fee525b678e065e7cc4349adf4b6339c`, whose SHA-256 begins `775faab7`), as read from the venue's signing-key read on 10 September 2026; the production key and its valid-from date are published here and on the production portal at go-live. **Verification example.** Two recipes, both worked against the RFC 8032 section 7.1 TEST 1 vector so that you can validate the recipe itself without the venue's key. The vector: public key (raw, hex) `d75a980182b10ab7d54bfed3c964073a0ee172f3daa62325af021a68f707511a`, base64 `11qYAYKxCrfVS/7TyWQHOg7hcvPapiMlrwIaaPcHURo=`, key id `21fe31df` (SHA-256 `21fe31dfa154a261626bf854046fd2271b7bed4b6abe45aa58877ef47f9721b9`); message: the single line `# Kronos X IFR data annex v2` followed by one LF (29 bytes); signature (hex) `ccac378177f2856fe372154b87b85226e366d5860cd33bea53ba05cc898960ec9ea3ea0b67fb01c745a1b020d32bde7923e84f57c1da4e80f2a4015a47b5f50e`, base64 `zKw3gXfyhW/jchVLh7hSJuNm1YYM0zvqU7oFzImJYOyeo+oLZ/sBx0WhsCDTK955I+hPV8HaToDypAFaR7X1Dg==`. Python 3 with the `cryptography` package (`publicKeyBase64` from the signing-key read or the key table, `sig` the base64 signature from the header or the `.sig` file, `csv_bytes` the annex file read in binary mode): ```python from base64 import b64decode from cryptography.hazmat.primitives.asymmetric.ed25519 import Ed25519PublicKey key = Ed25519PublicKey.from_public_bytes(b64decode(publicKeyBase64)) key.verify(b64decode(sig), csv_bytes) # raises InvalidSignature on any mismatch ``` OpenSSL 3 (`key.pem` is the PEM wrapping of the SubjectPublicKeyInfo DER `302a300506032b6570032100` followed by the 32 raw key bytes; because that prefix is 12 bytes, the PEM body is always `MCowBQYDK2VwAyEA` followed by `publicKeyBase64`, so for the RFC key it reads `MCowBQYDK2VwAyEA11qYAYKxCrfVS/7TyWQHOg7hcvPapiMlrwIaaPcHURo=` between the `-----BEGIN PUBLIC KEY-----` and `-----END PUBLIC KEY-----` lines; `sig.bin` is the base64-decoded signature, 64 bytes; `annex.csv` is the download, unchanged): ``` openssl pkeyutl -verify -pubin -inkey key.pem -rawin -in annex.csv -sigfile sig.bin ``` The expected output is `Signature Verified Successfully`; any other output means the bytes, the key and the signature do not belong together (a text editor that rewrites line endings or adds a byte order mark is the usual cause). The venue's own test suite pins the same vector, so a recipe that verifies it is the recipe the venue uses. ## 13. Connectivity and recovery Three transports, one engine, one set of rules: - **REST** for requests and history. - **WebSocket** for streaming (order, execution, wallet, position, venueEvents, market data) and for order entry with the same semantics as REST. - **FIX 4.4** for order entry plus an ExecutionReport drop copy and a streaming market data feed (snapshot 35=W, incremental 35=X, public trade tape). **Recovery is the same everywhere.** Guaranteed channels are never silently dropped. If your consumer stalls you receive a terminal gap frame and a disconnect (WebSocket close 4008, FIX Logout). A venue restart is announced the same deliberate way: every WebSocket receives an advisory frame and then close `1001` with reason `venue restart`, every FIX session a `Logout(35=5)` with `Text(58)="venue restart"`, and new WebSocket upgrades answer HTTP 503 while the venue is stopping; subscriptions and cancel-on-disconnect arming are not preserved. The venue sends the same advisory, close and Logout, while it keeps running, to every session that may have missed a frame when a venue-side fault lost frames of one command or batch (the command itself executed). The venue keeps running then, so new upgrades are not refused; the backfill below delivers every missed frame of the guaranteed families, and for `rfq`, `barriers`, `venueEvents` and the best-effort families you re-read state, exactly as after a restart. The venue adds no other close code or reason for it. After ANY disconnect, a restart included: reconnect with backoff, log in again by signing the NEW connection's challenge nonce (member API section 10.1; never reuse an old one), resubscribe, then page `GET /v1/stream/events` from your resume point (the ordinal maximum of the `nextCursor` of your last page under the same filter and the cursor of the last event you processed) until the store reports `COMPLETE`, deduplicating by `(seq, eventIndex, leg)`; stop a paging loop on `hasMore` false or `count` 0, never on `nextCursor` equal to the `afterCursor` you sent (since member API revision 3.73 a last page answers a position at the store watermark, valid only with the same `channels` and `symbol`, on an environment from the date venue operations announce for it there). This is a durable, totally ordered log; it is the authoritative way to prove you missed nothing. The one exception is the `rfq` and `barriers` channels: guaranteed, but recovered by state re-read, not by cursor (section 6.4). **The store can read `REPAIRING`.** The `store.status` of a backfill page describes the store of the node that answered. `REPAIRING` means it has a recorded hole: pages stop below it rather than skip it, so keep polling from your last cursor, recover the state you need from the state reads, and raise an operational alert. It starts at every leader change of a clustered venue, no timeout ends it and the venue sets no maximum duration; `lagSeq` then counts from the start of the hole to the engine head, and `GET /v1/executions` and `GET /v1/account/ledger` serve only rows at or below the watermark (Member API section 11.3, revision 3.83). Trading and the live feeds do not depend on the store. **Leader change (clustered deployments, among them the clustered sandbox of Member API revision 3.83 from the date venue operations announce).** Each environment publishes ONE entry host, which sends new connections to the node that accepts writes, the leader; the sandbox at `sandbox.mtf.perpetuals.net` runs three nodes behind it. Never pin a node. When leadership moves, the former leader closes every WebSocket with the advisory `leaderChange` and close `1001` reason `leader change, reconnect` and logs every FIX session out with `Text(58)="leader change, reconnect"`; reconnect to your entry host, re-arm cancel-on-disconnect (a leader change voids it and fires nothing) and recover as above. A node that is not the leader answers every request that is not a `GET` under `/v1`, and every WebSocket write op, with `5030` and the hint `leader`, the environment's published entry host; it never forwards a write, closes every HTTP connection after its answer, but does not close a WebSocket opened on it, so close that socket yourself. A `5030` is a redirect, never a rejection: follow the hint only when it equals the entry host you configured (otherwise send no credentials there and tell venue operations), send the request again with the SAME `clOrdId`, and a cancel, cancel-all or amendment answered `5030` at once, because it did not take effect. None of these other answers proves that a write was not executed: a single write's `5001`, a `5000` on a write whose commit the venue did not confirm within 10 seconds, a batch row's `5000`, no answer at all. Reconcile those by `clOrdId` on the leader before resubmitting, never under a new reference. A leader change pulls no resting order (Member API section 10.7). For Conformance Test Plan case I-05 venue operations stage a leader hand-over on the sandbox at an agreed time. ## 14. Pre-production checklist 1. Signer verified against the worked examples, the WebSocket login over the connection's challenge nonce included; every send, a retry included, signed with a fresh timestamp (member API revision 3.85). 2. Instruments fetched; all prices and quantities aligned from venue data. 3. Every order type in section 3 exercised on sandbox, including MARKET+FOK unfillable and POST_ONLY rejected. 4. Unknown-field rejection (2017) observed and understood. 5. Order state machine handles the full `cancelReason` set, including the venue-initiated ones. 6. Unsolicited flow handled: cancels and executions for orders you never sent. 7. Book maintained with checksum verification for 5 minutes without divergence. 8. Socket killed mid-flow; gap-free recovery proven via `/v1/stream/events`. 9. Per-client sub-positions reconciled against `/v1/reconciliation/end-client-positions`. 10. Read-only credential issued for your back-office systems. 11. Trader ID position agreed with venue operations: either you have no Authorised Users registered yet, or your order path carries a valid `reg.traderId` (tag 9012 on FIX) and your handling of 2021 is tested. 12. If you will trade RFQ markets: the full life cycle exercised on sandbox (create, quote, accept, both cancel paths, an expiry), and a 2022 observed on order entry to an RFQ market. 13. If you will trade barrier markets: the section 6.3 worked example reproduced on sandbox, the margin reservation verified, a knock-out observed settling at the barrier price, and recovery proven by re-reading `/v1/rfq/mine`, `/v1/rfq/open` and `/v1/barriers` after a killed socket. 14. Leader change exercised at the hand-over venue operations stage on the clustered sandbox (Conformance Test Plan I-05): a `5030` followed only to your configured entry host and never counted as a reject, cancels answered `5030` sent again at once, cancel-on-disconnect re-armed, and a write answered `5001` or `5000` meanwhile reconciled by `clOrdId`.