Changelog
Trade on KyanKyan Help Centre
Back to All
Improved

v1.19.0 - 2026-05-30

17 days ago by ReadMe CLI

Changed

  • Breaking: Perpetual order size now uses base contracts

    Perpetual orders are denominated in base contracts (the same unit as options) via the canonical contracts field. The legacy amount field (USD notional) is still accepted for backward compatibility — supply exactly one of contracts or amount (supplying both, or neither, is rejected). When using the legacy amount, the notional is converted to contracts at the order price; if a perpetual amount order is submitted without a usable price, it is rejected with VALUE_INVALID. Applies to POST /limit, PATCH /limit, POST /market, and POST /combo. Options are unchanged (always contracts).

  • Breaking: Perpetual minimum order size and size increment are now per-asset, in contracts

    The minimum order size equals the size increment: BTC 0.0001, ETH 0.001, ARB 1 (contracts). This replaces the previous flat $1 USD perpetual size increment. The minimum price increment is unchanged.

  • New contracts and filled_contracts fields on order, fill, and position payloads

    Order and fill responses (POST /market, POST /limit posted, GET /orders, and the WebSocket post_order / update_order / cancel_order and maker-orders events), trade events, and positions (GET /account_state, GET /positions, WebSocket position) now carry canonical base-contract sizes: contracts (order/position size) and filled_contracts (cumulative filled size). For perpetuals the existing size / amount / filled_amount remain the USD notional for backward compatibility; for options they equal the contract count (so filled_contracts equals filled_amount). For positions, contracts is now present on both perpetual and option positions (for options it equals size); a perpetual position's size is the USD notional (average price × contracts) and contracts equals the position delta.

  • Perpetual size error messages now report contracts

    MIN_SIZE_VIOLATION and MIN_INCREMENT_SIZE_VIOLATION messages express perpetual order sizes and limits in contracts rather than USD.

  • Breaking: RFQ perpetual legs are now contracts-only

    RFQ requests and responses must specify perpetual leg size via contracts; the legacy amount field is not accepted on RFQ. The previous RFQ-specific minimums (BTC $200,000 / ETH·ARB $100,000 notional for perpetuals, and 25 / 250 / 25,000 contracts for options) have been removed — RFQ legs now use the same per-asset minimums as regular limit and market orders.

New

  • DELETE /rfq/request

    Takers can cancel their own open RFQ request. Standard requests require an EIP-712 signature over the new CancelRFQRequestType type plus a signature_deadline; one-click trading sessions authenticate via the x-one-click header.

  • RFQ request duration

    POST /rfq/request accepts an optional duration (integer seconds, minimum 300, maximum 1800) controlling how long the request stays open for makers. RFQ requests are now signed (EIP-712) unless submitted via a one-click session.

  • New RFQ EIP-712 signing types

    PostRFQRequestType (with nested RFQOrderType[]), CancelRFQRequestType, and RFQResponseLimitOrder (the UserLimitOrder field set plus a trailing orderId) — see the EIP-712 Signatures guide.

  • New RFQ error codes

    RFQ_REQUEST_ALREADY_EXISTS (HTTP 409, returns the conflicting order_id), RFQ_RESPONSE_ALREADY_EXISTS (HTTP 409, returns the conflicting response_id), RFQ_FILL_TAKER_RISK_FAILED (HTTP 400), and RFQ_FILL_MAKER_RISK_FAILED (HTTP 400).

  • RFQ WebSocket events updated

    The rfq_request event was renamed to rfq_post_request, and rfq_cancel_request and rfq_fill_response were added. The rfq channel now emits rfq_post_request, rfq_cancel_request, rfq_post_response, rfq_cancel_response, and rfq_fill_response.

  • Combo leg limits

    A combo order may contain at most 6 option legs and at most 1 perpetual leg (7 legs total). limit_perp_price must be present and positive when a perpetual leg is included, and must be omitted otherwise. Violations are rejected with HTTP 400.

  • GET /v2/account_history/export (Beta)

    Exports account history as a downloadable CSV (text/csv, UTF-8 with BOM) using the same filters as GET /v2/account_history. Pagination parameters (cursor, offset, limit) are not accepted; the response is capped (see X-Export-Max-Rows) and sets X-Export-Truncated / X-Export-Row-Count headers.

  • Auto-deleveraging (ADL) fills on the trade channel

    When a position is reduced by ADL, the fill is delivered as a regular trade event with adl: true (alongside liquidation). There is no separate ADL channel.

Deprecated

  • Perpetual notional (amount) sizing

    The perpetual sizing model is migrating fully to base contracts. The legacy amount field on perpetual orders — and the notional values still emitted on perpetual size / filled_amount outputs for backward compatibility — are deprecated and will be removed in a future release. Migrate integrations to contracts.