Hvordan vi tapte $25k på grunn av en perp DEX API-særhet Vi handler tungt på en perp DEX (topp 10 poengholder, topp 5 etter volum). Det viser seg at deres cancel_order() API-endepunkt er.. spesiell. Den returnerer alltid 200 OK. Du kan ringe cancel_order() med: • En gyldig ordre-ID (13295238234991) • En gyldig kundeordre-ID • En ugyldig bestillings-ID eller kundeordre-ID • En bestillings-ID som allerede er kansellert • En bestillings-ID fra 6 måneder siden • Et skinkesmørbrød • Din mor → fortsatt 200 OK. Dette er greit hvis du vet at det skjer og koder rundt det. Det gjorde vi ikke. Det faktiske problemet: • Noen ganger øker create_order() RTT til 50 ms+ i travle tider. • Vi ville fyre av en bestilling, og deretter kansellere den med kundens ordre-ID før bestillingen faktisk hadde landet. • Kanseller returer 200 OK, så vi antar at bestillingen er død og fjerner den fra bøkene våre. • Noen sekunder senere fylles den. → Vi blir plukket av for 10-20 bps per hendelse. Kickeren? Disse fyllingene ble blandet inn med vanlige fyllinger, så det var vanskelig å få øye på. Vi hadde også foreldede bakgrunnssløyfer som kjørte, men de er periodiske og fanget ikke alltid opp disse før de ble fylt. Fiksere: • For denne DEX *krever* vi nå at websocket-kansellering bekrefter, eller vi fortsetter å spamme kanselleringen til grensen for maksimalt antall forsøk er oppbrukt. Skade: • Estimert tap: $20K-$30K. Lærepenge: • Hver API har særheter. De er vanligvis ikke logiske, noen ganger ikke engang synlige, og ofte dyre. • Bekreft alltid at suksess faktisk betyr suksess, stol på nei 200.

Ja, vi kjører også arb taker-strategier på dette stedet og "plukket oss selv av". Men det er et kappløp mot alle MM, og våre taker-terskler for perps DEX-er er generelt høyere, så ofte ville vi bomme eller ikke treffe taker-terskelen før vi prøvde

den andre litt f'ed up tingen er at nå er jeg motivert til å IKKE fortelle lokalet om dette siden det har blitt en fordel for meg

@0xKeef