How to Backtest Polymarket Strategies on the Order Book

Why last-price backtests lie

Most freely available Polymarket data is the last traded price, often sampled once an hour. That is enough to draw a chart and nothing more. A backtest needs to answer a harder question: if my order had been resting (or had crossed the spread) at that moment, would it have filled, in what size, and at what price?

Answering that requires the order book — every resting bid and ask with its size — not a single number. A strategy backtested against the mid assumes it always filled at the mid with zero slippage, which is never true. On short-dated crypto markets, where spreads widen near settlement, that assumption can flip a losing strategy into an apparent winner.

Step 1 — Get full-depth order-book data

Start from data that records the complete book on both sides, captured on every change rather than on a fixed clock. DepthFeed captures Polymarket event-driven straight from the CLOB websocket, so every book and price-change event is recorded with the full bid/ask ladder — not an hourly or per-minute sample that skips the life of a five-minute market.

Pull the markets you want over the REST API: discover them with GET /v3/{coin}/markets, then pull depth from /v3/{coin}/markets/{id}/snapshots. Each snapshot carries bid/ask price and size arrays plus epoch-millis exchange and receive timestamps.

Step 2 — Reconstruct the book at each moment

Replay the snapshots in timestamp order to rebuild the book as it stood at any instant. Because the data is event-driven, the reconstruction is exact between events — there is no interpolation guesswork. This is the state your strategy reacts to: best bid, best ask, the depth behind each, and the spread.

Step 3 — Model fills against real depth

Now simulate execution honestly. A marketable order walks the book: it fills against the best level first, then the next, until its size is exhausted — so its average price is worse than the touch whenever it consumes more than the top level. A resting order joins the queue and only fills if the market trades through its price with enough size behind it.

Sizing fills against the recorded ladder is the whole point: it gives you realistic slippage and fill-probability instead of the fiction that you always traded at the mid.

Step 4 — Join the underlying price

Polymarket's crypto up/down markets are driven by the underlying asset's spot move. Every DepthFeed snapshot joins to a high-frequency Binance reference price by epoch-millis timestamp, so you can line up book state with the spot move that repriced the contract — essential for any strategy that trades the relationship between the crypto price and the market's implied probability.

Step 5 — Go live on the same code

The historical REST API and the live WebSocket stream emit the identical JSON snapshot objects. That means the loader you wrote to replay history reads the live feed unchanged — no rewrite between research and production. Backtest, validate, then point the same code at wss://api.depthfeed.com/v3/stream and trade.

Common pitfalls

• Using last-price data: hides spread and slippage; inflates backtested returns.
• Fixed-interval snapshots: an hourly or per-minute sample misses most of a 5-minute market's life.
• Ignoring queue position: assuming resting orders always fill overstates passive strategies.
• Look-ahead bias: only react to data with a receive timestamp at or before your decision time.
• Skipping the underlying: crypto up/down edge usually lives in the spot-to-probability relationship.