Trading rules

The venue's trading manual: 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. This page is normative about behaviour. The wire formats live in REST, WebSocket and FIX; every numeric code is listed in the code reference.

Trading model

You are the member. The venue's counterparty is your firm: it holds the trading account, the margin, the API credentials and the legal relationship. Your end clients are known to the venue only through clientUid, an opaque reporting identifier you choose. The venue holds no name, no KYC and no personal data for an end client and cannot resolve a clientUid to a person.

Every order carries exactly one clientUid. A fill affects exactly the sub-position of that clientUid. The venue never offsets one end client's open interest against another's and never aggregates two end clients' orders into a single execution. What it does do is compute all risk on your member net position.

Sub-positions are exact, durable and reconcilable through GET /v1/positions/end-clients, but they are reporting objects. The risk engine never reads them. Three consequences follow directly and each one has bitten an integration.

The third consequence is that per-end-client leverage limits are yours to enforce, covered under Margin, leverage and fees below.

Trading hours and planned maintenance

Every market 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, with no daily open, close or auction on any market other than a SECURITY market with an auction block, whose calls are its daily open and close (tradingHours SCHEDULED, member reference section 6j); the underlying reference market of a tradfi perpetual keeps its own opening hours while the contract trades on. Trading in a market is interrupted only by a suspension, halt or removal under the Rulebook (including a venue-wide suspension), by the circuit breaker, or by the reduce-only and post-only sessions (Halts and suspensions below, and GET /v1/status); the trading state of every market is published at all times on GET /v1/status, GET /v1/instruments and the venueEvents channel, and every instrument row carries tradingHours, CONTINUOUS on every listing (open set). Funding settles on the schedule published per market whether or not the underlying reference market is open; daily allowances and daily flow statements are kept per UTC calendar day.

The venue operates no daily or weekly closure. The only scheduled interruption is the standard maintenance window, Saturday 02:00 to 06:00 UTC, published 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, and a release that requires the venue to stop is announced on the Website at least five Business Days ahead, naming the date, the start time in UTC and the expected duration, placed outside funding and settlement times. Most releases are rolling and need no window; one that needs it is executed with the restart procedure of the WebSocket page (advisory frame, close 1001, 503 with Retry-After, FIX Logout, cursor backfill): resting orders, positions, standing offers and open contracts survive it, subscriptions and cancel-on-disconnect arming do not, and trading resumes without an opening auction. A scheduled closure outside the window is published on the Website in advance with the notice the Rulebook requires for a material amendment; a stop without notice remains possible under the Rulebook's provision on suspension in response to system disruptions.

Instrument mechanics

Read GET /v1/instruments at startup and cache it. Never hard-code any of these values: sandbox and production configurations differ, and most parameters are reconfigured in place. The grid is the exception: a tickSize or qtyStep change is never made in place but by a re-listing (below).

A grid change is a re-listing (revision 3.83). Every resting order and open position is held on the market's grid, so the venue's listing controls refuse an in-place change of tickSize or qtyStep on every market kind. A re-listing is announced in writing in advance (the market, the new values, the date). On the date the market is delisted (STOP_TRADING with reason DELISTING, every working and pending-trigger order cancelled with INSTRUMENT_HALT, 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, 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 and re-read the instruments after the announced date. minNotional is not part of the grid and may change in place.

Two rejects sit alongside the instrument grid and are frequently confused. 3003 means the instrument is halted: temporary, worth retrying. 3006 means delisted: permanent for that listing, stop retrying (a re-listing brings the symbol back as a new market). 3005 means the instrument has no sequenced mark price yet, which is neither of those; the market is open but has no priced basis for margin or bands, so wait for the feed.

Contract sizing: qtyStep, minQty and minNotional (reject 2028)

Order types

Every order needs symbol, side, type, tif, qty, clientUid and a clOrdId you generate (36 characters maximum, unique per member per 24 hours). Order entry is strict: an unknown JSON field is rejected with 2017, never ignored. This is deliberate. A silently discarded displayQty or postOnly would let you believe a constraint applied that never did.

LIMIT

A price you will not cross. It trades immediately against everything eligible at or better than your price, then the remainder rests.

{
  "symbol": "BTC-USD-PERP",
  "side": "BUY",
  "type": "LIMIT",
  "tif": "GTC",
  "price": "65000",
  "qty": "2",
  "clOrdId": "a1f3c9d24b7e4f10",
  "clientUid": "CLIENT-A"
}

• The price band is checked at entry against the last sequenced mark: outside it, 2003. Note that the band is checked on immediate limit orders only, and on every amend of one, a quantity-only amend included (against its unchanged price, so a resting order the mark has moved away from can draw 2003 on a size reduction). Conditional orders are band-exempt throughout: neither the trigger price nor the post-trigger limit price is band-checked, at entry, on amend or at activation, so a triggered child can start working at a price the band would have refused on a direct order. Nor is a triggered limit child collared: the protection collar applies to MARKET orders and the children of STOP_MARKET and TAKE_PROFIT_MARKET only, so a STOP_LIMIT or TAKE_PROFIT_LIMIT child trades through the book up to its limitPrice, however far that lies from the mark. The venue keeps this exemption by decision (revision 3.83 states it in the member reference): choose limitPrice as the worst price you accept when the trigger fires.
• Partial fills are normal. The order reads PARTIALLY_FILLED on the order reads and the remainder keeps working at its original queue position; the WebSocket order channel reports the partial fill on execution only and reads NEW until the order completes.
• Price improvement is real: you trade at the resting order's price, not yours. A buy at "65000" hitting an offer at "64990" prints "64990".

MARKET

You send no price. The venue computes a protection collar from the best eligible opposing price and marketMaxSlippageBps, and the order then behaves exactly 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.

{
  "symbol": "BTC-USD-PERP",
  "side": "BUY",
  "type": "MARKET",
  "tif": "IOC",
  "qty": "1",
  "clOrdId": "m7b2e4a1c8d09f36",
  "clientUid": "CLIENT-B"
}

With a best eligible offer of "65000" and marketMaxSlippageBps of 50, the collar is 65000 + floor(65000 x 50 / 10000) = "65325". Everything at or below "65325" is available to you; anything above it is not, and the unfilled remainder cancels.

• Empty or fully ineligible book: rejected 2007. The collar cannot be formed without a best eligible price, so there is nothing to check the order against.
• Omit price entirely. Sending one is a malformed order.
• MARKET with POST_ONLY or GTD is rejected with 2013: neither combination has a meaning.
• A market order never rests. Under GTC or IOC an unfilled remainder is cancelled with IOC_REMAINDER. Under FOK the reason differs: an order that cannot fill completely inside the collar cancels untraded with FOK_UNFILLABLE, so do not hard-code one cancel reason for market orders.

STOP_MARKET and STOP_LIMIT

Conditional orders. They are invisible to the book and consume no queue position until they trigger; their status is PENDING_TRIGGER throughout. On trigger, STOP_MARKET becomes a market order (collar computed at that moment, from the book as it then is) and STOP_LIMIT becomes a limit order at trigger.limitPrice.

{
  "symbol": "BTC-USD-PERP",
  "side": "SELL",
  "type": "STOP_LIMIT",
  "tif": "GTC",
  "qty": "1",
  "clOrdId": "s4e8a0c7b1d25f93",
  "clientUid": "CLIENT-A",
  "trigger": {
    "source": "MARK",
    "price": "60000",
    "direction": "AT_OR_BELOW",
    "limitPrice": "59900"
  }
}

Prefer MARK for protective stops. A single small print at a bad price moves LAST and can arm your stop into a book that has not actually moved; the mark is constructed to resist exactly that. The stronger reason is consistency: the venue liquidates you on the mark, so a stop referenced to the mark measures the same thing your risk does. A LAST-referenced stop can sit untriggered while the mark walks you into a margin call.

• direction is AT_OR_ABOVE or AT_OR_BELOW and is not inferred from the side. Conventional use is at-or-below for a sell stop and at-or-above for a buy stop, but the venue does not enforce the convention, so a mis-set direction produces an order that triggers immediately or never. Check it in your own validation.
• 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; there is no third option.
• Triggers are evaluated inside the same deterministic command that moved the price, so one large print can trigger a conditional and fill it in a single step, with no window in between for you to cancel.
• Untriggered conditionals still consume order margin, valued at the worst of their trigger price, their limit price and the current mark.

TAKE_PROFIT_MARKET and TAKE_PROFIT_LIMIT

Mechanically identical to the stop family: same trigger block, same sources, same directions, same activation path. The distinct type name documents intent (the trigger is conventionally on the profitable side) and is preserved on every execution record and regulatory extract, which is why you should use it rather than expressing a take-profit as a stop.

{
  "symbol": "ETH-USD-PERP",
  "side": "SELL",
  "type": "TAKE_PROFIT_MARKET",
  "tif": "IOC",
  "qty": "10",
  "reduceOnly": true,
  "clOrdId": "t9c1b6d38e0a4f27",
  "clientUid": "CLIENT-C",
  "trigger": {
    "source": "MARK",
    "price": "4200",
    "direction": "AT_OR_ABOVE"
  }
}

Time in force

The FOK feasibility test is not a naive depth sum. It simulates the walk the engine would actually perform, honouring counterparty eligibility, your STP policy's stopping behaviour, the execution-time reduce-only cap on each maker, the funding of BOTH sides on spot, and the venue's exact-money range on a perpetual. That is what makes all-or-none exact: the venue never cancels a FOK that could have filled, and never fills one partially.

Two consequences for your cancel-reason handling, neither reachable at any tradable size. A perpetual FOK whose settlement would take a position past the venue's exact-money range now cancels whole with FOK_UNFILLABLE and no executions, where it used to fill what fitted and then cancel with POSITION_SIZE_LIMIT. A conditional spot FOK whose base asset left the account between acceptance and trigger now cancels whole with FOK_UNFILLABLE and delivers nothing, where it used to deliver what was still funded and then cancel with SPOT_UNFUNDED. Both of those reasons are unchanged on every other order type, where they still arrive as venue-initiated cancels: it is the FOK contract, not the guard, that changed.

What the venue does not offer

Stated plainly, so you do not build against a feature that is not there.

No iceberg or reserve orders

There is no hidden-quantity order type. A displayQty field is rejected with 2017 as an unknown field, not silently ignored, so a client that assumes icebergs will fail loudly on its first order rather than quietly showing full size.

The correct client-side substitute is order slicing: rest a child of your display size and submit the next child on each fill. Four rules make it work:

• A fresh child joins the BACK of the queue at its price. This is the whole cost of the technique and it is unavoidable: price-time priority is absolute, and a new order is new. A real iceberg refill behaves identically on any venue that implements it fairly, so slicing is not worse than an iceberg on queue position; it is worse only on message count.
• Randomise child size within a band. A constant child size is trivially detectable and defeats the purpose.
• Do not resubmit faster than your fills arrive. Every child is an order message, and it is spent twice over. It draws a token from the order bucket, 40000 order messages per minute, which is a wholly independent bucket from the 6000 reads per minute read bucket: order entry does not consume a read token, and reads never throttle order flow. It also counts toward the order-to-trade regime, which blocks new orders and amendments with 1004 until your ratio recovers. Cancels consume neither bucket but still count toward the ratio, so a fast slicer that cancels and replaces is charged for both legs.
• Keep one clOrdId per child and track the parent yourself. The venue has no parent-child concept and will never link them for you.

No trailing stops

Any trailing parameter is rejected, 2004 if it reaches the type check and 2017 as a stray field. Implement trailing on your side: watch the mark and amend or replace your stop. The reason this is not a venue feature is determinism. A venue-side trailing stop is a hidden order whose resting price depends on a continuous price history rather than on the command sequence, and the venue's core guarantee is that the same commands replayed produce the same state byte for byte, which is what makes every dispute answerable.

No pegged orders, no auctions

There are no pegged or discretionary order types and no opening, closing or intraday auctions in this release. The book is continuous from the moment an instrument is live. There is no good-till-crossing session. Halts are exactly that: order entry rejects with 3003 and resting orders remain in place, with no auction to reopen the market.

reduceOnly semantics

reduceOnly is a perp-only flag that refuses to increase your position. It is checked twice.

At admission. The order is rejected with 2008 unless your member net position in that instrument is non-zero, your side is the reducing side (sell against a long, buy against a short), and the sum of your already-pending reduce-only quantity on that side plus this order's quantity does not exceed the absolute net. Untriggered conditionals count against the same budget, so a stack of protective stops cannot silently over-commit.

At execution. A resting reduce-only order fills at most the maker's reducible quantity at that instant. If the position has already gone flat, the order is cancelled with REDUCE_ONLY_VIOLATION; if it has shrunk, the fill is trimmed to what remains reducible. This second check exists because the position can move between admission and fill through another of your orders, through funding or through a venue-initiated close. Independently, when your member position shrinks the venue trims your reduce-only orders, resting ones and untriggered conditional ones alike, newest first, or cancels them with REDUCE_ONLY_VIOLATION; a trim arrives unsolicited as OrderAmended (FIX 150=5).

• A client closing its own position can be refused. Client A is long 10 and your aggregate book leans short. A reduce-only sell for client A is rejected with 2008 REDUCE_ONLY_VIOLATION, even though client A genuinely holds the 10 it is trying to close.
• A perfectly netted member book refuses every reduce-only order. Client A long 10, client B short 10, member net exactly zero. Every reduce-only order on that instrument is rejected with 2008, from either client, on either side. There is nothing to reduce at member level, so there is no budget to spend, and the venue never looks any deeper.
• The mirror case is just as real. With client A long 10 and client B flat, a reduce-only sell submitted under client B's clientUid is admitted, because the venue judges it against the net.

What the flag is actually for. It is a venue-enforced guarantee that an order can only SHRINK your member's own house exposure, checked by the engine rather than trusted to your system. That is what you want when a risk desk is flattening the member book during a margin call: every order it sends is provably incapable of adding risk, whatever else is in flight, and the venue trims or cancels it as the position shrinks under it.

One useful property: reduce-only orders consume no order margin, because by construction they cannot increase exposure.

Matching

Price-time priority. Best price first; at equal price, earliest accepted first. Acceptance time is the sequencer's, not your clock's, and it is fixed at acceptance. An amend that changes price or quantity upward creates a new priority; nothing else moves you in the queue.

Exact integer arithmetic. Prices are integer ticks, quantities integer lots, money integer micro units. Notionals are staged through 128-bit intermediates and rounded by an explicit rule (ceiling for margin, half-even for fees), never by floating point. Two members computing the same fill from the same inputs get the same answer to the last micro unit, which is what makes the reconciliation endpoints meaningful.

Self-trade prevention

STP applies when two orders of the same member meet and are not exempted by scope. Under the default END_CLIENT scope, two of your orders with different clientUid values are not a self-trade at all and execute normally. Orders carrying the same clientUid never trade with each other; your configured policy applies instead.

That last row is the one to code for. Under REJECT_TAKER the same logical event reaches you as a reject or as a cancel depending on whether any quantity had already traded, so a state machine that expects only one of the two will desynchronise on a busy book.

Market Segments

Market Segments is the venue's counterparty-acceptance mechanism: you may restrict which members you are willing to trade with, and matching requires mutual acceptance. The default is open to all. Restricted liquidity stays visible in the full public book (the venue never hides depth), but your matchable book, GET /v1/orderbook/matchable, shows only what you can actually hit, and it is that book your pricing logic should read. Ineligible resting orders are skipped during the walk and keep their queue position; they are neither cancelled nor disadvantaged. Price-time priority is therefore honoured strictly within your accepted set, which means you can print at a worse price than the visible top of book when the better-priced liquidity belongs to a member outside your set. Segments apply identically on perp and spot markets. They do not apply to ADL, which is a rulebook disclosure rather than an oversight: a deleveraging cannot be selective about its counterparties and remain fair.

Margin, leverage and fees

Margin is computed and enforced at member level only, cross-margined per settlement currency. Initial margin (IM) is charged on positions and on working orders; maintenance margin (MM) is the level below which the liquidation waterfall opens.

• Risk tiers are marginal, like tax brackets. Each notional slice pays its own tier's rate and the slices are summed, each ceiling-rounded. A position of "1500000" notional against tiers of 1 percent up to "1000000" and 2 percent above it costs 10000 + 10000 = "20000" IM, not 2 percent of the whole.
• Order margin is worst case and one-sided. Each risk-increasing open order is valued at the worst of its limit price, its trigger price, its post-trigger limit price and the current mark. Buy-side and sell-side notionals are summed separately per instrument and only the larger side is charged, because only one side can fill against you first. Reduce-only orders are excluded entirely.
• The imMultiplier raises IM only. If the venue runs your account at a stricter margin profile, the multiplier (on GET /v1/account, "1" unless applied as a published class or a Rules measure) scales your initial margin. Maintenance margin is unaffected, so a stricter profile makes you stop earlier without moving your liquidation point.

Send {"orders": [ ... ]} with the same bodies you would place, and get back indicative accepted, im, mm and available. The array is priced as one basket of 1 to 50 entries: all of them together, on top of what you already hold, with the same one-sided netting per instrument that resting orders receive, so it answers "would ALL of these clear at once" and the result does not depend on array order. It runs the identical margin function the engine runs, on the identical state, so it is the correct way to answer "will this be rejected" without consuming your order bucket. It is a read, not a write, and a READ_ONLY credential can call it.

accepted applies the same admission rules order entry applies, entry by entry: available, the per-order size cap, the minNotional floor, the position cap and the reduce-only budget, with the reduce-only exemptions intact. A reduceOnly entry is exempt from the available gate, from minNotional and from the position cap exactly as it is when you send it, so a reduce-only basket previewed during a margin call answers accepted: true, which is the answer that matters when you are trying to get smaller. It is not exempt from the per-order size cap, and it is held to the reduce-only budget instead of the position cap: a reduceOnly order may only close what you hold, so a basket that would close MORE than your open position on that market (counting the reduce-only quantity already working) answers accepted: false, because sending it would place the first entries and reject the surplus with 2008. A MARKET entry is valued at the current mark, on perpetual and spot markets alike, which is the same price the per-order cap and the minNotional floor use; the collar a market order actually takes forms from the book at the instant of entry, so treat a market entry's answer as an indication at today's mark rather than a quote.

Fees are maker and taker rates per member, visible as makerFeeRate and takerFeeRate on GET /v1/account (null means the instrument default applies). Rates come from your fee tier, agreed at onboarding. They are applied to the fill notional, rounded half-even per fill, charged in the settlement currency at fill time, and visible on the wallet channel and in the ledger.

Funding settles on every perp at fixed UTC anchors, interval per instrument and 8 hours on all current instruments. A positive rate means longs pay shorts. Funding moves cash, so it can move you into a margin call between two of your own orders. Funding settles EVERY elapsed anchor: after a venue outage spanning several anchors you receive one FundingSettled event and one ledger entry per missed anchor, each computed at the rate in force (the published fixedRate on a market whose funding.rateSource is FIXED, else the last sequenced tick rate) and the last sequenced mark, at most 8 anchors per settlement with any remainder following on subsequent timer ticks about 30 seconds apart, and GET /v1/funding/history row counts reflect every settled anchor. Funding never settles on a mark the venue holds as stale (revision 3.70): while a market is in reduce-only for STALE_MARK_PRICE, or its last mark is older than the market's staleness threshold, due anchors wait and are settled at the first settlement after the market leaves reduce-only, each at the then rate in force and mark on the positions held at that settlement, with the anchor as settleTs and the settlement time as settledTs on GET /v1/funding/history; the catch-up after a venue outage waits for the mark feed the same way. Funding catch-up fence (revision 3.70): while a GRID perpetual's next settlement is more than 60 seconds overdue (after an outage or a leadership change, until the catch-up settlement lands) the venue refuses every order that does not carry reduceOnly (a client-level close sent without the flag included, stated since revision 3.80), every non-reduce-only amend and every RFQ acceptance on that market with code 3014 FUNDING_CATCH_UP, and a conditional order whose trigger fires inside the window is canceled with cancelReason FUNDING_CATCH_UP instead of executing; reduce-only orders and amends are admitted throughout. The fence makes the positions charged for a missed anchor exactly the positions that held through the gap. It lifts on the settlement itself, the FUNDING_SETTLED events, normally within one to two seconds of the venue resuming; retry then, or poll GET /v1/funding/current until nextFundingTs lies in the future. The venue settles every overdue anchor before it opens any listener after a restart, so in the ordinary case the window is closed before you can reconnect. Both rules are dormant on the sandbox until the operator decision batch epoch announced by venue operations and live on production from the first day.

Spot markets

Spot instruments ("kind": "SPOT") trade the base asset against the settlement currency with real delivery and full prefunding. No leverage, no short selling, no funding, no positions and no liquidation of spot balances. The order model, the book, market data, STP and Market Segments behave exactly as on perps. The differences are all about funding.

Current spot listings (revision 3.50, sandbox; informative, always read GET /v1/instruments): BTC-USD, ETH-USD, SOL-USD, BNB-USD and XRP-USD, each a central limit order book ("mode": "ORDER_BOOK") on the plain pair symbol, one book per base asset, USD-quoted and USD-settled, sized exactly like the perpetual of the same underlying (tick 0.5 / 0.05 / 0.01 / 0.05 / 0.0001, qtyStep 0.0001 / 0.001 / 0.01 / 0.001 / 1, minNotional 5 USD, maxOrderNotional 10000000 USD, fees 0.0002 maker / 0.0005 taker). The base asset codes BTC, ETH, SOL, BNB and XRP are the asset values of the assets array on GET /v1/account and the ccy of the asset legs on the private wallet channel; asset balances are decimal strings with up to six decimal places. Spot markets are offered under the venue's MiCA notification: spot fills are not MiFIR transactions, so no RTS 24 order record or RTS 22 transaction report is produced for them.

Reservations are bookkeeping, not escrow, and this has a consequence you must handle:

Settlement is per fill and atomic: the buyer pays notional plus fee and receives the asset; the seller delivers the asset and receives notional minus fee. Because spot trades on the perpetual's fractional grid (qtyStep 0.0001 on BTC-USD, and so on; revision 3.50, earlier revisions said whole units, which described the pre-listing fixture, never a rule), price x qty is exactly your cash leg and qty exactly your asset leg: a fill of 0.0003 BTC at 70000 moves exactly 0.0003 BTC and 21 USD. Asset movements appear on the wallet channel with the asset code in ccy; GET /v1/positions never contains spot rows, and holdings live in assets on the account. Spot asset holdings are not collateral for perp margin.

RFQ markets

Every instrument on GET /v1/instruments carries a mode: ORDER_BOOK or RFQ. Everything above this heading describes order-book markets. An RFQ market has no order book at all: no depth, no resting orders, no conditionals, no order entry. Sending an order to an RFQ market is rejected with 2022, and sending an RFQ operation to an order-book market is rejected with 2023, so a client that confuses the two surfaces fails loudly on its first message. Read the mode at startup with the rest of the instrument record and route accordingly.

Trading on an RFQ market is negotiated in three moves: you open a request, eligible members quote it, you accept exactly one quote. What the accepted quote produces depends on the instrument kind.

Request, quote, accept

{
  "symbol": "BTC-USD-KO",
  "side": "BUY",
  "qty": "2",
  "expiresInMs": 60000,
  "barrier": { "level": "65000" },
  "clOrdId": "r8c2e5a71d4b0f36",
  "clientUid": "CLIENT-A"
}

expiresInMs is the quoting window, default 60000; the engine accepts 1 second to 24 hours, and a window outside those bounds rejects with 2013. qty is a decimal number of units on the qtyStep grid (the perpetual's step on the barrier markets since revision 3.71) and obeys the grid and the order-size cap exactly as an order does (2002 off the grid; 2013 over the cap: maxOrderNotional valued at the current mark where published, else the base-unit maxOrderQty), and the minimum notional applies (100 USD on every barrier market since revision 3.71, 5 USD elsewhere): a request below minNotional valued at the current mark rejects with 2028, as does a quote below it at its quoted entry price, and a close request is valued at the contract's whole quantity, so a contract worth less than the floor at the mark ends at its barrier, its take profit or its expiry and not by an early close. clOrdId, clientUid and the reserved KX- prefix (2020) behave exactly as on order entry, and the Trader ID gate is identical too: a missing or unregistered reg.traderId rejects with 2021 on create, on quote and on accept. The barrier block is required on barrier markets and must be absent on perp and spot RFQ markets (2027 either way); unknown fields reject with 2017. You may hold at most 64 open requests at once (2012).

• Rate limits. Create, quote and accept each draw a token from the order budget, the same 40000 per minute pool that order placements, batch entries and amendments consume; the board and contract reads draw from the read bucket; cancels are never throttled.
• Anonymity is symmetric. The board never names the requester and the requester never learns which maker quoted. Identities meet only in the venue's own records.
• Market Segments apply throughout. A request from a member outside your mutual acceptance set is not on your board, cannot be quoted and cannot be accepted. Eligibility is re-checked at every step: an ineligible maker's attempt to quote sees 2024, and a segment change between quote and accept surfaces at accept as 2025, never as a trade.
• You cannot trade with yourself. Quoting your own request rejects with 2026. clientUid makes no difference here: the scope is the member.
• Margin is checked on both parties at accept. If you, the requester, fail the margin probe, the accept rejects with 3001 (3004 for a spot sell short of the asset). If the maker no longer passes margin or limits, the accept rejects with 3007 and nothing trades; the request stays open with its quotes, so you can accept a different one.
• Expiry is quiet for quotes, evented for requests. A quote past its validity simply stops being acceptable; a request past its window closes with an expired event. Reduce-only sessions block new requests outright with 3002: an RFQ opens new risk and there is no reduce-only RFQ. The instrument gates are otherwise as on order entry: 3003 halted, 3006 delisted, 3005 no mark yet.

RFQ trading is available over REST, with lifecycle pushes over WebSocket. There is no FIX representation of any RFQ message.

Barrier contracts

A barrier contract ("kind": "BARRIER") is a cash-settled knock-out traded only by RFQ. The requester is always the holder: BUY opens a long with the knock-out barrier below the entry, SELL opens a short with the barrier above. The maker writes the contract, and its quote is the entry price. The terms ride the request: barrier.level is required and must sit on the knock-out side of the current mark; barrier.expiryTs (Unix ms, must be in the future) is optional on a market that publishes no maxContractLifeHours, and without it the contract is open-ended there; a market that publishes one (revision 3.70, GET /v1/instruments) requires it at most that many hours after the request (2027 otherwise); barrier.takeProfit (revision 3.43) is optional too, a second exit level on the PROFIT side of the entry (above the mark and the entry for BUY, below both for SELL, so the two levels always bracket the entry) at which the contract also terminates AT the level, fee-free like the knock-out. Both levels are re-validated against the quoted entry at quote time and again at accept, so a negotiation can never place the barrier or the take profit on the wrong side of the entry price. barrier.strictTakeProfit (revision 3.45) is an optional flag on top: a STRICT take-profit contract pays only if the take profit is touched before the contract expiry and needs a takeProfit plus an expiryTs at most 24 hours ahead (below). Every terms violation is 2027. The barrier accept guard (revision 3.55; in force on every environment) additionally fences the OPENING accept against the CURRENT mark: entry within the market's barrierGuard.entryBandBps (50 bps unless the market sets its own; on the sandbox 20 bps on the FX knock-out markets (EUR, GBP and JPY, and since revision 3.75 USDJPY) and 30 bps on the gold and index knock-out markets (XAU, SP500 and NDX100, and since revision 3.75 US500 and US100) from the date venue operations announce) of a fresh mark (2039), no already-reached take profit (2040) or barrier (2043), and both levels at least the market's barrierGuard.minTakeProfitBps / minBarrierBps of the entry (10 bps unless the market sets its own) away from it (2041 / 2042); a refused accept leaves the request and the quote open. Writers: refresh or withdraw your quotes when the mark moves; an unexpired quote can otherwise be accepted against you right up to those fences.

Barrier contracts are bilateral. They never appear in GET /v1/positions, never contribute to open interest and never touch your perp netting. They live on GET /v1/barriers, one row per contract, with your role (HOLDER or WRITER), direction, qty, entry, barrier, the optional take profit, strictTakeProfit, the holder's premium and its premiumBps (revision 3.45), the live mark, barrierDistance (distance to knock-out as a fraction of mark), your role-signed unrealized PnL and your margin; ?status=CLOSED lists your recently settled contracts with the settlement price, your realized PnL and the terminationReason (KNOCK_OUT, TAKE_PROFIT, EXPIRY, TEAR_UP, FINAL_SETTLEMENT, EARLY_CLOSE). The barrier market is its own instrument with its own symbol and its own mark price feed (BTC-USD-KO on the sandbox); knock-out and expiry key off that mark and nothing else. There is no funding on barrier markets.

Early close by RFQ (revision 3.44)

The holder of an open contract can ask its writer to close it before the barrier, the take profit or the expiry gets there. The request is an ordinary POST /v1/rfq on the contract's market that names the contract instead of describing a trade:

{
  "symbol": "BTC-USD-KO",
  "closeContractId": 51,
  "expiresInMs": 120000,
  "clOrdId": "r8c2e5a71d4b0f37"
}

closeContractId is the id of an OPEN contract you HOLD on symbol (from GET /v1/barriers, role HOLDER). side, qty and barrier must be OMITTED (any of them present rejects 2013): the venue derives the CLOSING side (a long holder SELLs, a short holder BUYs), the full contract quantity and the contract's terms, and every RFQ view echoes them together with closeContractId. expiresInMs, clOrdId and reg behave as on any request; clientUid may be omitted (it defaults to the contract's holder-side client) or must equal it (2010). Only the holder may request, at most ONE close request per contract at a time, and an id that is not an open contract you hold on this market rejects 2035 (also when a close request is already open for it, and at accept when the contract terminated between the steps).

Only the writer sees it. A close request is on the board of the contract's WRITER only (GET /v1/rfq/open, and the WS rfq created frame is delivered to the writer with role WRITER); no other member ever sees it, and any other member quoting it is answered 2024. The writer's quote is the price the contract CLOSES at: tick-aligned (2002), inside the price band (2003) as always, and STRICTLY INSIDE the contract's terms relative to the holder's direction, barrier < price < takeProfit for a long holder (when a take profit exists) and mirrored for a short holder, otherwise 2027: a price at or beyond the barrier would exceed the guaranteed maximum loss, at or beyond the take profit the guaranteed maximum gain. Re-quotes replace as always.

Accept closes at the quoted price. The holder's POST /v1/rfq/{rfqId}/accept prints the closing trade, flagged BARRIER_CLOSE (a value in the flags vocabulary above RFQ, so trade history, drop copy and transaction reporting tell a contract's close from its entry), which pays ordinary maker/taker fees exactly like the entry trade (holder taker, writer maker, on qty x price x contract value); then settles the contract BARRIERSETTLE zero-sum, holder PnL = direction x (price - entry) x qty x contract value and the writer the negation, with terminationReason EARLY_CLOSE; and the accept response carries contractId (the closed contract), closeContractId, settlePrice (the quoted price) and your realizedPnl beside the trade fields. The accept re-checks that the contract is still open and held (2035), that the quote still lies inside the terms (2027), the band against the current mark (2003) and member statuses as always. There is NO margin admission check for a close, because closing releases margin; only the exact-money fence stays (2027).

Coupling. While a close request is open the contract refuses a second one (2035). If the contract terminates first, by knock-out, take profit, expiry, tear-up or final settlement, the venue CANCELS the open close request in the same command (an rfq canceled frame, an ordinary cancel), so no quote can land on a contract that no longer exists; when the request ends (accept, cancel, expiry) the contract is free for a new one. Cancelling a close request (POST /v1/rfq/{rfqId}/cancel) is free like every cancel.

The premium, the knock-out rebate and the strict take profit (revision 3.45)

The holder's maximum loss on a contract is its premium: a share of the entry-to-barrier distance times quantity, |entry - barrier| x qty x contract value x premiumBps / 10000 (floored to 6 places). premiumBps is FROZEN on the contract at the open and published on every barrier surface: 10000 - knockOutRebateBps on a normal contract, where knockOutRebateBps is the market's knock-out rebate from GET /v1/instruments (1000 bps = 10 percent on every barrier market listed today, so the premium is 90 percent of the distance); the market's strictTakeProfitPremiumBps on a strict take-profit contract (5000 bps = 50 percent today); and 10000, the full distance, on every contract opened before the rebate existed. The premium is what the holder margins at entry, what it loses at a knock-out (the writer receives it, and the rebate share of the distance is what the holder recovers from the writer at that moment) and the floor of every other settlement.

Strict take profit. barrier.strictTakeProfit: true asks for a contract that pays ONLY if the take profit is touched before the contract expiry: at the expiry without a touch the holder loses the whole (strict) premium whatever the mark, however close it is (terminationReason EXPIRY, holder realizedPnl = minus the premium), and "before" is strict: a price tick that arrives at or after expiryTs settles the expiry even if that tick is at or beyond the take profit (a normal contract's take profit is guaranteed on such a tick, a strict contract's is not). It requires a takeProfit, an expiryTs at most 24 hours after the request and a market whose strictTakeProfitPremiumBps is nonzero, else 2027; the share is re-checked at accept and frozen onto the contract. A knock-out, a take-profit touch and an early close settle exactly as on a normal contract; only the expiry differs. Absent or false = a normal contract.

Tear-up is two-sided: a member entering liquidation, holder or writer, has every barrier contract it is party to closed at the barrier-clamped mark inside the episode, its open requests cancelled and its outstanding quotes withdrawn. The contract itself, however, can never cause its holder's liquidation: the holder's requirement is the REMAINING distance from the mark to the barrier less the rebate (IM equals MM), so the unrealized loss and the released requirement cancel tick for tick and the holder's equity-minus-MM contribution stays constant, at minus the premium, from entry to knock-out. An account funded with exactly the premium rides to the barrier and ends at zero, never in an episode. The flip side: unrealized profit on the contract stays reserved until the contract closes, and losses on the member's OTHER positions remain able to force the whole account into liquidation.

A close books its PnL as a zero-sum pair of ledger entries of kind BARRIERSETTLE, the holder's PnL against the writer's exact negation, visible on the wallet channel and in the ledger like any other cash movement (an early close books its fee legs separately, as ordinary FEE entries against the closing trade). A close at exactly the entry price has nothing to book.

How many contracts you may hold at once. Alongside the size caps, an accept is refused if it would take you past 256 open barrier contracts (holder or writer, all barrier markets together), or take the market past 4096 open contracts. Your own limit answers 2011; the quoting member's answers 3007, the same codes the size caps use. These bound how much work each open contract adds to every margin calculation and every price tick, they are not risk limits, and they release as contracts knock out, take profit, expire or settle. No member is near either.

Yield contracts

A SWAP market ("kind": "SWAP", always RFQ; six on the sandbox: USD-TBILL-SWAP, EUR-TBILL-SWAP, BTC-STAKE-SWAP, ETH-STAKE-SWAP, SOL-STAKE-SWAP, USD1-STAKE-SWAP) trades a bilateral yield contract in ONE asset, the market's baseAsset. A writer posts a standing offer with POST /v1/rfq: qty (the size on offer), rateBps (the annualised rate it pays, whole basis points), tenorDays, an optional minQty (smallest single take, floor: the market's minNotional) and expiresInMs (validity 60 s to 30 days, default 24 h); no side, no barrier. Any other member takes a size with POST /v1/rfq/{rfqId}/accept and qty, no quoteId; the board of offers is GET /v1/rfq/open?symbol=, writers anonymous, best rate first, your own offers excluded. Partial takes are normal (remainingQty on every view; a take below the minimum is admitted only when it clears the whole remainder); the writer withdraws the rest with the ordinary cancel; the offer lapses at its validity end.

Each take is a contract. The taker's qty moves to the writer at once as principal (a SWAPPRINCIPAL wallet entry in the asset), both pay the market's fee on the notional in the asset (writer maker 1 bps, taker taker 2 bps on every listing, the instrument rates for every member since revision 3.70: fee tiers and programmes do not apply on swap markets; nothing at maturity), a trade flagged SWAP prints with price = the rate in basis points, and reward = floor(notional x rateBps x tenorDays / 3,650,000) in the asset (ACT/365, floor to the 6th decimal) is frozen. At maturity, exactly tenorDays x 24 h after the take, the venue's timer pays principal plus reward from the writer to the taker (a SWAPSETTLE entry): in full, the contract closes MATURED; short, the part the writer can pay moves, the rest stays as the taker's CLAIM (contract DEFAULTED), the writer's offers are withdrawn, it may post no new offer while any claim of its is open (3008), and every later tick retries the claim from whatever it can then pay until the contract closes CURED. A halted swap market takes no offers or takes but still matures; a delisting withdraws every standing offer on the market and then settles principal plus the pro rata reward (FINAL_SETTLEMENT). A writer in default management on the venue (in liquidation or default) pays no swap settlement while it lasts, exactly like a withdrawal: such a maturity leaves the whole due as a claim, cured in full on the first tick after the freeze lifts. Contracts ride through a party's liquidation and cannot be closed early. Your contracts, both roles, are GET /v1/swaps; nothing about a swap ever appears in GET /v1/positions, open interest or margin.

Streaming and recovery

Three private channels cover the whole lifecycle, all with guaranteed delivery.

The open board is deliberately not pushed: poll GET /v1/rfq/open. Pushing every new request to every member would leak across Market Segments. The one push beyond the requester is the close request's created frame to the contract's writer: it has exactly one eligible quoter, so nothing leaks.

The RFQ surface adds twelve codes to the registry. As everywhere, the numeric code is the contract and the message is advisory.

Venue-initiated flow

The venue acts on your account without a request from you. There are exactly four mechanisms and none of them is optional to handle.

Margin call

When equity falls below total initial margin, your riskStatus becomes MARGINCALL and a MARGIN_CALL message with state: "ACTIVE" is published on the venueEvents channel, carrying equity, IM, MM, available and the currency. Recovery publishes CLEARED. Nothing is cancelled and nothing is closed at this stage: it is a notice. Add margin or reduce.

Liquidation

When equity falls below maintenance margin while you hold exposure, an unwind episode opens and the waterfall runs in a fixed order. Automatic DETECTION pauses while any market the member holds a position, an open order or barrier exposure on is stale (the staleness reduce-only overlay) or has no mark price yet: the breach re-detects and the episode starts on the first margin sweep after the market recovers. A liquidation ordered by venue operations is not gated by this pause.

1. Your entire order book is cancelled, venue-wide. Every working and pending order across every instrument, perps and spot alike, with cancelReason: "LIQUIDATION_CANCEL". This happens first because cancelling releases order margin and may cure the breach on its own. It is not scoped to the instrument that caused the problem, and a member whose systems have no unsolicited-cancel concept will lose its book without understanding why.
2. Paced closing orders. The venue then works IOC limit orders against the book on a fixed cadence, picking the instrument giving the largest maintenance-margin relief per lot, sizing each slice as a configured fraction of the net position, and pricing at the mark offset by a configured aggression. The episode pauses on an instrument whose mark has gone stale rather than closing you into an unreliable price.
3. Allocation across your end clients. Each slice is split pro rata across the sub-positions holding the same direction, floor pro rata by size with the remainder going to the largest, so every liquidation fill names the clientUid it reduced. Each synthetic order carries the reference KX-LQ-{orderId}.
4. The episode closes as soon as a re-check finds you above maintenance margin or flat.

While the episode is open your own order flow is frozen: new orders and amends reject with 3002 on risk status alone, whatever your member status shows; cancels stay accepted, and withdrawals are refused. The same freeze persists while riskStatus is DEFAULTED after a shortfall, until venue operations clear the default.

ADL

If the book cannot absorb the close and equity has reached zero in a settlement currency where you still hold exposure, the venue tears up matching exposure against counterparty members at the bankruptcy price. Counterparties are selected by a member-level ranking, published to you as a quintile on GET /v1/adl/indicator (5 being first in line): each position scores its unrealized profit as a fraction of its entry notional multiplied by the member's account leverage on that market (divided by it for a losing position), highest score first, ties to the lower member id, refreshed about every 5 seconds; the ranking basis is stated in full on the REST page beside GET /v1/adl/indicator. 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. Both legs of an ADL trade carry KX-ADL-{tradeId}, and the flag on the execution is ADL. An auto-deleveraging close is credited to the counterparty final and immediate at the close-out price; nothing is withheld against the defaulting member's negative balance, which the venue claims separately, and any later recovery reaches the deleveraged members as a RECOVERYDISTRIBUTION ledger entry (revision 3.30). In extreme conditions a venue-generated close (ADL, the one-step liquidation close on an RFQ-mode market, final settlement of a delisted instrument) executes at the nearest representable price rather than the raw bankruptcy or operator price: the venue caps the close price so the settlement amount stays exactly representable, both legs settle at the same capped price, and final settlement applies one uniform effective price to every sub-position on the instrument. No position of tradable size approaches the cap. Both legs of an ADL execution are fee-free, in the classic case and in the one-step close of a liquidated member's position on an RFQ-mode market: no maker, taker or other fee is charged, and the only ledger entry it books on either side is the realized profit or loss (ADLSETTLEMENT).

Halts and suspensions

Circuit breakers, stale marks, administrative halts and delisting stop trading with a typed reason on venueEvents. Order entry then rejects with 3003 (halted, retry after resume), 3006 (delisted, permanent for that listing) or 3005 (no mark yet). A suspended member's working orders are cancelled and new flow rejects with 3002; the same code covers reduce-only and post-only sessions where your order does not meet the session's requirement, and the liquidation or default freeze described above.

Your stops do not fire into a halted market. Conditional orders are not triggered while the market is halted, including a halt raised by the very run of trades that would have triggered them: when a cascade of stops trips the circuit breaker, the stops still pending at that instant stay PENDING_TRIGGER rather than activating into the halted market, and they are evaluated again on the first qualifying price after trading resumes. That price can be materially different from the one that would have triggered them, which is the whole point of the breaker, so size and place stops on the assumption that a violent move can defer them rather than fill them.

The breaker is armed wherever a market can print. Not only while a market is fully trading: a market in REDUCE_ONLY or POST_ONLY still prints, because two members closing opposite positions cross and because a conditional order placed before the session changed can still fill, and the same band applies there. That is deliberate: a restricted session is where a violent print is most likely and least welcome.

Venue-initiated closes stop at the halt as well. A liquidation being worked through the book stops when the market halts, including when it is the liquidation's own trade that trips the breaker, and the remainder is worked on the first step after trading resumes. The part not yet closed is still the member's position, still margined and still inside the open liquidation; the venue does not keep trading it into a market it has just published as halted. If you are on the other side of that flow, expect fewer LIQUIDATION executions in the instant a market halts and the balance of them after it resumes.

One exception, and only one. A breaker halt raised out of a REDUCE_ONLY or POST_ONLY session carries no resume time and ends only when venue operations end it, so waiting is not bounded by anything. If the member being liquidated has no other market left to work and its equity has already reached zero, the venue closes that position by auto deleveraging at the bankruptcy price on the suspended market rather than carrying an uncollateralised position until a person lifts the halt. It is the same last-resort step the waterfall always ends in, applied one market earlier, and it reaches you as an ordinary ADL on venueEvents and in your executions, on a market whose tradingState is HALTED. Nothing else trades there: the book stays closed and member order entry still rejects with 3003. Every other suspension keeps blocking venue-initiated closes outright, including an operations halt and a breaker halt that carries a resume time, because both of those end at a moment the venue already knows.

Of the four stop reasons, only an automatic circuit breaker with a published resume time ends by itself: it is the only one that carries an expectedResumeTs and resumes with reason CIRCUIT_BREAKER_EXPIRY. Every other halt stays in force until venue operations lift it, which covers three cases: a halt raised by venue operations; an operations resume of a breaker halt, which is final rather than a pause in the published cool-down; and a breaker halt raised while the market was in REDUCE_ONLY or POST_ONLY, which carries no expectedResumeTs, because ending it automatically would put the market back into full trading rather than back into the restricted session it interrupted. Treat expectedResumeTs as the venue's current intention, and RESUME_TRADING as the fact.

A STOP_TRADING can repeat for a market you already hold as stopped. It repeats when the reason changes under it, which happens when venue operations take over a halt the breaker had raised: the message carries the same tradingState with reason: "ADMINISTRATIVE" and expectedResumeTs: null, and it supersedes the earlier message for that market. That is published whether or not a resume time had ever been advertised for the halt being taken over. Replace your stored reason and resume time on every STOP_TRADING rather than ignoring the ones that do not change state; the venue never leaves standing a resume time it will not keep.

reason and expectedResumeTs answer different questions. The reason says who stopped the market, the resume time says whether it ends by itself, and a breaker halt with no resume time keeps reporting CIRCUIT_BREAKER for as long as it is in force, on venueEvents and on GET /v1/status, across venue restarts included. ADMINISTRATIVE means venue operations, always. Do not infer the reason from the presence of a resume time, and do not treat a missing one as an operations halt.

Handling unsolicited flow

Two further facts about unsolicited flow. First, venue-generated orders never produce an accept event: a liquidation slice becomes visible only as a fill or a cancel, so a client that requires an accept before it will process a fill will stall. Second, clientUid rides every venue-initiated close and every rejection, so the tuple (clientUid, symbol) resolves any venue action to exactly one of your sub-positions. You are never shown another member's end-client identifiers, on any surface, including ADL allocation reporting.

Before you go live, prove all of this on sandbox: exercise every order type including an unfillable MARKET plus FOK and a rejected POST_ONLY, observe a 2017 unknown-field reject, drive your order state machine through the full cancelReason set including the venue-initiated ones, and reconcile per-client sub-positions against GET /v1/reconciliation/end-client-positions.