Maker Protection

最近一次更新： 2026年9月30日

本文為 Maker Protection 的概要說明。如需完整技術細節，包括 REST、WebSocket 及 FIX 的協議特定行為，請參閱 Maker Protection 開發者指南。

Maker Protection 是一種短暫的固定延遲機制，適用於可能在 Kraken 指定衍生品市場上吃單的訂單。它為靜止掛單訂單提供短暫的反應窗口，使其能在新進訂單與之成交前響應最新資訊。Maker Protection 已於 2026 年 9 月 24 日正式上線。

什麼是 Maker Protection？

在啟用 Maker Protection 的市場中，任何可能吃取流動性的訂單操作，在到達撮合引擎前均會被暫緩一個短暫窗口。Post-only 訂單的提交及所有撤單操作不受延遲影響。

•
延遲時間：上線時為 20 毫秒，最長不超過 100 毫秒。延遲時間以 makerProtectionMillis 形式按市場公布。
•
適用市場：僅限部分衍生品（期貨）市場。現貨市場不受影響。
•
一致性：REST、WebSocket 及 FIX 的行為完全一致。
•
公平性：延遲機制對所有客戶一視同仁，不設任何帳戶豁免。
•
如何避免延遲：請以 post-only 方式提交訂單。未設 post-only 的限價訂單即使原本會靜止於訂單簿，亦會被暫緩——因為延遲取決於訂單類型，而非最終成交結果。

被暫緩的訂單在釋放時才按序排隊，而非以接收時間計算。

哪些市場啟用了 Maker Protection？

最權威的資料來源是 GET /instruments 及 GET /trading/instruments 上的 makerProtectionMillis 欄位。若某市場未啟用 Maker Protection，該欄位將完全省略——欄位缺失與數值為零含義相同：即無延遲。

•
上線首日（2026 年 9 月 24 日）共涵蓋 59 個市場。
•
流動性最高的 10 個線性永續合約市場不在涵蓋範圍內，以免拖慢主流市場的活躍吃單流。
•
2026 年 9 月 24 日後上線的所有永續合約市場，自上線起即啟用 Maker Protection。
•
新增市場將在每次維護視窗前於 status.kraken.com 公告。

哪些訂單會被延遲？

行動	是否延遲？
限價、IOC、FOK 或市價訂單	是
Post-only 訂單	否
可掛單亦可吃取流動性的訂單修改	是
已掛單的 post-only 訂單之修改	否
止損、止盈或移動止損的下單	否
止損或止盈觸發後所產生的訂單	是，除非觸發訂單為 post-only
附帶新非 post-only 母單的訂單組	是
附加至現有訂單的訂單組	否
撤單、全部撤單、定時全部撤單	否

大宗交易及其他場外交易流量同樣豁免。

延遲機制說明

公開 API 中並無「持有中」的訂單狀態。Maker Protection 會以主動單額外延遲的形式呈現，以下特性值得在系統設計時考量：

•
驗證於釋放時進行。 孖展、價格限幅及市場狀態均在延遲結束時才會檢查，而非提交時。提交時有效的訂單，釋放時仍可能遭拒。
•
延遲視窗必定完整執行。 若令訂單具主動性的流動性在視窗期間消失，訂單仍需等待完整的延遲時間。持有中的訂單不會重新評估。
•
訂單按序釋放。 持有以先進先出方式釋放，後提交的訂單不能超越先提交的訂單。
•
延遲時間「至少」為設定視窗長度。 由止損或止盈觸發的訂單，將在撮合引擎處理下一個事件時釋放。在交投淡靜的市場，等待時間可能明顯超過設定視窗。
•
請勿自行量測延遲時間。 請改為讀取 makerProtectionMillis，因為該值可隨時更改。

訂單持有期間可能發生的情況

持有中的訂單尚未進入訂單簿，亦無法保證最終進入。在視窗期間，訂單可能受到與您本身交易無關的事件影響：

•
市場暫停交易： 訂單將遭拒，並返回 marketSuspended。
•
帳戶被降低風險敞口或強制平倉： 訂單將遭拒，並返回 CANCELLED_WHILE_HELD。
•
孖展或價格限幅對您不利： 訂單可能在釋放時遭拒。
•
您更改槓桿或孖展模式： 若有持有中的請求，變更將遭拒。請等待持有釋放後再重試。

若您在提交訂單約一個視窗時間後收到拒絕通知，通常並非因為訂單格式有誤。請檢查返回的狀態碼。

取消等待中的訂單

訂單持有期間可以撤單，且撤單不受延遲影響。但請注意，撤單無法撤回已提交的主動成交意圖。撤單僅取消訂單在訂單簿掛單的權利，並不能免除其成交義務。

已撤銷的持有訂單仍可能成交。若視窗期間市場走勢對您有利，訂單釋放時仍會盡可能吸納流動性。撤單成功後，請勿重新提交同一訂單。

具體結果視持有請求的類型而定：

•
限價訂單： 撤單請求獲確認後，訂單將以即時成交或取消（IOC）方式釋放，盡量成交後餘量自動取消。您將收到兩個回應：撤單的回應，以及約一個視窗後訂單本身的回應。若訂單釋放時無法成交，REST v3 將返回 iocWouldNotExecute。
•
IOC、FOK 或市價訂單： 無須進行類型轉換，撤單將返回 ORDER_NOT_FOUND，訂單仍會在釋放時執行。
•
修改掛單中的訂單： 在視窗期間，原始訂單將以原有價格繼續有效。撤單請求會被吸收；釋放時，修改指令將被改寫，訂單重新定價後不再以掛單方式留存。
•
訂單組：若父訂單處於等待狀態，該訂單組在等待期間無法取消，並將在釋放時生效。請於生效後再行取消。
•
緊急停止開關（cancelallordersafter）：處於延遲等待中的訂單將以相同方式被轉換處理。緊急停止開關不會撤回延遲等待中的訂單。

若您希望不保留任何掛單、也不產生新成交，請等待窗口期結束（最長 100 ms），然後再取消。

自我交易防護

延遲等待中的訂單釋放後，無論您的帳戶採用何種防止自我交易策略，系統均會取消所有與之匹配的掛單中的訂單。此規則適用於整個帳戶樹，包括主帳戶、同級帳戶及子帳戶。

•
您的掛單中的訂單將以 CANCELLED_BY_SELF_TRADE 為原因被取消，已釋放的訂單則正常成交。
•
FOK 訂單及報價請求（RFQ）屬例外，將按您設定的策略正常處理。
•
從未處於等待狀態的訂單不受影響。

若您依賴 REJECT_TAKER 來保護 Maker Protection 市場上的掛單報價，請注意該保護機制不適用於您自身已釋放的訂單。

訂單延遲等待期間適用的限制

同時延遲等待請求上限。您最多可同時持有 250 個延遲等待中的請求。超出上限的請求將被拒絕，並以達到訂單上限的方式回報（REST v3 回傳 tooManyOrders，REST v4 回傳 TOO_MANY_ORDERS，市場數據及 SBE 回傳 ORDER_LIMIT_EXCEEDED）。此上限限制的是同時延遲等待中的請求數量，而非發送訂單的速率。上限由主帳戶及其子帳戶共享，待早前的等待請求釋放後即可重試。

帳戶限制於延遲等待開始時確定。為防止帳戶設定在窗口期內被更改，部分限制將於延遲等待開始時結算，而非於釋放時結算：

•
掛單數量上限：若您已達上限，訂單仍會被接受，但將被轉換為無法掛單的類型。
•
最大倉位：訂單提交時，系統即為其預留相應額度。該時點被拒絕的訂單，即使其後釋出額度亦維持拒絕狀態；已預留的額度對後續訂單不可用，後續訂單將以 MAX_POSITION_EXCEEDED 被拒絕。
•
客戶訂單 ID：延遲等待期間，系統將為訂單保留其客戶訂單 ID。在窗口期內重複使用同一 ID 下新訂單，將立即以 clientOrderIdAlreadyExist 被拒絕。請等待窗口期結束後再重複使用該 ID，或改以訂單 ID 處理進行中的取消請求。

批量訂單

批量訂單不會作為單一單元整體進入延遲等待，窗口期從批量中第一條吃單指令開始計算。

•
第一條吃單指令之前的指令將即時發送。
•
第一條吃單指令及其後的所有指令，將一同等待窗口期結束。
•
取消指令始終即時發送。在同一批量中，位於目標訂單之後的取消指令可承接該訂單的延遲等待；位於目標訂單之前的取消指令則不能。

如需確保被動指令無延遲地進入訂單簿，請將其置於批量中所有主動吃單指令之前。

使用 API 及 FIX

REST。連線將在延遲期間保持，回應中包含最終結果。請將客戶端超時時間設定為明顯高於窗口期的數值。由於窗口期從不超過 100 ms，單一超時設定即可覆蓋所有市場。若您在主動吃單訂單上設置 processBefore，必須為等待時間預留足夠空間，否則訂單每次都會以 wouldProcessAfterSpecifiedTime 被拒絕。

WebSocket。訂單處於等待狀態期間不會發布任何消息。訂單釋放後，您將收到一般的 open_orders 及 fills 事件，時間約比以往延遲一個窗口期。

FIX。當請求處於等待狀態時，閘道器將發送一條通知性 ExecutionReport：下單時為 Pending New（39=A），修改時為 Pending Replace（39=E）。此報告僅供參考，並非終態。等待中的下單請求尚無 OrderID，因此在窗口期內 ClOrdID 是您追蹤該訂單的唯一依據。真正的確認回應將於釋放時發出。

訂單組的已知限制

若訂單組中某一腿在暫掛期間，對立的另一腿已成交，被暫掛的一腿不會自動撤銷，兩腿均可能同時生效。相關修復正在進行中。

在啟用 Maker Protection 的市場中，當訂單組的任一腿成交後，請確認您的成交紀錄，切勿假設另一腿已自動取消。

測試您的整合設定

自 2026 年 8 月 27 日起，Maker Protection 已在客戶 UAT 環境的上線市場啟用，延遲窗口及暫掛上限均與正式環境相同（20 ms 窗口、250 個暫掛上限）。如需 UAT 存取權限，請聯絡您的客戶經理。建議測試以下場景：

•
在暫掛期間取消訂單，以及處理訂單於取消後仍然成交的情況
•
在暫掛修改期間取消訂單
•
即使已設定 REJECT_TAKER，您的掛單中的訂單仍可能被已釋放的訂單取消的情況
•
處理下單時出現的 tooManyOrders 錯誤，並進行重試
•
在同一窗口內重複使用客戶訂單 ID
•
批次指令的排序，以及客戶端逾時設定須高於市場的 makerProtectionMillis