Market Resolution Data: What to Capture and How to Use It

Market resolution data is the record of how a prediction market ended: which outcome won, who or what declared it, when, under which rules, and whether anyone disputed it. For a quant or a bot builder, it is the label on every backtest and the trigger for every payout. Treat it as a first-class dataset with its own schema, not as a single winner column.

This guide covers how resolution works on the two largest venues, which fields matter, where cross-venue joins break, and how to turn settlement events into usable signals.

AssymetrixBuild With Unified Resolution DataAssymetrix brings prediction market data across Polymarket, Kalshi, and Limitless together through one API for research and trading tools.Explore the Data API

TL;DR

• Resolution is a lifecycle, not a flag: market creation, close, proposal, challenge window, optional dispute, final outcome, payout. Store each stage with its own timestamp.

• Polymarket markets mostly settle through the UMA Optimistic Oracle. Kalshi settles centrally against named source agencies in its contract terms.

• Resolution is source-dependent. Two markets on the same event can settle differently if their rules or data sources differ, so keep the rule text next to the outcome.

• Joining venues requires identifier mapping and timestamp normalization, because block time and exchange-server time are not the same clock.

• Dispute and challenge windows are tradable information. Model them as states, not noise.

Table of Contents

• What resolution data actually contains

• How Polymarket resolution works, as data

• How Kalshi resolution works, as data

• Source-dependent, not exchange-dependent

• Joining resolution data across venues

• A minimal resolution schema

• Using resolution data in research and bots

• Our perspective

• Working with resolution data through an API

• Pre-launch checklist

• FAQ

• Sources

What resolution data actually contains

A useful resolution record answers six questions about every market:

1. What was the question? The exact title and the full rule text, versioned, since clarifications can be posted after launch.

2. What counted as evidence? The named resolution source: an agency, a data release, an official result page, or a free-text description.

3. When did it close and when did it settle? These are different timestamps, and the gap between them is where most of the interesting behavior lives.

4. Who proposed the outcome? On oracle-based venues, a proposer address. On centralized venues, the exchange itself.

5. Was it disputed? A boolean is not enough. Keep the number of rounds, the timing, and the final verdict.

6. What was the final payout vector? For binary markets, 1 or 0. For multi-outcome or scalar markets, the full vector, including any split outcomes.

Researchers at HKUST and NYU describe the same need from the academic side. Their suite of prediction market datasets links market metadata, fill-level trades and oracle-resolution events into one lifecycle, and reports that the main obstacle to algorithmic trading in this space is data fragmentation across on-chain and off-chain sources. As of March 2026, the paper counts more than 770,000 market records and 943 million fill records in its aggregated data.

How Polymarket resolution works, as data

Polymarket does not decide its own winners. Most markets resolve through the UMA Optimistic Oracle. According to the UMA documentation, the sequence runs like this:

• A proposer posts an outcome and a bond (the documentation lists $750).

• A challenge window opens, which is 2 hours.

• If nobody disputes, the proposal becomes final and payouts execute.

• If someone disputes, the request moves to a debate period of roughly 24 to 48 hours, then a vote by UMA token holders through the DVM, which takes about 48 hours.

UMA reports that 99.8% of requests resolve without dispute. That number is a useful prior, but it is an average over every request type. Ambiguous political or legal questions are overrepresented among the disputed ones, so do not apply the 0.2% to every market you track.

The states worth storing

For a bot or a research pipeline, the oracle flow maps cleanly onto a small state machine:

The on-chain events behind each transition carry block numbers and transaction hashes, which makes them auditable. That is a real strength of this venue’s data, and a reason to keep the raw event next to your parsed state.

Why the challenge window matters to a model

The UMA design rests on economic incentives: staking and slashing create a quantifiable cost of corruption. For anyone consuming this data, the practical consequence is that the challenge window acts as a buffer zone. Prices on a proposed-but-unfinalized market often sit just below the payout value, and volatility can cluster around the window as participants weigh the chance of a dispute. Treat that as a hypothesis to test on your own data, not as a guarantee. Label every fill with its distance to the proposal and to the window end, and let the data tell you whether the clustering exists for your market categories.

How Kalshi resolution works, as data

Kalshi uses a centralized model. According to a summary of how contracts settle, each market lists named source agencies in contract terms that are filed with the CFTC through the exchange’s self-certification process. The same summary gives examples by category: governing leagues for sports, government data releases such as BLS and BEA for economics, and NOAA or the National Weather Service for weather.

For your schema, the consequence is that the resolution source is a structured input you can read before the event, not only after. Practitioners who work with Kalshi rule datasets point to two fields in particular: rules_primary and rules_secondary. Read both. The primary rule usually states the trigger; the secondary text often carries the edge cases, such as what happens if a source is revised, delayed or unavailable.

The practical difference between the two venues:

Source-dependent, not exchange-dependent

The most common modeling mistake is assuming that “will X happen” means the same thing everywhere. It does not. Resolution is source-dependent: the same real-world event can settle differently on two venues if one names an official release and the other names a news report, or if the cutoff times differ by hours.

A few places where this bites:

• Cutoff semantics. “By December 31” can mean 11:59 p.m. in one time zone on one venue and a UTC boundary on another.

• Revisions. An economic figure revised after the first release may or may not change the settlement, depending on the rule text.

• Ambiguity clauses. Some rules specify a fallback outcome when the event is unclear or cancelled. These produce 50/50 or void outcomes that break naive win/loss labels.

• Multiple sources. A rule may name a primary source and a backup. Record which one actually triggered settlement.

Store the rule text as a hash plus the raw text, so you can detect when it changes between snapshots.

Joining resolution data across venues

Cross-venue analysis is where resolution data pays off, and where it breaks. Two problems dominate.

Identifier mapping

The same outcome can be represented differently on each venue: a token ID on one, a ticker string on another. The HKUST and NYU paper frames the fix as an abstraction layer that performs identifier resolution, linking market creation, order-level trading and oracle settlement into one coherent timeline. Without it, you cannot tell whether two markets are the same bet, and your arbitrage or divergence work will be built on false pairs. We cover the approach in detail in our guide to event deduplication with canonical IDs.

Timestamp normalization

Polymarket data typically relies on on-chain receipts, so its time resolution is block time. Kalshi uses exchange-server timestamps. The research behind the HKUST and NYU datasets names timestamp standardization as the primary technical hurdle for unified analysis. A workable approach:

1. Convert everything to UTC with millisecond precision.

2. Keep the original timestamp and its source type (block_time, server_time) in separate columns.

3. Never compare a block time and a server time at sub-second precision. Use a tolerance band that matches the coarser clock.

4. For event ordering across venues, prefer the sequence within each venue and join on coarse time buckets.

If you are building on exchange ticker feeds for the market-data side, this documentation on real-time market data from exchange tickers is a useful reference for how streaming feeds are typically structured before you add your own timestamp layer.

A minimal resolution schema

This is a starting point, not a standard. Adjust it to your pipeline.

A few habits keep this table honest. Never overwrite rows; append versions. Keep the raw payload. And keep your labels reproducible: the same query should return the same outcomes next year. Our walkthrough on versioning prediction market datasets shows one way to do that.

Using resolution data in research and bots

Calibration and backtests

Resolution outcomes are the ground truth for calibration curves: bucket final pre-resolution prices, compare to realized frequency, and measure the gap by category and venue. Two cautions. First, exclude void and split outcomes, or handle them explicitly. Second, choose the price snapshot carefully. A price taken after the proposal is not a forecast anymore, it is a bet on dispute risk.

Time-to-settlement features

The gap between close and final settlement is a feature in its own right. Longer gaps can reflect ambiguity, disputes or slow source publication. Capital locked in a market that has already effectively ended has a cost, and a bot that tracks expected time to payout can rank opportunities by annualized return rather than raw edge.

Dispute-aware execution

For an algorithmic agent, a sensible rule set might look like this:

• Flag any market whose rule text contains discretionary language and apply a wider uncertainty haircut.

• Pause or reduce size in the window between proposal and finalization unless your edge was measured inside it.

• Log every dispute event and review whether your model’s prior was too confident.

These are design suggestions for you to test, not performance claims.

Skill scoring

Trader-level analysis needs resolution data too. A wallet’s realized profit and loss is undefined until markets finalize, so skill scores that mix open and resolved positions are biased. Score on resolved positions only, and weight by market difficulty if you can.

Our perspective

We built our platform because resolution data is where venue-specific details leak into otherwise clean analysis. After working through venue data at scale, a few things stand out to us.

First, resolution belongs in the same schema as trades and orderbooks, not in a side table maintained by hand. When a settlement event sits on the same timeline as the fills that preceded it, questions like “who was buying into the challenge window?” become simple queries. Our data layer covers roughly 1.5 terabytes of history across Polymarket, Kalshi and Limitless, and we describe how the resolution side is organized in our guide to normalized resolution data.

Second, neutrality matters. A data layer tied to one exchange will tend to inherit that exchange’s assumptions about what a market is. A venue-neutral layer has to expose the differences, such as source dependence and timestamp types, rather than hide them.

Third, most resolution errors we expect researchers to make are not statistical. They are join errors: two markets treated as one, or one outcome labeled with another venue’s rule. Fix identifiers first, then model.

— Dean

Working with resolution data through an API

If you would rather not maintain three parsers and a mapping table, our Data API exposes cross-venue market, trade and resolution data through a single integration. Pricing is not published on our site, so check the Data API page for current access options. For related build guides, see our notes on orderbook data for developers and OHLCV candles.

Pre-launch checklist

Before you trust a resolution dataset, whether you built it or bought it:

1. Spot-check twenty resolved markets against the venue’s own page, including rule text.

2. Confirm that void, split and cancelled outcomes are represented, not silently dropped.

3. Verify that timestamps carry a type and a time zone.

4. Test that a rule edit creates a new version instead of overwriting.

5. Reconcile the count of markets per venue against a second source.

6. Check that disputed markets show their dispute timing, not only the final answer.

FAQ

What is market resolution data?

It is the structured record of how a prediction market ended: the final outcome, the rules and source used, the timing of each settlement step, and any dispute. It is the ground truth for backtests, calibration studies and payout logic.

How long does Polymarket resolution take?

If no one disputes a proposal, the market finalizes after a 2-hour challenge window, according to the UMA documentation. A dispute adds a debate period of about 24 to 48 hours and a token-holder vote of roughly 48 hours. Always check the specific market, since rules and timing can differ.

Do Polymarket and Kalshi resolve the same event the same way?

Not necessarily. Polymarket mostly relies on an oracle process, while Kalshi names source agencies in contract terms and determines outcomes itself. Even for similar events, cutoffs and sources can differ, so compare rule text before treating two markets as equivalent.

Why is it hard to combine resolution data across venues?

Identifiers and clocks differ. The same outcome can have different IDs on each venue, and on-chain block time is not comparable to exchange-server time at fine precision. Identifier mapping and timestamp normalization are the two steps that make a unified timeline possible.

Sources

• How does UMA work? | UMA Documentation

• Unlocking the Forecasting Economy: A Suite of Datasets for the Full Lifecycle of Prediction Markets (arXiv)

• How Contracts and Dispute Resolution Work at Prediction Markets

• Real-time Market Data with Exchange Tickers | Darkbot Documentation