Most retail backtesting frameworks process historical trades in whatever order the data file lists them — usually just sorted by timestamp. That’s a reasonable assumption on a centralized exchange with a single matching engine. It is not automatically true on Hyperliquid.
What HyperBFT changes
Hyperliquid’s L1 uses HyperBFT, a consensus mechanism where block proposers and validators agree on transaction ordering through a Byzantine fault-tolerant protocol — not a simple FIFO queue. Two trades that appear to happen “at the same millisecond” in a naive timestamp-sorted dataset may have a specific, non-arbitrary consensus order that actually determines which one got the better fill.
Why this matters for backtest accuracy
A backtest that gets trade ordering wrong during high-activity periods — exactly when it matters most — will misattribute fills, mis-simulate slippage, and produce a P&L curve that doesn’t reflect what would have actually happened. This is a subtle bug: the backtest runs fine, produces plausible-looking numbers, and is wrong in a way that’s hard to catch without deliberately checking ordering against consensus data.
Summary
If your backtesting framework assumes timestamp order equals execution order on Hyperliquid, it’s making an assumption that doesn’t always hold under HyperBFT consensus — and the error is invisible unless you specifically test for it.