Backtest Polymarket & Kalshi Strategies Without Writing Code

What the Backtest Lab is

Most prediction-market backtesting starts with a chore: pull the data, reconstruct the book, write a fill model, then finally test the idea. The Backtest Lab collapses that into a single screen. It loads a set of resolved up/down crypto markets, replays each one snapshot by snapshot in the browser, applies your entry rule, and settles every position at the market's real $0/$1 outcome — then shows you the equity curve, hit rate, and per-trade log.

Because the markets it tests on have already settled, results are instant and honest: there is no look-ahead, the outcome is the real one, and the book you fill against is the book that actually existed. It is the fastest way to answer the only question that matters early on — does this idea have an edge before costs, and does it survive them?

Presets, or your own rule

Start from a preset and adjust it, or write your own. The built-in presets are prediction-market-native, not repurposed TA: 'Late favorite' (buy the leading side in the final minutes), 'Fade the panic' (dip reversion after a sharp drop), 'Level cross' (enter when a price crosses a threshold), 'Spot leads the book' (act when the underlying moves before the contract reprices), and 'Cheap lottery' (small stakes on long-shot underdogs).

For anything the presets don't express, the Lab has a small JavaScript rule: a function called once per snapshot, oldest to newest, that sees only the past — window, minutes left, the up/down prices, the book — and returns a side to enter or nothing to pass. The custom script runs in a sandboxed worker, so untrusted code never touches the page, and one entry is allowed per market.

Fill models — from optimistic to honest

The fill model is where most backtests quietly lie, so the Lab makes it an explicit choice. 'Mid fill' fills at the snapshot midpoint — optimistic, useful as a best-case ceiling. 'Mid + slippage' adds a fixed slippage assumption to every entry. 'Book depth (VWAP)' walks the real recorded ladder at each entry, so a larger order pays a worse average price exactly as it would live.

Running the same rule under all three is the point: if an edge only exists at the mid and evaporates under depth-aware VWAP fills, it was never real. That gap — the difference between a fill at the touch and a fill that consumes resting size — is precisely what depth data exists to measure.

Coins, windows, and how much you test

The Lab covers all seven crypto assets (BTC, ETH, SOL, XRP, DOGE, BNB, HYPE) and every up/down window — 5-minute, 15-minute, 1-hour, 4-hour, and 24-hour. You choose how many resolved markets to replay, from a quick 25 up to 500, so you can sanity-check an idea in seconds and then stress it over a larger sample.

How many markets you can pull into a single run scales with your plan, the same gating as the data API — the free Explorer tier is enough to feel the tool out, and paid tiers widen both the sample and the history the run draws from.

Polymarket and Kalshi are not interchangeable samples

A cross-venue rule can use one normalized research workflow, but the sample construction must retain venue-native identity. On Polymarket, distinguish outcome tokens that belong to the same event. On Kalshi, do not treat every strike in one event as an independent observation. Otherwise the trade count and apparent confidence both grow while the number of independent outcomes does not.

Run venue-level results before showing a combined result. A signal may appear transferable while actually benefiting from one venue's spread, contract family or listing schedule. Keeping the same rule and stake while separating venue P&L makes that dependence visible.

Set the test before looking at the result

This short pre-registration prevents the most common form of accidental overfitting: changing several assumptions until one equity curve looks good. The Lab keeps markets, strategy and execution as separate parts of the setup so each result has an inspectable configuration behind it.

• Choose the venue, asset or event universe and market window before selecting a favorable sample.
• Write the entry condition in one sentence that another researcher could implement without guessing.
• Fix the stake or sizing rule, exposure limit and fill assumption before running the replay.
• Choose a chronological sample and do not remove losing periods after seeing them.
• State the pass condition in advance, including minimum sample, cost sensitivity and risk limit.

Read the result beyond ROI

Net P&L and ROI are necessary but insufficient. Read the trade count, win rate, average P&L, realized edge, drawdown and equity path together. A high win rate can still lose if the occasional loss is large; a positive average can be produced by one outlier; and a smooth full-period curve can hide a weak recent holdout.

Inspect individual trades. Look for clustered entries in the same event, partial or expensive fills, performance concentrated in one market regime, and losses that occur exactly where spreads widen. If a result cannot be explained from its trade log, it is not ready for deployment.

Stress-test the rule before accepting it

The goal is not to prove the idea. It is to find the nearest realistic change that breaks it. A strategy that remains positive only at one stake, one threshold or one brief period has still given useful evidence: the edge is too fragile for the next stage.

• Increase the simulated stake and check whether VWAP deterioration removes the edge.
• Delay the entry by one or more observations to test sensitivity to perfect timing.
• Move each threshold slightly; a durable rule should not depend on one magic decimal.
• Compare venues and windows separately before pooling them into one headline result.
• Preserve a chronological holdout or later period that was not used to choose the rule.
• Record configurations that failed as well as the one that survived.

Worked example: test whether spot leads a 15-minute market

Suppose the hypothesis is that a sharp move in BTC spot reaches a 15-minute prediction market with a short delay. Define the rule before running it: enter the matching contract side only when the underlying move exceeds the chosen threshold, require a minimum number of minutes before settlement, allow one entry per market, and use a fixed $100 stake.

Run a broad chronological sample first at midpoint, then with fixed slippage, then against book-depth VWAP. If midpoint is profitable but the depth replay is not, reduce the stake and inspect the losing fills. Shift the signal threshold and entry delay slightly, then preserve a later group of markets as a holdout. The output is not merely an ROI number; it is a record of where the signal, timing and executable liquidity did or did not survive.

Keep a reproducible experiment record

Save the venue, market scope, asset, window, chronological date boundary, sample count, rule name and every parameter. Add stake, sizing rule, fill model, slippage value, fees, starting bankroll and any exposure caps. Export the result with the trade list rather than copying only the headline metrics into a spreadsheet.

The record should also explain why the test was run and what would falsify it. Note every prior configuration tried during the same research session. If the final rule is the survivor of fifty variations, its apparent performance must be interpreted as the best of fifty searches, not as one untouched hypothesis.

When rerunning later, separate a software or data revision from a new market period. A changed historical result may come from corrected settlement, better book reconstruction or modified execution logic; a changed forward result may reflect a different regime. Versioning the configuration is what lets another researcher tell the difference.

• Hypothesis and pre-declared pass/fail condition.
• Exact universe and independent-event counting rule.
• Signal, parameters, stake, exposure and execution assumptions.
• Software, data and configuration version or export timestamp.
• All tested variants, including failures.
• Holdout and forward-paper results kept separate from development results.

From a backtest to a live paper track record

A backtest tells you how a rule would have done on markets that already settled. The obvious next question is how it does on markets that haven't happened yet — so when a rule survives, you deploy it straight from the Lab to Paper Trading. Time-window, level-cross, and dip rules map to the server-side paper worker, which then runs the rule forward against live quotes with a stake, take-profit/stop-loss, and a max-open cap.

That chain — backtest on the archive, then forward-test on live books — is the whole workflow the platform is built around. The Lab is where you kill bad ideas cheaply; paper trading is where the survivors earn a real, forward track record before a dollar is at risk.

What a backtest cannot prove

No backtester can prove that future returns will match historical results. Recorded displayed depth does not reproduce hidden liquidity, exact queue position, cancellations ahead of an order, or the market impact the simulated order itself might create. Venue rules, fees and available market families can also change.

Use the replay to reject weak hypotheses, estimate execution sensitivity and create reproducible evidence. Do not treat one profitable run as a forecast or guarantee. A locked forward paper period is the next test, not a victory lap.