HFT on Polymarket: Rust, timestamps and the 98% hit rate that wasn't

Phase 1 hit a data bottleneck: for long-horizon prediction, the dataset had to be built before any model could be trained. Phase 2, a 15-minute trading system, found expected value near zero after fees. The next question was narrower: could second-scale signals still contain something useful?

I kept the 15-minute crypto Up/Down markets from phase 2, where UP and DOWN tokens trade between 0 and 1, and used Binance as the reference price. This is HFT in style rather than in the microsecond sense: most targets look 1 to 10 seconds ahead, and the network alone adds 50–200 ms or more.

Three hypotheses drove the work:

• Polymarket lags the reference market.
• Order-book imbalance and short lag features carry signal a model can use.
• The edge, if any, lives in data freshness and execution discipline rather than in prediction alone.

All three are about timing. The question stopped being "can I train a model?" and became "can I observe, align and execute honestly enough that the model means anything?" That made the project infrastructure-first.

Each update has two times. Exchange event time (E) is when Binance or Polymarket says it happened. Local receipt time (L) is when my recorder got it. A strategy can only act on L, so the datasets were built on L, and the gap L − E was kept per row as network_latency_ms.

Two feeds almost never update in the same millisecond. Instead of pretending they share timestamps, alignment took the last known value of each feed, and freshness columns (binance_age_ms, poly_age_ms) turned that misalignment into explicit information. Rows could then be filtered by latency thresholds such as 200–500 ms, so training did not learn from lag spikes.

The rule is point-in-time: a feature may only use what had arrived when its row was built. Exchange timestamps are future-friendly, and a model built on them can be mathematically correct and still temporally dishonest.

This is the result I trust more than a flashy headline. The pipeline could produce a decent classifier and still refuse to confuse classification quality with executable edge. Knowing that the bid is about to drop is not the same as being filled at a price that pays; latency, queue position and actual fills decide that.

The same evaluation timed inference at tens of microseconds per batch. Next to 50–200 ms of network latency, the model was never the slow part of the loop.

Short-horizon backtests are easy to flatter. Without reaction latency, the simulation bought the visible ask at time t, sold the bid at t + 5 s, and assumed it acted instantly. The hit rate came out at about 98%.

Real orders are not instant. The network adds 50–200 ms or more, before computing, deciding and sending. By the time an order reaches the book, the ask seen at t may be gone: the backtest was buying ghost quotes. With reaction_latency_ms set to at least 300, the simulation traded at the prices of t + 300 ms, and the hit rate fell to about 55%.

Latency was only the first cut. Slippage and queue realism made the result more fragile, and the quant diagnostics exposed several ways a careless simulator fakes PnL.

The rule I settled on: before trusting a short-horizon model, run a stress backtest with 1 s of latency, 2% slippage and a minimum ask size of 500. If PnL collapses there, the model is not ready for live. The full checklist is in How a real backtest works.

I never took the HFT branch live. By design, it had to survive the painful backtest first, then paper trading with the full order lifecycle, and only then a tightly controlled live test.