You send your burst a few milliseconds before an event. It chokes up C (all of those depth updates sit in his queue and he's busy for the next 50 millis churni

You send your burst a few milliseconds before an event. It chokes up C (all of those depth updates sit in his queue and he's busy for the next 50 millis churning through them). Then both you and A are free to pick him off. The thing is, you know to ignore the burst on the public feed, since you know it is coming (you created it). You still have to process the order book updates, but you can skip your decision logic. So any participant who has an internal latency (packet decode + orderbook update + decision logic) greater than 1 exchange cycle, and who doesn't have an "out" clause to stop making decisions if it is falling behind, will be vulnerable. Like I said, I don't buy it, but it is possible in theory.