Como perdemos $25k por causa de uma peculiaridade da API de um DEX perpétuo Negociamos intensamente em um DEX perpétuo (top 10 detentores de pontos, top 5 por volume). Acontece que o endpoint da API cancel_order() é... especial. Ele sempre retorna 200 OK. Você pode chamar cancel_order() com: • Um ID de pedido válido (13295238234991) • Um ID de pedido do cliente válido • Um ID de pedido ou ID de pedido do cliente inválido • Um ID de pedido que já foi cancelado • Um ID de pedido de 6 meses atrás • Um sanduíche de presunto • Sua mãe → Ainda assim, 200 OK. Isso é aceitável se você souber que está acontecendo e programar em torno disso. Nós não sabíamos. O problema real: • Ocasionalmente, os picos de RTT do create_order() chegam a 50ms+ durante horários de pico. • Disparamos um pedido, depois o cancelamos pelo ID do pedido do cliente antes que o pedido realmente tivesse sido realizado. • O cancelamento retorna 200 OK, então assumimos que o pedido está morto e o removemos de nossos livros. • Alguns segundos depois, ele é preenchido. → Somos pegos por 10-20 bps por incidente. A cereja do bolo? Esses preenchimentos estavam misturados com preenchimentos normais, então era difícil de detectar. Também tínhamos loops de fundo de pedidos obsoletos rodando, mas eles são periódicos e nem sempre capturavam esses antes do preenchimento. Solução: • Para este DEX, agora *exigimos* confirmações de cancelamento via websocket ou continuamos enviando o cancelamento até que nosso limite máximo de tentativas seja esgotado. Dano: • Perda estimada: $20K-$30K. Lição: • Toda API tem peculiaridades. Elas geralmente não são lógicas, às vezes nem visíveis, e muitas vezes caras. • Sempre verifique se o sucesso realmente significa sucesso, não confie em nenhum 200.

Sim, também estamos a executar estratégias de arb taker neste local e provavelmente estávamos também a "retirar-nos". Mas é uma corrida contra todos os MM e os nossos limites de taker para DEXs de perps são geralmente mais altos, por isso muitas vezes não conseguimos ou não atingimos o limite de taker antes de tentar.

a outra coisa meio estranha é que agora estou incentivado a NÃO contar ao local sobre isso, uma vez que se tornou uma vantagem para mim

@0xKeef