Don’t invest unless you’re prepared to lose all the money you invest. This is a high-risk investment and you should not expect to be protected if something goes wrong. Take 2 minutes to learn more.

Maker Protection

Last updated: 30 September 2026

This article is a summary of Maker Protection. For the full technical detail, including protocol-specific behavior for REST, WebSocket and FIX, see the Maker Protection developer guide.

Maker Protection is a short, fixed delay applied to orders that could take liquidity on selected Kraken Derivatives markets. It gives resting maker orders a brief window to react to new information before an incoming order can trade against them. Maker Protection has been live since September 24, 2026.

On a market with Maker Protection, any order action that could take liquidity is held for a short window before it reaches the matching engine. Post-only placements and all cancellations are never held.

  • •

    Delay: 20 ms at launch, and never more than 100 ms. The delay is published per market as makerProtectionMillis.

  • •

    Markets: Selected Derivatives (Futures) markets only. Spot is not affected.

  • •

    Consistency: Behavior is identical on REST, WebSocket and FIX.

  • •

    Fairness: The delay applies equally to every client. There are no per-account exemptions.

  • •

    How to avoid it: Submit the order as post-only. A limit order without post-only is held even if it would have rested on the book, because the delay depends on the order type, not the outcome.

A held order takes its place in the queue when it is released, not when it was received.

The authoritative source is the makerProtectionMillis field on GET /instruments and GET /trading/instruments. If a market has no Maker Protection, the field is left out entirely, so treat a missing field and a value of zero as the same thing: no delay.

  • •

    59 markets were covered at launch on September 24, 2026.

  • •

    The 10 most liquid linear perpetual markets are excluded, so that active taker flow in the majors is not slowed.

  • •

    Every perpetual listed after September 24, 2026 has Maker Protection from launch.

  • •

    Additions are announced on status.kraken.com ahead of each maintenance window.

Action

Delayed?

Limit, IOC, FOK or market order

Yes

Post-only order

No

Edit of an order that can rest and take liquidity

Yes

Edit of a resting post-only order

No

Stop, take-profit or trailing-stop placement

No

The order a stop or take-profit trigger fires

Yes, unless the fired order is post-only

Order group with a new non-post-only parent

Yes

Order group attaching to an existing order

No

Cancel, cancel-all, cancel-all-after

No

Block trades and other off-book flow are also exempt.

There is no “held” order state in the public API. Maker Protection shows up as extra latency on aggressive orders, and these properties are worth designing around:

  • •

    Validation happens at release. Margin, price collars and market status are checked when the delay ends, not when you submit. An order that was valid on submission can still be rejected.

  • •

    The full window is always served. If the liquidity that made your order aggressive disappears during the window, the order still waits out the delay. Held orders are not re-evaluated.

  • •

    Orders are released in order. Holds are released first in, first out, so a later order cannot overtake an earlier one.

  • •

    The delay is “at least” the configured window. Orders fired by a stop or take-profit trigger are released by the next event the matching engine processes, so on a quiet market they can wait noticeably longer than the configured window.

  • •

    Do not measure the delay. Read makerProtectionMillis instead, as it can be changed at any time.

A held order is not yet on the book and is not guaranteed to get there. During the window, an order can be affected by events unrelated to your own trading:

  • •

    The market is suspended: the order is rejected with marketSuspended.

  • •

    Your account is de-risked or liquidated: the order is refused with CANCELLED_WHILE_HELD.

  • •

    Margin or price collars move against you: the order can be rejected at release.

  • •

    You change your leverage or margin mode: the change is refused while you have any request held. Retry once your holds have released.

If you receive a rejection roughly one window after sending an order, it has usually not been rejected because the order itself was malformed. Check the returned status.

You can cancel an order while it is held, and cancels are never delayed. However, a cancel cannot recall committed aggression. Canceling removes the order’s right to rest on the book, but not its obligation to trade.

A canceled held order can still fill. If the market moves in your favor during the window, the order still takes the liquidity it can at release. Do not retry the placement after a successful cancel.

What happens depends on the type of request being held:

  • •

    Limit order: the cancel is acknowledged, and the order is released as immediate-or-cancel. It takes what it can and any remainder is discarded. You receive two responses: the cancel’s, and the order’s own about one window later. If the order cannot trade at release, REST v3 returns iocWouldNotExecute.

  • •

    IOC, FOK or market order: there is nothing to convert, so the cancel returns ORDER_NOT_FOUND and the order still lands at release.

  • •

    Edit of a resting order: the original order stays live at its old price during the window. A cancel is absorbed, and at release the edit is rewritten so the order reprices and can no longer rest.

  • •

    Order group: a group with a held parent cannot be canceled during the window and goes live at release. Cancel it once it is live.

  • •

    Dead man’s switch (cancelallordersafter): a held order is converted in the same way. The switch does not recall a held order.

If you need nothing left resting and nothing new trading, wait out the window (100 ms at most) and then cancel.

When a held order is released, it always cancels any resting order of yours that it would match, whatever self-trade strategy your account uses. This applies across your whole account tree, including your master account, sibling accounts and sub-accounts.

  • •

    Your resting order is canceled with the reason CANCELLED_BY_SELF_TRADE, and the released order trades.

  • •

    FOK orders and RFQs are the exception. Your configured strategy applies as normal.

  • •

    Orders that were never held are also unaffected.

If you rely on REJECT_TAKER to protect your resting quotes on a Maker Protection market, that protection does not apply against your own released orders.

Concurrent holds. You can have at most 250 requests held at once. A request beyond the cap is refused and reported as though you had hit your order limit (tooManyOrders on REST v3, TOO_MANY_ORDERS on REST v4, ORDER_LIMIT_EXCEEDED on market data and SBE). The cap limits how many holds are live at the same time, not how fast you can send orders. It is shared across a master account and its sub-accounts, and it is safe to retry once your earlier holds have released.

Account limits decided when the hold opens. To stop account settings being changed mid-window, some limits are settled when the hold opens rather than at release:

  • •

    Open-order limit: if you are at your limit, the order is admitted but converted so that it cannot rest.

  • •

    Maximum position: the budget is reserved for the order at submission. An order refused at that point stays refused even if you free up budget, and reserved budget is unavailable to later orders, which are refused with MAX_POSITION_EXCEEDED.

  • •

    Client order IDs: a hold reserves its client order ID for the window. Reusing it for another placement is refused immediately with clientOrderIdAlreadyExist. Wait out the window before reusing an ID, or address in-flight cancels by order ID.

A batch is not held as a single unit. The window starts at the first liquidity-taking instruction in the batch.

  • •

    Instructions before the first aggressive instruction are sent immediately.

  • •

    The first aggressive instruction, and everything after it, wait out the window together.

  • •

    Cancels are always sent immediately. A cancel placed after the order it targets claims that order’s hold within the same batch. A cancel placed before it cannot.

To make sure a passive instruction reaches the book without delay, put it ahead of any aggressive instruction in the batch.

REST. The connection is held for the delay, and the response carries the final outcome. Set your client-side timeout comfortably above the window. Because the window never exceeds 100 ms, a single timeout budget covers every market. If you send processBefore on an aggressive order, it must allow for the hold, otherwise the order is rejected every time with wouldProcessAfterSpecifiedTime.

WebSocket. Nothing is published while an order is held. You receive the usual open_orders and fills events once the order is released, about one window later than before.

FIX. The gateway sends an advisory ExecutionReport when a request is held: Pending New (39=A) for a placement, or Pending Replace (39=E) for an amend. The report is advisory only and is not a terminal state. A held placement has no OrderID yet, so ClOrdID is your only handle on the order during the window. The real acknowledgement follows at release.

If one leg of an order group is held when an opposing sibling fills, the held leg is not removed and both legs can go live. A fix is in progress.

On Maker Protection markets, check your fills after any sibling fill in an order group rather than assuming one leg has canceled the other.

Maker Protection has been enabled on the launch markets in the client UAT environment since August 27, 2026, with the same 20 ms window and 250-hold cap as production. Contact your account manager for UAT access. It is worth testing:

  • •

    Canceling during a hold, and handling an order that still fills afterwards

  • •

    Canceling during a held amend

  • •

    A resting order of yours being canceled by a released order, even with REJECT_TAKER set

  • •

    Handling tooManyOrders on a placement, and retrying it

  • •

    Reusing a client order ID inside a window

  • •

    Batch instruction ordering, and client-side timeouts above the market’s makerProtectionMillis