Hur vi förlorade $25k på grund av en perp DEX API-quirk Vi handlar mycket på en perp DEX (topp 10 poänghållare, topp 5 i volym). Det visar sig att deras cancel_order() API-slutpunkt är. speciell. Den returnerar alltid 200 OK. Du kan ringa cancel_order() med: • Ett giltigt beställnings-ID (13295238234991) • Ett giltigt kundorder-ID • Ett ogiltigt order-ID eller kundorder-ID • Ett order-ID som redan har avbrutits • Ett order-ID från 6 månader sedan • En skinksmörgås • Din mamma → fortfarande 200 OK. Det här är bra om du vet att det händer och kodar runt det. Det gjorde vi inte. Den faktiska frågan: • Ibland ökar create_order() RTT till 50ms+ under hektiska tider. • Vi skulle skicka en beställning och sedan avbryta den med kundorder-ID innan beställningen faktiskt hade landat. • Avbryt returnerar 200 OK, så vi antar att beställningen är död och tar bort den från våra böcker. • Några sekunder senare fylls den. → Vi blir plockade för 10-20 bps per incident. Kickern? Dessa fyllningar var blandade med vanliga fyllningar, så det var svårt att upptäcka. Vi hade också bakgrundsloopar i inaktuell ordning som kördes, men de är periodiska och fångade inte alltid upp dessa innan de fylldes. Reparera: • För denna DEX *kräver* vi nu att websocket cancel bekräftar eller så fortsätter vi att spamma cancel tills vår maximala gräns för återförsök är uttömd. Skada: • Beräknad förlust: $20K-$30K. Lektion: • Varje API har egenheter. De är vanligtvis inte logiska, ibland inte ens synliga och ofta dyra. • Kontrollera alltid att framgång faktiskt betyder framgång, lita inte på 200.

Ja, vi kör också arb taker-strategier på den här platsen och var förmodligen också "plocka oss själva". Men det är en kapplöpning mot alla MM och våra takertrösklar för perps DEX är i allmänhet högre, så ofta skulle vi missa eller inte nå takertröskeln innan vi försökte

den andra grejen är att jag nu har incitament att INTE berätta för lokalen om detta eftersom det har blivit en fördel för mig

@0xKeef