Как мы потеряли 25 тысяч долларов из-за особенностей API перпетуального DEX Мы активно торгуем на перпетуальном DEX (входим в топ-10 по количеству токенов, топ-5 по объему). Оказалось, что их API-метод cancel_order()... особенный. Он всегда возвращает 200 OK. Вы можете вызвать cancel_order() с: • Действительным ID заказа (13295238234991) • Действительным клиентским ID заказа • Недействительным ID заказа или клиентским ID заказа • ID заказа, который уже был отменен • ID заказа, который был 6 месяцев назад • Бутербродом с ветчиной • Вашей матерью → Все равно 200 OK. Это нормально, если вы знаете, что это происходит, и обрабатываете это в коде. Мы не знали. Фактическая проблема: • Периодически время отклика create_order() возрастает до 50 мс и более в загруженные моменты. • Мы отправляли заказ, а затем отменяли его по клиентскому ID заказа до того, как заказ фактически был выполнен. • Отмена возвращает 200 OK, поэтому мы предполагаем, что заказ мертв и удаляем его из наших книг. • Через несколько секунд он выполняется. → Мы теряем 10-20 базисных пунктов за инцидент. Изюминка? Эти исполнения смешивались с обычными исполнениями, поэтому их было трудно заметить. У нас также работали фоновый цикл устаревших заказов, но они периодические и не всегда успевали поймать эти заказы до исполнения. Решение: • Для этого DEX мы теперь *требуем* подтверждения отмены через вебсокеты, иначе продолжаем спамить отмену, пока не исчерпаем лимит повторных попыток. Ущерб: • Оценочные потери: 20-30 тысяч долларов. Урок: • У каждого API есть свои особенности. Обычно они нелогичны, иногда даже не видны и часто дорогостоящи. • Всегда проверяйте, что успех действительно означает успех, не доверяйте 200.

Да, мы также используем стратегии арбитража на этой платформе и, вероятно, тоже "подбираем себя". Но это гонка против всех маркетмейкеров, и наши пороги для тейкеров на DEX для перпетуумов, как правило, выше, поэтому мы часто пропускаем или не достигаем порога тейкера перед попыткой.

другая, довольно странная вещь в том, что теперь я мотивирован НЕ сообщать заведению об этом, так как это стало моим преимуществом

@0xKeef