A prediction market backtest can use the right-looking ticker, the right price history, and the wrong contract. That mistake is easy to miss because market names are short, event pages get updated, and a YES share always looks like a price between zero and one.
Take a hypothetical market labeled “Will the Clean Transit Act pass?” A strategy buys YES at 0.42 after a news signal. The backtest later marks the position at 1.00. Before trusting that win, I want to know exactly what the contract promised: which bill, what counted as “pass,” the deadline, and the source that settled it.
The title: “Will the Clean Transit Act pass?”
A title is a display string, not a stable instrument identifier. Two markets can use nearly identical wording while referring to different legislative sessions, amended bills, or deadlines. A venue can also change a title to clarify the market without changing its underlying terms.
So the backtest should key the position to the venue’s immutable market or contract ID, then retain the full rules text and its version. If historical data contains only a title and a ticker, you can’t establish that the price series belongs to the contract your strategy intended to trade.
| Identity field | What it pins down | Failure if omitted |
|---|---|---|
| Venue and market ID | The specific listed market | Similar titles get joined together |
| Rules version | The terms participants agreed to | A later edit is applied to earlier trades |
| Outcome token ID | YES or NO claim being traded | YES and NO prices are swapped or combined |
| Resolution source | Evidence used to decide the outcome | The backtest assumes a different authority |
The rules: what does “pass” mean?
Suppose the rule says the bill must pass the House and Senate by June 30, then be signed by the president. A backtest that treats passage by either chamber as success has changed the bet. So has one that counts a bill with the same name in the next session.
Read the actual resolution criteria as executable conditions. Record the deadline and timezone, the qualifying event, any exceptions, and the named resolution source. Ambiguity matters too: if the venue’s rules leave a plausible scenario unresolved, don’t quietly choose the interpretation that matches the historical outcome.
There’s a wonderfully unglamorous part of this work: saving the rules page before anything interesting happens. A page captured only after resolution may show the final wording, while your strategy entered under an earlier version.
The timeline: when could the strategy know?
Now suppose the rules are sound and the news signal fired at 14:05 UTC. The historical feed says a trade occurred at 14:05, priced at 0.42. That timestamp alone doesn’t tell you whether the information was available before the trade, whether the recorded price was executable afterward, or whether the bar represents a quote, a trade, or an interval summary.
Keep the signal’s availability time separate from the market event time. Then place the order after the strategy could compute and submit it. For a thin market, the next recorded trade may be minutes later; it’s not evidence that your order would have received that price.
The price: a quote is not a fill
YES at 0.42 implies a 42-cent price per share, but a last-trade series hides the spread and available size. If the best ask is 0.45 for 20 shares, a simulated 100-share purchase cannot fill entirely at 0.42. It might walk the book, wait, or remain unfilled.
Prediction-market prices also invite an accounting shortcut: treating 0.42 as a 42% chance and forgetting that it is also the entry cash outlay. A 100-share YES position costs $42 before fees. If it settles to $1, gross proceeds are $100; if it settles to $0, they’re zero. Fees, partial fills, and any venue-specific settlement mechanics belong in the ledger.
The settlement: what closes the trade?
A backtest often ends the position at the final market price. But a held-to-resolution contract pays according to the rules, and its last quoted price may be stale, wide, or far from the eventual payout. Model resolution as its own event: the outcome, settlement time, and cash movement should come from the contract record.
Also account for a market that resolves to an invalid or disputed outcome, if the venue’s rules define one. That may return stake, pay a different amount, or require a delay. A binary payout assumption cannot represent every resolution path.
The verdict on the backtest
For this example, I’d accept the reported win only after matching the immutable market ID, the rules version in force at entry, the YES token, the signal’s availability time, executable asks and size, fees, and the recorded settlement. If the price archive can’t support those checks, the honest output is a scenario range or an unverified result.
That may sound strict for one small trade. Multiply the same join mistake across thousands of markets and the backtest can become a careful measurement of contracts your strategy never traded.
← All posts
