Polymarket Quantitative Research and Strategy Studies

A wallet wins 19 of its first 20 markets. The leaderboard calls it elite. A bootstrap asks a less exciting question: how often would a trader with the same odds, sizing, and market mix produce that record by luck?

Polymarket research gets interesting after that question. Public market and wallet data make many studies possible, while the order book, resolution rules, and selection effects make naive conclusions fragile.

Start with the venue mechanics

Polymarket's official prices and order-book documentation says trading uses a central limit order book. Prices emerge from users' bids and asks. A displayed midpoint is not necessarily executable, and a marketable order pays the ask when buying or receives the bid when selling.

The documentation also describes off-chain matching with on-chain settlement. For research, that means a market-price series, an executable quote series, trades, orders, and settlement records are related but not interchangeable.

Build a point-in-time market registry

Polymarket's market-discovery documentation describes public event and market metadata that can be fetched without authentication. Store event IDs, market IDs, condition IDs, outcome token IDs, slugs, question text, opening and closing state, and the retrieval timestamp.

Version the text. A market title is a label, while the rules define the settlement condition. If clarifying text changes, a backtest should use the version visible at the decision time. Save market-to-event relationships as well because a single event can contain several mutually related markets.

Schedule snapshots independently of trading activity. Trade-only sampling overrepresents busy markets and skips quiet periods when a wide spread is itself informative. A regular book snapshot, combined with every observed trade and state change, supports both calibration and execution studies.

Do not filter the history to markets that resolved neatly. Canceled, ambiguous, delayed, or disputed cases belong in the sample because they are part of the strategy's ex ante opportunity set. This is the prediction-market version of survivorship bias. The look-ahead bias guide provides a general checklist for keeping later facts out of historical rows.

Study calibration at fixed horizons

A basic calibration test groups observations by quoted probability and compares the average forecast with the realized outcome rate. Sample one observation per market at fixed horizons, such as seven days, one day, and one hour before the rule-defined end time. That end time makes a reproducible analysis anchor, but it is not guaranteed to equal the last tradable moment or the resolution time. Store actual closed and accepting-orders states separately. Using every tick gives long-lived markets far more weight.

Use executable sides for trading questions. If the best bid is 0.34 and the best ask is 0.40, a displayed 0.37 may describe consensus, but a buyer does not acquire the contract at 0.37. Save spread and depth beside the probability.

for horizon in ["7d", "1d", "1h"]:
    snapshot = last_book_before(rule_end_time - horizon)
    forecast = snapshot.midpoint
    executable_buy = snapshot.best_ask
    accepting_orders = snapshot.accepting_orders
    outcome = resolved_value
    save(market_id, horizon, forecast, executable_buy, accepting_orders, outcome)

report_by_bin(forecast, outcome)
report_brier_score(forecast, outcome)

Break results out by event family, horizon, liquidity, and rule complexity. A well-calibrated election market does not prove that a thin entertainment market is calibrated.

Test wallet skill against the right luck baseline

Profit alone is a poor skill statistic. Large wallets take more risk, active wallets generate more observations, and accounts may transfer positions or specialize in a favorable period. A leaderboard conditions on survival and visibility.

Reconstruct each wallet's decision-time exposure. Then create matched simulations that preserve its trade count, odds distribution, market categories, holding horizons, and rough sizing concentration. Randomize outcomes or matched trade selection while respecting correlations among markets from the same event.

Compare realized performance with that simulated distribution using several measures: log loss or Brier score for forecasts, spread-adjusted profit, maximum loss, concentration, and consistency across time splits. Require a minimum history and apply a multiple-testing correction when scanning thousands of wallets.

We Figured Out How Prediction Market Quants Actually Trade is useful context for mechanism-based wallet research. Treat the observed patterns as hypotheses to reproduce, not as permission to copy a wallet.

Model execution from the order book

A signal at the midpoint is not a fill. Replay the book at the decision timestamp, walk available asks for a buy, cap participation, and allow partial execution. Add the delay from data receipt through model calculation and order submission. If historical depth is unavailable, state that limitation and use conservative spread scenarios.

Related-market strategies need simultaneous execution assumptions. A basket that costs 0.98 at top-of-book prices may cost more than 1.00 after one leg fills and the rest move. Report legging risk separately from theoretical mispricing.

Polymarket's official fee documentation says fee treatment can depend on market category and price, with taker fees in specified markets and maker rebates funded from collected fees, while other categories can be fee-free. Snapshot the fee parameters and rebate rules for each market at signal time. Calculate the basket after taker fees, expected rebates, partial fills, and legging rather than assuming one permanent platform-wide rate.

The event-study design guide is helpful for event-linked reactions. Use a timestamped external source, pre-declare the reaction window, and distinguish a forecast edge from a faster-execution edge.

Resolution risk is a model input

Polymarket's official resolution documentation says every market has predefined rules covering its source, end date, and edge cases. It describes an UMA Optimistic Oracle process in which proposed outcomes may be disputed. Rules, not the short title, determine the result.

A contract at 0.98 risks far more than two cents of foregone upside. One adverse resolution can erase many small gains. Bonding Bots in Prediction Markets examines that payoff shape directly.

Create rule-complexity fields before testing: number of named sources, subjective terms, scheduled versus open-ended close, related outcomes, clarification history, and dispute status. A near-certain strategy should report its worst loss and expected shortfall, not only win rate.

Five studies worth running

1. Calibration by horizon, category, spread, and volume.
2. Wallet persistence after matching for odds, exposure, and market selection.
3. Price response to timestamped public news using executable quotes.
4. Cross-market constraints among mutually exclusive or linked outcomes.
5. Late-stage pull-to-par returns after spreads, tail losses, and resolution delays.

Each study needs a written null, data cutoff, unit of observation, execution rule, and missing-data policy. Register those choices before inspecting the final chart.

Publish event-level counts beside observation counts. Ten thousand hourly snapshots from twenty markets are still twenty independent resolutions. Confidence intervals should respect that dependence, especially when several contracts share one election, match, or economic release.

A reproducible research checklist

• Freeze raw API responses and retrieval times.
• Version questions, rules, outcomes, and event relationships.
• Separate midpoint, bid, ask, trade, and settlement prices.
• Preserve failed, canceled, disputed, and illiquid markets.
• Cluster uncertainty by event when contracts share the same outcome driver.
• Simulate depth, partial fills, latency, and unmatched legs.
• Correct for the number of wallets, rules, or thresholds searched.
• Publish code, hashes, sample exclusions, and a later holdout.

Use the Alphanume dataset catalog for complementary point-in-time market and event inputs. Keep venue data and external data on separate clocks until the join rule has been tested.

The interesting Polymarket questions are quantitative. The credible answers are mostly about bookkeeping: what was visible, what was executable, how the market resolved, and how many alternatives were tried.

Prediction markets involve financial and legal risk, and access rules vary. Confirm current eligibility and venue terms before any trading activity.