Building a Time Series From Market Odds: A Practical Guide
Building a Time Series From Market Odds: A Practical Guide
Building a Time Series From Market Odds: A Practical Guide
Turn prediction market odds into clean, analysis-ready time series: schema, timestamps, resampling, cross-venue alignment and the pitfalls that distort the data.
Building a Time Series From Market Odds: A Practical Guide
A time series from market odds is a sequence of timestamped prices for one contract, read as the market’s implied probability of an outcome. To build one you need four things: a stable contract identifier, UTC timestamps, a consistent price definition (last trade, midpoint or bid and ask), and a rule for what happens when nobody trades. Get those right and the series is ready for analysis. Get them wrong and every model downstream inherits the error.
This guide covers the structure of the series, how to collect and resample it, how to align it across venues, and how to read it without fooling yourself.
Assymetrixdata.assymetrix.comBuild on unified market dataAssymetrix brings historical and real-time data from Polymarket, Kalshi, and Limitless together through one Data API integration.Explore the Data API
TL;DR
A binary contract priced at $0.63 implies roughly a 63% probability, but only after you decide whether the price is a last trade, a midpoint or a bid/ask pair.
Store timestamps in UTC at full precision, keep raw events separate from resampled bars, and flag gaps instead of silently filling them.
Thin liquidity, resolution effects and venue-specific rules change what the same price means, so normalize across venues before comparing.
Historical odds describe what the market believed, not what will happen. Use them to calibrate, backtest and detect event-driven shifts.
Table of Contents
What a prediction-market time series actually is
Which fields belong in the series
Collecting historical odds
From events to a regular series
How researchers read these series
Aligning series across venues
Reading the series without fooling yourself
Our perspective
Getting the data without building every adapter
A checklist before you trust the series
Sources
What a prediction-market time series actually is
A prediction market contract pays a fixed amount, typically $1, if an event happens and nothing if it does not. The price therefore sits between $0 and $1 and is commonly read as a probability. A contract trading at $0.63 says the crowd, weighted by money, puts the event near 63%.
A time series stacks those readings over time. For a single binary market you get one line, bounded between 0 and 1, that ends at either 0 or 1 when the market resolves. That terminal behavior is what separates it from a stock price. A stock has no known end value. A contract’s path is pulled toward a hard boundary, and volatility typically rises as resolution approaches and information arrives.
Three structural facts shape everything you do with the data:
Prices are bounded. Standard return calculations misbehave near 0 and 1. A move from 0.02 to 0.04 doubles the price but changes the implied probability by two points.
The two sides are linked. In a binary market, the Yes and No prices should sum to roughly $1 after spread. Storing both lets you check consistency.
The series has an end. Each contract is a life cycle: listing, trading, resolution. Analyses that ignore the life cycle mix early-life noise with late-life convergence.
Which fields belong in the series
A minimal row is a timestamp, a contract identifier and a price. A useful row carries more. The schema below works for most research and trading pipelines.
Field | Why it matters |
|---|---|
| Event time in UTC, stored as an integer (epoch microseconds or milliseconds) |
| A stable internal ID, mapped to each venue’s native identifier |
| Yes/No, or the named outcome in a multi-outcome market |
| The implied probability, with the definition recorded (last, mid, bid, ask) |
| Lets you compute spread and a midpoint |
| Separates a quote from a trade, and a liquid move from a thin one |
| Needed the moment you compare sources |
| Open, halted, resolved |
On timestamps, follow the convention used in open data schemas: one public data format document specifies all timestamps as int64 epoch microseconds in UTC. Integers in UTC avoid daylight-saving ambiguity, sort cleanly and survive joins across sources. Convert to local time only at the display layer.
Two habits save you later. First, record the price definition in a column or in metadata, because a last-trade series and a midpoint series behave differently. Second, keep the raw event stream (trades and book updates) separate from any bars you derive. You can always rebuild bars from events. You cannot rebuild events from bars.
Collecting historical odds
There are three common ways to get the data.
Venue APIs. Each venue exposes price history, but the granularity and retention rules differ. For example, a reported issue in Polymarket’s Python client describes the price-history endpoint returning data only at coarse granularity, 12 hours or more, for resolved markets, even for heavily traded events. If you need minute-level history for a closed market, assume the native endpoint may not give it to you and plan to capture data going forward or source it elsewhere.
Your own capture. Subscribe to a streaming feed and write every event to disk. This gives you full fidelity from the day you start, with no history before it.
A normalized historical provider. An aggregated source saves you from writing one adapter per venue and from reconciling identifiers. Our guide to real-time and historical prediction market data feeds covers how a single integration handles both modes.
Whichever route you take, build the pipeline in layers:
Raw layer. Append-only events exactly as received, with the receipt time as well as the venue time.
Clean layer. Deduplicated, typed, UTC-normalized, with canonical contract IDs.
Analysis layer. Resampled bars, derived probabilities and feature columns.
If you work in Python, the Python prediction market data guide walks through the developer side of that pipeline.
From events to a regular series
Prediction markets trade irregularly. A presidential market may update many times a second. A niche contract may go hours with no trade. Most statistical tools expect a regular grid, so you resample. The decisions you make here matter more than the choice of model.
Pick the price you resample
Last trade price is simple and reflects real transactions, but it can sit stale for hours and it bounces between bid and ask.
Midpoint of best bid and ask is smoother and better for thin books, but it is a quote, not a trade, and wide spreads make it a poor estimate.
Volume-weighted average price per bar is robust when volume is uneven, but undefined when no trade occurs.
Choose a bar size
Match the bar to the question. Intraday event studies, such as a data release or a debate, call for one-minute or finer bars. Forecast calibration often works on hourly or daily closes. A bar size finer than the typical gap between trades just manufactures empty bars.
Treat missing bars honestly
Forward-filling the last price is the usual default, and it is reasonable for a price that persists. But it has a cost: it creates the appearance of stability that was never observed. Keep a boolean is_filled column, or carry the time since the last trade, so downstream code can down-weight or exclude stale observations.
A small pandas sketch shows the pattern:
import pandas as pd # trades: columns ts (UTC datetime), price, size trades = trades.set_index("ts").sort_index() bars = trades["price"].resample("1h").ohlc() bars["volume"] = trades["size"].resample("1h").sum() bars["n_trades"] = trades["price"].resample("1h").count() bars["is_filled"] = bars["n_trades"] == 0 bars["close"] = bars["close"].ffill()
import pandas as pd # trades: columns ts (UTC datetime), price, size trades = trades.set_index("ts").sort_index() bars = trades["price"].resample("1h").ohlc() bars["volume"] = trades["size"].resample("1h").sum() bars["n_trades"] = trades["price"].resample("1h").count() bars["is_filled"] = bars["n_trades"] == 0 bars["close"] = bars["close"].ffill()
The n_trades column is the important one. It tells you how much evidence sits behind each bar.
Work in the right scale
Because prices are bounded, many analysts transform to log-odds, log(p / (1 - p)), before modeling. In log-odds a move from 0.02 to 0.04 looks large, which matches its informational weight, and the series is unbounded, so standard time series tools behave better. Clip prices away from exact 0 and 1 first, or the transform blows up.
How researchers read these series
Once the data is regular, the common analyses fall into a few families.
Trend and level. Smooth the series, or look at its change over a window, to see how consensus drifted. This is descriptive: it tells you what the market believed, not why.
Event studies. Mark a timestamp, such as a court ruling, a data release or a poll, and compare the price before and after over a short window. Fine timestamps and a clean volume record are essential here, because you want to attribute the move to the event and not to a coincident trade. Questions about how prices react to unusual moves overlap with work on momentum and behavioral effects in price series, though prediction contracts have a hard terminal value that equities lack.
Calibration. Group historical contracts by their price at a fixed point, say one week before resolution, then compare the average price in each bucket with the realized frequency of Yes outcomes. A well-calibrated market resolves Yes about 70% of the time when it trades near 70%. Calibration needs many resolved contracts, which is why history depth matters.
Backtesting. Replay the series against a rule and measure the result, with fees and slippage included. Our write-up on backtesting prediction market strategies on historical snapshots shows how snapshot depth affects what you can trust.
Forecast updating. Treat the series as a stream of evidence for a forecasting model. A price path is one input among several, and a model that blends it with polls, base rates or fundamentals can outperform any single source.
Aligning series across venues
The same real-world question is often listed on more than one venue. Comparing those series is where most data-quality problems show up.
Identifiers. Each venue names contracts differently. Without a canonical ID that maps equivalent contracts, you will join on text titles and quietly mismatch markets. This is the single biggest source of silent error. See our guide to canonical IDs in cross-venue prediction market data for the mapping problem in detail.
Resolution rules. Two contracts with similar titles can resolve on different sources, at different times, or with different edge-case wording. A 3-point gap may be a real disagreement or two different questions. Read the rules before you call anything a divergence.
Price conventions. Venues quote in dollars or cents, apply different fee structures, and define the quoted price differently. Convert everything to a common probability scale, and decide whether to compare gross or after-fee prices.
Clocks and cadence. One venue may publish every second and another only on trades. Align to a shared grid, and compare only bars where both sides have recent observations.
Liquidity depth. A one-cent gap on a deep book is not the same as a ten-cent gap on a book with a few hundred dollars of size. Carry depth alongside price. Our quant guide to cross-venue price gaps covers how to measure gaps so they survive realistic execution assumptions.
A practical check: after alignment, plot the absolute difference between venues over time. Persistent, stable differences usually point to a rules or fee mismatch. Short spikes that close quickly more often reflect real disagreement or thin quotes.
Reading the series without fooling yourself
Liquidity changes what a price means
A price is information only to the extent that people were willing to trade at it. Prediction markets are often thinly traded, and that may make them less efficient and less martingale-like than liquid financial markets. Weight observations by volume or depth, and be wary of conclusions drawn from bars with a handful of trades.
Biases and manipulation are real
Research on election markets finds that prices can incorporate new information quickly but may also exhibit herding, cognitive biases, excess volatility, and active manipulation. Treat a sharp move on low volume with suspicion until you see it confirmed by other venues, by volume or by an outside signal.
Resolution warps the end of the series
Near resolution, prices converge toward 0 or 1, and for some contracts the final stretch is dominated by traders locking in near-certain payoffs. Exclude the last stretch from analyses that assume ordinary price discovery, or analyze it separately.
Survivorship and selection
If your dataset only contains markets that stayed listed or reached high volume, your calibration estimates will be biased. Keep delisted, cancelled and voided contracts, and record their status.
Lookahead
The quickest way to inflate a backtest is to use information that was not available at the time. Timestamp every field with the time it became known, and when you join features to prices, join backward in time only.
Our perspective
Most failures we see in prediction market research are not modeling failures. They are plumbing failures: a contract matched to the wrong twin on another venue, a timestamp in local time, a forward-filled gap treated as a real observation.
That is why we built Assymetrix around a single idea: a venue-neutral data layer. We aggregate real-time and historical data across Polymarket, Kalshi and Limitless, with canonical IDs and normalized schemas, so the series you build on one venue lines up with the series on another. Our historical store spans roughly 1.5 terabytes and nearly one billion rows of trading activity, which is the depth calibration and backtesting need.
Our view is simple. If the data is structured, timestamped and comparable before it reaches your code, your time is spent on the question and not on the cleanup. We think independent, cross-venue infrastructure is the right foundation for quants, bot builders and AI agents alike.
Dean
Getting the data without building every adapter
If you would rather skip the per-venue adapters, the Assymetrix Data API gives developers, quants, bots and AI agents unified access to cross-venue prediction market data through a single integration, covering real-time and historical data across Polymarket, Kalshi and Limitless. Start with the Data API, or read how the historical data for reproducible backtests is organized.
For streaming use cases, the prediction market WebSocket API page covers real-time feeds, and the real-time data guide for algorithmic systems covers latency-sensitive designs.
A checklist before you trust the series
Every timestamp is UTC and stored as an integer.
Each row carries a canonical contract ID and a venue tag.
The price definition (last, mid, bid, ask) is recorded and consistent.
Raw events are stored separately from derived bars.
Filled bars are flagged, and trade counts are kept.
Resolved, voided and delisted contracts are retained.
Cross-venue comparisons use matched resolution rules and aligned grids.
Features are joined backward in time only.
If all eight hold, the series is ready for calibration, event studies and backtests.
FAQ
Can I read market odds directly as probabilities?
Approximately. A binary contract trading at $0.63 is commonly read as a 63% implied probability. Fees, spreads and thin liquidity mean the price is a noisy estimate, so a midpoint with depth information is safer than a stale last trade.
What bar size should I use for a prediction market time series?
Match it to the question and to trading frequency. Minute or finer bars suit event studies on busy markets, while hourly or daily closes suit calibration. A bar smaller than the typical gap between trades mostly creates empty, forward-filled observations.
How do I handle gaps when nobody trades?
Forward-fill the last price if you need a regular grid, but keep a flag and the trade count for each bar. That way models and backtests can down-weight or exclude stale observations instead of treating them as fresh evidence.
Why transform prices to log-odds?
Prices are bounded between 0 and 1, so ordinary returns and linear models behave badly near the edges. Log-odds are unbounded and treat a move from 2% to 4% as the large shift it is. Clip prices slightly away from 0 and 1 before transforming.
Can historical odds predict future outcomes?
They describe what traders believed at each moment, which is useful as an input to a forecast and for calibration. They are not a guarantee, and research on election markets documents herding, biases and manipulation that can distort prices.
Sources
Building a Time Series From Market Odds: A Practical Guide
A time series from market odds is a sequence of timestamped prices for one contract, read as the market’s implied probability of an outcome. To build one you need four things: a stable contract identifier, UTC timestamps, a consistent price definition (last trade, midpoint or bid and ask), and a rule for what happens when nobody trades. Get those right and the series is ready for analysis. Get them wrong and every model downstream inherits the error.
This guide covers the structure of the series, how to collect and resample it, how to align it across venues, and how to read it without fooling yourself.
Assymetrixdata.assymetrix.comBuild on unified market dataAssymetrix brings historical and real-time data from Polymarket, Kalshi, and Limitless together through one Data API integration.Explore the Data API
TL;DR
A binary contract priced at $0.63 implies roughly a 63% probability, but only after you decide whether the price is a last trade, a midpoint or a bid/ask pair.
Store timestamps in UTC at full precision, keep raw events separate from resampled bars, and flag gaps instead of silently filling them.
Thin liquidity, resolution effects and venue-specific rules change what the same price means, so normalize across venues before comparing.
Historical odds describe what the market believed, not what will happen. Use them to calibrate, backtest and detect event-driven shifts.
Table of Contents
What a prediction-market time series actually is
Which fields belong in the series
Collecting historical odds
From events to a regular series
How researchers read these series
Aligning series across venues
Reading the series without fooling yourself
Our perspective
Getting the data without building every adapter
A checklist before you trust the series
Sources
What a prediction-market time series actually is
A prediction market contract pays a fixed amount, typically $1, if an event happens and nothing if it does not. The price therefore sits between $0 and $1 and is commonly read as a probability. A contract trading at $0.63 says the crowd, weighted by money, puts the event near 63%.
A time series stacks those readings over time. For a single binary market you get one line, bounded between 0 and 1, that ends at either 0 or 1 when the market resolves. That terminal behavior is what separates it from a stock price. A stock has no known end value. A contract’s path is pulled toward a hard boundary, and volatility typically rises as resolution approaches and information arrives.
Three structural facts shape everything you do with the data:
Prices are bounded. Standard return calculations misbehave near 0 and 1. A move from 0.02 to 0.04 doubles the price but changes the implied probability by two points.
The two sides are linked. In a binary market, the Yes and No prices should sum to roughly $1 after spread. Storing both lets you check consistency.
The series has an end. Each contract is a life cycle: listing, trading, resolution. Analyses that ignore the life cycle mix early-life noise with late-life convergence.
Which fields belong in the series
A minimal row is a timestamp, a contract identifier and a price. A useful row carries more. The schema below works for most research and trading pipelines.
Field | Why it matters |
|---|---|
| Event time in UTC, stored as an integer (epoch microseconds or milliseconds) |
| A stable internal ID, mapped to each venue’s native identifier |
| Yes/No, or the named outcome in a multi-outcome market |
| The implied probability, with the definition recorded (last, mid, bid, ask) |
| Lets you compute spread and a midpoint |
| Separates a quote from a trade, and a liquid move from a thin one |
| Needed the moment you compare sources |
| Open, halted, resolved |
On timestamps, follow the convention used in open data schemas: one public data format document specifies all timestamps as int64 epoch microseconds in UTC. Integers in UTC avoid daylight-saving ambiguity, sort cleanly and survive joins across sources. Convert to local time only at the display layer.
Two habits save you later. First, record the price definition in a column or in metadata, because a last-trade series and a midpoint series behave differently. Second, keep the raw event stream (trades and book updates) separate from any bars you derive. You can always rebuild bars from events. You cannot rebuild events from bars.
Collecting historical odds
There are three common ways to get the data.
Venue APIs. Each venue exposes price history, but the granularity and retention rules differ. For example, a reported issue in Polymarket’s Python client describes the price-history endpoint returning data only at coarse granularity, 12 hours or more, for resolved markets, even for heavily traded events. If you need minute-level history for a closed market, assume the native endpoint may not give it to you and plan to capture data going forward or source it elsewhere.
Your own capture. Subscribe to a streaming feed and write every event to disk. This gives you full fidelity from the day you start, with no history before it.
A normalized historical provider. An aggregated source saves you from writing one adapter per venue and from reconciling identifiers. Our guide to real-time and historical prediction market data feeds covers how a single integration handles both modes.
Whichever route you take, build the pipeline in layers:
Raw layer. Append-only events exactly as received, with the receipt time as well as the venue time.
Clean layer. Deduplicated, typed, UTC-normalized, with canonical contract IDs.
Analysis layer. Resampled bars, derived probabilities and feature columns.
If you work in Python, the Python prediction market data guide walks through the developer side of that pipeline.
From events to a regular series
Prediction markets trade irregularly. A presidential market may update many times a second. A niche contract may go hours with no trade. Most statistical tools expect a regular grid, so you resample. The decisions you make here matter more than the choice of model.
Pick the price you resample
Last trade price is simple and reflects real transactions, but it can sit stale for hours and it bounces between bid and ask.
Midpoint of best bid and ask is smoother and better for thin books, but it is a quote, not a trade, and wide spreads make it a poor estimate.
Volume-weighted average price per bar is robust when volume is uneven, but undefined when no trade occurs.
Choose a bar size
Match the bar to the question. Intraday event studies, such as a data release or a debate, call for one-minute or finer bars. Forecast calibration often works on hourly or daily closes. A bar size finer than the typical gap between trades just manufactures empty bars.
Treat missing bars honestly
Forward-filling the last price is the usual default, and it is reasonable for a price that persists. But it has a cost: it creates the appearance of stability that was never observed. Keep a boolean is_filled column, or carry the time since the last trade, so downstream code can down-weight or exclude stale observations.
A small pandas sketch shows the pattern:
import pandas as pd # trades: columns ts (UTC datetime), price, size trades = trades.set_index("ts").sort_index() bars = trades["price"].resample("1h").ohlc() bars["volume"] = trades["size"].resample("1h").sum() bars["n_trades"] = trades["price"].resample("1h").count() bars["is_filled"] = bars["n_trades"] == 0 bars["close"] = bars["close"].ffill()
The n_trades column is the important one. It tells you how much evidence sits behind each bar.
Work in the right scale
Because prices are bounded, many analysts transform to log-odds, log(p / (1 - p)), before modeling. In log-odds a move from 0.02 to 0.04 looks large, which matches its informational weight, and the series is unbounded, so standard time series tools behave better. Clip prices away from exact 0 and 1 first, or the transform blows up.
How researchers read these series
Once the data is regular, the common analyses fall into a few families.
Trend and level. Smooth the series, or look at its change over a window, to see how consensus drifted. This is descriptive: it tells you what the market believed, not why.
Event studies. Mark a timestamp, such as a court ruling, a data release or a poll, and compare the price before and after over a short window. Fine timestamps and a clean volume record are essential here, because you want to attribute the move to the event and not to a coincident trade. Questions about how prices react to unusual moves overlap with work on momentum and behavioral effects in price series, though prediction contracts have a hard terminal value that equities lack.
Calibration. Group historical contracts by their price at a fixed point, say one week before resolution, then compare the average price in each bucket with the realized frequency of Yes outcomes. A well-calibrated market resolves Yes about 70% of the time when it trades near 70%. Calibration needs many resolved contracts, which is why history depth matters.
Backtesting. Replay the series against a rule and measure the result, with fees and slippage included. Our write-up on backtesting prediction market strategies on historical snapshots shows how snapshot depth affects what you can trust.
Forecast updating. Treat the series as a stream of evidence for a forecasting model. A price path is one input among several, and a model that blends it with polls, base rates or fundamentals can outperform any single source.
Aligning series across venues
The same real-world question is often listed on more than one venue. Comparing those series is where most data-quality problems show up.
Identifiers. Each venue names contracts differently. Without a canonical ID that maps equivalent contracts, you will join on text titles and quietly mismatch markets. This is the single biggest source of silent error. See our guide to canonical IDs in cross-venue prediction market data for the mapping problem in detail.
Resolution rules. Two contracts with similar titles can resolve on different sources, at different times, or with different edge-case wording. A 3-point gap may be a real disagreement or two different questions. Read the rules before you call anything a divergence.
Price conventions. Venues quote in dollars or cents, apply different fee structures, and define the quoted price differently. Convert everything to a common probability scale, and decide whether to compare gross or after-fee prices.
Clocks and cadence. One venue may publish every second and another only on trades. Align to a shared grid, and compare only bars where both sides have recent observations.
Liquidity depth. A one-cent gap on a deep book is not the same as a ten-cent gap on a book with a few hundred dollars of size. Carry depth alongside price. Our quant guide to cross-venue price gaps covers how to measure gaps so they survive realistic execution assumptions.
A practical check: after alignment, plot the absolute difference between venues over time. Persistent, stable differences usually point to a rules or fee mismatch. Short spikes that close quickly more often reflect real disagreement or thin quotes.
Reading the series without fooling yourself
Liquidity changes what a price means
A price is information only to the extent that people were willing to trade at it. Prediction markets are often thinly traded, and that may make them less efficient and less martingale-like than liquid financial markets. Weight observations by volume or depth, and be wary of conclusions drawn from bars with a handful of trades.
Biases and manipulation are real
Research on election markets finds that prices can incorporate new information quickly but may also exhibit herding, cognitive biases, excess volatility, and active manipulation. Treat a sharp move on low volume with suspicion until you see it confirmed by other venues, by volume or by an outside signal.
Resolution warps the end of the series
Near resolution, prices converge toward 0 or 1, and for some contracts the final stretch is dominated by traders locking in near-certain payoffs. Exclude the last stretch from analyses that assume ordinary price discovery, or analyze it separately.
Survivorship and selection
If your dataset only contains markets that stayed listed or reached high volume, your calibration estimates will be biased. Keep delisted, cancelled and voided contracts, and record their status.
Lookahead
The quickest way to inflate a backtest is to use information that was not available at the time. Timestamp every field with the time it became known, and when you join features to prices, join backward in time only.
Our perspective
Most failures we see in prediction market research are not modeling failures. They are plumbing failures: a contract matched to the wrong twin on another venue, a timestamp in local time, a forward-filled gap treated as a real observation.
That is why we built Assymetrix around a single idea: a venue-neutral data layer. We aggregate real-time and historical data across Polymarket, Kalshi and Limitless, with canonical IDs and normalized schemas, so the series you build on one venue lines up with the series on another. Our historical store spans roughly 1.5 terabytes and nearly one billion rows of trading activity, which is the depth calibration and backtesting need.
Our view is simple. If the data is structured, timestamped and comparable before it reaches your code, your time is spent on the question and not on the cleanup. We think independent, cross-venue infrastructure is the right foundation for quants, bot builders and AI agents alike.
Dean
Getting the data without building every adapter
If you would rather skip the per-venue adapters, the Assymetrix Data API gives developers, quants, bots and AI agents unified access to cross-venue prediction market data through a single integration, covering real-time and historical data across Polymarket, Kalshi and Limitless. Start with the Data API, or read how the historical data for reproducible backtests is organized.
For streaming use cases, the prediction market WebSocket API page covers real-time feeds, and the real-time data guide for algorithmic systems covers latency-sensitive designs.
A checklist before you trust the series
Every timestamp is UTC and stored as an integer.
Each row carries a canonical contract ID and a venue tag.
The price definition (last, mid, bid, ask) is recorded and consistent.
Raw events are stored separately from derived bars.
Filled bars are flagged, and trade counts are kept.
Resolved, voided and delisted contracts are retained.
Cross-venue comparisons use matched resolution rules and aligned grids.
Features are joined backward in time only.
If all eight hold, the series is ready for calibration, event studies and backtests.
FAQ
Can I read market odds directly as probabilities?
Approximately. A binary contract trading at $0.63 is commonly read as a 63% implied probability. Fees, spreads and thin liquidity mean the price is a noisy estimate, so a midpoint with depth information is safer than a stale last trade.
What bar size should I use for a prediction market time series?
Match it to the question and to trading frequency. Minute or finer bars suit event studies on busy markets, while hourly or daily closes suit calibration. A bar smaller than the typical gap between trades mostly creates empty, forward-filled observations.
How do I handle gaps when nobody trades?
Forward-fill the last price if you need a regular grid, but keep a flag and the trade count for each bar. That way models and backtests can down-weight or exclude stale observations instead of treating them as fresh evidence.
Why transform prices to log-odds?
Prices are bounded between 0 and 1, so ordinary returns and linear models behave badly near the edges. Log-odds are unbounded and treat a move from 2% to 4% as the large shift it is. Clip prices slightly away from 0 and 1 before transforming.
Can historical odds predict future outcomes?
They describe what traders believed at each moment, which is useful as an input to a forecast and for calibration. They are not a guarantee, and research on election markets documents herding, biases and manipulation that can distort prices.
Sources
Other Blog
