我們因為一個永續合約去中心化交易所的 API 特性損失了 25,000 美元 我們在一個永續合約去中心化交易所進行大量交易（前 10 名持有者，按交易量排名前 5）。結果發現他們的 cancel_order() API 端點是..特別的。它總是返回 200 OK。 你可以用以下方式調用 cancel_order()： • 一個有效的訂單 ID (13295238234991) • 一個有效的客戶訂單 ID • 一個無效的訂單 ID 或客戶訂單 ID • 一個已經被取消的訂單 ID • 一個 6 個月前的訂單 ID • 一個火腿三明治 • 你的母親 → 仍然是 200 OK。 如果你知道這種情況並且在代碼中處理它，那這是可以的。我們不知道。 實際問題： • 偶爾，create_order() 的 RTT 在繁忙時段會飆升到 50ms 以上。 • 我們會發出一個訂單，然後在訂單實際到達之前通過客戶訂單 ID 取消它。 • 取消返回 200 OK，所以我們假設訂單已經失效並將其從我們的帳簿中刪除。 • 幾秒鐘後，它被成交了。 → 我們每次事件損失 10-20 個基點。 更糟的是？這些成交與正常成交混在一起，所以很難發現。 我們還有過期訂單的背景循環在運行，但它們是定期的，並不總是能在成交之前捕捉到這些。 解決方案： • 對於這個去中心化交易所，我們現在 *要求* websocket 取消確認，否則我們會繼續發送取消請求，直到達到最大重試次數限制。 損失： • 估計損失：20,000-30,000 美元。 教訓： • 每個 API 都有特性。它們通常不合邏輯，有時甚至不可見，並且往往代價高昂。 • 總是要驗證成功是否真的意味著成功，對 200 不要抱有信任。

是的，我們也在這個平台上運行套利交易策略，並且可能也在「自我挑選」。但這是一場與所有做市商的競賽，而我們對於永續合約去中心化交易所的交易者門檻通常較高，因此我們經常會錯過或在嘗試之前未能達到交易者門檻。

另一件讓人感到有點糟糕的事情是，現在我有動機不告訴場地這件事，因為這已經成為我的一個優勢。

@0xKeef