Backtesting prediction markets: resolution lookahead, survivorship, and the terminal-value trap

Prediction-market contracts have a property no equity has: a known, discrete terminal value. Every contract eventually settles at 0 or 1. That is what makes the asset class analytically clean, and it is also what makes it treacherous to backtest, because the answer to the question your strategy is trying to predict is stored one join away from your feature table.

The terminal-value trap

The classic leak is not someone writing 'if outcome == 1 then buy'. Nobody does that. The leaks are structural and boring:

• Normalizing or scaling a feature using statistics computed over the market's full life, which includes its post-resolution behaviour.
• Restricting the universe to markets that resolved cleanly — a filter that can only be applied with knowledge of the future.
• Joining a market-level metadata table that is refreshed on a cadence, so every row carries the market's CURRENT state rather than its state at the row's timestamp.
• Labelling with a resolution date and then using bars up to and including it, when the informative move happened in the minutes before the venue flipped the flag.

The rule that catches all four: every field in a training row must be reconstructible from data timestamped at or before that row's own timestamp. If you cannot write down how you would have computed a column in real time, it does not belong in the row. Enforce it mechanically — build features from an event-ordered tape rather than from a joined current-state table, and the whole class of bug becomes hard to write.

Resolution status is a derived, ex-post field

It is worth understanding how a resolution flag is actually produced, because people treat it as ground truth. In our own Polymarket market records, resolved is not published directly by the venue — it is derived: the market must be flagged closed AND one of its outcome prices must have reached at least 0.99. The resolution date is then taken from the venue's closedTime field.

Two consequences follow. First, both inputs only exist after the fact, and they describe the market's state as of the last sync, not as of any historical timestamp. Second — and this is the one people miss — a market can be closed without ever satisfying the price condition. Voided markets, markets closed administratively, markets whose final prices never converged: all of them are closed and not resolved. Treating a false resolved flag as 'still trading' will quietly put dead instruments in your live universe.

Model three states, not two: open, closed-without-resolution, and resolved. Then check how many of each you have. The middle bucket is usually larger than people expect, and it is disproportionately full of exactly the weird markets a naive strategy loves.

Survivorship comes in three flavours

• Market survivorship. A venue's market listing tells you what exists now. Markets that were created and later delisted or voided are simply absent, and they are absent non-randomly. Build your historical universe from event-time lifecycle records — the market-creation and resolution events captured with the timestamp they arrived — rather than from a current listing.
• Capture-bound survivorship. Every continuous capture is bounded by a top-N universe chosen at capture time, ours included. Instruments below the bound are missing, and they are missing precisely because they were illiquid. If your strategy claims to trade the long tail, an archive that never recorded the long tail will flatter it enormously. Ask any vendor — including us — what the bound was and how it moved over time.
• Liquidity survivorship. Filtering to markets with 'enough depth to trade' is itself a lookahead filter unless the depth criterion is evaluated on trailing data only, at each decision time, using the book as it stood then.

Time-to-resolution is a regime, not a control variable

The same contract is a fundamentally different instrument ninety days from resolution and ninety minutes from it. Spreads compress, depth concentrates near the eventual outcome, and the price stops behaving like a diffusion and starts behaving like a step function around the resolving event. Pooling observations across the whole horizon mixes regimes that have almost nothing in common, and the resulting average describes no market that ever existed.

There is a data-side corollary that catches people out. Capture cadence often varies with time-to-expiry by design — our Polymarket snapshot fetcher runs tiered, sampling markets that expire within the hour far more often than markets a week out. That is the right engineering trade, but it means your effective sampling resolution is not constant across the horizon. Any statistic sensitive to sampling frequency will show a spurious term-structure if you do not bucket by time-to-resolution first.

Timestamps worth being suspicious of

• Venue-supplied resolution dates. Often administrative — when the flag was flipped, not when the outcome became known. The market usually knew first, and that gap is where the interesting research lives.
• Market creation and metadata dates. Mutable. A market's title, category and end date can all be edited after the fact.
• Anything on a table maintained by a sync job. Last write wins, so the row reflects the most recent sync, not history. Unless the table is explicitly append-only and versioned, it is a current-state view wearing a timestamp.
• Event arrival timestamps from a lifecycle stream. These are the trustworthy ones — recorded when the message actually reached the capture process, immutable after the fact, and directly usable as an 'as-of' clock.

A short pre-flight checklist

• Can every feature be computed from data at or before its row timestamp? Prove it for the three most important columns.
• Was the universe constructed from event-time lifecycle records, or from a current listing?
• Do you know the capture universe bound, and does your strategy trade inside it?
• Are open, closed-unresolved and resolved handled as three distinct states?
• Are results bucketed by time-to-resolution, and do they survive that bucketing?
• Have you excluded windows where the underlying capture is flagged stale, rather than interpolating across them?

None of this is exotic. It is the same discipline equity researchers apply to point-in-time fundamentals, transplanted to an asset class where the temptation is sharper because the answer is so close at hand. The one structural advantage prediction markets give you: because contracts settle at 0 or 1, a leaking backtest tends to look spectacular rather than merely good. Treat an implausibly clean equity curve as a data-integrity alarm, not a discovery.