How we lost $25k because of a perp DEX API quirk We trade heavily on a perp DEX (top 10 points holder, top 5 by volume). Turns out their cancel_order() API endpoint is..special. It always returns 200 OK. You can call cancel_order() with: • A valid order ID (13295238234991) • A valid client order ID • An invalid order ID or client order ID • An order ID that was already canceled • An order ID from 6 months ago • A ham sandwich • Your mother → Still 200 OK. This is fine if you know it’s happening and code around it. We didn’t. The actual issue: • Occasionally, create_order() RTT spikes to 50ms+ during busy times. • We’d fire off an order, then cancel it by client order ID before the order had actually landed. • Cancel returns 200 OK, so we assume the order is dead and remove it from our books. • A few seconds later, it fills. → We get picked off for 10-20 bps per incident. The kicker? These fills were mixed in with normal fills, so it was hard to spot. We also had stale-order background loops running, but they’re periodic and didn’t always catch these before fill. Fix: • For this DEX, we now *require* websocket cancel confirms or we continue spamming the cancel until our max retries limit is exhausted. Damage: • Estimated loss: $20K-$30K. Lesson: • Every API has quirks. They’re usually not logical, sometimes not even visible, and often expensive. • Always verify that success actually means success, trust no 200.

Yes, we are also running arb taker strategies on this venue and were also probably "picking ourselves off". But it's a race against all MM and our taker thresholds for perps DEXs are generally higher, so often we would miss or not hit the taker threshold before attempting

the other kinda f'ed up thing is now i'm incentivized to NOT tell the venue about this since it has become an edge for me

@0xKeef