什麼是“僅發布”訂單以及何時應該使用它？

了解僅後訂單

1. 只交訂單是一種限價訂單，僅作為掛單者執行，這意味著它必須添加到訂單簿中，並且不能立即與對方的現有訂單匹配。

2. 如果僅發布指令檢測到任何潛在的針對掛單的立即執行，交易所會直接拒絕該訂單，而不是將其轉換為接受者訂單。

3. 這種行為確保交易者避免支付接受者費用，並有資格獲得許多交易所提供的掛單者回扣。

4. 訂單在訂單簿中保持可見，直到被傳入的市場訂單或激進限價訂單完全成交，或者被用戶手動取消。

5. 交易所在匹配引擎級別強制執行 post-only 邏輯，使其原子化且一旦提交就不可協商。

費用影響和激勵措施

1. 大多數中心化加密貨幣交易所採用不對稱的費用結構，製造商獲得 0.01% 至 0.05% 的回扣，而接受者則支付 0.05% 至 0.25% 的費用。

2.持續使用post-only訂單可以讓交易者隨著時間的推移積累回扣，特別是在訂單量大但單筆規模小的高頻或倒賣策略中。

3. 一些衍生品平台將這種模式擴展到資金利率套利，其中精確的時機和費用最小化直接影響淨利潤。

4. 部署跨交易所延遲敏感策略的套利者嚴重依賴後期放置來保持保證金效率並避免滑點引起的接受者轉換。

5. 運營專門流動性提供計劃的做市商通常將所有掛單配置為僅事後掛單，以符合交易所對回扣資格的要求。

風險和限制

1. 如果在波動的情況下，特別是當買賣價差迅速擴大時，如果放置得太接近中間價格，則僅發布訂單可能會默默失敗。

2. 在閃崩或突然撤回流動性期間，先前安全的僅後期水平可能變得可執​​行，導致意外拒絕或超出預期參數的部分填充。

3.當價格在任何匹配發生之前超過其限制時，僅依賴事後執行的交易者可能會完全錯失機會。

4. 訂單簿深度可視化工具有時會歪曲真實的可用流動性，導致用戶根據不完整的數據下達事後訂單。

5. 某些交易所不支持止損限價或條件訂單的僅發布標誌，限制了其在自動化風險管理系統中的適用性。

集成到算法交易系統中

1. 高頻交易機器人將 post-only 邏輯直接嵌入到訂單提交管道中，在傳輸前驗證與最佳出價/要價的價格距離。

2.日曆價差或交易所間三角套利等多腿策略需要嚴格遵守post-only規則，以防止單腿作為吃單者執行並破壞倉位平衡。

3. 回測框架必須準確模擬僅發布拒絕機制，包括訂單到達和預訂更新之間基於延遲的競爭條件。

4. Exchange API 在報告 post-only 失敗的方式上存在顯著差異 - 有些返回 HTTP 400 錯誤，其他則發送 WebSocket 拒絕消息，需要強大的錯誤解析。

5. 機構算法套件通常將事後強制執行置於自定義價格發現模塊之上，這些模塊根據實時價差分析動態調整限制。

常見問題解答

問：在特殊情況下，僅發布訂單可以作為接受者執行嗎？不會。交換保證原子的僅發布語義。任何導致接受者執行的情況都表明交易所的匹配引擎存在錯誤，或者在記錄的行為之外濫用 API 參數。

問：去中心化交易所支持post-only訂單嗎？大多數基於 AMM 的 DEX 不實現訂單簿或製造商/接受者的區別，因此僅發布邏輯不適用。然而，像 dYdX v3 和 Injective Protocol 這樣的訂單簿 DEX 確實通過其匹配引擎支持本機 post-only 標誌。

問：“僅發布”和“僅創建者”之間有區別嗎？它們指的是幾乎所有交易所的相同功能。術語因平台文檔而異，但沒有操作上的區別。

問：如果我的郵寄訂單數天未成交，會發生什麼情況？它保留在訂單簿中，直到取消、過期或匹配。儘管一些交易所在延長期限後實施閒置訂單清理政策，但被動放置不會產生額外費用。