Paper Trading Prediction Markets: Replay API Data Before Live Stakes

Paper trading prediction markets means simulating trades with virtual capital to validate a strategy’s logic, sizing, and probability calibration before risking real money. It helps developers debug bots, lets quants test edge hypotheses, and gives AI agent builders a safe loop for iterating on decision logic. The first move is picking a data source and defining one testable hypothesis.

TL;DR:

• A contract paying $1 on success and $0 otherwise trades at an implied probability, but credible fills also require orderbook depth, spreads, and settlement rules.

• Fix the hypothesis, sample size, capital, sizing, fees, and fill model before trading; log every order and avoid changing parameters during the test.

• Win rate alone can mislead: track profit and loss, Brier score, edge per trade, fill rate, and modeled slippage across the full test window.

• Begin with small live stakes only after calibration remains steady across nonoverlapping periods and the edge survives fill assumption checks; verify registration and contract rules.

Assymetrixdata.assymetrix.comTest Strategies With Cross-Venue DataAssymetrix gives developers and researchers unified API access to historical prediction market data across Polymarket, Kalshi, and Limitless.Explore the Data API

Table of Contents

• How event contracts map prices to probabilities

• Why paper trade before risking real capital

• A step-by-step workflow for reproducible paper trading

• Metrics and statistical checks that predict live transferability

• Tools and environments for simulating trades

• How a cross-venue Data API supports rigorous backtests

• When to graduate from paper trading to small live stakes

• A cross-venue data layer can support your paper trading setup

• FAQ

• Sources

How event contracts map prices to probabilities

A prediction market event contract pays a fixed amount, typically $1, if the specified outcome occurs and $0 otherwise. Because of that binary payout, the contract’s price functions as the market’s implied probability: a contract trading at 60 cents implies roughly a 60% chance of the outcome, a relationship confirmed in standard descriptions of how prediction markets work. That mapping matters for expected value calculations, since any simulated position’s theoretical edge depends on the gap between your estimated probability and the market’s implied one.

A simulation needs to model more than the headline price. It has to represent:

• The full orderbook depth at the moment of a simulated fill, not just the last trade price.

• Bid-ask spread width, which widens on thin or newly listed contracts.

• Settlement source and timing, since contracts resolve against a specific, often external, data feed.

Skipping these details produces a backtest that looks profitable on paper and falls apart against a live orderbook.

Why paper trade before risking real capital

Paper trading earns its place in a development cycle by isolating specific failure modes before capital is on the line. It is the standard way to catch a bot’s logic errors, test position sizing rules, and check whether a forecasting model’s probabilities are well calibrated against outcomes.

• Debugging: catches sign errors, off-by-one timing bugs, and malformed order logic.

• Calibration testing: reveals whether your 70% calls resolve true about 70% of the time.

• Sizing validation: lets you stress-test a Kelly-style or fixed-fraction sizing rule without drawdown risk.

• Algorithmic logic checks: confirms that signal generation and execution code behave as designed across many scenarios.

What it cannot do is reproduce the psychology of holding a real position, or the slippage and partial fills that show up when your own order moves a thin book. Define success criteria before you start, such as a target Brier score or a minimum sample size, so the result is not graded against a moving goalpost.

Pro Tip: Write your success criteria down before the first simulated trade, not after reviewing the results.

A step-by-step workflow for reproducible paper trading

A paper trading run only has evidentiary value if another person, or your future self, can rerun it and get the same answer. That requires documenting decisions before execution rather than after.

1. State the hypothesis precisely: which markets, what signal, what time window, and what sample size counts as sufficient.

2. Fix the simulated capital, position sizing rule, and fee assumptions in a config file, not in your head.

3. Document the fill model: are you assuming mid-price fills, worst-case touch fills, or an orderbook-walk model for larger sizes.

4. Pull and normalize data using canonical market and outcome IDs so the same event is tracked identically across venues.

5. Choose a replay method: real-time streaming for live-logic testing, or historical snapshot replay for faster iteration over past periods.

6. Log every simulated order, fill, and cancellation with timestamps, and keep the logging code under version control alongside the strategy code.

7. Run the experiment for the full predetermined window without adjusting parameters mid-run.

8. Export trade-level records and compute your metrics, then hold out a separate period for an out-of-sample check before drawing conclusions.

The backtesting methodology using historical price snapshots and canonical IDs follows this same sequence when validating cross-venue strategies against large historical datasets.

Metrics and statistical checks that predict live transferability

Raw win rate is a weak signal for event contracts, since a strategy can win most trades and still lose money on sizing or settlement timing. Track profit and loss per contract alongside a calibration measure like the Brier score, which scores the accuracy of your stated probabilities rather than just whether you picked the winning side. Edge per trade, meaning your estimated probability minus the market’s implied probability at entry, tells you whether a win was skill or variance.

• P&L per trade and cumulative P&L across the full test window.

• Brier score or a similar calibration metric for your stated probabilities.

• Fill rate: the share of simulated orders that would plausibly have executed at your assumed price.

• Modeled slippage against documented orderbook depth and spread behavior.

A simulated strategy that only ever gets tested on one historical window is a strategy that has only been tested once. Cross-validation across multiple non-overlapping periods, combined with a sensitivity analysis on your sizing and fill assumptions, is how you tell a real edge from a backtest-overfitting artifact. Prediction market prices reflect implied probability directly, as the standard description of market mechanics lays out, which is why calibration checks matter more here than in point-forecast trading.

Tools and environments for simulating trades

Four broad categories cover most paper trading setups, each suited to a different stage of development.

• Exchange sandboxes: built-in paper trading modes on some venues, useful for quick manual checks of order mechanics.

• Historical replay engines: custom scripts that step through recorded market states tick by tick, needed for execution-sensitive strategy testing.

• Spreadsheet and lightweight backtest stacks: fast for early-stage hypothesis screening before committing engineering time.

• API-driven data feeds: programmatic access to live and historical data, required for anything run at scale or across multiple venues.

Cross-venue testing only works when events are tracked under consistent canonical IDs and synchronized timestamps. Analysts have flagged forecasting and analytics tools like PlotStudio AI’s forecasting software overview as relevant reference points for teams building out statistical workflows around this kind of data. Replay fidelity should match the test’s purpose: a quick signal screen tolerates mid-price fills, but anything claiming an execution edge needs an orderbook-walk model that accounts for thin liquidity.

How a cross-venue Data API supports rigorous backtests

A data layer built for paper trading needs three things: canonical IDs that track the same event across venues, enough historical depth to run a meaningful out-of-sample split, and a live feed that matches the format of the historical data so code written against one works against the other.

• Canonical IDs resolve the same event listed separately on different venues into a single trackable record.

• Historical backfill measured in hundreds of millions of rows supports cross-validation across many non-overlapping periods.

• REST and WebSocket feeds sharing a schema let a backtest script become a live-paper script with minimal rewrites.

• Wallet-level tagging and Trader Skill Score data add a benchmark layer: how does your simulated strategy compare to tracked top performers.

A typical workflow pulls historical snapshots for an initial backtest, replays them against a documented fill model, then switches the same code to a live feed for a forward paper run before any capital is committed. The developer guide to feed formats and backfill details the schema used across both modes.

Pro Tip: Export every simulated trade with its canonical ID, timestamp, and fill price so a reviewer can rebuild your P&L from raw records alone.

When to graduate from paper trading to small live stakes

Graduate once calibration holds steady across multiple out-of-sample windows and the edge survives a sensitivity check on fill assumptions. Scale up gradually, from minimal stakes to full size, watching for slippage that exceeds your modeled estimate. Confirm venue registration and contract terms, since the CFTC’s guidance on event contracts notes customers should verify a market’s registration and rules before committing funds.

— Dean

A cross-venue data layer can support your paper trading setup

Reproducible paper trading depends on data that stays consistent across venues and across time, which is the specific problem our Data API addresses for developers and quant teams.

• Canonical IDs keep the same event aligned across multiple prediction market venues for multi-venue backtests.

• Historical backfill spans hundreds of millions of rows, providing depth for proper out-of-sample splits.

• REST and WebSocket access share a schema, allowing backtest scripts to carry over to live paper runs with minimal changes.

• Wallet tracking and trader skill scoring data can provide benchmarks for comparing simulated strategies against tracked performance.

Review the Data API landing page for integration details and get in touch to start building your paper trading pipeline on normalized, cross-venue data.

FAQ

What are the top prediction markets to track?

The largest venues by trading activity include Polymarket, Kalshi, and Limitless, each covering different event categories and regulatory structures. Cross-venue tracking of these three gives the broadest signal coverage for paper trading experiments.

Can you actually make money on prediction markets?

Outcomes depend on forecasting skill, execution quality, and fees, and no outcome is guaranteed in either simulated or live trading. Paper trading exists specifically to test whether a given strategy’s edge is real before committing capital.

What are the best platforms for paper trading?

The right setup depends on whether you need quick manual checks or full execution-sensitive testing; options range from exchange sandboxes to custom replay engines built on a cross-venue Data API. Teams running multi-venue backtests generally need canonical IDs and historical backfill that a spreadsheet alone cannot provide.

Is paper trading illegal?

Paper trading with virtual capital and no real money at stake carries no betting or trading legal exposure since no funds change hands. Live event contract trading, by contrast, is regulated activity, and the CFTC’s prediction markets guidance explains the obligations that apply to registered exchanges and their customers.

Does paper trading fully predict live trading results?

No. Paper trading tests logic, sizing, and calibration well, but it cannot fully reproduce live slippage, partial fills, or the psychological effect of real capital at risk, which is why a sensitivity analysis and a small live-stakes ramp matter before scaling up.

Sources

• Prediction market — Wikipedia

• Prediction markets | CFTC

Market Closing Times for Quants: Trust Settlement, Not End Dates

For prediction market backtests and bots, the correct closing signal is settlement_ts and status, not the venue-published endDate. A market closing times dataset covers three distinct moments: scheduled close, trading close, and final settlement. We build and normalize these fields across venues, and the rule holds everywhere: trust settlement, not schedule.

TL;DR:

• Store scheduled, operational, and settlement timestamps separately in UTC, preserve original venue values, and retain updated_time and source_version for audit and reproducible backtests.

• Treat a market without a populated settlement_ts as unresolved; closed only means trading stopped, and Kalshi also uses settlement_value_usd as its authoritative settlement indicator.

• Join candles to market metadata by venue and market_id, tag the settlement_ts candle as resolution, and freeze signal inputs before settlement using a safety buffer.

• Calculate realized PnL from settlement_value_usd, not the last traded price, and reconcile settlement records against final candle closes after each refresh.

Assymetrixdata.assymetrix.comUse Reliable Cross-Venue Market DataAssymetrix brings prediction market data from Polymarket, Kalshi, and Limitless into a unified API for research and trading tools.Explore the Data API

Table of Contents

• 1. Canonical schema: fields to store and why each matters

• 2. Mapping venue data to the canonical schema

• 3. Common data hazards and engineering practices to avoid them

• 4. Practical integration patterns and query examples for backtests and bots

• 5. Quant and trader use cases that depend on precise closing times

• Why closing-time precision keeps failing in practice

• Getting normalized closing-time data through a unified Data API

• FAQ

• Sources

1. Canonical schema: fields to store and why each matters

A reliable market closing times dataset needs a fixed set of fields, each serving a distinct computation. Mixing them up is the most common source of backtest errors we see in production pipelines.

• market_id (string): a canonical identifier that stays stable across venue renames or re-listings.

• venue (string): the originating exchange, needed for cross-venue joins and reconciliation.

• market_start_time and market_end_time (timestamp, UTC): the scheduled window as published by the venue at listing time.

• open_time and close_time: operational timestamps that can be updated by the venue after a market’s initial listing.

• settlement_ts (timestamp): the moment a market’s outcome was actually determined, the field to treat as authoritative.

• status (enum): lifecycle state, typically active, closed, determined, or finalized/settled.

• resolved_outcome, updated_time, source_version: fields that support reconciliation when upstream data changes.

market_end_time answers “when was this scheduled to close.” close_time answers “when did new orders stop.” settlement_ts answers “when did this market’s outcome become final,” and it is the field that belongs in PnL calculations and resolution labeling. Every timestamp should be stored in UTC, with the original venue-published value preserved alongside the normalized one so that corrections can be audited rather than silently overwritten.

2. Mapping venue data to the canonical schema

Cross-venue normalization starts with knowing which upstream table owns which fact. Dune’s prediction_markets.markets table serves as the cross-venue dimension, carrying market_end_time, settlement_ts, and status side by side, and it explicitly flags that Polymarket’s published end date is often inaccurate for historical outcome calculations.

• prediction_markets.markets: the cross-venue dimension table; use settlement_ts and status, not market_end_time, for resolution logic.

• kalshi.market_details: holds lifecycle metadata including open_time and close_time, with close_time capable of reflecting later venue updates rather than the original listing value.

• polymarket_polygon.ohlcv_hourly: hourly candles that forward-fill no-trade hours and pin the closing price to the settlement value on the resolution hour.

The working rule of thumb: treat market_end_time as a scheduling hint, and treat settlement_ts paired with status as the field pair that determines whether a market’s outcome is actually final.

3. Common data hazards and engineering practices to avoid them

The single most expensive mistake in this space is conflation: treating a scheduled endDate as if it were the final resolution timestamp. This causes backtest label leakage, because a position that looks closed at the scheduled hour may still be open, pending, or reversed before true settlement. It also corrupts PnL calculations that reference a price snapshot from before the actual outcome was determined.

Lifecycle nuance compounds the problem. Kalshi’s market_details schema defines a status vocabulary that includes finalized, determined, inactive, closed, active, and initialized, and uses settlement_value_usd as the authoritative settlement indicator rather than any single timestamp alone. A market can be “closed” to new orders while still awaiting a “determined” or “finalized” state, and bots that treat “closed” as equivalent to “settled” will act on incomplete information.

1. Build an explicit status state machine rather than inferring lifecycle from timestamps alone.

2. Run nightly reconciliation jobs comparing settlement_value_usd or settlement_ts against the final candle close.

3. Store source_version and updated_time on every row so corrected upstream fields can be traced and backfilled.

4. Keep audit logs of status transitions, with alerts fired on any transition into or out of “determined.”

5. Flag markets with delayed settlement and apply a safety buffer before automated systems act on them.

Pro Tip: Treat any market without a populated settlement_ts as unresolved, regardless of what its scheduled close_time suggests.

4. Practical integration patterns and query examples for backtests and bots

A workable architecture joins the canonical market dimension to hourly candle data on (venue, market_id), then uses settlement_ts to mark which candle bar represents the true resolution event rather than relying on bar position alone.

• Join canonical market metadata to ohlcv_hourly on venue and market_id, then tag the bar containing settlement_ts as the resolution bar.

• For backtest entry signals, freeze decisions at t <= settlement_ts - safety_buffer so no feature computation leaks information from after resolution.

• Compute realized PnL from settlement_value_usd rather than the last traded price, since the last trade can predate the actual determination.

• Run a streaming layer for live status updates, paired with a periodic full historical refresh that captures corrected settlement_ts values pushed upstream after the fact.

• After every refresh, run data quality asserts: no null settlement_ts on rows marked finalized, no close_time earlier than open_time, no orphaned market_id values.

This pattern works whether the consumer is a backtesting engine replaying history or a live bot gating new positions against markets that are not yet genuinely closed.

5. Quant and trader use cases that depend on precise closing times

Reproducible backtests depend on freezing both settlement_ts and source_version, so a result computed today can be regenerated months later even after upstream corrections. Latency and arbitrage detection compares settlement_ts timing across venues covering the same real-world event, using candle pin timing as a secondary confirmation signal.

• Time-to-resolution: a feature built from the gap between current time and expected settlement, useful for decay-weighted signal construction.

• Pre-close volume surge: volume concentrated near close_time often signals information asymmetry worth modeling separately from mid-market activity.

• Cross-venue settlement lag: comparing settlement_ts for equivalent markets across venues surfaces latency arbitrage windows.

• Auditability: canonical IDs paired with source_version are what let a published result be rerun and verified rather than taken on faith.

Why closing-time precision keeps failing in practice

Most backtest failures we encounter trace back to one root cause: a pipeline treated a scheduled close as a settled outcome. The fix is rarely more data. It is almost always a missing status check or a settlement_ts field that was never actually plumbed through from the venue source to the application layer.

Teams that adopt a canonical schema early spend far less time debugging phantom PnL discrepancies later. The lesson scales: normalize the lifecycle fields before writing a single line of strategy logic, not after a trade goes wrong.

— Dean

Getting normalized closing-time data through a unified Data API

Normalized settlement_ts, lifecycle status, and canonical market IDs are available across leading prediction market venues through a single integration, built on a substantial historical trading dataset. Engineers designing execution safeguards around these timestamps can also review risk management setup practices for automated order controls and safety buffers.

Review the Data API documentation, or see the real-time and historical feed guide and Python integration examples to request a sample export.

FAQ

What is a market closing times dataset?

It is a structured dataset covering a prediction market contract’s scheduled close, trading close, and final settlement timestamp, rather than a single closing field. The distinction matters because a market’s scheduled close and its actual resolution can differ by hours or more.

Why shouldn’t I trust the venue’s endDate field?

settlement_ts paired with status reflects the actual resolution event and should be used instead for historical outcome calculations.

How do OHLCV candles handle market resolution?

Hourly candle tables like polymarket_polygon.ohlcv_hourly forward-fill no-trade hours and pin the close price to the settlement value on the resolution-hour bar. This gives backtests a reliable anchor point for labeling the bar where a market’s outcome actually became final.

What lifecycle statuses should a dataset track?

A robust schema tracks at minimum active, closed, determined, and finalized or settled states, mirroring the vocabulary used in Kalshi’s market_details table. Treating “closed” as equivalent to “settled” is a common error since a market can stop accepting orders well before its outcome is determined.

Does a Data API provide these normalized fields?

A Data API provides normalized settlement_ts, lifecycle status, and canonical IDs across Polymarket, Kalshi, and Limitless for developers and quant teams. Pricing details and access tiers are available on the Data API page.

Sources

• kalshi.market_details - Dune Docs

• polymarket_polygon.ohlcv_hourly - Dune Docs

Prediction Market Taxonomy: 9 Axes Developers Must Track

Prediction markets can be analyzed across independent axes, including trading mechanism, share structure, numeraire, and resolution method. Each combination produces distinct liquidity behavior and data requirements, which is why normalizing feeds across venues like Polymarket, Kalshi, and Limitless demands more than matching tickers. Metrics like Loss-Versus-Rebalancing and market-scoring rules only make sense once you know which axis you are measuring.

TL;DR:

• Winner take all contracts pay holders of correct outcomes, yes no bundles pair complementary shares, and scalar prices map to ranges rather than probabilities.

• Do not compare displayed depth directly: order books show posted orders, while AMM quotes come from a pricing curve and depend on available subsidy.

• CDA and LMSR have statistically similar average predictive performance; liquidity conditions and parameter settings, rather than mechanism alone, determine which performs better.

• Exclude play money venues from accuracy benchmarks unless the study accounts for weaker external incentives; credits lack the financial stake found in real money markets.

• Store canonical identifiers, timestamped trades or AMM curve snapshots, numeraires tagged by market, dispute records, and separate resolution and settlement timestamps.

AssymetrixBuild With Unified Market DataExplore cross-venue prediction market data from Polymarket, Kalshi, and Limitless through a single Data API integration.Explore the Data API

Table of Contents

• Taxonomy overview: modular axes and how to combine them

• Share structures: WTA, yes-no bundles, scalar, and implementation variants

• Money models: real-money vs play-money and numeraire implications

• Trading mechanics and liquidity: CDA vs AMM/LMSR, divergence loss, and LVR to monitor

• Market resolution and settlement: oracles, arbiters, vote-based and archival consequences

• Practical implications: the data fields and signals developers and quants must collect

• Case note and pointers to Assymetrix resources for taxonomy-aware data feeds

• Author’s take: where to start using the taxonomy in design or research

• Assymetrix Data API: unified cross-venue feeds, canonical IDs, and live signals

• FAQ

• Sources

Taxonomy overview: modular axes and how to combine them

An academic framework for classifying online prediction markets decomposes a system into independent modules rather than a single label. That structure holds up well for anyone building cross-venue tooling, because it lets you compare systems that look nothing alike on the surface.

The modular axes are:

• Infrastructure and permissioning: who can list markets, trade, or access data.

• Market topic: the domain a contract covers, from macroeconomics to sports.

• Share structure and pricing: how outcomes are represented and priced.

• Numeraire: the unit of value settled and traded.

• Initialization: how a market is seeded and opened.

• Trading: the matching or pricing mechanism in use.

• Resolution: how the true outcome gets determined.

• Settlement: how winnings get paid out.

• Archiving: what happens to market data after close.

Because these axes are independent, a venue using an automated market maker can pair with crowdsourced resolution, while another uses an order book with an arbiter. Reading a market correctly means checking each axis rather than assuming mechanism implies resolution, or that numeraire implies liquidity depth.

Share structures: WTA, yes-no bundles, scalar, and implementation variants

Share structure determines what a trader actually owns and how a dataset should represent it. Winner-take-all (WTA) contracts pay a fixed amount to holders of the correct outcome and nothing to everyone else. Yes-no bundle (YNB) markets, including the YNB-NR variant used in practice, split a binary question into complementary shares that together sum to a fixed value. Scalar markets settle to a point on a numeric range rather than a discrete outcome, which changes how you compute implied probability.

Implementation also varies within each structure:

• Splitting (collateral split, automated issuance) creates shares algorithmically and ties displayed liquidity to the pricing curve itself.

• Matching (order-book fills) creates shares only when a buyer and seller agree on price, so liquidity reflects standing orders rather than a formula.

• Scalar markets often require a different normalization path than binary ones, since “price” maps to a range rather than a probability.

Datasets that blend splitting and matching venues without flagging the distinction will misread displayed depth as comparable, when the two numbers describe different things entirely.

Money models: real-money vs play-money and numeraire implications

Real-money markets settle in a numeraire with external value: US dollars, a stablecoin, or another transferable asset. Play-money markets settle in platform credits that carry no exchange value outside the system. The numeraire shapes participation incentives directly, since traders risking real capital behave differently than traders accumulating points.

That difference shows up in liquidity and in forecasting quality. Real-money venues tend to attract traders with financial skin in the outcome, which generally sharpens price signals, while play-money venues can still generate useful directional signal in low-stakes or experimental settings.

• Real-money markets: USD or stablecoin numeraires, direct financial incentive to trade accurately.

• Play-money markets: platform credits, lower barrier to entry, weaker external validity.

• Mixed research use: exclude play-money venues from accuracy benchmarks unless the study design accounts for incentive differences explicitly.

Trading mechanics and liquidity: CDA vs AMM/LMSR, divergence loss, and LVR to monitor

Continuous double auction (CDA) venues match buy and sell orders directly against a standing order book, so liquidity depends entirely on what traders have posted. Automated market maker and market-scoring-rule systems, including LMSR, instead price trades against a formula, which guarantees a quote at any size but ties liquidity to the subsidy behind the curve.

Comparative research on CDA and LMSR finds the two mechanisms produce statistically similar average predictive performance, though superiority depends heavily on liquidity conditions and parameter settings rather than the mechanism alone.

• CDA liquidity: order-book depth, visible bid-ask spread, sensitive to trader participation.

• AMM/LMSR liquidity: constant by design, but exposed to subsidy drawdown as volume grows.

• Divergence loss: a risk specific to splitting-based AMMs, where share creation through collateral splitting can erode the value backing the pool.

• LVR (Loss-Versus-Rebalancing): a monitoring metric for quantifying how much an AMM loses relative to a continuously rebalanced benchmark.

Treat displayed AMM liquidity as a statement of algorithmic commitment, not a resting limit order, when sizing a position or backtesting a strategy against liquidity depth data.

Pro Tip: Track LVR alongside raw spread when comparing venues, since a tight quoted spread on a thin AMM can still carry meaningful rebalancing cost that a CDA spread never shows.

Market resolution and settlement: oracles, arbiters, vote-based and archival consequences

Resolution design determines how a market learns its own outcome, and the mechanism varies widely across venues. Common patterns include a designated arbiter who rules on the outcome, network reporters who submit attestations, crowdsourced voting among token or reputation holders, optimistic resolution that assumes a proposed outcome unless challenged, and oracle integrations that pull from external data feeds.

• Arbiter-based: fast but centralized, with dispute risk concentrated in one party.

• Crowdsourced or optimistic: slower to finalize, but resistant to single-point manipulation.

• Push settlement pays out automatically once resolution finalizes; pull settlement requires the trader to claim winnings, which affects when a position actually closes in your records.

For backtesting, resolution delays and post-resolution amendments matter as much as the headline outcome. A market that resolves, gets disputed, and later flips introduces a data quality problem that archiving policy either preserves or erases.

Practical implications: the data fields and signals developers and quants must collect

Taxonomy only earns its keep once it is operationalized into a schema. A normalized feed across venues needs a consistent set of fields regardless of which axis combination a given market uses.

1. Canonical market and outcome identifiers, consistent across venues and resilient to renaming.

2. Timestamped fills and orders for CDA venues, or AMM curve state snapshots for market-maker venues.

3. Numeraire and denomination, tagged per market rather than assumed per venue.

4. Resolution metadata, including method, resolver identity, and dispute status.

5. Settlement timestamps, separated from resolution timestamps where push and pull flows differ.

From those fields, the signals worth deriving include liquidity depth, bid-ask spread, trade counts, price variance over time, smart-money wallet traces, cross-venue arbitrage gaps, and LVR for AMM-based markets.

Pro Tip: Align timestamps to a single clock source before joining feeds across venues, since resolution and settlement events on different mechanisms rarely land on the same cadence.

Integration work mostly comes down to canonical identifiers, consistent quality flags for amended resolutions, and a clear separation between resolution time and settlement time in every stored record.

Case note and pointers to Assymetrix resources for taxonomy-aware data feeds

A common integration problem surfaces when combining AMM-based and order-book venues into one dataset: displayed liquidity numbers look comparable but describe different underlying mechanics, which skews naive depth comparisons until the axes are separated explicitly.

Resources that speed this work include the cross-venue canonical ID guide, the real-time and historical API guide, and writeups on arbitrage signal construction. Each one reduces the normalization work a team would otherwise rebuild from scratch per venue.

Author’s take: where to start using the taxonomy in design or research

For market design work, start with the trading mechanism axis, since it sets the liquidity behavior everything else depends on. For research work comparing venues, start with resolution, since inconsistent resolution handling quietly corrupts more backtests than mechanism choice does. Either way, instrument LVR and liquidity depth from day one rather than retrofitting them later.

— Dean

Assymetrix Data API: unified cross-venue feeds, canonical IDs, and live signals

Our Data API delivers canonical market identifiers, live and historical feeds, and liquidity and wallet signals across Polymarket, Kalshi, and Limitless through a single integration.

• Canonical IDs resolve the identifier mismatch between venues before you write a line of strategy code.

• Historical data supports backtesting resolution and liquidity assumptions.

• Smart Money and arbitrage signals support taxonomy classification and signal generation.

Check field definitions and get started on the Data API page.

FAQ

What are the main axes used to classify prediction markets?

Prediction markets are classified along independent axes: trading mechanism, share structure, numeraire, and resolution method, with infrastructure, initialization, settlement, and archiving as supporting dimensions in the modular taxonomy. Each axis can combine freely with the others, so two markets sharing a mechanism can still differ completely in resolution or numeraire.

Is LMSR or a continuous double auction more accurate?

Neither mechanism wins outright. Comparative research finds CDA and LMSR produce statistically similar average predictive performance, with the better performer depending on liquidity conditions and parameter settings rather than the mechanism itself.

What is divergence loss in an AMM-based prediction market?

Divergence loss describes value erosion in splitting-based automated market makers, where share creation through collateral splitting can introduce risk roughly equivalent to the liquidity committed to the pool. It is distinct from order-book slippage, since it arises from the pricing curve rather than from matching trades against standing orders.

Should researchers include play-money markets in cross-venue studies?

Play-money markets generally carry weaker external validity than real-money markets because participants have no financial stake in the outcome. Researchers typically exclude play-money venues from accuracy benchmarks unless the study design explicitly accounts for the incentive difference.

What data fields do I need to normalize across prediction market venues?

A workable cross-venue schema needs canonical market and outcome identifiers, timestamped fills or AMM curve state, tagged numeraire, resolution metadata, and settlement timestamps kept separate from resolution timestamps. These fields let you derive liquidity depth, spreads, and arbitrage signals consistently regardless of which mechanism a given market uses.

Sources

The classification framework here draws on a foundational academic taxonomy for online prediction markets, which established the modular, axis-based approach to comparing disparate systems. Mechanism trade-offs draw on comparative research measuring CDA against LMSR performance, and on practitioner-level microstructure analysis covering divergence loss and LVR in decentralized prediction market AMMs. Together they cover the academic systematization, the mechanism comparison, and the microstructure detail a developer or quant needs to apply the taxonomy in practice.

• SoK: Market Microstructure for Decentralized Prediction Markets (DePMs)

• The Relative Accuracy of LMSR and CDA Prediction Markets

• Towards a classification of online prediction markets

Scalar Markets Data: 3 Feeds for Realistic Agent Backtests

Scalar markets data is the unified real-time and historical feed of range-settled prediction markets, covering orderbook state, trade prints, and settlement outcomes across venues. Ingesting it correctly lets you backtest, run, and scale algos and AI agents against execution-realistic conditions rather than idealized prices. Platforms like Assymetrix aggregate this data across major venues into a single schema, which is the starting point for any serious integration.

TL;DR:

• Capture trade prints, full orderbook depth, lifecycle events, range endpoints, resolution rules, and derived prices; millisecond timestamps preserve event order for deterministic replay.

• Use WebSockets for live top of book and trades, REST for metadata and snapshots, and bulk columnar exports for historical backtests.

• Build canonical IDs from venue, normalized range endpoints, and an internal slug; preserve source provenance and normalize prices to probabilities from zero to one.

• Backtests should model venue specific maker and taker fees by fill, historical depth based fill probability, slippage, latency, and fee schedule versions.

• Keep sizing and risk limits in a deterministic execution layer, cap each position, monitor fills and slippage, and test in paper mode before live deployment.

Assymetrixdata.assymetrix.comBuild More Realistic Market BacktestsAssymetrix brings real-time and historical prediction market data from Polymarket, Kalshi, and Limitless into one API integration.Explore the Data API

Table of Contents

• 1. What data fields you need for scalar markets

• 2. How to access scalar markets data: APIs, streaming, and exports

• 3. Normalizing cross-venue scalar data and canonical IDs

• 4. Orderbook, fee models, and execution realism for agents and algos

• 5. Backtesting and replay: episode formats that stay deterministic

• 6. Engineering practices for AI agents consuming scalar data

• Where belief meets execution in scalar markets

• How the Assymetrix Data API covers these needs

• FAQ

• Sources

1. What data fields you need for scalar markets

A scalar, or range-settled, market resolves to a numeric value inside a continuous range rather than a binary yes or no, so the data you pull has to capture both price and the shape of the distribution traders expect. Reconstructing market state at any point in time requires five field groups.

• Trade prints: timestamp, price, size, side, and wallet ID for every executed fill.

• Orderbook snapshots: bid and ask levels, depth at each level, and visible resting size.

• Lifecycle events: market open, suspension, close, and the settlement window itself.

• Market metadata: numeric endpoints of the range, resolution rules, tick size, and quote currency.

• Derived series: implied probability, midprice, cumulative volume, and liquidity measures computed from the raw feed.

Timestamp precision matters more than it looks. Millisecond or sub-second precision is what lets you order trades against orderbook updates correctly; second-level timestamps collapse fast sequences into ambiguous ordering, which breaks replay determinism later. Get this field list right and the rest of the pipeline, from normalization to backtesting, inherits a solid foundation.

2. How to access scalar markets data: APIs, streaming, and exports

Three transport patterns cover almost every integration need, and most production systems end up using all three at once.

1. REST for metadata and historical snapshots, where request volume is low but payload completeness matters.

2. WebSocket for top-of-book and trade streaming, where latency matters more than payload size.

3. Bulk exports in Parquet or similar columnar formats for large-scale backtests that need months of history in one pull.

Polymarket’s order book endpoint illustrates the REST side well: it returns aggregated bid and ask arrays with configurable depth, typically defaulting to three levels and capping at ten, alongside instrument state and requires bearer-token authentication. Rate limits on these endpoints push most serious integrations toward exponential backoff rather than fixed-interval polling, and a fetch cadence tied to market volatility, more frequent during active hours, sparser overnight, keeps you inside limits without starving your models of fresh state.

A workable integration recipe: subscribe via websocket for top-of-book, pull periodic full snapshots for deeper book reconstruction, and combine trade prints with bulk exports for historical replay. Our own developer guide to real-time and historical access walks through this pattern in more detail.

Pro Tip: Cache orderbook snapshots locally and diff against streamed updates; it catches silent websocket drops before they corrupt your book state.

3. Normalizing cross-venue scalar data and canonical IDs

Polymarket, Kalshi, and Limitless each expose scalar markets with different field names, different settlement conventions, and different ways of describing the same underlying question. Without a canonical schema, joining feeds across venues turns into a matching problem you solve badly, over and over.

• Build canonical IDs from a venue tag, normalized numeric endpoints, and an internal slug, so the same underlying market resolves to one identifier regardless of source.

• Normalize price to implied probability on a 0 to 1 scale, and handle tick-size differences explicitly rather than rounding silently.

• Harmonize metadata fields including settlement window, resolution rules, and question text, since wording differences across venues otherwise look like different markets.

• Detect cross-venue equivalents algorithmically, but retain provenance on every record so you can trace a normalized field back to its original source if something looks wrong.

This is the step most teams underestimate, and it is also the step that makes Smart Money tracking and arbitrage signals possible once it is done right. Our guide to canonical IDs for cross-venue data goes deeper on the matching logic.

4. Orderbook, fee models, and execution realism for agents and algos

A forecast is worthless to an algo if the execution layer cannot translate it into a realistic fill. Modeling that realism requires data most teams don’t collect by default.

• Maker and taker fees differ by venue and sometimes by market, so per-fill fee accounting has to be tracked at the trade level, not assumed as a flat rate.

• Fill probability should be modeled from historical fills against orderbook depth at the time, not assumed as instant and complete.

• Slippage and latency between signal generation and order placement erode edge fast, especially in thin scalar markets.

• Fee schedules change over time, so replay systems need versioned fee models attached to each historical period, not just the current schedule applied retroactively.

Execution realism dominates forecasting gains more often than teams expect. Research on deterministic replay frameworks finds that fee-aware simulation and maker/taker semantics materially affect realized profit and loss and can swamp the improvements from a better forecasting model. A sharper signal with a naive execution assumption often underperforms a mediocre signal with realistic fill modeling. Our orderbook data guide for developers covers depth-aware fill modeling in practical terms.

5. Backtesting and replay: episode formats that stay deterministic

Deterministic replay is what separates a backtest you can trust from one that quietly lies to you. PredictionMarketBench standardizes this with a four-file episode format that is worth adopting directly.

1. metadata.json: market definition, numeric endpoints, resolution rules, and the fee model version in effect.

2. orderbook.parquet: sequenced orderbook updates with UTC timestamps for exact state reconstruction.

3. trades.parquet: every trade print with side, size, price, and sequence number for tie-breaking against orderbook events.

4. settlement.json: the final settlement value and the timestamp the market closed.

Unifying the timeline matters as much as the files themselves: UTC timestamps throughout, sequence numbers to resolve same-millisecond ties, and an explicit fee-model version attached to the episode rather than inferred from the run date. Track profit and loss, drawdown, total fees, slippage, fill ratio, and forecast skill metrics on every replay, since those six numbers tell you whether a strategy’s edge is real or an artifact of unrealistic fills. Our backtesting walkthrough using historical snapshots applies this episode format to a worked example.

6. Engineering practices for AI agents consuming scalar data

The gap between a good forecast and an executed trade is where most agent systems fail, and closing it is an engineering problem, not a modeling one.

• Separate the forecaster from a deterministic execution layer that enforces position sizing, hard caps, and stop-loss rules independently of model confidence.

• Size positions with quarter or fractional Kelly against a hard USD or USDC cap per position, never scaling purely off model-reported confidence.

• Budget for latency between signal and order, cache aggressively on metadata that rarely changes, and respect venue rate limits with backoff rather than retries.

• Keep audit logs of every decision, run monitoring and alerting on fill ratios and slippage, and run a paper mode alongside live trading before promoting any strategy.

Research on belief-to-trade architectures finds that execution layers enforcing deterministic sizing and risk constraints produce better risk-adjusted returns in replay than forecast-only sizing, largely because they prevent overleveraging on model errors. A canary market and a daily loss limit catch most of the failure modes before they become expensive. Teams building this kind of agent infrastructure sometimes bring in outside engineering support; Bitrupt’s AI and data engineering practice builds production LLM and agent pipelines for exactly this kind of work.

Pro Tip: Run new strategies against a canary market with real capital but a tiny cap before scaling position sizes; a model that looks great on 2026 replay data can still behave unpredictably on live orderbook latency.

Where belief meets execution in scalar markets

The hardest problem in this space isn’t forecasting. It’s the belief-to-trade gap: the distance between a model that knows something and a system that acts on it without bleeding the edge away in fees and slippage. Research on autonomous agent wallets finds agents improve price discovery on text-heavy decisions but lose their edge on numerically intensive tasks, a reminder that forecasting strength is domain-specific. Our own feeds span roughly 1.5 terabytes of historical data across the major venues, with Smart Money wallet tracking built on top. The immediate priority for most teams: get canonical IDs and fee versioning right before touching sizing logic.

— Dean

How the Assymetrix Data API covers these needs

We built our Data API at Data around the exact pipeline this guide describes: one integration instead of three separate venue connections, with normalization already handled.

• Unified canonical IDs across venues so cross-venue joins don’t require custom matching logic.

• Real-time streaming and historical bulk access drawn from a large dataset spanning significant rows of trading activity.

• Smart Money wallet tracking and cross-venue arbitrage signals layered on top of the same normalized schema.

Developers can start with our prediction market API documentation to see endpoint structure and authentication before wiring up a first integration.

FAQ

What makes scalar markets different from binary markets?

Scalar markets settle to a numeric value inside a range, while binary markets settle to yes or no. Data for scalar markets needs the numeric endpoints and resolution rules captured explicitly, since the settlement value itself carries information a binary outcome doesn’t.

Which venues does scalar markets data typically cover?

Coverage typically spans Polymarket, Kalshi, and Limitless, each with distinct data characteristics such as orderbook depth conventions and settlement timing. Normalizing across these three is the common starting point for cross-venue analysis.

What’s the minimum data needed for a deterministic backtest?

At minimum you need orderbook snapshots, trade prints, and settlement records tied together with UTC timestamps and sequence numbers, following formats like the one described in PredictionMarketBench. Fee-model versioning should be included so replays stay comparable as venue fee schedules change.

How do I handle rate limits across multiple venue APIs?

Use bearer-token authentication with exponential backoff rather than fixed polling intervals, and adjust fetch cadence to market activity rather than a flat schedule. Bulk exports reduce rate-limit pressure significantly for historical work compared to repeated REST calls.

Does Assymetrix offer a unified API for all three venues?

Yes, our Data API aggregates Polymarket, Kalshi, and Limitless into a single schema with canonical IDs, documented at Assymetrix. Pricing details are available on request through that page.

Sources

• PredictionMarketBench: A SWE-bench-Style Framework for Backtesting Trading Agents on Prediction Markets

• Polymarket API — Get order book

• The Performance and Risks of Autonomous LLM Agents in Financial Prediction Markets — 12 August 2026 Codex Revision