我们因为一个 perp DEX API 的怪癖损失了 25,000 美元 我们在一个 perp DEX 上进行大量交易（前 10 名持有者，按交易量排名前 5）。结果发现他们的 cancel_order() API 端点是……特别的。它总是返回 200 OK。 你可以用以下方式调用 cancel_order()： • 一个有效的订单 ID (13295238234991) • 一个有效的客户订单 ID • 一个无效的订单 ID 或客户订单 ID • 一个已经被取消的订单 ID • 六个月前的订单 ID • 一块火腿三明治 • 你母亲 → 仍然是 200 OK。 如果你知道这种情况并且在代码中处理它，那就没问题。我们不知道。 实际问题： • 在繁忙时段，create_order() 的 RTT 偶尔会飙升到 50ms 以上。 • 我们会发出一个订单，然后在订单实际落地之前通过客户订单 ID 取消它。 • 取消返回 200 OK，所以我们假设订单已经失效并将其从账本中删除。 • 几秒钟后，它被成交了。 → 我们每次事件损失 10-20 个基点。 更糟糕的是？这些成交与正常成交混在一起，所以很难发现。 我们还运行了过期订单的后台循环，但它们是周期性的，并不总是能在成交前捕捉到这些。 解决方案： • 对于这个 DEX，我们现在 *要求* websocket 取消确认，否则我们会继续发送取消请求，直到达到最大重试限制。 损失： • 估计损失：20,000-30,000 美元。 教训： • 每个 API 都有怪癖。它们通常不合逻辑，有时甚至不可见，并且往往代价高昂。 • 始终验证成功是否真的意味着成功，绝不要相信 200。

是的，我们也在这个平台上运行套利交易策略，并且可能也在"自我提取"。但这是一场与所有做市商的竞赛，我们对永续合约去中心化交易所的交易者阈值通常较高，因此我们经常会错过或在尝试之前未能达到交易者阈值。

另一个有点糟糕的事情是，现在我有动力不告诉场地这件事，因为这对我来说变成了一个优势。

@0xKeef