IOC（立即或取消）訂單和 FOK（成交或取消）訂單有何區別？

訂單執行機制

1. IOC 訂單嘗試立即執行訂單中與可用流動性相匹配的任何部分，並立即取消未執行的剩餘部分。

2. FOK 訂單要求按指定價格完全執行或完全不執行——任何情況下都不允許部分執行。

3. 兩種訂單類型都在中心化加密貨幣交易所的撮合引擎內運行，其中交易路由的速度和精度對於做市商和套利者至關重要。

4. IOC 行為在價格波動期間特別有用，此時交易者旨在捕獲稍縱即逝的價差而不積累未平倉頭寸。

5. FOK 訂單通過拒絕執行來完全消除滑點風險，除非所請求規模的每個單位都以確切的限價進行交易。

流動性互動模式

1. 只要每個匹配立即發生，針對分散訂單簿下的 IOC 訂單就可以跨越多個價格水平進行填充。

2. 如果即使有一個單位在指定價格上缺乏交易對手，無論賬簿的其餘部分出現多深，FOK 訂單都會失敗。

3. 市場深度可視化工具經常歪曲 FOK 的可行性——看似足夠的交易量可能分​​​​佈在不連續的價格層級或每級規模不足的靜置訂單上。

4. 具有積極的交易後報告的交易所可能會實時披露部分 IOC 填充，而 FOK 拒絕通常在公共交易源中顯示為無聲的非事件。

5. 使用算法策略的交易者經常快速連續地分層 IOC 訂單來探測流動性，而 FOK 的使用往往集中在具有嚴格風險參數的高確信度方向入場點上。

特定於交易所的實施變體

1. 幣安將 IOC 邏輯應用於現貨和期貨市場，但對其 USDⓈ-M 永續合約中的 FOK 訂單執行更嚴格的時間戳驗證。

2. Bybit將FOK訂單視為繞過標準隊列定位的原子操作——如果完全匹配失敗，則不會根據到達時間授予優先級。

3. OKX 實現了混合模型，如果不滿足匹配條件，在拍賣階段提交的 FOK 訂單可能會轉換為限價訂單，這違反了嚴格的 FOK 語義。

4. Kraken 的 API 文檔明確警告，由於不同的掛單者-吃單者費用結構影響了靜息訂單激勵，因此 ETH/USD 上的 FOK 訂單的表現可能與 BTC/USD 不同。

5. Coinbase Prime 客戶會收到 FOK 失敗的詳細拒絕代碼，包括“INSUFFICIENT_LIQUIDITY_AT_PRICE”和“PRICE_BAND_VIOLATION”，而零售 IOC 拒絕則帶有通用的“CANCELLED”標籤。

風險管理的影響

1. IOC指令降低了倉位積累風險，但在跨交易所套利過程中，在分散的場所重複使用時會引入跟踪誤差。

2. FOK 訂單可以防止部分成交帶來的逆向選擇，但會增加低交易量期間的機會成本，尤其是與訂單簿稀疏的山寨幣對相關。

3. 投資組合保證金系統計算 IOC 與 FOK 的初始保證金要求的方式不同：IOC 觸發的部分填充可能會觸發增量追加保證金通知，而 FOK 不執行則不會影響抵押品。

4. 鏈上結算層（例如集成到 dYdX v4 中的結​​算層）將 FOK 語義視為不可協商的 — 任何偏差都會導致交易恢復，而不是回退邏輯。

5. 交易所託管政策有時會限制使用增強型 KYC 協議標記的賬戶的 FOK，理由是擔心潛在的搶先交易檢測規避行為。

常見問題及解答

問：IOC 訂單會導致零成交嗎？是的。如果在提交時不存在等於或優於指定價格的匹配訂單，則整個 IOC 訂單將被取消而不執行。

問：主要加密貨幣交易所的止損限價單是否支持 IOC 或 FOK 修改器？大多數沒有。 Binance和Bybit禁用止損限價訂單的IOC/FOK標誌； Kraken 僅允許 IOC 在止損市場觸發時使用，而不是在止損限價觸發時使用。

問：IOC 訂單和 FOK 訂單的費用處理有區別嗎？不存在標準化差異。費用分類僅取決於訂單在執行時充當掛單者還是接受者，而不取決於有效時間類型。

問：去中心化交易所如何處理 IOC 和 FOK 語義？原生 DEX 協議很少實現真正的 IOC/FOK 邏輯。 Uniswap v3 使用滑點容差代替； Serum 通過其匹配引擎支持 IOC，但由於 AMM-DEX 混合架構的限製而缺乏 FOK。