FlyingFish

@HyperliquidX's IOC speed-bump mechanism has a flaw. Normally designed to protect makers in the interests of a more liquid market, it breaks down in periods of high activity. When blocks become full, pending modifies and cancels queue up for later blocks, so their latency increases. However, IOCs behave as though they have a separate blockspace dedicated for them, and their latency barely budges. You can see this in the lower left chart, showing latency of different order types during 19 activity bursts. The result is that under relatively modest load (25-30k tps), IOC + 8 bps (priority fee) orders can pick off resting liquidity before it has a chance to get out the way. Meanwhile, under higher load (35-40k tps), even IOCs without any priority fee can pick off resting liquidity. This, in my opinion, is antithetical to the ethos and design of the ALO and cancel prioritization mechanism and needs investigation by the team. It exists to reduce toxicity from HFT takers, and is breaking down precisely when most needed. It may also be exploitable. If IOCs really are insulated from the congestion affecting cancels and modifies, a malicious user could spam orders, delaying makers’ cancels while their own IOCs go through, and taking the liquidity left stale. One single example that occurred on AVAX today caused 1.3M$ of volume to be adversely selected for a total loss of ~13k$ over the subsequent 10 seconds. This affected us materially. Faced with such episodes of adverse selection, spreads and liquidity are undoubtedly worse than they could be otherwise. Would appreciate if anyone with a contact at HL could share this with the team.