Changelog

Edits that would activate a waiting trailing stop or immediately fire an active one now return TRIGGER_WOULD_TRIGGER_IMMEDIATELY and preserve its existing settings.

A trailing stop submitted with an activation price already reached by its watched price now ends FAILED, sends no order, and releases its reserved funds. Equality counts as reached. Changing an active stop’s trailing distance is also refused if the resulting trigger price is already reached. The same checks apply to attached trailing stops on orders with an executable fill. To start trailing immediately, omit the activation price when creating the stop or clear it when editing.

REST clients also receive route-specific quantity and price precision rejections, changing how batch creation and preview responses must be handled.

Exact decimals such as "1.500" for a two-decimal quantity are accepted subject to normal order validation. Excess nonzero digits in base quantities or tick-checked prices produce QTY_STEP_SIZE or PRICE_TICK_SIZE with field violations. Batch creation rejects only the affected item; previews return HTTP 200 with admissible:false and a rejection. Modify and batch-replace requests with overly precise tick-checked prices return HTTP 400 PRICE_TICK_SIZE, with batch replacement still refusing the whole request.

REST order errors now include field-level validation details. Some error codes and REST and ConnectRPC field paths have changed, requiring updates for clients that match those values.

Order API problem responses include an optional violations array with fieldPath, ruleId, and message. REST violations identify REST request fields, including indexed batch items and preview rejections. For POST /v1/orders, quantities with nonzero digits beyond the supported scale now return QTY_STEP_SIZE; limit prices and supported attached-risk prices with nonzero digits beyond their scale return PRICE_TICK_SIZE instead of INVALID_ARGUMENT. ConnectRPC quantity and limit-price violations now identify the actual request fields, and batch-replace attached-risk violations include the item index.

Attached take-profit, stop-loss and trailing-stop exits now reserve the funds they need. Sell orders with attached trailing stops must also specify a maximum buy-back price.

Protection reserves appear in reserved balances and cannot be used by other orders or withdrawals. Buy orders reserve purchased coins as fills settle; sell orders reserve quote funds for their buy-back exits, including any required amount at order creation. Both legs share one reserve, which adjusts as protection changes and releases when it ends. Fill credits enter trading balances after settlement is recorded. A trailing buy-back exit fills only at or below its declared maximum.

Affected REST endpoints now accept only camelCase query parameter names. Clients using snake_case names must update their requests to preserve filtering and pagination.

The changes cover balances and history, transfers, chain analytics and flows, deposit addresses, market overview, QuickSwap reads, address-book reads, rewards, and pagination. API-key and address-book reads now honor subaccountId, and address-book reads honor minimumViewRevision. Spot fee-rate requests for unknown or unavailable symbols return HTTP 400 with UNKNOWN_SYMBOL. Trigger and fee-rate filtering continues to use symbol with the trading pair name.

Trading integrations now receive rejection codes consistent with API errors and distinct cancellation reasons across order reads and authenticated streams.

Rejected orders expose rejectReason using ErrorCode, while canceled orders expose cancelReason using CancelReason. These replace the previous terminal reason fields. REST omits unset reasons and returns names such as POST_ONLY_CROSS and USER_REQUEST. Replacement events identify the ended order with cancellation reason REPLACED. Batch replacement status uses the same public rejection names, and nine additional error codes describe trigger refusals.

WebSocket connections now enforce session, connection, and reconnect-rate limits.

Trade WS rejects connection attempts above API-key or account session limits with HTTP 429 and TOO_MANY_SESSIONS_API_KEY or TOO_MANY_SESSIONS_ACCOUNT. Closing an unused session frees capacity. Realtime and private WebSocket endpoints also apply connection and reconnect-rate limits per client address.

USDT- and USDC-quoted pairs default to a maximum market-order value of 1,000,000 quote units.

Market orders above the configured cap return MAX_NOTIONAL. Buys are valued at their protection price including slippage, while sells use their reference price; fees are excluded. GET /v1/spot/config exposes maxMarketNotionalQuote as a decimal string, omitted when uncapped. This cap does not apply to limit orders.

REST clients must update batch replacement payloads and trailing-stop request fields and response parsing.

POST /v1/orders/replace-batch now accepts newPrice as a decimal price in quote asset units. Trailing stops use trailingDistance as a decimal price delta across order and trigger requests and responses. Requests using the removed newPriceTicks or trailingDistanceTicks names return 400 BAD_REQUEST.

Frequent cancel-all callers gain capacity aligned with their account’s configured cancellation budget, while integrations must handle a changed retry response.

Retries with the same identity and criteria within 120 seconds preserve the original submission status, counts and acceptance timestamp, but return no historical order list and request no additional cancellations. The new listingStatus field distinguishes INCLUDED initial responses from NOT_RETAINED_READ_OPEN_ORDERS retries. Initial responses list up to 200 orders; use order updates for final outcomes and open-order reads for current state.

Canceling an exit order created by an attached take-profit or stop now cancels that leg instead of allowing it to fire again. With OCO enabled, both attached legs end.

This applies to individual cancellation, cancel-all and cancel-all-after. With OCO disabled, the other leg continues protecting the remaining position. Changing only OCO preserves existing leg IDs, arming and trailing-stop tracking. Editing, pausing or resuming attached legs while an exit is working now returns ATTACHED_EXIT_WORKING (292) as HTTP 400 / FailedPrecondition instead of HTTP 503 / Unavailable; removing a leg remains allowed.

If a market stops responding, new orders for it are now refused within about a second with a retryable "market busy" error, and no funds are held for them. Orders already submitted complete when the market recovers, and other markets are unaffected.

Clients can opt into market-specific resync notifications to keep their private trading connection open while other markets continue streaming. SBE integrations must update to schema 28.

Enable marketResync alongside orders or executions in Subscribe to receive MarketResync messages identifying the affected symbol and recovery reason. Reconcile that market’s orders and executions through the Orders API before applying subsequent events, which may repeat reconciled state. Notifications precede resumed events and may arrive even for markets the account does not trade. Without the opt-in, private-event sessions receive a WebSocket 1012 close when a market requires resynchronization. A single market’s interruption no longer blocks new connections while the service is starting up.

Market makers refreshing quotes frequently avoid replacement rejections caused by completed modifications consuming their outstanding-request allowance.

Batch replacement admission results can now be replayed for 60 seconds from acceptance, reduced from 120 seconds. Individual modification request IDs remain reserved while pending and for 60 seconds after the answer; identical retries replay that answer, while changed contents conflict.

Order-stream integrations now receive account snapshots and sequenced updates in JSON or protobuf, with cursor-based reconnection and explicit readiness signals.

The previous private order and batch-replace channels are retired. The replacement stream provides complete order records, including attached risk, and sends a fresh snapshot when a reconnect cursor cannot resume. Batch-replace progress is available through GetBatchReplaceStatus and individual order updates.

Trading APIs return more specific rejection codes and clearer WebSocket error messages. Trigger cancellation error handling requires a client update.

Trigger cancellation refusals now return TRIGGER_STATUS_INVALID (45) or TRIGGER_NOT_MODIFIABLE (46), replacing TRIGGER_CANCEL_REJECTED (44). Cancel-all and cancel-all-after distinguish venue rate limiting (429 SYSTEM_RATE_LIMITED) from invalid server replies (500 INTERNAL_ERROR). Trigger REST precondition failures and duplicate conflicts return 400 and 409 respectively, replacing 502. Additional codes identify order validation, capacity, market availability and trigger failures.

Adds batch order creation, replacement, and cancellation over protobuf and SBE. SBE clients must upgrade to schema version 19.

Submit up to 20 creates or 50 replacements or cancellations per batch, with results returned in request order. Replacements must target one trading pair. Busy responses or missing acknowledgements may follow partial execution; retry with the same request identity and unchanged items.

Order creation and replacement failures involving a zero order identifier now report a specific client error instead of a generic server error.

Single-order failures return HTTP 400 over REST or invalid_argument over ConnectRPC, while batch results identify the rejected item. Binary trading WebSocket clients must use SBE schema version 16, which adds INVALID_ORDER_ID as rejection code 80.

Order API and WebSocket clients receive specific rejection codes for pair limits and replacements at or below the filled quantity.

Rejections distinguish MAX_QTY, MAX_NOTIONAL and QTY_AT_OR_BELOW_FILLED. Order reads and realtime updates also identify orders ended by a quantity change at or below the filled amount. Busy-pair rejections tell clients to retry shortly.

Open-order policy limit rejections now return HTTP 400 instead of 429. Trading WebSocket errors more accurately identify invalid quantities and prices.

POLICY_MAX_OPEN_ORDERS now uses invalid_argument in ConnectRPC. Invalid-sizing WebSocket rejections use BAD_QTY, and SBE responses preserve BAD_QTY and BAD_PRICE. The public order error contract also defines MAX_QTY and MAX_NOTIONAL separately from the subaccount policy notional limit; their availability is not established by this change.

Market trades, account trades, ledger transfers, and trigger events now use ordered event batches to reduce realtime backlog under trading load.

JSON publications use {"events":[...]} even for a single event. Protobuf publications use the corresponding batch message. Transfer updates and transfer history also expose a stable transferId for matching and updating transfer legs.

API clients retrying a trigger create after INTERNAL_ERROR may now receive CONFLICT_DUPLICATE_CLIENT_TRIGGER_ID (code 47), even for an identical request.

After a failed create, list triggers and reconcile using the client trigger ID before submitting a replacement with a new ID. Identical retries of an accepted create continue to return the same trigger.

Each account can hold up to 100 pending or active triggers per market, including at most 15 TWAP orders and five ladder orders.

Attached take-profit, stop-loss and trailing legs count toward the total. Requests exceeding a limit are rejected with a specific limit error; capacity becomes available when an existing trigger ends. An order whose attached protective legs would exceed the total is rejected in full.

The limits apply even without an account policy, with defaults of 1,000 resting orders per account and 200 per market.

GTC and GTD orders count toward the caps; IOC, FOK and market orders do not. Account policies can lower the limits. Replacing an order preserves its place, and ending an order frees capacity. Orders exceeding a cap are rejected with MAX_OPEN_ORDERS_TOTAL or the new MAX_OPEN_ORDERS_PER_PAIR error (306). Each ladder level counts, and limit TWAP slices are also subject to the caps.

API clients can choose the last traded price or the market’s index independently for each attached take-profit, stop-loss, or trailing stop.

Set trigger_price_source to INDEX_PRICE to use the market’s index; omitted values continue to use the last traded price. Order reads and history include the selected source when returning the attached policy. Changing the source replaces that attached stop. On markets without an index, a new order requesting index-based protection is rejected before any fill; adding it through a modify cancels the existing order, and earlier fills remain valid. Mark price is unsupported.

API clients can select index pricing for standalone stop-loss, take-profit and trailing-stop orders while last-trade pricing remains the default.

Trailing stops use the selected price for activation, tracking and triggering. Index-based stops remain armed while the index is stale or unavailable; creating one on a market without an index fails with an index-price-unavailable reason. Trigger reads and realtime updates report the selected source. Changing the source requires cancelling and recreating the trigger.

Market-data clients can recover trades missed during a live-stream interruption in oldest-first order, including across restarts.

GET /v1/spot/markets/{symbol}/trades accepts afterTradeId, with after_trade_id available through GetTrades. Responses include a completeness boundary, a continuation cursor and trade-ID epoch endings. Continue with nextAfterTradeId; if it matches the requested cursor, retry later with backoff. This mode cannot be combined with time, side or page-token filters.

Standalone stop-loss and take-profit triggers now also accept buy market orders, with funds reserved when the trigger is created.

Set a market child's slippage cap in basis points or absolute price units, update or clear it while the trigger is live, and retrieve it through trigger Get/List responses. Omitting or clearing the cap uses the trading pair's default market slippage. Buy triggers reserve funds for their maximum purchase price plus fees; changing the trigger price or cap adjusts that reservation. Price gaps can result in partial or no execution. This change covers standalone triggers.

Market-data API clients can request these intervals for historical candles and subscribe to matching live updates.

The new intervals support spot and reference candle history, plus optional inclusion of the current open candle. Live candle updates are available in JSON and Protobuf. All buckets use UTC; 8h candles start at 00:00, 08:00 and 16:00, while 3d candles follow three-day boundaries counted from January 1, 1970.

QuickSwap TWAP swaps on trading routes now execute as a series of protected orders spread over the requested duration; bridge routes remain market-only. Missed slots are skipped rather than sent late, and anything left untraded at the deadline is returned or refunded with a clear reason. TWAP quotes require a minimum deposit large enough for every slice to be a valid order.

Traders can track the lowest trade price after activation and buy when the price rises by their chosen trailing distance.

Buy trailing stops require a maximum purchase price and submit an immediate-or-cancel limit order when triggered. An optional slippage cap can lower that limit further. Funds are reserved upfront, including applicable fees, and any reservation the submitted order does not need is released immediately. If prices jump above the maximum, the stop still triggers but cannot fill above it. The maximum is fixed when created and appears in trigger reads and realtime updates.

Adds authenticated API support to quote, execute, and track asset conversions on supported direct spot pairs using Trading balances.

Quotes show estimated output, minimum output, price impact, and the account’s applicable taker fee, with no additional Swap fee. Quotes expire after 30 seconds and reserve no liquidity; confirmation checks current prices against the accepted minimum. Repeated confirmations with the same terms and idempotency key return the same Swap. Status responses show settled amounts, fees, and completed, partial, or failed outcomes. API-key and subaccount policies must grant SWAP permission.

Open your VIP badge in the account dashboard or desktop wallet menu to see your tier, fee rates, and progress toward the next tier.

The new popover shows your tier’s maker and taker rates alongside progress for 30-day trading volume and average portfolio value. Preview the next tier’s rates and open the full fee schedule. Overall VIP progress now reflects whichever metric is closest to its target.

Repeating a cancel after an order has ended now returns ORDER_ALREADY_TERMINAL instead of another ACCEPTED response.

This applies to REST and ConnectRPC. Repeats while cancellation is still in progress remain ACCEPTED. Cancels naming the wrong market return ORDER_UNKNOWN when the market can still be verified; older ended orders may return ORDER_ALREADY_TERMINAL. Every cancel retry counts against the cancel rate limit. Cancelling by client order ID more than a minute after the order ends may return ORDER_UNKNOWN.

Fixed average execution prices being rounded down to a whole price tick, improving accuracy for orders filled across multiple price levels.

REST avgPx now returns up to 18 decimal places, rounded half to even, across open orders, order history and single-order reads. ConnectRPC and private WebSocket orders include avg_price_e18, scaled by 10^18; avg_price_ticks retains its existing precision. With no fills, REST returns "0" and avg_price_e18 is unset.

Ledger reads now return specific errors for invalid subaccount selectors, and private trade WebSocket messages consistently include the fee rebate indicator.

Balance, balance-history, equity-history and transfer reads reject zero subaccount selectors with INVALID_SUBACCOUNT_ID. REST also returns this code for malformed selectors, with HTTP 400; Connect returns invalid_argument with structured error details. Private spot-trade WebSocket JSON always includes feeIsRebate, including false when no rebate applies. REST transfer pagination now binds continuation tokens to the selected subaccount.

Traders reducing an order’s total quantity through batch replacement keep its order ID and queue position when its price and client order ID stay unchanged.

POST /v1/orders/replace-batch, Connect BatchReplaceOrders and trading WebSocket batch replacement now amend eligible orders in place. Leaving the price unset or resending the current price allows an amend when total quantity does not increase and the client order ID stays unchanged. These items return actionTaken: AMENDED with oldOrderId and no replacementOrderId. A different price, larger total quantity or different client order ID still produces REPLACED with a successor order ID.

API clients reconciling an order submission after a lost response can now obtain the existing order’s ID directly from a duplicate rejection when known.

Single and batch create rejections expose optional existingOrderId in REST and existing_order_id in typed Connect and protobuf WebSocket errors, with equivalent SBE WebSocket fields. HTTP 409 and Connect AlreadyExists remain unchanged. Use GetOrder to check the existing order’s current state; the field may be absent for duplicates detected within the same batch before an order is assigned.

Single and batch order submissions now return ORDER_CREATE_OUTCOME_UNKNOWN (303) when confirmation is lost, telling API clients to check whether orders were accepted before retrying.

For a single order, reconcile using its client order ID or open orders before resubmitting. For a batch, check every item or resend the same correlationId and identical items within 15 minutes to recover results without duplicate admission. A batch-level UNAVAILABLE response can still follow accepted items and must also be reconciled.

REST and Connect clients can distinguish missing confirmations for single orders, batch orders, and triggers from definite submission failures.

A submitted request whose confirmation is lost or late returns HTTP 504 / Connect deadline_exceeded with ORDER_CREATE_OUTCOME_UNKNOWN (303) or TRIGGER_CREATE_OUTCOME_UNKNOWN (304), indicating that creation may have succeeded. An uncertain batch returns no per-item results.

Integrations still using the previous private order stream must switch to /v1/ws/private to receive order updates.

Subscriptions to retired private order channels now return permanent bad-request error code 107 instead of succeeding without delivering updates, including protobuf and batch-replace variants.

Immediately after a successful create or edit, clients receive the acknowledged trigger configuration or a retryable UNAVAILABLE response while the read catches up.

Applies to standalone triggers and attached take-profit, stop-loss and trailing-stop legs, including configuration changes, pauses and cancellations. Fill quantities and other market-driven updates can still lag briefly.

API clients now receive an explicit unknown-outcome response when a cancellation or modification was sent but its confirmation did not arrive in time.

These responses use HTTP 504 with ORDER_CANCEL_OUTCOME_UNKNOWN (297) or ORDER_MODIFY_OUTCOME_UNKNOWN (298), indicating that the change may still apply. This covers single and batch requests, Cancel All, and Cancel All After. Unknown batch outcomes include no per-order results; read every affected order before retrying. For Cancel All, read open orders; for Cancel All After, resend the heartbeat.

SBE trading WebSocket rejections now correctly distinguish absent rate-limit information from quota failures.

For rejections unrelated to rate limits, weight, retry delay, policy version, and rate-limit classification fields now carry their documented zero values. This prevents absent retry information from appearing as an enormous delay. Quota failures retain their rate-limit metadata even when the retry delay is zero. The public schema remains version 12 with the same message layout.

The validation applies when creating or modifying standalone trailing stops and trailing stops attached to buy orders.

Requests setting a selling trailing stop’s maximum slippage to 100% now return ERROR_CODE_MAX_SLIPPAGE_INVALID. Positive caps up to 99.99% remain accepted, while attached trailing stops that buy still permit 100%. Rejected modifications leave the existing stop unchanged.

Traders can now see the applicable exit slippage in Confirm Order and Trigger Details for attached market take-profit and stop-loss orders.

Each market exit shows Max Slippage labelled “(market default)”, using the trading pair’s default for the exit’s buy or sell side. Trigger Details preserves explicitly configured slippage values, and limit exits remain unchanged.

Traders using Fix for a missing amount on market or limit orders now receive an amount that meets the form’s minimum order value.

The suggested amount accounts for the order price, market-sell slippage protection, and applicable fees when buying with a quote-currency budget. Market amount fields also use the corrected minimum when leaving a zero value. Insufficient-balance checks still apply.

Traders with fee discounts can more clearly distinguish their effective maker and taker rates from their VIP tier rates.

In the order form’s Fees row, the lightning icon sits directly beside the discounted rates, and the VIP badge sits beside the crossed-out base rates.

Trading-hours traits are also hidden when trades exist but their hourly breakdown is missing.

Checkpoint recaps omit unsupported trading and portfolio traits, hide activity figures when there is nothing to report, and center no-data labels within empty charts. Headline punctuation stays attached to the preceding word.

When a trailing stop has no distance, entering a slippage cap or buy-back limit no longer makes it appear in the order review.

Confirm Order now omits attached take-profit and stop-loss orders without a positive trigger price, and trailing stops without a positive distance, matching what will actually be placed.

Stop Loss Buy and Take Profit Sell now show one validation message when traders enter a trigger price of zero in market or limit orders.

The trigger field shows only “Trigger price must be greater than 0.” and its Fix action, removing the extra market-direction error. Positive trigger prices still receive the applicable market-direction validation.

One trader's rejected take-profit or stop-loss exit no longer unexpectedly interrupts other users' orders on the same market.

This fixes a rare case where a quantity-step increase leaves a completed parent order with no tradable quantity while its protective exit is pending. If that exit is rejected, the affected protective orders end with a quantity-step failure and release their reserved balance.

This fixes a rare interruption affecting traders on a pair when an attached take-profit or stop-loss is refused after the remaining position becomes too small to trade.

The refused attempt is recorded before the affected protective orders end with a quantity-step failure, leaving the remaining balance available.

REST and ConnectRPC clients now receive specific price-increment errors even when a trigger modification omits the optional symbol.

PUT /v1/triggers/{triggerId} returns PRICE_TICK_SIZE with a tick_size violation identifying triggerPrice or activationPrice when that price does not align with the trading pair’s increment, leaving the trigger unchanged. REST trigger error explanations also use REST field names and decimal price units.

Edits to stop-loss, take-profit and trailing-stop triggers now reject resulting orders that fail the pair’s minimum rules, preserving the existing trigger and reserved funds.

Validation checks the pair’s current minimum quantity, quantity step and minimum order value. Changing an order’s quantity also checks any attached protective orders it retains. Rejected trigger edits return MIN_QTY, QTY_STEP_SIZE or MIN_NOTIONAL through PUT /v1/triggers/{trigger_id} and ModifyTrigger, with a message confirming that nothing changed.

This affects order, withdrawal and internal-transfer requests while newly granted permissions are still taking effect.

Permission checks now isolate concurrent traffic by API key, preventing one key from blocking other keys’ checks. Requests may still require retries while permission updates take effect or during overall overload.

A rare take-profit and stop-loss handoff now finishes without interrupting account trading when the remaining position falls below the quantity increment.

Both protective orders finish and release their reserved funds when the exit is canceled during this handoff, leaving the remaining quantity available in the balance.

This applies when an entry order’s final fill settles while its protective exit is pending or working, leaving a remainder below that exit’s market minimums.

Once the exit fills its full original quantity, the triggered take-profit, stop-loss or trailing stop completes and its OCO sibling is cancelled. The trigger no longer attempts another exit for the dust, fails, and leaves its sibling running. Exits reduced by amendment or ended before filling completely retain their existing behavior.

Trading clients receive a retryable error when an API-key or subaccount permission update is still taking effect.

Affected order requests now return Unavailable instead of a final permission denial after trading permissions have been granted. Clients can retry while the update takes effect; requests refused during that interval are not executed.

After an order finishes and its fills settle, attached exits below the applicable trading minimums now end immediately when no exit is pending or working.

If no exit has run, an affected trigger shows Failed with a minimum quantity or minimum order value reason; another attached trigger that meets its minimums stays active. If an earlier exit has finished and the remainder is below its minimums, its trigger completes and the paired trigger is cancelled.

API clients can now retrieve the configured maximum buy-back price for a sell order’s attached trailing stop in order details, open orders, and order history.

GET /v1/spot/orders/{order_id}, GET /v1/orders/open, and GET /v1/orders/history return the optional attachedRisk.trailingStop.policy.limitPrice as a decimal price. The field is omitted for trailing stops attached to buy orders.

Attached take-profit and stop-loss triggers re-arm for the remaining quantity when the exchange cancels their working exit during account recovery.

Unfilled ladders whose levels are canceled solely during account recovery now finish as Completed with zero execution and no user-cancellation reason. Attached exits can fire again on a later qualifying price update. Manual cancellations and the dead man’s switch retain their existing behavior.

Previously accepted trailing stops and TWAP orders can resume after a restart even when newer creation rules reject their original settings.

Trailing stops retain their saved terms, and TWAP orders retain their planned slice counts when restored after creation rules tighten.

Traders paying spot buy fees in the quote currency can size orders using their account’s effective fees once those rates load.

Balance checks and maximum order sizing now account for market-specific fee discounts, including when editing orders. Post-only buys reserve maker fees, while other buys reserve the higher of maker and taker fees. Standard rates apply until account rates load.

Under Expire Taker self-trade prevention, attached take-profit, stop-loss and trailing-stop orders wait while another of your orders remains first in line at the best price.

New trades and index-price updates no longer generate repeated cancelled exit orders while the blocker remains. Once it clears or loses its place, the exit fires once if its trigger condition still holds, without requiring a fresh price crossing.

Traders can submit market and immediate-or-cancel limit buys with attached protection when specifying how much of the quote asset to spend.

Take-profit, stop-loss and trailing-stop protection follows the quantity actually bought as fills settle, including partial fills, subject to trading minimums and quantity steps.

Developers can identify the invalid request field or rejected ladder order when a trigger request is refused.

Error responses now include available field violations with fieldPath, ruleId, and message. Paths use REST request field names, and rejected ladder orders include a zero-based order index.

Triggers refused by a halted market now explain their failure even when the create request already returned success.

Trigger details, lists, event history and authenticated WebSocket updates now report the existing MARKET_HALTED failure reason instead of an unknown or blank value.

For newly created spot pairs, GET /v1/spot/config now suggests order-book grouping sizes matched to each pair’s minimum price increment.

Suggested grouping sizes start at the pair’s tick size and increase tenfold across five options, supporting low-priced pairs without a fixed 0.01 minimum. Existing pairs retain their current settings.

New price instruments no longer inherit historical prices from a removed instrument.

Re-adding the same instrument preserves its own price history, keeping historical prices associated with the correct asset.

REST open-order and order-history responses now omit submittedMaxQuoteDebit when the order was not sized by a quote amount.

Previously, these lists returned "0" for an unsubmitted quote budget, which could cause clients to misidentify quantity-sized orders as quote-sized. Submitted quote budgets continue to appear with their original values.

Fixed a rare issue that could leave trade settlement processing blocked indefinitely during recovery.

Stalled settlement operations now time out, allowing processing to restart from confirmed progress.

Order reads now expose the quote amount used by fills and recorded fee totals, helping clients calculate how much of a quote-sized buy remains unspent.

REST orders include cumQuote, with the equivalent cum_notional field in ConnectRPC and private order updates. Order history and single-order reads with execution history also include feeTotal, net of rebates. Fee totals may briefly trail fills; compare feeTotal.qty with cumQty before treating them as complete. Open-order reads, state-only single-order reads and private updates omit fee totals. For quote-sized buys, clients add quote-denominated fees to cumQuote, subtract net rebates, or use cumQuote alone when fees are paid in base.

Unused reserves from filled, cancelled or expired orders are released sooner, reducing temporary insufficient-funds rejections when placing the next order.

Buy orders release unused reserves from better execution prices and unused slippage allowances when they end. Partially filled orders that are cancelled or expire release reserves for their unfilled remainder. Excess fee reserves are released as fills settle.

Fixed attached take-profit and stop-loss quantities when a market order fills at multiple prices and its take-profit fires before all fills settle.

Active attached legs now reflect the remaining settled position even while an exit order is working. Later-settling fills can receive an additional exit after the earlier exit ends, provided the trigger condition still holds. A leg’s displayed quantity can therefore exceed its current exit order’s quantity.

Fixed a settlement issue that could eventually interrupt trading after prolonged activity.

Improves trading continuity by preventing settlement bookkeeping from accumulating unnecessarily as trades complete.

Fixed missing timestamps in REST order book responses when a book is still being built or has been invalidated.

GET /v1/orderbook/{symbol} now includes ts: 0 when the snapshot timestamp is unavailable, keeping responses consistent with the published schema and preventing parsing failures in generated clients. The API reference clarifies that ts is zero while available is false.

Ladders now report Canceled with a User Request reason when their orders are canceled by the user before any quantity fills, instead of reporting Completed.

The status updates once all planned levels have ended. This includes individual cancellations, cancel-all, and the user’s dead man’s switch. Trigger history and realtime updates include the cancellation reason. Ladders with any filled quantity still report Completed once their remaining levels end.

Trigger history and realtime updates now explain refused attempts that leave a trigger active.

A new FIRE_REFUSED event includes the attempt sequence, refusal reason, and firing price when available. It covers attached take-profit, stop-loss, and trailing-stop attempts waiting on market conditions or minimum order requirements, plus trigger attempts awaiting retry after rate limits or account repair. The trigger remains armed or running; refusals that end it continue to appear as FAILED. These events are available through REST, ConnectRPC, and WebSocket trigger updates.

Buys sized by a quote amount now report Filled when their remaining budget cannot buy another quantity step, instead of reporting Canceled.

Applies to market and limit immediate-or-cancel buys. A spent-budget buy finishes with no cancel reason. Orders stopped by insufficient liquidity, price protection or the maximum order quantity while budget remains available for another whole step retain their canceled outcome and executed fills.

Markets with less than 24 hours of trading history now measure price changes from their first trade instead of incorrectly reporting zero.

Market overview responses and live updates use a reference price with minute-level granularity. For markets that began trading within the last 24 hours, the reference is their first trade. Change remains zero before any trades occur and until the first minute of trading has closed.

Attached trailing-stop validation now identifies maximum-price mistakes with specific error codes and field details.

Order creation, previews, and batch creation now report BAD_PRICE when a maximum is supplied on a BUY parent or falls below activation, TRIGGER_BUY_REQUIRES_LIMIT when missing on a SELL parent, and PRICE_TICK_SIZE when misaligned with the market’s tick size. Modify and batch-replace requests include field details for tick-size and activation-price errors; side-related errors return BAD_PRICE without field details.

ConnectRPC, gRPC and gRPC-web clients can now distinguish authentication failure reasons on order, trigger and ledger read APIs.

Authentication errors now include a readable message and a typed auth.v1.AuthErrorDetail identifying issues such as an invalid signature, clock skew, missing headers, expired or disabled API keys, or an IP restriction. Browser gRPC-web clients can also read these details. Requests without credentials retain AUTH_AUTHENTICATION_REQUIRED. REST authentication responses remain unchanged.

Market halts now produce clear order and trigger cancellations. This release also fixes misleading order-history entries, stale trigger reads, and funding for attached exit protection.

Open orders and triggers, including attached take-profit and stop-loss legs, now end with MARKET_HALTED when their market halts; earlier fills remain valid. Orders submitted after a halt receive a visible rejection. Refused order modifications leave the original order unchanged without adding a phantom rejected order to history, and batch status reports each item's refusal reason. After an acknowledged trigger modification, pause or resume, reads return the updated state or a retryable unavailable response while catching up. Attached exit protection correctly reserves settlement proceeds, including fractional amounts left after fees. VIP qualification no longer remains blocked for 30 days by missing price history immediately after an environment reset.

A previously selected Good Til Date expiry no longer blocks limit orders after switching to Good Til Canceled, Immediate Or Cancel, or Fill Or Kill.

The selected expiry is preserved when switching away from Good Til Date and validated again when switching back. An invalid expiry still blocks Good Til Date orders.

Trigger creation now rejects orders that fail supported trading-pair minimum checks before arming them or reserving funds.

Stop-loss, take-profit and trailing-stop requests check quantity and quantity increments, plus minimum order value where it can be determined. TWAP validation checks slice size rather than total size. Orders with attached protective legs receive equivalent checks during creation, preview and updates that install legs. Rejections explain the quantity, increment or value issue. Sell trailing stops check quantity only; market TWAP value checks wait until execution when no usable quote is available.

Clearing a trading pair’s listing or delisting schedule now correctly updates eligibility for new orders and triggers.

Cancelling a scheduled delisting or removing a future listing time no longer causes otherwise eligible orders and triggers to be rejected using the old schedule.

Buys entered as a quote amount, such as USDT, now use your account’s applicable fee rate when fees are paid in that same asset.

Accounts with lower trading fees can spend closer to their entered amount instead of leaving extra funds unspent. Total spending, including fees, remains capped at that amount, subject to available liquidity, price protection and order limits.

Fixed a rare case where reading a standalone trigger immediately after modifying, pausing, or resuming it could return its previous configuration or status.

GetTrigger now returns state reflecting the acknowledged change, or a retryable UNAVAILABLE response while the update becomes readable.

Buy and Sell buttons now reflect the current price range, and excessive level counts show an explanation even while Levels has focus.

Leaving Max Price, choosing a percentage preset, or adjusting the range on the chart now refreshes the price-range error. Correcting the range clears stale errors, while equal or reversed prices disable submission. Level counts that exceed the range show the error and Fix option without requiring you to leave Levels; empty values and 1 still defer new error messages until focus leaves.

Fixed missing order outcomes and account reads that could remain unavailable after a market halted.

Orders admitted but subsequently refused by a halted market now appear as REJECTED with MARKET_HALTED in order history and the private feed. Existing working orders, attached legs, and active triggers show their canceled outcomes. Affected accounts can resume reading orders across other markets, including after a restart.

External reference pricing stops refreshing a market’s last quote when incoming updates cannot be processed.

Affected quotes resume after valid data arrives from Kraken, Binance, Binance.US, OKX, Bybit, Bitstamp or Gemini. When the affected market can be identified, other markets continue updating. Otherwise, the feed reconnects to recover.

The trading WebSocket SBE reference now explains when BatchReplaceOrders amends an order in place or replaces it with a new order.

Amendments that keep the price and client order ID without increasing total quantity retain the order ID and queue priority. Replacements receive a new order ID and reset queue priority. Reducing total quantity to or below the filled quantity ends the order without a successor. This corrects documentation of existing behavior; trading behavior and message formats are unchanged.

Fixed an issue where initial price-history gaps after an environment reset could block portfolio-based VIP tier updates for up to 30 days.

Hours before price history begins no longer block VIP qualification. The fixed 30-day averaging period and safeguards for subsequent price gaps remain unchanged.

Refused order modifications no longer create extra rejected orders in history. Batch status now reports each item's rejection reason.

When a modification is refused, such as a post-only price change that would cross, the original order remains unchanged and no replacement order appears in history. GetBatchReplaceStatus reports items rejected after admission as REJECTED with the refusal code, no action taken, and replacement_order_id set to 0. Admission counts and replayed admission responses remain unchanged.

Trigger records now distinguish cancellations caused by a halted market.

Active stop-loss, take-profit, trailing-stop, TWAP and ladder triggers, including attached legs, receive a market-halted cancellation reason and completion time. Parent order records also reflect canceled attached legs while preserving previously completed order outcomes and fills.

Open orders on a halted market now appear as canceled with the MARKET_HALTED reason, while retaining earlier fills.

Order history records cancellations at the market’s halt timestamp and preserves them across recovery. Trade WebSocket sessions receive a market resync notification, or reconnect through the existing resync flow, to refresh order state.

Fixed reserve calculations for attached take-profit, stop-loss, and trailing-stop orders as fills settle and orders change.

Reserves now include fractional amounts remaining after fees paid in the purchased asset. Order changes also account correctly for funds already reserved for an exit replacement, avoiding incorrect insufficient-funds rejections while requiring enough funds for increased protection.

When a Coinbase update cannot be processed, the affected market’s Coinbase quotes pause until a fresh order-book snapshot is accepted.

This prevents subsequent quotes from being calculated from an incomplete Coinbase order book and repeatedly refreshed as current index-price inputs.

Fixed heatmaps that could show identical bid and ask prices when the actual order book had a spread.

Newly generated heatmap data keeps bid and ask bands separate when the best bid is below the best ask. Best bid, best ask and midpoint values now reflect actual order prices. Heatmap resolution and API response fields remain unchanged.

Swap and QuickSwap buy legs now spend up to their budget at available prices while respecting price protection and market limits.

Better prices can deliver more destination assets instead of leaving the slippage allowance unspent. Buy quotes reflect current order-book depth, fees and quantity steps, and maximum amounts account for market order-size limits. Small rounding remainders may remain; liquidity and price limits can prevent the full amount from trading.

When an open order is partly filled, an exit refusal caused by trading minimums now preserves its attached protection for later fills.

Attached stop-loss, take-profit and trailing stops remain Running after an exit is refused for minimum quantity, minimum value or quantity-step requirements. Price updates do not repeatedly retry the same refused quantity. Later fills resize the protection, allowing the next qualifying price update to trigger another exit attempt. If the original order ends with the same refused quantity remaining, the affected protection fails once with the refusal reason.

Fixed attached take-profit, stop-loss and trailing exit quantities being understated when a buy fills in multiple parts with fees paid in the purchased asset.

Exit sizing now accounts for fractional amounts across fills before rounding down to the market’s permitted quantity step. This prevents repeated rounding losses from leaving additional inventory outside attached protection, including after an order replacement.

Buy and sell ladders on LTC-USDT and DOGE-USDT now handle totals that do not divide evenly across levels while preserving the requested quantity.

Each level rounds down to the pair’s quantity increment, and the final level receives the remainder. For example, 0.4 LTC across three levels becomes 0.133333, 0.133333 and 0.133334 LTC. Each level must still meet the pair’s order requirements.

Fixed a case that could delay trade settlement when requests were retried during a processing backlog.

A retry arriving while the original settlement is still completing can now share its outcome, avoiding an unnecessary capacity-related delay.

Clients consuming order events receive the corrected sequence in both JSON and Protobuf when an order executes immediately.

Acceptance now carries a lower version than subsequent fills. Partially filled immediate-or-cancel orders report ACCEPTED, then their FILLED events, then CANCELED for the remaining quantity.

Fixed index-price gaps caused by normal differences in external venues’ price increments.

Index prices now account for each venue’s minimum price increment when evaluating spreads and price differences. This helps keep prices available for low-priced assets when qualifying quotes previously exceeded percentage-based limits. Limits on wide spreads and off-market prices remain in place.

When cancelling many TP/SL orders, temporary rate limits now trigger automatic retries before a failure is reported.

After a partial cancellation, the dialog’s total and per-pair counts show only orders eligible for retry. If rate limits persist, the error message asks you to wait and try again.

Fixed understated USD portfolio values when asset prices are converted through an intermediate currency.

Portfolio calculations used for VIP qualification now retain conversion precision, improving accuracy for low-priced assets. Prices below the supported precision are treated as unavailable for valuation without reusing the previous hour’s portfolio value.

For pairs with very small price increments, grouping controls display values such as 0.000000001 consistently across desktop and mobile.

The selected grouping displays as a plain decimal and matches the corresponding option in the dropdown, context menu, and mobile settings.

Requests made immediately after creating or attaching a subaccount policy now distinguish temporary syncing delays from permission refusals.

Affected reads, transfers, withdrawals and subscription requests can wait up to two seconds before returning a retryable unavailable error. Order submissions return UNAVAILABLE immediately while the policy is syncing, and trading WebSocket sessions stay open. Retry unavailable responses with backoff.

Cancelling ladder, TWAP or attached exit orders now completes when another order’s good-till-date deadline has just passed.

Orders due to expire are closed before the strategy’s remaining orders are cancelled, preventing this timing condition from halting the market. The fix also covers OCO switches that cancel a resting exit order.

Fixed an issue that could cause unnecessary settlement delays when a settlement request was retried while still processing.

Retried requests now use the original settlement’s outcome, avoiding additional retries when that settlement has already succeeded.

Swap and QuickSwap minimum amounts now account for order size requirements at the protection price. Signed-in Swap buy quotes also show more accurate expected output and fees.

Amounts below the calculated minimum are rejected before a Swap is created, preventing size-related failures after confirmation. For signed-in buys, expected output reflects the quantity the order buys at its price limit after fees. At better prices, that quantity costs less and the unspent source amount stays in the account. Quotes remain estimates and reserve no liquidity.

Traders and API clients can see when attached take-profit, stop-loss, or trailing-stop protection first becomes live through trigger history and WebSocket updates.

Each attached leg records one ARMED event when it first starts protecting the parent order’s filled quantity, including when protection is attached after a fill. Protection paused before the fill records ARMED upon resume. Later fills and subsequent pauses or resumes do not repeat the event. Attached trailing stops continue to report ACTIVATED when tracking begins.

Clients resuming or modifying a trigger can now distinguish a different listed trading pair from a symbol that is not listed.

REST and Connect return TRIGGER_SYMBOL_MISMATCH for a different listed pair and UNKNOWN_SYMBOL for an unlisted pair. Both cases return HTTP 400, with invalid_argument on Connect, and leave the trigger unchanged.

Clients requesting attached take-profit, stop-loss, or trailing-stop state receive the same arming time as the corresponding trigger.

Attached protection no longer reports a later arming timestamp in the parent order than in trigger details. For attached trailing stops, the parent order also reflects the updated arming time when the activation price is reached.

A rejected level no longer makes the whole ladder fail when other levels have traded and all level orders have ended.

The ladder remains Running while any level order is open. Completed does not mean fully filled: executed quantity, executed levels and individual order statuses show what traded. When every level is rejected before placement, the ladder ends as Failed with the first rejection reason.

GetTrigger and ListTriggers can now return terminal trigger states when those reads require historical data.

Fixes history-backed reads for stop-loss, take-profit, trailing-stop, TWAP and ladder triggers, including their recorded status and version.

Standalone and attached stop-loss and take-profit market orders can execute through price gaps within their applicable slippage limits.

Slippage limits are measured from the firing price, using the requested cap or the market’s default. Buy orders also retain their reserved spending maximum. Orders may fill partially or remain unfilled beyond these limits; attached protection re-arms for the remaining quantity. Generated market orders no longer carry a client reference price, while trigger events retain the firing price.

Order REST responses now omit inapplicable enum fields instead of returning UNSPECIFIED, matching the public API schema.

Direct orders omit origin.triggerType in order details, open orders, and order history. Cancel-all-after omits effectiveScope.side when covering both buy and sell orders. Rejected batch-replacement items omit actionTaken. Order API errors also correctly identify internal failures and spot-read policy denials.

Fixed stale trigger lists immediately after acknowledged trigger and order updates.

Trigger lists now check that active triggers reflect acknowledged creates, modifications, pauses and attached-trigger changes. When updates are still catching up, the API returns a retryable UNAVAILABLE response instead of outdated trigger settings or parent-order associations.

Certain permanent internal-transfer failures now return a precondition error instead of temporary service unavailability.

Affected requests are recorded as refused rather than left pending for retry, giving API clients a definitive failure response.

Traders can see attached protection change after an order fills, including pauses, resumes and failures.

Historical order reads that include attached protection now reflect its status changes instead of leaving take-profit and stop-loss at Created until the final outcome.

Traders can still update trigger prices for take-profit and stop-loss orders attached to a parent order.

The Edit Trigger dialog no longer offers a slippage cap for attached market take-profit and stop-loss orders, preventing unsupported cap changes from being submitted. Standalone market triggers and trailing stops retain slippage editing. Unsupported order changes now display “This change isn't supported for this order.”

Traders can confirm quantity increases when their available balance covers the additional funds needed beyond the order’s existing reservation.

Modify Order now checks only the additional reservation needed for a change. MAX and the amount slider also account for funds already reserved by the order and quantities already filled, preventing them from sizing edits using free balance alone. Increases exceeding the available funds remain blocked.

This affects index-price stop-loss and take-profit orders attached to an entry order when market restrictions prevent execution.

Repeated price updates no longer resend an unchanged running status while the same restriction blocks execution. Attached protective orders remain armed and can trigger on the first qualifying price update after trading resumes.

Fixed avoidable delays in order acknowledgements after periods of low trading activity.

Orders submitted after a quiet period can receive faster responses on affected trading infrastructure. This reduces delays caused by idle processing without changing order behavior.

Traders can resume placing orders after a temporary market restriction blocks a pending attached take-profit or stop-loss exit.

Fixes an unintended market stoppage when a pending attached exit encounters cancel-only, reduce-only, or halted trading. The affected protective leg remains active and can trigger on a qualifying price update after trading resumes.

Trigger responses now include a version field so clients can reconcile API reads with realtime updates.

After editing an order with attached take-profit or trailing-stop protection, replayed updates no longer replace newer trigger states with older ones. Stop and trailing-stop realtime timestamps reflect the state’s actual update time. Clients can compare each trigger’s version across GetTrigger, ListTriggers and realtime updates, keeping the highest version; list results can briefly lag, and reconnects can repeat earlier updates.

Traders face shorter interruptions when pending fills must settle before new orders can execute.

After an unexpected restart, trade settlement resumes sooner, reducing temporary order refusals and pauses across trading pairs.

Cancels that specify the wrong trading pair now return ORDER_UNKNOWN and leave the order active. Replace-batch requests reject only the mismatched item, allowing valid items to proceed.

The cancellation rule applies when targeting an order by order ID or client order ID, including batch-cancel items. The trading pair remains optional for cancellations; omitting it uses the order's own pair.

A limit order for 0.00015 BTC at 90,000 USDT now displays 13.50 USDT instead of 13.49 USDT.

Corrects displayed order values in Open Orders and Order Details, including the details drawer. Filled values and the value shown in Order History also receive the correction. Open Orders now shows at least two decimal places for order values.

Reducing an order’s quantity while resending its current price now amends the order in place, preserving its order ID and queue priority.

AMEND_ONLY accepts these changes instead of rejecting them as requiring replacement. Resending only the current price leaves the order unchanged. Increasing quantity, changing the client order ID, or selecting REPLACE_ONLY still requires replacement.

Traders regain order reads and live order updates sooner when both copies of their account data require recovery.

Recovery now skips an unnecessary waiting period when neither copy can restore the other, while affected order data remains unavailable until recovery completes.

Developers receive listing times consistent with spot configuration, and date-added sorting follows those times.

Market overview uses each pair’s configured listing time and reflects subsequent corrections or removal of that time. Delayed updates cannot restore an outdated listing date.

Trigger reads reject zero-valued ID filters instead of silently ignoring them, and return consistent errors for invalid parent order IDs.

Listing triggers with a zero or invalid parentOrderId returns HTTP 400 with INVALID_ORDER_ID on REST, or invalid_argument with ERROR_CODE_INVALID_ORDER_ID on Connect. A zero subaccountId is rejected when listing triggers, retrieving a trigger, or reading trigger events; REST returns INVALID_SUBACCOUNT_ID, while Connect returns ERROR_CODE_INVALID_ARGUMENT.

Order book snapshots now report whether their depth is current, and QuickSwap and Swap use this status when calculating quotes.

The new available field distinguishes a current book with no liquidity from a book that is temporarily unavailable. Unavailable snapshots contain no price levels and can be requested again later. QuickSwap and Swap exclude unavailable books from pricing, regardless of their sequence number.

Accounts trading through a temporary service interruption spend less time waiting for pending fills to settle.

Settlement catches up sooner after service resumes, reducing backlog-related order refusals while preserving each account's fill order.

Traders regain order reads and live updates without an unnecessary recovery delay following certain market restarts.

Fixes a case where order reads returned catching-up errors and private WebSocket order updates remained paused after trading resumed.

Traders face fewer prolonged settlement backlogs when balance updates take longer during busy periods.

Settlement allows slow balance updates to finish before treating an attempt as failed, reducing unnecessary retries and temporary order refusals. Interrupted settlement attempts are also detected sooner so pending work can be retried promptly.

Fixed an issue that could prevent trading from resuming after a second trading pair was added.

Both the existing pair and the newly added pair can now resume trading.

Matched trades earning maker rebates can settle after periodic fee collection without waiting for new trading fees to accumulate.

Fixes a case where an unpaid maker rebate left a matched trade unsettled and order funds reserved after the order had filled or ended.

Traders can continue submitting orders in existing markets when another trading pair is assigned alongside them.

Prevents the brief trading interruption caused by assigning a new pair while existing markets are running; the new pair still waits to complete activation.

Fixes temporary insufficient-funds rejections caused by counting quote-currency trading fees twice after a buy fills.

Applies to both maker and taker buys whose fees are paid in quote currency. Those fees no longer temporarily reduce the funds available for subsequent orders beyond their actual cost.

Improved the reliability of trading settings after new pairs are added during maintenance.

When additional pairs are added to an existing group of markets, existing markets continue receiving trading-setting updates after the restart, while the new pairs receive their initial settings.

Improved fee handling when trading services recover from an interruption.

Trades using standard trading fees now wait for fee configuration recovery to complete before settlement resumes.

Traders can cancel an attached take-profit or stop-loss immediately after creating its parent order without a temporary-unavailable error caused by creation still completing.

Cancellation now proceeds during the brief interval after an attached trigger receives its ID but before order creation finishes. Cancelling the take-profit leaves the attached stop-loss active, including when the parent order fills immediately.

Order-book heatmap updates also recover when a newly listed trading pair experiences a brief initialization delay.

Order history and heatmap updates resume automatically when the temporary delay clears within the recovery window, preventing a new listing from leaving updates stopped across existing pairs.

Temporary setup delays for a newly listed trading pair no longer stop account fill and trigger-event delivery.

Applies to authenticated real-time subscriptions for root accounts and subaccounts when temporary market initialization delays resolve within the recovery window.

Fixed an order-count limit that could prevent accounts with sustained high trading activity from placing further orders.

Accounts can now continue placing orders beyond the previous per-account limit. Public order ID formats remain unchanged, with no client integration changes required.

Fixed cases where growing account numbers could prevent accounts from placing or canceling orders.

VIP and custom rate-limit settings are retained without crowding out other accounts. Accounts with valid access can cancel orders when their rate-limit policy is unavailable, while cancellation rate limits still apply. New account creation now returns a capacity error when available trading capacity is exhausted.

Fixed an issue where the private order WebSocket could omit a filled order’s final take-profit and stop-loss statuses.

When take-profit completed and its paired stop-loss was canceled, subscribers could miss the final update even though order history showed the outcome. The stream now includes the final order revision before removing the order from the live view.

Fixed an issue that could interrupt market-data updates when multiple trading pairs were processed together.

New trading activity could unexpectedly stop market-data publishing for affected pairs. This fix prevents that interruption when updates arrive between processing steps.

Fixed trading reservations remaining locked after an affected market stops for recovery.

Pending requests are resolved, and reservations for unfilled orders and live triggers are released. Orders with executed trades retain their reservations until settlement completes, then release the remaining funds.

Reduced delays in real-time fill updates on quiet spot markets.

Authenticated account trade subscriptions receive fill updates more promptly after settlement, including during periods of low trading activity.

WebSocket subscribers receive the latest market snapshot once its volume data becomes valid, without requiring another market change.

Market overview updates remain pending while volume data is missing or stale and are retried on subsequent publication cycles.

Fixed an issue that could prevent new accounts and subaccounts from placing orders as the platform’s account count grew.

Account configuration capacity is now managed independently, preventing unrelated accounts from exhausting it. The change also preserves fee-related credits that arrive before a recipient’s account setup completes.

Reduced duplicate trading updates after realtime service interruptions.

Fill and trigger updates now retain better duplicate detection through service recovery. Rare duplicates remain possible during prolonged recovery, so clients should continue handling repeated events by identity.

Fixed a recovery case where looking up a reused client order ID could return an older completed order.

When a newer accepted order finishes during recovery, lookups preserve its identity and retrieve its details from history when available. Affected private order subscriptions resynchronize their state.

Fixed a submission conflict that could prevent internal transfers between trading accounts from appearing on chain and delay later transfer records.

Affected records can now recover automatically, allowing queued records to continue processing. Recovery checks for existing on-chain records before retrying to avoid duplicates.

Routine cleanup during restart recovery no longer leaves affected markets refusing new order requests.

Fixes a recovery failure that could require an additional operator restart before traders could place orders again.

Traders retain access to healthy markets when a restart leaves another pair unable to process orders.

New orders on the affected pair may still be refused until it recovers.

Temporary data availability errors are retried automatically so traders can receive live updates once the new market is ready.

Live candle updates recover from brief failures during trading pair listings. Recovery is bounded, so prolonged or permanent failures can still interrupt updates.

A temporary interruption to one trading pair’s settled execution updates no longer immediately disconnects every private WebSocket session.

Clients subscribed to marketResync receive a notification for the affected pair before its execution updates resume after a read failure, keeping their connection open. Clients without that opt-in still reconnect and resynchronize on recovery. Temporary health-check failures alone no longer trigger a resync.

After a restart, traders can submit orders once balances are up to date even if withdrawal or internal-transfer processing remains delayed.

Delayed withdrawal and transfer processing no longer keeps otherwise ready accounts from resuming trading.

Fixed an issue that could prevent newly listed pairs from becoming available for trading.

Trading services can now process catalog updates that previously blocked activation of newly listed pairs.

Reduced interference between accounts during bursts of order activity, including batch replacements and cancellations.

Order submissions and cancellations now have separate per-account concurrency allowances, helping cancellations remain available during heavy submission activity. Requests refused at the account limit return OVERLOADED without being admitted and can be retried after an outstanding request completes.

Fixed an issue that could leave a trading pair rejecting new orders after a temporary interruption.

Affected pairs can now resume processing pending commands after routine maintenance, including when the pair has little trading activity while other pairs remain busy.

Traders can continue placing orders and triggering stop-loss orders on existing markets while a newly listed market starts up.

Only the newly listed market waits until it is ready to accept orders; its startup no longer blocks trading on other markets.

Order placement no longer fails during a partial service outage.

Order placement now recovers automatically when part of the service stops responding, including when a response stalls partway through.

Fixed an issue that could leave accounts unable to place or modify orders when settlement processing fell behind.

Related settlement balance updates now take effect together, preventing this catch-up condition from leaving affected accounts frozen.

Fixed an issue where an invalid fee update could interrupt trade settlement.

Settlement keeps the last valid fee settings when an update cannot be read, and subsequent valid updates continue to apply.

API clients can identify when a disabled market caused a stop-loss, take-profit, trailing stop, TWAP, ladder, or attached exit to be canceled.

Trigger details, lists, and event history now return named cancellation reasons for disabled markets: PAIR_DRAIN_TRIGGER, PAIR_DRAIN_TWAP, PAIR_DRAIN_LADDER, and PAIR_DRAIN_ATTACHED_LEG.

Fixed an issue under load where an order could disappear from the live WebSocket view without showing its filled, canceled, or rejected outcome.

When an order ends and leaves the live view in the same update, that update now includes its final order revision alongside its removal. Clients should process orders before removedOrderIds within each update. The message format is unchanged.

Fixed a bottleneck that could delay or temporarily pause order acceptance during heavy settlement activity.

Reduces settlement-related processing delays while preserving balance calculations.

Disabling a market automatically cancels its active strategies and releases unused reserved funds once outstanding fills settle.

Cancellation covers resting orders, stop-loss, take-profit, trailing-stop, TWAP and ladder strategies, including attached protective orders. Replacements on cancel-only and reduce-only markets now identify the applicable restriction. Market orders on closed markets report the trading restriction before quote availability is checked.

Traders can submit bulk cancellations and arm cancel-on-timeout for listed pairs even before those pairs are available for trading.

Cancel-all requests, including dry runs, accept listed pairs with no trading activity and report zero matching orders there. Unknown symbols remain rejected. Modifications that require replacing a non-post-only order on a post-only pair now return PAIR_POST_ONLY instead of PAIR_DISABLED; quantity-only reductions remain allowed.

Editing a take-profit or stop-loss trigger now shows a warning when the selected price could cause it to execute immediately.

The warning appears beneath the trigger price when available market data indicates the trigger condition is already met. It is advisory: you can still save the change.

Traders and API clients can retrieve historical order book heatmaps without a previous timed-out read causing an unrelated request to fail.

The fix covers historical heatmap snapshots, updates, and the anchors used to continue into live data.

Rejected edits preserve the previous trigger price and existing protection.

The check includes equality and uses the last-trade or index price the trigger watches. ModifyTrigger returns ERROR_CODE_TRIGGER_WOULD_TRIGGER_IMMEDIATELY (302). Standalone CreateTrigger requests still receive initial acceptance, then end FAILED with TRIGGER_FAILURE_REASON_TRIGGER_WOULD_TRIGGER_IMMEDIATELY (244), without placing an order and with reserved funds released. Attached TP/SL changes are also checked when an order has fills left to protect; attachments on new or unfilled orders are unchanged. Prices crossed after creation is submitted can still trigger normally.

API consumers can distinguish TWAP rollover, cancel-all-after expiry, and strategy cleanup from cancellations requested directly by a user.

GET /v1/orders/history reports TWAP_ROLLOVER (20) when a TWAP cancels its resting slice for the next slice, DEAD_MANS_SWITCH (18) when cancel-all-after expires, and STRATEGY_CANCEL (21) when a strategy cancels its child orders during cleanup or exit coordination. Direct user cancellations retain USER_REQUEST (2).

Resume and modify requests can use the trigger’s stored trading pair, while API keys restricted to specific markets must still supply its symbol.

POST /v1/triggers/{id}/resume accepts an empty body. Resume and PUT /v1/triggers/{id} also accept symbol through the ?symbol= query parameter. Supplying conflicting symbols in the query and body returns 400 BAD_REQUEST without changing the trigger.

Traders reducing a partially filled order now see a single quantity-limit message explaining the filled amount and minimum remaining order size.

The message shows the minimum valid total quantity and offers a Fix action to set it. Entering exactly the filled amount also displays guidance to cancel the order.

Canceling or modifying a finished order now explains that the order has ended, whether identified by order ID or client order ID.

The error message now reads: “The order has already ended (filled, canceled or expired).” The public API error description matches this wording; error codes and transport statuses are unchanged.

Ladder notifications now distinguish fully filled, partially filled, and zero-fill outcomes.

Ladders that end without fills show “Ladder ended” with zero filled quantity and levels. Partial outcomes show the filled quantity and level count against their totals. Fully filled ladders show “Ladder filled,” and cancellation notifications include any quantity already filled.

Traders reaching the account’s cancel-all limit now receive guidance explaining the 120-second retry window.

REST, Connect and WebSocket refusals identify cancel-all as the affected operation, confirm that the request changed nothing, and advise retrying after earlier cancel-all requests leave the window. The public REQUEST_RECEIPTS_EXHAUSTED error code and existing limits remain unchanged.

Traders now see cancellation or rejection reasons in the placement notification when a newly submitted order cannot proceed.

The success notification updates in place when an order is canceled or rejected shortly after submission, including unfilled market orders and rejected post-only orders. If the outcome arrives before the submission confirmation, only the outcome notification appears.

In Modify Order, traders can edit Client Order ID only alongside a change that replaces the order.

The field enables when changing the price, increasing the amount, or choosing Replace Only alongside an order change. In-place amendments keep the existing ID. Submitting an unchanged form no longer shows an update error.

Filled and partially filled limit orders now show their executed value even after a price edit.

Order History calculates Order Value using average fill price multiplied by filled quantity. The optional Cost column in Open Orders uses the same calculation.

API clients receive new trading pairs and changed order book grouping settings after temporary interruptions without waiting for a service restart.

Pair status, price increments and minimum order sizes also catch up automatically when configuration updates resume, instead of remaining stale until restart.

Traders using linked take-profit and stop-loss orders can submit the remaining quantity without a false insufficient-funds rejection immediately after a take-profit fill settles.

When the stop-loss triggers after a partial take-profit, the remaining position is no longer temporarily treated as unavailable because of the earlier fill.

Market makers who promptly consume updates can cancel more than 256 resting orders, up to the 10,000-order account limit, without losing their private stream.

The cancellation acknowledgement precedes individual cancellation updates for each order, and the same connection remains available for subsequent commands.

Markets such as ETC-USD can retain an index price when at least two fresh, qualified venues agree despite wide spreads elsewhere.

Venue quotes with excessive bid–ask spreads are excluded before checking price agreement. Index prices remain unavailable when fewer than two qualified venues agree.

API clients receive asset metadata changes made during recovery from a temporary interruption without waiting for a service restart.

Fixes a case where the asset list, asset names, and market-data volume precision could remain stale after an interruption.

Market makers sending overlapping SBE trading commands can receive fills and order updates without unrelated pending commands blocking delivery and causing a disconnect.

Fixes private-stream queue overflows caused by continuously pipelined commands delaying queued updates. Each command’s acknowledgement still precedes its own events, and acknowledgements and events each retain their order. Existing overflow disconnect and resynchronization behavior remains.

API clients receive 404 when a trigger is confirmed absent, while temporary history delays remain retryable.

Requests for nonexistent trigger IDs no longer repeatedly return “Order history is catching up” after absence has been confirmed.

Individual order lookups and open-order lists can proceed while earlier reads are still waiting, reducing avoidable delays during heavy server load.

Requests continue to require current order state and return a retryable error when that state cannot be confirmed; timeouts remain possible under load.

Reduced delays in order lookups and open-order lists for accounts with many completed orders.

Improved lookup performance by order ID and client order ID, and reduced interruptions to order reads while completed orders are processed in bulk.

Fixed an intermittent delay that could leave attached trailing stops, take-profit and stop-loss orders waiting several seconds to become active after their parent order filled.

Attached exits now activate more promptly once the parent fill settles, reducing the window in which a trailing stop could miss a price peak and reversal.

Improved available-balance handling during withdrawals and internal transfers.

Transferred amounts remain reserved until the account reflects the completed movement, keeping available balances consistent while balance updates are pending.

Protobuf trading WebSocket clients now receive cancel-all statuses that reflect the requested mode even when no orders match or every cancellation fails.

Dry-run requests return DRY_RUN even with zero matching orders. Live requests return SUBMITTED even when every cancellation fails, with failure counts preserved so clients can identify unsuccessful cancellations.

This fixes immediate lookups of replacement take-profit triggers returned by a successful order protection edit.

GetTrigger waits for the accepted trigger's state to become readable. If catch-up exceeds the read deadline, it returns a retryable unavailable response.

This fixes a regression that could block new orders on active accounts during ordinary sustained trading.

Trade-related balance updates remain in trade order, including after a restart.

Changes to a resting order’s take-profit, stop-loss, or trailing stop now apply together with any price or quantity edit, or the entire edit is rejected.

A rejected edit preserves the existing order and its protection. Exhausted trigger capacity returns TRIGGER_CAPACITY_REACHED so clients can retry later; an unsupported index-price source returns TRIGGER_PRICE_SOURCE_UNSUPPORTED.

Pending trade settlements no longer accumulate increasing retry delays while their requests cannot be delivered during a connection outage.

Settlement automatically resumes when the connection returns, without carrying forward retry delays from requests that were never delivered.

Newly listed trading pairs produce live and historical candles from their first available trade.

Existing markets continue receiving candle updates while a new pair becomes ready, and trades received before readiness are included when its candles begin.

Traders can continue receiving trades, order books and candles for ready pairs while another pair awaits its data feeds.

Each newly listed pair starts supplying market data independently once its required feeds are available.

Improved settlement recovery after temporary confirmation failures.

Settlement processing can retry interrupted confirmations automatically, helping avoid extended delays after brief infrastructure disruptions.

Reduced prolonged order-entry failures caused by temporary infrastructure disruptions.

Fixed a recovery issue that could interrupt placing, modifying, and canceling orders when configuration updates were temporarily unavailable. Affected services now recover automatically when those updates resume.

When a fill is permanently refused settlement, its reserved funds release after the order ends instead of remaining unavailable indefinitely.

The refused fill moves no funds and no longer blocks settlement of later fills for the affected accounts. Reservations release once the order has ended and every fill has a final settlement outcome. The order retains its filled quantity; this change adds no customer notification.

Attached take-profit and stop-loss orders now trigger when they become active if the latest eligible price already meets their trigger condition.

Previously, a price move during settlement could leave an attached exit waiting for another price update. Newly activated legs now check the latest eligible price, including when additional fills restore a remaining position. Activation still waits for settlement; price moves that reverse before activation remain outside this fix.

Clients can distinguish stale or missing order data from current data while updates for other orders continue.

The private orders WebSocket sends Unavailable with reason ORDER_UNAVAILABLE and the affected public order IDs in order_ids (orderIds in JSON). The list updates as affected orders change, including for new subscriptions, and Available signals when the subscription is current again.

Both traders can recover reserved balances automatically when a fill's settlement record is skipped.

The affected trade remains in history without transferring assets. Its reserved funds are released when the order ends and its fills have been accounted for.

Corrected a price validation issue that could exclude eligible trades from VIP volume calculations.

Affected trades can now be included during scheduled historical recalculation, allowing VIP qualification to recover automatically without manual intervention.

Ladder creation errors now identify which order was rejected and why.

REST and ConnectRPC responses name the rejected ladder order and its reason, such as insufficient funds. ConnectRPC error details also identify the affected level and its rejection code, making failures easier to diagnose.

Fixed cases where temporary service interruptions or restarts during startup could leave affected markets unavailable until manual intervention.

Affected markets can now recover automatically after these interruptions clear, including restarts that interrupt market initialization.

Developers creating TWAP orders receive distinct duration and interval error codes through REST and ConnectRPC.

A duration below 1000 ms returns TWAP_DURATION_INVALID; a slice interval below 100 ms or above the duration returns TWAP_INTERVAL_INVALID. When both are invalid, duration is reported first. REST returns HTTP 400, while ConnectRPC returns InvalidArgument with the specific error code.

Traders receiving live updates avoid repeated fill and trigger notifications when recent events are resent during recovery.

Duplicate suppression covers settled-fill updates and trigger events, including JSON and Protobuf feeds. Protection applies to recent events; existing client-side handling of duplicate events remains necessary for older replays or restarts.

Traders experience shorter history delays when heavy trading creates a backlog of completed orders.

Reduces delays in recording completed orders, terminal trigger outcomes, and trigger events for history reads.

Spot charts and public candle APIs use the previous close for intervals starting after rollout, across all timeframes.

High and low include the opening price, even when no trade in the interval reached it. A market’s first candle opens at its first trade, and intervals without trades remain flat with zero volume. Existing history is not rewritten, and candles already open at rollout retain their original opening price until they close.

Affected markets catch up on missed trading activity once the interruption ends, instead of leaving trade history and candle charts frozen.

Fixes a case where a temporary market-data outage stopped updates indefinitely while trading continued.

Longer-interval charts retain earlier prices and volume when a minute or hour closes following a restart.

Fixes missing pre-restart trades in live candles, including 2-hour, 4-hour, daily, weekly and monthly intervals. For markets that first traded during the restart minute, candles of three minutes or longer also retain those trades instead of becoming flat with zero volume.

Traders using TradingView charts now receive live candle updates again after the market data connection recovers or encounters a stream error.

The chart automatically reloads candle data and resumes live updates when recovering from an interruption.

Private trade and trigger streams also pick up newly listed spot markets automatically.

New markets are included from their first fills and trigger updates, while processing continues for existing markets.

Spot traders can switch between Standard and Advanced layouts while order book and recent trade updates stay connected.

Charts reuse current candle history during brief layout switches and continue receiving live updates. Fresh history is requested again if the live connection is interrupted.

Traders now see matching text sizes for the order type and status in the order details header.

The correction applies to both the desktop dialog and mobile drawer.

When an order's current state becomes temporarily unavailable, affected reads can recover automatically without waiting for another order update.

Recovery is retried periodically and restores affected reads once current order state can be verified, while other order updates continue processing.

Traders continue receiving new order-history updates after temporary connection failures that previously required manual recovery.

Recovery now skips identical repeated history records so processing can continue, with the same protection applied to trigger history.

API clients receive a retryable UNAVAILABLE error when a matching live order’s current state cannot be read.

Open-order requests now fail explicitly instead of returning stale order data or silently omitting an affected live order. Order-history requests also fail when an affected order appears on the requested page. REST returns HTTP 503 with code UNAVAILABLE; retry the same request. Orders outside the requested market filters do not block the list.

Rejected price changes leave the original order and its attached protection unchanged.

For limit buys, attached take-profit triggers must stay strictly above the order price and stop-loss triggers strictly below it; limit sells use the reverse. Creation and edits reject prices equal to or beyond these boundaries, including direct trigger edits while the parent order is working. You can update the order price and protection together when the resulting prices are valid. No minimum distance is required.

Swaps refused because an index price is unavailable now report MARKET_UNAVAILABLE.

If this refusal occurs, the swap can finish with a failure result instead of remaining in reconciliation. Its failure reason identifies market unavailability rather than a generic order rejection.

Traders can adjust protection after a full entry fill or a partial fill with the remainder canceled.

Change the attached trailing stop’s distance, activation price or slippage cap while retaining its tracked peak and protected quantity. Edits remain unavailable while an exit is being placed or remains active.

Fixed a timeout edge case that could delay reference-price history from becoming available.

History recovery can now continue when a brief availability check times out after data has been received. Historical data must still be verified before recovery is considered complete.

The fix applies to buy and sell orders, including standalone orders, attached TP/SL, and attached TP/SL edits.

Take-profit-limit and stop-loss-limit prices can be below, equal to, or above their trigger price. Existing trigger-direction checks remain in place.

Fixes trading interruptions caused by delayed responses for paused or not-yet-active stops, and prevents temporary post-only restrictions from permanently ending attached stop-loss orders.

An attached stop-loss blocked by post-only mode remains armed and can trigger again on a qualifying trade after the market reopens. Delayed responses for paused or not-yet-active triggers preserve their current state without interrupting the market.

Fixed order placement failures caused by expired client order IDs continuing to consume order capacity.

New orders can reclaim expired IDs even when other accounts have older records. Order previews also account for this reclamation. Orders created by fired stops and attached risk controls count toward trigger capacity while open and for 60 seconds after ending.

Fixed cases where order matching, timed order expiry, or replacing an expiring order could halt trading on an affected market.

Orders matching across multiple counterparties and batches of timed order expirations now complete without these interruptions. Replacing an order that expires during processing returns a rejection without halting the market.

Orders with attached trailing stops now reject invalid caps before acceptance, and trailing-stop updates enforce the same limit as creation for both buy and sell orders.

Explicit percentage-based slippage caps must be between 1 and 9,999 basis points; 10,000 returns ERROR_CODE_MAX_SLIPPAGE_INVALID. Setting zero during an update still clears the cap. API descriptions also clarify how attached take-profit and stop legs share the remaining filled position and coordinate exits.

API clients checking batch replacements under heavy activity can retrieve results throughout the existing replay window.

Status lookups no longer lose recent batches because other batches were submitted, and restarting the reader preserves results that have not expired.

Buy orders paying fees in the purchased asset now size attached take-profit and stop-loss exits to the market’s quantity step, leaving smaller remainders in the balance.

Exit rejections such as minimum-quantity or insufficient-balance failures now show Failed with a reason, while sibling protection can continue protecting the remaining quantity. Temporary market or system refusals remain eligible to retry. If a finished parent order leaves only a remainder below one quantity step and no exit has occurred, its attached protection ends with a quantity-step failure.

Trigger list, detail, and realtime updates now include the recorded closing instant for cancellations and failures.

This covers stop-loss, take-profit, trailing, TWAP, and ladder triggers, including user cancellations and OCO sibling cancellations. The completedAt field matches the terminal event timestamp and remains absent while a trigger is active.

Developers requesting candle history now receive up to the requested number of closed candles, with the current open candle included only when requested and available.

With sufficient history, limit=3 returns three closed candles; includeIncomplete=true can add one current open candle within the requested range. Historical candles returned by GetCandles now report isClosed=true, while the open candle reports false.

Removing a take-profit or stop-loss leg while its limit exit is resting now preserves the exit’s attached-order classification in order history.

The cancelled exit remains linked to its parent whether it was unfilled or partially filled. Replacing an exit preserves that relationship, and replacing its parent updates the relationship to the replacement order.

Fixed a scheduling delay that could postpone candle close updates when trading activity paused.

Candle completion now follows whole-second boundaries instead of inheriting a delay from the previous input's timing. This scheduling correction also survives service recovery.

Order history now identifies attached exits canceled before they start working as belonging to their parent order rather than a standalone trigger.

This covers exits canceled when another protective trigger takes over or when their trigger is canceled during submission, including after the parent order is replaced.

Fixes a case where routine maintenance left new order records, recent trades and candle data missing from history.

History updates can resume automatically after background processing is reassigned, without waiting for the affected processing to restart.

Fixed an issue where delayed updates could replace newer spot and reference candle data with stale values.

Completed candles now retain their latest values when older updates arrive after a processing interruption or retry. Longer chart intervals also use the latest candle values when calculating prices, volumes, and trade counts.

The fix addresses temporary read failures that became more frequent as completed orders accumulated.

Fetching open orders and individual order details no longer encounters the periodic interruption addressed by this fix.

Traders receive continuing market-data updates after temporary processing failures that previously could stop price and candle updates.

Recovery also prevents previously processed trades from changing index-price calculations a second time.

Fixed unnecessary QuickSwap failures when account readiness is briefly delayed.

Affected swaps now wait and retry automatically, allowing them to proceed once the account is ready. Orders awaiting confirmation remain tracked even if confirmation arrives after the execution deadline.

Fixed errors when retrieving triggers and their event history through the orders API client prefix.

GetTrigger, ListTriggers, and ListTriggerEvents requests using /api/orders-api-write now reach the supported read endpoints instead of returning an unimplemented error.

Clients replacing order data from private WebSocket updates receive attached protection details from the first pending version.

Initial pending updates include attached take-profit, stop-loss and trailing-stop settings, trigger identifiers and whether the protective orders cancel each other. This prevents the initial update from making configured protection appear absent.

Order history now identifies take-profit, stop-loss, and trailing-stop exits as attached protection and includes the order they protect.

When a protected order is replaced, subsequent exit records reference its replacement, preserving the relationship in historical order reads.

Attached stop-loss and trailing-stop orders can now take over the remaining position without an insufficient-funds rejection caused by the previous take-profit order.

When the stop triggers, the remaining take-profit order is cancelled and the protective exit is sized to the remaining position, even before earlier fills settle. This applies to both OCO-linked and independent attached exits.

QuickSwap rejects unsupported TWAP requests before issuing a deposit address and routes previously credited TWAP deposits through the normal return process.

TWAP quote and create requests return ROUTE_UNSUPPORTED with an explicit message to use market execution. Previously accepted TWAP deposits are processed for return without trading, subject to the usual withdrawal requirements.