How to Backtest a Polymarket Trading Bot

Quick answer

To backtest a Polymarket trading bot, replay historical market records in chronological order, calculate signals using only information available at each simulated time, model realistic order execution, and evaluate the result against the resolved outcome.

A useful backtest needs more than final prices. It should include timestamps, available order book liquidity, trades, fees, and clear rules for entries and exits.

Define the research question

Start with one narrow question.

Examples include:

• Does order book imbalance predict a short-term price move?
• Does a wide spread create a useful entry opportunity?
• Does recent trade flow provide information before market close?
• Does a TWAP deviation identify unusual pricing?
• How does liquidity change during the final minute?

A precise question makes it easier to define the required data, signal, execution model, and evaluation metric.

Choose the historical markets

Select markets that match the intended strategy.

For a five-minute crypto strategy, keep the market series consistent. Do not mix unrelated market types without a clear reason.

Record selection can consider:

• Crypto asset
• Market duration
• Date range
• Resolution status
• Data completeness
• Minimum liquidity
• Minimum trade count

Only resolved markets should be used when final outcomes are required for evaluation.

Build a chronological event stream

A trading bot experiences events over time. The historical simulation should do the same.

A basic event stream can combine:

1. Full order book snapshots
2. Order book deltas
3. Completed trades
4. Market opening and closing events
5. Market resolution

Events should be sorted using the selected timestamp policy.

If both platform and collection timestamps exist, decide which one represents the information available to the simulated bot. Platform timestamps describe exchange time, while collection timestamps may better represent when a collector received the information.

Reconstruct the order book

Start with a complete snapshot. Store each bid and ask level by price.

Apply every later delta in order:

• Replace the existing size when a level changes
• Remove the level when the new size is zero
• Keep bids and asks separate
• Restart from a reseed snapshot when required

After each update, calculate the best bid, best ask, spread, midpoint, depth, and any strategy features.

A reconstruction should be tested against later full snapshots. Large differences can indicate missing changes, incorrect ordering, or a bug in level removal.

Calculate signals without future data

Every signal must use only information available at the current simulated time.

Possible signals include:

• Bid and ask depth imbalance
• Spread changes
• Midpoint momentum
• Recent trade direction
• Recent trade volume
• Distance from TWAP
• Time remaining before close
• Short-term volatility

A common imbalance calculation is:

imbalance = bid_depth / (bid_depth + ask_depth)

A value near one indicates more recorded bid depth. A value near zero indicates more recorded ask depth. This does not guarantee future price direction because visible liquidity can change or be canceled.

Avoid look-ahead bias

Look-ahead bias occurs when a simulation uses information that was not available at the decision time.

Examples include:

• Reading the final outcome before resolution
• Using a complete future candle
• Calculating a rolling feature with later rows
• Entering at a price that appeared after the signal
• Filtering markets using future performance
• Using a future snapshot to repair the current book

A backtest with future information is not a historical simulation. It is an explanation of the past using facts the strategy could not have known.

Every feature and decision should have a timestamp that is earlier than or equal to the simulated decision time.

Model market orders

A marketable order consumes available liquidity.

Do not assume that a large order fills entirely at the best displayed price. Walk through available levels until the desired size is filled or the order book runs out of liquidity.

| Step | Action | | First | Take available size at the best price | | Next | Move to the following price level | | Continue | Repeat until filled or liquidity ends | | Result | Calculate the volume-weighted execution price |

The simulation should record partial fills when the available size is smaller than the requested order.

Model limit orders

Limit orders are harder to simulate because historical order books do not always reveal exact queue position.

A conservative model can require the market to trade through the limit price before assuming a fill.

A more optimistic model might fill when a trade occurs at the limit price. That method can overestimate fills because other orders may have been ahead in the queue.

Report the selected assumption clearly and test multiple execution models.

Include fees and latency

Small costs can change the result of a short-horizon strategy.

A simulation should consider:

• Trading fees
• Spread cost
• Price impact
• Partial fills
• Network delay
• Signal processing delay
• Order submission delay

One simple latency model delays every simulated action by a fixed number of milliseconds. A stronger test evaluates the strategy under several latency values.

Define exits and settlement

A strategy needs explicit exit rules.

Possible exits include:

• Close after a fixed time
• Close when the signal reverses
• Close at a profit target
• Close at a loss limit
• Close before the market ends
• Hold until resolution

Holding until resolution requires the correct winning outcome and settlement calculation.

Separate training and testing periods

Do not optimize and evaluate a strategy on the same markets.

A time-based split is usually safer:

| Dataset | Purpose | | Training | Develop model parameters | | Validation | Select settings and thresholds | | Testing | Final untouched evaluation |

The testing period should remain untouched until the strategy rules are fixed.

For rolling evaluation, train on older markets and test on the next chronological period.

Measure more than profit

Total profit alone does not explain strategy quality.

Useful measurements include:

• Number of markets
• Number of trades
• Win rate
• Average return
• Median return
• Total return
• Maximum drawdown
• Largest loss
• Average position size
• Average fill price
• Partial fill rate
• Fee total
• Performance by asset
• Performance by time remaining
• Performance by liquidity level

A result based on only a few markets is less reliable than a result observed across many independent periods.

Run sensitivity tests

A strategy should not depend on one perfect parameter.

Test nearby values for:

• Entry threshold
• Exit threshold
• Position size
• Latency
• Fees
• Spread limit
• Minimum depth
• Holding time

Stable performance across reasonable settings is more credible than one isolated result.

Keep an audit log

For every simulated action, save:

• Market identifier
• Decision timestamp
• Feature values
• Signal value
• Requested order
• Available book levels
• Filled size
• Average execution price
• Fees
• Exit reason
• Final result

An audit log makes unexpected results easier to inspect and helps other researchers repeat the test.

Common backtesting mistakes

Avoid these common errors:

• Using final outcomes as live features
• Assuming unlimited size at the midpoint
• Ignoring spread and fees
• Filling every limit order
• Randomly mixing rows from the same market
• Optimizing on the final test period
• Ignoring missing data
• Reporting only the best parameter
• Treating historical profit as guaranteed future profit

Final checklist

Before accepting a result, confirm that:

• Events are chronological
• Features use no future information
• Order books begin from valid snapshots
• Deltas are applied correctly
• Execution uses available liquidity
• Fees and latency are included
• Training and testing periods are separate
• Every simulated trade has an audit record
• Results include risk and sensitivity measurements

The BTC five-minute historical dataset provides the market, snapshot, delta, trade, and resolution records needed to build this type of backtest.