Learn & Explore

Latest Insights

Latest Insights

Stay up to date with the latest insights, guides, research, and prediction market trends.

Stay up to date with the latest insights, guides, research, and prediction market trends.

Build Copy Trading for Prediction Markets with Canonical Data & Rules

Build Copy Trading for Prediction Markets with Canonical Data & Rules

Programmatic copy trading for prediction markets means running a deterministic trading layer on top of canonical, cross-venue data, not mirroring a single trader’s clicks. Building one requires five components: normalized data across venues, semantic matching that resolves identical questions into one canonical ID, a belief-to-trade layer that turns forecasts into sized orders, deterministic execution and risk controls, and a replayable backtest harness. Cross-venue aggregators supply the normalized data layer this architecture depends on.

TL;DR:

  • Ensuring normalized, cross-venue data with canonical IDs, price equivalence, and explicit multi-outcome handling is essential for accurate backtesting and trading.

  • Deriving signals like trader skill scores, divergence metrics, and semantic match confidence significantly improves trading decisions and downside management.

  • Modeling fees, order queue mechanics, and settlement risks explicitly in simulation reduces overestimation of strategy profitability.

  • Automating belief-to-trade rules with deterministic execution and risk caps outperforms forecast-only approaches and minimizes manual intervention.

  • Comprehensive, historical bulk data exports and strict event ordering are crucial for reliable backtesting and assessing true trading performance.

Assymetrixassymetrix.comBuild With Unified Market DataAssymetrix gives traders, developers, and AI agents unified cross venue prediction market data through a single Data API integration.Explore Assymetrix

Table of Contents

  • What Data and Signals Does Copy Trading Need?

  • Architecture for a Copy-Trading Pipeline

  • How to Integrate Feeds and Backtest Deterministically

  • Risk and Execution Considerations That Break Naive Systems

  • Legal and Regulatory Considerations for Copy Trading

  • Psychological and Behavioral Factors in Copy Trading

  • Technological Platforms and Tools for Copy Trading

  • What the Research Actually Tells Builders

  • How Assymetrix Maps to This Architecture

  • FAQ

  • Sources

What Data and Signals Does Copy Trading Need?

A copy-trading system is only as good as the feed under it. At minimum, you need per-market fields: market ID, question text, resolution rules, cutoff timestamp, oracle ID, tick size, fee schedule, full orderbook snapshots, trade events, and timestamps normalized to UTC. Skip any of these and your backtests will disagree with live results the first time a market resolves ambiguously.

Normalization is where most homegrown pipelines break. You need a canonical ID strategy that maps the same real-world event across Polymarket, Kalshi, and Limitless to one identifier, USD-equivalent pricing so spreads are comparable, a unified time series despite each venue’s own tick cadence, and explicit handling for multi-outcome markets that partition probability across more than two states.

On top of raw data, derived signals are what make the system worth building, including the benefits of automated trade signals for smarter trading:

  • Smart Money wallet leaderboards that rank addresses by realized edge rather than volume alone.

  • Trader Skill Scores that separate consistent forecasters from lucky streaks.

  • Cross-venue spread and divergence metrics that flag when the same event prices differently on two platforms.

  • Semantic match confidence scores that quantify how sure your matching layer is that two listings describe the same event.

Data quality heuristics matter as much as the fields themselves: apply liquidity thresholding before trusting a quoted price, define staleness windows per venue, enforce a minimum depth per side before sizing a position, and flag markets whose resolution rules are worded ambiguously.

A hybrid statistical and LLM semantic filtering pipeline improved win rates and reduced the average size of losing trades on tested Kalshi markets, according to research on LLM semantic filtering for lead-lag trading. That single layer of semantic verification changes the shape of your downside, not just your hit rate.

Architecture for a Copy-Trading Pipeline

Four layers do the work, each with a narrow job and a clean interface to the next.

  1. Canonical data layer. Ingestion pipelines pull orderbooks, trades, and resolution events from each venue, deduplicate them, and assign canonical IDs through semantic matching. This layer exposes normalized REST and WebSocket APIs for live consumption and bulk exports for backfill, so the same schema serves both your production bot and your historical research.

  2. Belief-to-trade layer. This is where a forecast becomes an order. It applies candidate selection (which markets clear your confidence threshold), position sizing through fractional Kelly or another constrained rule, and deterministic stake logic so the same inputs always produce the same trade. Soft and hard exposure caps sit here too, capping single-market and portfolio-wide risk before anything reaches the execution layer.

  3. Execution and risk. This module decides maker versus taker order placement, whether to use POST_ONLY or GTC, and how to route for the best fee-adjusted price. It enforces slippage guardrails, retry and cancel policies for stale quotes, and tracks capital locked against pending settlement or disputed resolutions, since that capital is not available for new positions.

  4. Monitoring and archive. Every trade, snapshot, and wallet interaction gets logged for reproducible replay later. Anomaly detectors watch for coordinated wallet clusters acting in lockstep, which often precede manipulation attempts rather than organic signal.

Pro Tip: Persist a “pulse” artifact with every trade decision: the data snapshot, any external evidence consulted, and the pre-trade thesis, so a replay months later can reconstruct exactly why the system acted.

For a concrete walkthrough of wiring orderbook data into execution logic, our guide to building a Polymarket bot covers the data, signal, and execution stages in sequence.

How to Integrate Feeds and Backtest Deterministically

Integration starts with episode construction: replay orderbook updates, trade events, and settlement events together in strict UTC order with sequence numbers, so no event can be processed out of turn. Without strict ordering, a backtest can “see” a price move before the trade that caused it, producing results that never happen live.

Your simulator needs to model the mechanics that actually move P&L: maker and taker fee schedules, order queue semantics (who gets filled first at a given price level), deterministic fills rather than randomized ones, and settlement modeling that accounts for dispute-era lockups where capital is frozen pending resolution.

Once the simulator is in place, track metrics that reveal whether a strategy is real or a backtest artifact:

  • Edge after fees, not raw mid-price edge, since fee schedules can erase an apparent advantage.

  • Realized P&L and equity curves across the full replay window, not a cherry-picked segment.

  • Maximum drawdown, which tells you how much capital stress the strategy can survive.

  • Hit rate against forecast calibration, confirming your confidence scores mean what they claim.

  • Execution slippage decomposition, separating fee cost from timing cost from queue-position cost.

A sensible rollout sequence is a small-scope replay on high-liquidity events first, then sensitivity sweeps across latency, fee, and liquidity assumptions, and only then a full-sample reproducible run across your entire history. Deterministic, event-driven replay benchmarks that model maker and taker semantics, such as PredictionMarketBench, exist specifically so two teams testing different agents can compare results on identical ground. Our orderbook parsing reference walks through the field-level details this stage depends on.

Risk and Execution Considerations That Break Naive Systems

Fees decide profitability more often than signal quality does. At a 50 cent price with a 7% taker fee, a trade needs more than 53.5% edge just to break even, according to PredictionMarketBench’s fee analysis, and maker orders carry substantially lower costs than taker orders in the same schedule. A strategy that looks profitable on mid-price alone can flip to a loss the moment real fee-aware execution is applied.

Settlement and oracle divergence is a second failure mode. Cross-platform arbitrage analysis found an oracle disagreement rate of roughly 5.7% to 6.2%, meaning a hedge that looks risk-free on paper carries real counterparty exposure while capital sits locked awaiting resolution. Risk models need an explicit capital-lock horizon, not just a price-based VaR figure.

A third failure mode is semantic non-fungibility: two venues can list what looks like the same question with subtly different resolution rules, producing price deviations averaging 2% to 4% that look like arbitrage but are not. Mitigations worth building into any system:

  • Two-pass semantic matching, generating high-recall candidates by embedding similarity and temporal proximity, then verifying structurally with an LLM.

  • Coordinated wallet detection, flagging groups of addresses that trade in persistent lockstep.

  • Exposure caps and watchlists on flagged wallets or markets pending manual review.

  • Delayed execution windows on low-confidence semantic matches rather than firing immediately.

Legal and Regulatory Considerations for Copy Trading

Regulatory treatment of prediction markets varies by venue structure and jurisdiction, and that variance carries directly into any automated system built on top of them. Some venues operate as regulated derivatives exchanges under commodities oversight, while others run as offshore or decentralized platforms with different compliance postures. A copy-trading system that routes capital across venues inherits each venue’s own regulatory status for that leg of the trade, so treating “prediction markets” as one uniform legal category is a mistake that shows up later as an operational surprise.

For developers, the practical questions are narrower than broad market legality: does the venue’s terms of service permit automated or algorithmic order placement, does API access require a specific account tier or disclosure, and does the venue restrict residents of certain jurisdictions from trading specific contract types. These terms change without much notice, so a production system should check venue terms programmatically where possible rather than assuming last quarter’s rules still apply.

Tax treatment of realized gains also differs by jurisdiction and by whether the activity is classified as trading or gambling, a distinction regulators have not settled uniformly. None of this substitutes for legal review specific to where you operate and where your users are based. Build the engineering assumption that compliance requirements are venue-specific and time-varying, and design your execution layer to accept per-venue rule changes without a code rewrite.


Legal and Regulatory Considerations for Copy Trading — overview diagram

Psychological and Behavioral Factors in Copy Trading

Automating the belief-to-trade layer removes manual hesitation, but it does not remove behavioral risk from the system design itself. The most common failure is anchoring a sizing rule to a single backtest window that happened to favor the strategy, then treating that window’s Kelly fraction as universal truth rather than as a sample estimate with its own uncertainty.

A second pattern is overfitting confidence thresholds to past coordinated-wallet behavior that will not repeat identically. Wallets that showed skill in one market regime can revert once liquidity conditions or the pool of counterparties shifts, and a system tuned too tightly to historical Smart Money signals will lag that shift rather than adapt to it.

A third factor is the temptation to override deterministic rules manually after a losing streak, which defeats the purpose of building a deterministic layer in the first place. Research on belief-to-trade architectures found that a deterministic, auditable trading layer outperformed forecast-only approaches precisely because it removed discretionary intervention from the sizing and execution decision. Any team running a copy-trading agent should treat manual override as a logged, reviewed exception, not a routine adjustment, and should revisit sizing assumptions on a fixed schedule rather than in reaction to a single bad week.

Technological Platforms and Tools for Copy Trading

A working copy-trading stack has three layers of tooling, and conflating them is a common design mistake. The first is venue-native APIs: Polymarket, Kalshi, and Limitless each expose their own endpoints for orderbooks, trades, and account actions, with different schemas, rate limits, and authentication models. Building directly against three separate APIs means maintaining three separate integrations that drift out of sync every time one venue changes its schema.

The second layer is cross-venue aggregation and intelligence, which normalizes those three schemas into one canonical feed, resolves semantic matching across venues, and surfaces derived signals like wallet skill scores and arbitrage spreads without requiring you to rebuild that logic from raw trade data. This is the layer most development time goes to when teams build in-house, and it is also the layer most prone to silent bugs, since a bad canonical match looks like valid data until a trade settles unexpectedly.


Three venue feeds normalized into one canonical layer

The third layer is execution and backtesting infrastructure: the order router, the risk engine, and the deterministic replay simulator described earlier in this piece. Open-source and research-grade tools exist for parts of this stack, including event-driven replay benchmarks and semantic matching frameworks, but production systems typically combine a licensed data layer with custom execution logic tuned to the operator’s own risk tolerance and capital base.

What the Research Actually Tells Builders

The clearest finding across recent prediction market research is that forecasting skill alone does not produce returns. The belief-to-trade architecture study found that a deterministic trading layer enforcing sizing and execution rules was the only tested policy to post a positive risk-adjusted return in a controlled replay, while forecast-only agents did not. Semantic filtering research reinforces the same lesson from a different angle: verification layers do not just catch noise, they cut the size of losing trades.

The practical prescription follows directly: pair a forecasting model with deterministic trading rules and fee-aware execution modeling, and evaluate the combination on a reproducible replay harness rather than a single historical run. Our AI agent architecture guide extends this reasoning into agent-specific design patterns.

— Dean

How Assymetrix Maps to This Architecture

Everything described above needs a canonical data layer underneath it, and that is the layer we built. A data API can normalize feeds across Polymarket, Kalshi, and Limitless into one schema, resolve semantic matching into canonical IDs to avoid false arbitrage from mismatched question text, and provide historical bulk exports large enough for building reproducible backtests.


Assymetrix

For teams assembling the components in this piece, the integration list looks like this:

  • Normalized REST and WebSocket feeds covering multiple venues through unified access.

  • Canonical IDs that resolve semantically equivalent markets.

  • Wallet tracking and trader skill scores as inputs to a belief-to-trade layer.

  • Historical bulk exports sized for full-sample backtests rather than thin sample windows.

Check our Data API documentation to see the endpoints and schema in full.

FAQ

What is copy trading in prediction markets for developers?

For developers, copy trading means building a deterministic system that detects skilled trader or wallet behavior across venues and replicates it through sized, rule-based orders, not manually mirroring a single account. The components are canonical cross-venue data, a belief-to-trade sizing layer, and fee-aware execution.

How do I detect arbitrage across prediction market venues?

Reliable detection starts with semantic matching that resolves identical questions into one canonical ID, since naive text matching produces false positives from semantically non-fungible listings. Research on semantic non-fungibility found persistent price deviations averaging 2% to 4% between venues even on supposedly matched markets, which a two-pass embedding-plus-LLM verification step helps filter out.

Why do backtests overstate copy-trading profitability?

Most overstated backtests ignore maker and taker fee schedules and order queue semantics, both of which change realized P&L substantially. A deterministic, event-driven replay that models fees explicitly, such as the PredictionMarketBench approach, shows that a position needing over 53.5% edge to break even at a 50 cent price with a 7% taker fee can look profitable under a naive mid-price backtest and unprofitable once real execution costs are applied.

What data do I need before building a copy-trading bot?

At minimum you need normalized orderbook snapshots, trade events, resolution rules, and oracle identifiers across every venue you trade, all timestamped to UTC with a canonical ID scheme linking equivalent markets. Our cross-venue data feed guide details the schema fields this requires.

Does Assymetrix provide historical data for backtesting?

Yes, our Data API includes historical bulk exports spanning multiple terabytes across hundreds of millions of rows of cross-venue trading activity, suitable for full-sample reproducible backtests. Pricing and access details are available on our Data API page.

Sources

  • LLM as a Risk Manager: LLM Semantic Filtering for Lead–Lag Trading in Prediction Markets

  • PredictionMarketBench: deterministic replay benchmark for evaluating trading agents on prediction markets

Prediction Market Developers: Detect Microsecond Latency Arbitrage

Prediction Market Developers: Detect Microsecond Latency Arbitrage

Latency arbitrage is the practice of exploiting microsecond differences in price or quote dissemination to trade ahead of slower participants, and it transfers value from liquidity providers and slower traders to whichever actor processes and acts on information fastest. Gains concentrate among low-latency firms with direct feeds and co-located infrastructure; costs land on market makers and anyone trading through consolidated or delayed data. For algorithmic agents and data integrations, the immediate implication is simple: measure your feed latency and verify your timestamps before you trust any signal.

TL;DR:

  • Latency arbitrage profits can reach billions of dollars, but estimates vary widely depending on market data and the scope of analysis.

  • Strategies rely on microsecond delays between exchange feeds, with co-location and network routing playing critical roles in advantage.

  • Implementing safeguards like cross-checking multiple feeds and verifying timestamps can help reduce exposure to latency-based trading risks.

  • Normalized, real-time cross-venue data and divergence measurement are essential for identifying opportunities and avoiding stale information.

  • Speed alone is not enough; trading models that interpret signals more accurately can outperform faster ones in high-frequency trading environments.

Assymetrixassymetrix.comBuild With Unified Market DataAssymetrix gives developers and algorithmic agents unified cross-venue prediction market data through a single Data API integration.Explore the Data API

Table of Contents

  • How Market Architecture Creates Latency Gaps

  • What the Research Says About Profits and Market Harm

  • How Latency Arbitrageurs Actually Operate

  • Exchange Protections and Developer-Side Defenses

  • Detecting Latency Divergence Across Prediction Market Venues

  • What Practitioners Should Prioritize

  • Trial the Assymetrix Data API for Cross-Venue Testing

  • FAQ

  • Sources

How Market Architecture Creates Latency Gaps

Latency arbitrage exists because no market distributes price information instantly or uniformly. In US equities, the Securities Information Processor (SIP) aggregates quotes from every exchange and publishes a consolidated National Best Bid and Offer, but that aggregation step takes time. Direct feeds from individual exchanges reach co-located servers before the SIP ever recalculates NBBO, and that gap, often a few hundred microseconds to a few milliseconds, is where pickoff trades happen.

Several layers compound this delay:

  • Geographic and routing latency: physical distance between venues (the Albany-to-Chicago link cited in market design research is significant enough to create fixed, unavoidable propagation delay measured in the order of milliseconds) creates fixed, unavoidable propagation delay.

  • Co-location advantage: servers placed inside exchange data centers shave microseconds that remote participants cannot recover regardless of code quality.

  • Feed-processing pipelines: parsing, normalizing, and timestamping raw exchange messages introduces variable software latency that differs firm to firm.

  • Market fragmentation: the same asset trading across multiple venues (stock exchanges, or Polymarket, Kalshi, and Limitless in prediction markets) means price discovery never happens in one place at one instant.

Tactic taxonomy follows from these gaps. Pickoffs hit stale quotes before they update. Hedged cross-venue arbitrage buys on one venue and sells an equivalent position on another before prices converge. News-tick arbitrage races to trade on a headline or data release before slower feeds process it. Masking disguises order flow intent, often through order-splitting or iceberg orders, to avoid tipping off other latency-sensitive participants. Each tactic depends on the same underlying resource: knowing the true price before the rest of the market does.

What the Research Says About Profits and Market Harm

Published estimates of latency arbitrage profits vary enormously, which itself is a finding worth taking seriously. Aggregated historic estimates cited in the agent-based model literature on fragmented markets put cumulative figures as high as $21 billion, while other analyses covering narrower time windows conclude latency arbitrage is not a dominant profit source at all. The spread between these numbers comes down to methodology: what counts as an arbitrage trade, which venues are included, and over what period.

Agent-based modeling shows the answer depends on who you simulate. The same research comparing Zero Intelligence Constrained (ZIC) agents against Zero Intelligence Plus (ZIP) agents found that more adaptive trading agents can reverse conclusions drawn from simpler models about whether fragmentation helps or harms overall market efficiency.

Three metrics matter most for anyone trying to quantify exposure in their own market:

  • NBBO divergence time: how long a quote remains stale relative to the fastest available price.

  • Quote cancellation rates: a spike often signals market makers pulling back ahead of anticipated adverse selection.

  • Spread shifts: widening spreads around volatile events frequently reflect liquidity providers pricing in latency risk.

Regulatory filings add a narrower, more concrete data point: exchange analyses of targeted quote protections report activation windows measured in fractions of a percent of total trading time, a figure covered in the next section.

How Latency Arbitrageurs Actually Operate

Building a latency arbitrage strategy is an exercise in budgeting microseconds against decision quality, not just chasing raw speed.

  1. Pickoff and hedge execution: the trader monitors a fast feed for a price move, fires an order against a stale quote on a slower venue, and simultaneously hedges the resulting position on a third venue, all within a latency budget typically under a few milliseconds end to end.

  2. News-tick sequencing: the strategy parses a headline or data release, classifies its market impact, and routes an order before consolidated feeds or human traders can react, requiring tight coordination between parsing latency and order gateway latency.

  3. Masking and obfuscation: orders are split across venues or sizes to avoid revealing the full position, reducing the risk that other latency-sensitive algorithms detect and front-run the strategy itself.

The operational risk in all three is real: masking can trigger exchange surveillance flags, and pickoff strategies that misjudge feed staleness can end up hedging against a price that has already moved again.

Pro Tip: Benchmark your strategy’s win rate against a naive “fastest feed wins” baseline before adding complexity. If a smarter but slower model beats raw speed, you have found your actual edge.

That last point matters more as AI agents enter latency-sensitive trading. Recent benchmark work on latency-quality tradeoffs in trading agents found that faster inference is not automatically better. An agent that trades a few milliseconds slower but interprets signals more accurately can outperform a faster, lower-quality model in simulated high-frequency conditions.

Exchange Protections and Developer-Side Defenses

Market design has produced several direct responses to latency arbitrage, each with measurable tradeoffs.

IEX’s D-Limit and ORP are formulaic indicators that temporarily protect displayed liquidity when the system detects a likely stale quote. Regulatory filings and SEC commentary on these order-type protections report that these protections activate during a vanishingly small fraction of trading time, in the range of 0.021% to 0.001% depending on the metric used, yet still meaningfully reduce adverse selection against resting orders.

A more structural proposal, examined in theoretical work on synchronized execution, lets traders specify an execution time T after order arrival, so competing orders land simultaneously rather than in a speed race. Simulation results show this can sharply reduce arbitrage incidence, though it requires coordinated adoption across venues to work.

Developers and algorithmic traders do not need to wait on exchange-level change:

  • Cross-check prices across at least two independent feeds before acting on any single data source.

  • Verify timestamp integrity with synchronized clocks (PTP or NTP) rather than trusting feed-reported times.

  • Add execution jittering to avoid predictable, exploitable order timing patterns.

  • Set adaptive thresholds that widen during detected high-divergence windows rather than using static spread limits.

Pro Tip: Log NBBO divergence time and quote cancellation rate as first-class telemetry in your execution pipeline, not just fill rate and P&L; they are the earliest warning signs of adverse selection. A practical orderbook integration checklist covers the timestamp and sequencing fields worth tracking from day one.

Detecting Latency Divergence Across Prediction Market Venues

Prediction markets fragment the same way equities do, just across a smaller set of venues. The same event can trade at meaningfully different implied probabilities on Polymarket, Kalshi, and Limitless at the same moment, and without canonical event IDs mapping equivalent markets across venues, a divergence signal is just noise.


Three venue streams mapped for divergence detection

Data APIs can normalize real-time and historical feeds across prediction market venues into a single schema, so a price gap between venues appears as a comparable, timestamped data point rather than three separate formats to reconcile by hand. Some platforms surface arbitrage signals and Smart Money wallet tracking directly on top of normalized data layers, which means a developer testing for latency-driven divergence does not need to build venue-specific parsers first.

A reasonable detection workflow looks like this:

  • Pull normalized order book snapshots across venues using canonical IDs to confirm you are comparing the same event.

  • Measure divergence duration and magnitude against historical baselines, following the backtest patterns in our quant strategy guide to prediction market arbitrage.

  • Feed arbitrage signals into agent decision logic as a confirmation layer, not a sole trigger, to avoid acting on stale or one-sided data, a pattern covered in our guide to feeding data into AI trading agents.

What Practitioners Should Prioritize

Measurement comes before optimization. Establish a reproducible backtest baseline on real cross-venue data before tuning any latency-sensitive strategy, because an unmeasured edge is indistinguishable from noise. Signal and model quality improvements tend to beat marginal speed gains once you are past the point of catastrophic feed staleness, and the research on agent latency-quality tradeoffs backs that judgment. Transparency between exchanges, data providers, and trading teams about feed timing is the cheapest risk reduction available.

— Dean

Trial the Assymetrix Data API for Cross-Venue Testing

Detecting latency-driven divergence requires normalized data you can trust, not three separate venue integrations to reconcile by hand. Some prediction market data APIs deliver canonical IDs, normalized real-time and historical feeds, and arbitrage signals across major prediction market venues through a single integration, built on substantial historical trading data.


Assymetrix

Start with the Data API landing page to see endpoint documentation and trial access, or review the cross-venue historical dataset guide for coverage details before you integrate.

FAQ

Is latency arbitrage illegal?

Latency arbitrage itself is generally legal in most regulated markets; it exploits publicly available market structure rather than privileged inside information. Regulators have instead focused on exchange-level countermeasures, such as IEX’s D-Limit order type, rather than banning the practice outright.

What is latency arbitrage trading?

Latency arbitrage trading means using faster data access or order execution to trade ahead of slower participants before quotes update across all venues. It typically relies on direct exchange feeds, co-location, and optimized processing pipelines rather than any informational advantage about the asset itself.

What is a good latency for trading?

There is no single universal benchmark since the “good” latency depends on the strategy and venue, but pickoff and hedge strategies generally need end-to-end execution budgets under a few milliseconds to remain competitive. Slower but higher-quality decision models can still outperform in latency-quality benchmark research, so raw speed is not the only variable worth optimizing.

What are the three types of arbitrage?

Common classifications include spatial arbitrage (the same asset priced differently across venues), temporal or statistical arbitrage (price relationships expected to converge over time), and latency arbitrage (speed-based exploitation of quote staleness). These categories overlap in practice, since a latency arbitrage trade is often also a spatial arbitrage trade executed before prices converge.

Does latency arbitrage increase trading costs for liquidity providers?

Evidence suggests latency arbitrage contributes to wider spreads and more cautious quoting from market makers who adjust pricing to account for adverse selection risk. The magnitude of this effect is contested in the agent-based modeling literature, where results depend heavily on how realistically the simulated trading agents behave.

Sources

  • On Market Design and Latency Arbitrage (arXiv:2202.00127)

  • IEX filings and SEC commentary on ORP/D-Limit

  • Agent-Based Model Exploration of Latency Arbitrage in Fragmented Financial Markets (Duffin & Cartlidge)

  • Win Fast or Lose Slow: Balancing Speed and Accuracy in Latency-Sensitive Decisions of LLMs

Reproducible Brier Audits for Prediction Markets and Traders

Reproducible Brier Audits for Prediction Markets and Traders

The Brier score is the mean squared error between a predicted probability and the realized outcome, and lower values mean better calibrated forecasts. It is the standard, decomposable metric for evaluating prediction-market probabilities, because it rewards confident correct calls and penalizes confident wrong ones on a continuous 0 to 1 scale. For researchers and quants, it is the starting point for any serious accuracy audit.

TL;DR:

  • A Brier score near zero signifies well-calibrated and discriminative forecasts, while around 0.25 indicates no skill beyond random guessing.

  • Reliable discrimination on rare events requires over 1,000 samples and careful definition matching to avoid misleading scores.

  • Cross-venue canonicalization and comprehensive historical data are essential for accurate and reproducible Brier score audits.

  • Monitoring the Brier score over time and across probability bins helps detect calibration drift and model degradation in prediction markets.

  • Comparing scores using the Brier skill score clarifies whether market forecasts truly outperform naive baseline predictions.

AssymetrixBuild More Reproducible Market AuditsAssymetrix provides unified historical and real-time prediction market data across Polymarket, Kalshi, and Limitless through one Data API.Visit Assymetrix

Table of Contents

  • The Brier score formula and how it fits among scoring rules

  • Why Brier score works well for market evaluation

  • Computing Brier score: hand calculation and code

  • What counts as a good Brier score in prediction markets

  • Where Brier score misleads: rare events and sample size

  • Building Brier scoring into backtests and live monitoring

  • Cross-venue data as the backbone of reproducible Brier audits

  • A researcher’s take on using Brier score well

  • A practical next step: the Assymetrix Data API

  • FAQ

  • Sources

The Brier score formula and how it fits among scoring rules

For a binary outcome, the Brier score is the mean of the squared differences between each forecast probability and the actual result, coded as 1 for the event occurring and 0 otherwise. Across N forecasts, that is the average of (forecast minus outcome) squared, which puts the score on a 0 to 1 scale where 0 is a perfect forecast and 1 is the worst possible one. This binary form already divides by N, so no further rescaling is needed for a single-outcome market.

The original multiclass formulation, as described on the Brier score Wikipedia page, sums squared errors across all possible categories rather than just one, which produces values on a 0 to 2 scale instead of 0 to 1. This is the source of a recurring confusion among developers porting code between binary and multiclass contexts: a binary score computed with the two-category sum formula needs to be divided by two to land back on the familiar 0 to 1 scale. Keeping track of which convention a library or paper uses matters more than it should, because a score of 0.3 under one convention can mean something entirely different under the other.

The Brier score belongs to the family of strictly proper scoring rules, a property discussed in depth in Buja and colleagues’ work on loss functions for binary class probability estimation. A strictly proper rule means a forecaster cannot improve their expected score by reporting anything other than their true believed probability, which is exactly the incentive structure we want when scoring market-implied probabilities rather than a model’s internal confidence. That paper also flags link-function caveats worth knowing before treating squared-error loss as interchangeable with other proper scores like log loss.


The Brier score formula and how it fits among scoring rules — overview diagram

Why Brier score works well for market evaluation

The Brier score’s main advantage over a single accuracy number is that it decomposes into three components: uncertainty, reliability, and resolution, as laid out in the Brier score decomposition literature. Uncertainty reflects the inherent variance of the outcome itself and is fixed by the base rate. Reliability captures calibration, meaning whether a market’s 70% probabilities actually resolve “yes” about 70% of the time. Resolution captures discrimination, meaning whether the market’s probabilities vary enough across events to be informative rather than hovering near the base rate for everything.

This decomposition is what makes Brier score actionable rather than descriptive. A market with poor reliability has a systemic bias correctable with recalibration. A market with poor resolution is not differentiating outcomes at all, regardless of how well-calibrated its averages look. Log loss penalizes extreme wrong predictions far more harshly, which makes it useful for flagging catastrophic miscalibration but harder to interpret in aggregate. Rank-based metrics like AUC tell you about ordering, not about whether the stated probabilities themselves are trustworthy, which is usually the question a trader actually has.

For sizing decisions, calibration is the metric that matters: a trader deciding how much capital to commit to an edge needs to trust that a market quoting 65% really does resolve “yes” close to that often, and Brier’s reliability component is the direct, decomposable check on that trust.


Why Brier score works well for market evaluation — overview diagram

Computing Brier score: hand calculation and code

Consider three binary-outcome markets. Market A forecasts 0.70 for an event that occurs (outcome 1), Market B forecasts 0.40 for an event that does not occur (outcome 0), and Market C forecasts 0.90 for an event that occurs (outcome 1).

  • Market A: (0.70 − 1)² = 0.09

  • Market B: (0.40 − 0)² = 0.16

  • Market C: (0.90 − 1)² = 0.01

The mean of 0.09, 0.16, and 0.01 is 0.0867, which is the Brier score for this three-market sample.

For production code, scikit-learn’s brier_score_loss implements this directly:

from sklearn.metrics import brier_score_loss
y_true = [1, 0, 1]
y_proba = [0.70, 0.40, 0.90]
brier_score_loss(y_true, y_proba)
from sklearn.metrics import brier_score_loss
y_true = [1, 0, 1]
y_proba = [0.70, 0.40, 0.90]
brier_score_loss(y_true, y_proba)

This returns 0.0867, matching the hand calculation. The function includes a scale_by_half parameter controlling whether binary scores are rescaled, which matters when comparing output against papers or dashboards using the multiclass sum convention.

Pro Tip: Always confirm which scaling convention a dashboard or paper uses before comparing a Brier number across sources, since a 0 to 2 scale score will look twice as bad as the same forecast quality on a 0 to 1 scale.

The Brier skill score benchmarks a forecast against a reference, typically a naive base-rate forecast. If our three-market sample’s base rate is 2 out of 3 events occurring (0.667), a naive forecaster predicting 0.667 for every event scores (0.667−1)² + (0.667−0)² + (0.667−1)² averaged, which is 0.247.

What counts as a good Brier score in prediction markets

Markets consistently beating a naive baseline typically show measurable skill, with tighter forecasting horizons generally scoring lower (better) than longer ones, according to empirical tracking summarized on the Longterm Wiki prediction markets entry. A Brier score near 0 indicates near-perfect calibration and discrimination; a score near 0.25 is what a forecaster gets by predicting 0.5 for every binary event, meaning it reflects maximum uncertainty rather than any real skill; a score near 1 indicates confidently wrong forecasts.

Translating a raw score into a skill statement requires the Brier skill score framing introduced above. A skill score of 0% means the forecast is no better than the naive reference; 100% means perfect prediction; negative values mean the forecast is actively worse than guessing the base rate every time.

  • A skill score near 100% represents forecasts close to perfect resolution.

  • A skill score near 0% represents forecasts no better than the base rate.

  • A negative skill score flags a model or market actively underperforming a naive guess, worth investigating before trusting its signals.

These are illustrative figures for the calculation method, not claims about any specific market’s historical performance.

Where Brier score misleads: rare events and sample size

Reliable discrimination on rare events requires a much larger sample than common events do, with meteorological literature summarized on Wikipedia’s Brier score page indicating sample sizes well over 1,000 events are typically needed before rare-event Brier scores stabilize into something trustworthy.

Event definition mismatches compound the problem. A market resolving on a loosely worded condition, or one where the forecast horizon does not match the evaluation window, will produce a Brier score that reflects definitional noise rather than forecasting skill.

  • Small samples on rare events produce unstable Brier scores that shift dramatically with one or two resolutions.

  • Mismatched horizons, comparing a day-ahead forecast against a month-ahead outcome, inflate apparent error unrelated to skill.

  • Aggregating across heterogeneous event types without separating by base rate hides where the real miscalibration lives.

Mitigations include aggregating by base-rate bucket rather than pooling everything, running calibration plots across probability bins (0 to 0.1, 0.1 to 0.2, and so on) to localize miscalibration, and pairing Brier with the skill score so small-sample noise is contextualized against a reference rather than read as an absolute.

Pro Tip: Before trusting a rare-event Brier score, check the underlying event count first: fewer than a few hundred resolutions on a low base-rate category is usually too thin to draw conclusions.

Building Brier scoring into backtests and live monitoring

A reproducible Brier pipeline starts with data hygiene, since the metric is only as trustworthy as the event alignment feeding it. Canonical market IDs that persist across venues prevent the same underlying event from being double-counted when it trades on multiple platforms. Consistent resolution fields, meaning a single source of truth for how and when an event resolved, prevent silent disagreements between data sources. Snapshot cadence needs to be fixed and timestamps aligned to the evaluation horizon, not to whenever a scrape happened to run.

A practical backtest recipe follows four steps:

  1. Align each market’s probability snapshot to the exact evaluation horizon being tested, such as 24 hours before resolution.

  2. Compute the per-event Brier score for every aligned snapshot against its final resolved outcome.

  3. Aggregate per-event scores by horizon bucket to see how calibration changes as events approach resolution.

  4. Compute the Brier skill score against a naive baseline for each bucket to express the result as a skill percentage rather than a raw number.

Monitoring in production extends the same logic on a rolling basis:

  • Track a rolling Brier score over the trailing N resolved events rather than a single all-time aggregate.

  • Maintain calibration plots by probability bin to catch miscalibration concentrated in a specific range, like overconfidence above 0.8.

  • Weight or segment metrics by smart-money flow to see whether wallets with strong historical accuracy are associated with better-calibrated market prices.

  • Set alert thresholds on rolling Brier degradation so a drifting model or a stale data feed gets flagged before it silently erodes trading performance.

Compute-wise, vectorized aggregation across thousands of events outperforms row-by-row loops once a backtest spans multiple venues and horizons, and sample weighting becomes necessary when some event categories are overrepresented in a historical pull. Keeping a fixed, versioned seed dataset for any audit matters as much as the metric itself: a Brier score computed against a shifting data sample cannot be reproduced or defended later.

Pro Tip: Store the exact snapshot timestamp and canonical event ID alongside every computed Brier score, so any later audit can reproduce the number without re-querying a live feed that may have since changed.

For a structured walk-through of applying this kind of evaluation across market datasets, our prediction market accuracy guide and our backtesting guide built on large-scale price snapshots cover the alignment and aggregation steps in more detail.

Cross-venue data as the backbone of reproducible Brier audits

A Brier audit is only as reliable as the historical record feeding it, and that record has to be complete, canonical, and consistent across venues to avoid the double-counting and misalignment problems described above. We aggregate real-time and historical prediction market data across Polymarket, Kalshi, and Limitless into a unified intelligence layer, built on approximately 1.5 terabytes of historical data spanning nearly one billion rows of trading activity.

That scale matters directly for Brier work: rare-event sample-size requirements are only solvable with deep historical coverage, and cross-venue canonicalization is what prevents the same event from inflating or deflating an aggregate score when it trades in more than one place.

  • Canonical market IDs and resolved-outcome fields are structured for direct per-event Brier computation without manual reconciliation.

  • Smart Money wallet tracking and Trader Skill Scores let researchers weight or segment Brier analyses by the accuracy of the capital behind a price, not just the price itself.

  • Cross-venue arbitrage and market divergence signals surface where two venues disagree on the same canonical event, a useful flag before trusting either venue’s calibration in isolation.

A researcher’s take on using Brier score well

Brier score is a diagnostic, not a verdict. The number that matters is not a single aggregate but the trend of a rolling score across enough resolved events to be statistically meaningful, with clear event definitions so the denominator means what you think it means. Use it to check calibration, then pair it with a decision-focused metric, since a well-calibrated market can still offer poor risk-adjusted trading edges. Run backtests routinely rather than trusting one historical snapshot, because calibration drifts as market composition and participant behavior change.

— Dean

A practical next step: the Assymetrix Data API

Running the workflows above at scale requires canonical event IDs, full snapshot history, resolved outcomes, and Smart Money flags in one schema rather than stitched together from multiple venue APIs. Our Data API provides exactly that structure for Brier audits across Polymarket, Kalshi, and Limitless.


Assymetrix

For a methodology comparison from outside the prediction-market space, PennyStockScout’s scoring methodology outlines a similar data-driven evaluation approach worth a look. To start building reproducible Brier pipelines on real cross-venue history, check the API documentation and example datasets at Data.

FAQ

What is considered a good Brier score?

A Brier score near 0 indicates strong calibration and discrimination, while a score near 0.25 reflects no better performance than always guessing 0.5 on a binary event. Context matters more than the raw number: comparing against a Brier skill score baseline tells you whether a given score represents real skill or just a favorable base rate.

What does Brier score calculate?

The Brier score calculates the mean squared difference between a forecast probability and the actual binary outcome, coded as 1 or 0. It is a strictly proper scoring rule, meaning a forecaster has no incentive to report anything other than their true believed probability.

Can you actually make money on prediction markets?

Trading prediction markets profitably depends on identifying mispriced probabilities relative to true outcome likelihood, which is exactly what calibration metrics like Brier score are designed to audit. Edge comes from systematically better-calibrated forecasts than the market’s current price, not from the existence of the market itself.

What are the two major prediction markets?

Polymarket and Kalshi are widely referenced as major prediction market venues, alongside platforms such as Limitless that have grown in the same space. Each venue has its own liquidity, participant base, and resolution conventions, which is part of why cross-venue canonicalization matters for any accuracy comparison.

How do you compute Brier score in Python?

Using scikit-learn, brier_score_loss takes true binary outcomes and predicted probabilities and returns the mean squared error directly. The function’s scale_by_half option controls whether the result follows the 0 to 1 binary convention or the 0 to 2 multiclass sum convention.

Sources

  • Brier score — Wikipedia

  • brier_score_loss — scikit-learn documentation

  • Loss Functions for Binary Class Probability Estimation and Classification: Structure and Applications — Buja et al.

Reproducible Brier Audits for Prediction Markets and Traders

Reproducible Brier Audits for Prediction Markets and Traders

The Brier score is the mean squared error between a predicted probability and the realized outcome, and lower values mean better calibrated forecasts. It is the standard, decomposable metric for evaluating prediction-market probabilities, because it rewards confident correct calls and penalizes confident wrong ones on a continuous 0 to 1 scale. For researchers and quants, it is the starting point for any serious accuracy audit.

TL;DR:

  • A Brier score near zero signifies well-calibrated and discriminative forecasts, while around 0.25 indicates no skill beyond random guessing.

  • Reliable discrimination on rare events requires over 1,000 samples and careful definition matching to avoid misleading scores.

  • Cross-venue canonicalization and comprehensive historical data are essential for accurate and reproducible Brier score audits.

  • Monitoring the Brier score over time and across probability bins helps detect calibration drift and model degradation in prediction markets.

  • Comparing scores using the Brier skill score clarifies whether market forecasts truly outperform naive baseline predictions.

AssymetrixBuild More Reproducible Market AuditsAssymetrix provides unified historical and real-time prediction market data across Polymarket, Kalshi, and Limitless through one Data API.Visit Assymetrix

Table of Contents

  • The Brier score formula and how it fits among scoring rules

  • Why Brier score works well for market evaluation

  • Computing Brier score: hand calculation and code

  • What counts as a good Brier score in prediction markets

  • Where Brier score misleads: rare events and sample size

  • Building Brier scoring into backtests and live monitoring

  • Cross-venue data as the backbone of reproducible Brier audits

  • A researcher’s take on using Brier score well

  • A practical next step: the Assymetrix Data API

  • FAQ

  • Sources

The Brier score formula and how it fits among scoring rules

For a binary outcome, the Brier score is the mean of the squared differences between each forecast probability and the actual result, coded as 1 for the event occurring and 0 otherwise. Across N forecasts, that is the average of (forecast minus outcome) squared, which puts the score on a 0 to 1 scale where 0 is a perfect forecast and 1 is the worst possible one. This binary form already divides by N, so no further rescaling is needed for a single-outcome market.

The original multiclass formulation, as described on the Brier score Wikipedia page, sums squared errors across all possible categories rather than just one, which produces values on a 0 to 2 scale instead of 0 to 1. This is the source of a recurring confusion among developers porting code between binary and multiclass contexts: a binary score computed with the two-category sum formula needs to be divided by two to land back on the familiar 0 to 1 scale. Keeping track of which convention a library or paper uses matters more than it should, because a score of 0.3 under one convention can mean something entirely different under the other.

The Brier score belongs to the family of strictly proper scoring rules, a property discussed in depth in Buja and colleagues’ work on loss functions for binary class probability estimation. A strictly proper rule means a forecaster cannot improve their expected score by reporting anything other than their true believed probability, which is exactly the incentive structure we want when scoring market-implied probabilities rather than a model’s internal confidence. That paper also flags link-function caveats worth knowing before treating squared-error loss as interchangeable with other proper scores like log loss.


The Brier score formula and how it fits among scoring rules — overview diagram

Why Brier score works well for market evaluation

The Brier score’s main advantage over a single accuracy number is that it decomposes into three components: uncertainty, reliability, and resolution, as laid out in the Brier score decomposition literature. Uncertainty reflects the inherent variance of the outcome itself and is fixed by the base rate. Reliability captures calibration, meaning whether a market’s 70% probabilities actually resolve “yes” about 70% of the time. Resolution captures discrimination, meaning whether the market’s probabilities vary enough across events to be informative rather than hovering near the base rate for everything.

This decomposition is what makes Brier score actionable rather than descriptive. A market with poor reliability has a systemic bias correctable with recalibration. A market with poor resolution is not differentiating outcomes at all, regardless of how well-calibrated its averages look. Log loss penalizes extreme wrong predictions far more harshly, which makes it useful for flagging catastrophic miscalibration but harder to interpret in aggregate. Rank-based metrics like AUC tell you about ordering, not about whether the stated probabilities themselves are trustworthy, which is usually the question a trader actually has.

For sizing decisions, calibration is the metric that matters: a trader deciding how much capital to commit to an edge needs to trust that a market quoting 65% really does resolve “yes” close to that often, and Brier’s reliability component is the direct, decomposable check on that trust.


Why Brier score works well for market evaluation — overview diagram

Computing Brier score: hand calculation and code

Consider three binary-outcome markets. Market A forecasts 0.70 for an event that occurs (outcome 1), Market B forecasts 0.40 for an event that does not occur (outcome 0), and Market C forecasts 0.90 for an event that occurs (outcome 1).

  • Market A: (0.70 − 1)² = 0.09

  • Market B: (0.40 − 0)² = 0.16

  • Market C: (0.90 − 1)² = 0.01

The mean of 0.09, 0.16, and 0.01 is 0.0867, which is the Brier score for this three-market sample.

For production code, scikit-learn’s brier_score_loss implements this directly:

from sklearn.metrics import brier_score_loss
y_true = [1, 0, 1]
y_proba = [0.70, 0.40, 0.90]
brier_score_loss(y_true, y_proba)

This returns 0.0867, matching the hand calculation. The function includes a scale_by_half parameter controlling whether binary scores are rescaled, which matters when comparing output against papers or dashboards using the multiclass sum convention.

Pro Tip: Always confirm which scaling convention a dashboard or paper uses before comparing a Brier number across sources, since a 0 to 2 scale score will look twice as bad as the same forecast quality on a 0 to 1 scale.

The Brier skill score benchmarks a forecast against a reference, typically a naive base-rate forecast. If our three-market sample’s base rate is 2 out of 3 events occurring (0.667), a naive forecaster predicting 0.667 for every event scores (0.667−1)² + (0.667−0)² + (0.667−1)² averaged, which is 0.247.

What counts as a good Brier score in prediction markets

Markets consistently beating a naive baseline typically show measurable skill, with tighter forecasting horizons generally scoring lower (better) than longer ones, according to empirical tracking summarized on the Longterm Wiki prediction markets entry. A Brier score near 0 indicates near-perfect calibration and discrimination; a score near 0.25 is what a forecaster gets by predicting 0.5 for every binary event, meaning it reflects maximum uncertainty rather than any real skill; a score near 1 indicates confidently wrong forecasts.

Translating a raw score into a skill statement requires the Brier skill score framing introduced above. A skill score of 0% means the forecast is no better than the naive reference; 100% means perfect prediction; negative values mean the forecast is actively worse than guessing the base rate every time.

  • A skill score near 100% represents forecasts close to perfect resolution.

  • A skill score near 0% represents forecasts no better than the base rate.

  • A negative skill score flags a model or market actively underperforming a naive guess, worth investigating before trusting its signals.

These are illustrative figures for the calculation method, not claims about any specific market’s historical performance.

Where Brier score misleads: rare events and sample size

Reliable discrimination on rare events requires a much larger sample than common events do, with meteorological literature summarized on Wikipedia’s Brier score page indicating sample sizes well over 1,000 events are typically needed before rare-event Brier scores stabilize into something trustworthy.

Event definition mismatches compound the problem. A market resolving on a loosely worded condition, or one where the forecast horizon does not match the evaluation window, will produce a Brier score that reflects definitional noise rather than forecasting skill.

  • Small samples on rare events produce unstable Brier scores that shift dramatically with one or two resolutions.

  • Mismatched horizons, comparing a day-ahead forecast against a month-ahead outcome, inflate apparent error unrelated to skill.

  • Aggregating across heterogeneous event types without separating by base rate hides where the real miscalibration lives.

Mitigations include aggregating by base-rate bucket rather than pooling everything, running calibration plots across probability bins (0 to 0.1, 0.1 to 0.2, and so on) to localize miscalibration, and pairing Brier with the skill score so small-sample noise is contextualized against a reference rather than read as an absolute.

Pro Tip: Before trusting a rare-event Brier score, check the underlying event count first: fewer than a few hundred resolutions on a low base-rate category is usually too thin to draw conclusions.

Building Brier scoring into backtests and live monitoring

A reproducible Brier pipeline starts with data hygiene, since the metric is only as trustworthy as the event alignment feeding it. Canonical market IDs that persist across venues prevent the same underlying event from being double-counted when it trades on multiple platforms. Consistent resolution fields, meaning a single source of truth for how and when an event resolved, prevent silent disagreements between data sources. Snapshot cadence needs to be fixed and timestamps aligned to the evaluation horizon, not to whenever a scrape happened to run.

A practical backtest recipe follows four steps:

  1. Align each market’s probability snapshot to the exact evaluation horizon being tested, such as 24 hours before resolution.

  2. Compute the per-event Brier score for every aligned snapshot against its final resolved outcome.

  3. Aggregate per-event scores by horizon bucket to see how calibration changes as events approach resolution.

  4. Compute the Brier skill score against a naive baseline for each bucket to express the result as a skill percentage rather than a raw number.

Monitoring in production extends the same logic on a rolling basis:

  • Track a rolling Brier score over the trailing N resolved events rather than a single all-time aggregate.

  • Maintain calibration plots by probability bin to catch miscalibration concentrated in a specific range, like overconfidence above 0.8.

  • Weight or segment metrics by smart-money flow to see whether wallets with strong historical accuracy are associated with better-calibrated market prices.

  • Set alert thresholds on rolling Brier degradation so a drifting model or a stale data feed gets flagged before it silently erodes trading performance.

Compute-wise, vectorized aggregation across thousands of events outperforms row-by-row loops once a backtest spans multiple venues and horizons, and sample weighting becomes necessary when some event categories are overrepresented in a historical pull. Keeping a fixed, versioned seed dataset for any audit matters as much as the metric itself: a Brier score computed against a shifting data sample cannot be reproduced or defended later.

Pro Tip: Store the exact snapshot timestamp and canonical event ID alongside every computed Brier score, so any later audit can reproduce the number without re-querying a live feed that may have since changed.

For a structured walk-through of applying this kind of evaluation across market datasets, our prediction market accuracy guide and our backtesting guide built on large-scale price snapshots cover the alignment and aggregation steps in more detail.

Cross-venue data as the backbone of reproducible Brier audits

A Brier audit is only as reliable as the historical record feeding it, and that record has to be complete, canonical, and consistent across venues to avoid the double-counting and misalignment problems described above. We aggregate real-time and historical prediction market data across Polymarket, Kalshi, and Limitless into a unified intelligence layer, built on approximately 1.5 terabytes of historical data spanning nearly one billion rows of trading activity.

That scale matters directly for Brier work: rare-event sample-size requirements are only solvable with deep historical coverage, and cross-venue canonicalization is what prevents the same event from inflating or deflating an aggregate score when it trades in more than one place.

  • Canonical market IDs and resolved-outcome fields are structured for direct per-event Brier computation without manual reconciliation.

  • Smart Money wallet tracking and Trader Skill Scores let researchers weight or segment Brier analyses by the accuracy of the capital behind a price, not just the price itself.

  • Cross-venue arbitrage and market divergence signals surface where two venues disagree on the same canonical event, a useful flag before trusting either venue’s calibration in isolation.

A researcher’s take on using Brier score well

Brier score is a diagnostic, not a verdict. The number that matters is not a single aggregate but the trend of a rolling score across enough resolved events to be statistically meaningful, with clear event definitions so the denominator means what you think it means. Use it to check calibration, then pair it with a decision-focused metric, since a well-calibrated market can still offer poor risk-adjusted trading edges. Run backtests routinely rather than trusting one historical snapshot, because calibration drifts as market composition and participant behavior change.

— Dean

A practical next step: the Assymetrix Data API

Running the workflows above at scale requires canonical event IDs, full snapshot history, resolved outcomes, and Smart Money flags in one schema rather than stitched together from multiple venue APIs. Our Data API provides exactly that structure for Brier audits across Polymarket, Kalshi, and Limitless.


Assymetrix

For a methodology comparison from outside the prediction-market space, PennyStockScout’s scoring methodology outlines a similar data-driven evaluation approach worth a look. To start building reproducible Brier pipelines on real cross-venue history, check the API documentation and example datasets at Data.

FAQ

What is considered a good Brier score?

A Brier score near 0 indicates strong calibration and discrimination, while a score near 0.25 reflects no better performance than always guessing 0.5 on a binary event. Context matters more than the raw number: comparing against a Brier skill score baseline tells you whether a given score represents real skill or just a favorable base rate.

What does Brier score calculate?

The Brier score calculates the mean squared difference between a forecast probability and the actual binary outcome, coded as 1 or 0. It is a strictly proper scoring rule, meaning a forecaster has no incentive to report anything other than their true believed probability.

Can you actually make money on prediction markets?

Trading prediction markets profitably depends on identifying mispriced probabilities relative to true outcome likelihood, which is exactly what calibration metrics like Brier score are designed to audit. Edge comes from systematically better-calibrated forecasts than the market’s current price, not from the existence of the market itself.

What are the two major prediction markets?

Polymarket and Kalshi are widely referenced as major prediction market venues, alongside platforms such as Limitless that have grown in the same space. Each venue has its own liquidity, participant base, and resolution conventions, which is part of why cross-venue canonicalization matters for any accuracy comparison.

How do you compute Brier score in Python?

Using scikit-learn, brier_score_loss takes true binary outcomes and predicted probabilities and returns the mean squared error directly. The function’s scale_by_half option controls whether the result follows the 0 to 1 binary convention or the 0 to 2 multiclass sum convention.

Sources

  • Brier score — Wikipedia

  • brier_score_loss — scikit-learn documentation

  • Loss Functions for Binary Class Probability Estimation and Classification: Structure and Applications — Buja et al.

3 Proper Scoring Rules Researchers and Market Quants Must Use

3 Proper Scoring Rules Researchers and Market Quants Must Use

A scoring rule assigns a numeric score to a probabilistic forecast once the outcome is known, and it is proper when reporting the true predictive distribution optimizes the expected score, strictly proper when that optimum is unique. For researchers, the practical rule is simple: match the score to the forecast object, whether that is a pmf, a density, a CDF, or a quantile, then use that same proper rule for both evaluation and training. The three workhorses are the logarithmic score, the Brier (quadratic) score, and the continuous ranked probability score, each suited to a different forecast shape.

TL;DR:

  • The proper scoring rule must match the forecast object, such as density or quantile, to ensure unbiased evaluation and training.

  • The logarithmic score is best for likelihood-based models and is highly sensitive to overconfidence by penalizing tiny probabilities assigned to realized outcomes.

  • CRPS is ideal for ensemble and continuous forecasts, rewarding predictions close to the outcome without explosion near zero probabilities, and can be computed from samples.

  • Brier scores are suitable for categorical forecasts, providing bounded, interpretable calibration metrics and decomposing prediction quality into calibration and resolution.

  • Implementation accuracy requires consistent orientation, correct forecast object matching, and avoiding smoothing or post-processing that breaks propriety guarantees.

AssymetrixBring Market Data Into Your ModelsAssymetrix unifies prediction market data across Polymarket, Kalshi, and Limitless through one integration for research and trading tools.Explore Assymetrix

Table of Contents

  • Definitions and core properties of scoring rules

  • Common scoring rules: formulas, scope, and intuition

  • Mathematical foundations: entropy, Bregman divergences, and representations

  • How to choose a scoring rule for evaluation or training

  • Using scoring rules for estimation and model training

  • Computation, implementation notes, and pitfalls to avoid

  • Recent research and empirical comparisons (2024–2026): what changed and open questions

  • Implications for prediction-market engineers and quant teams

  • Sources

  • FAQ

Definitions and core properties of scoring rules

A scoring rule is a function S(P, y) that takes a forecaster’s predictive distribution P and a realized outcome y and returns a number. Depending on convention, that number is a reward to maximize or a loss to minimize. It helps to define the expected score, S(P, Q), as the expected value of S(P, y) when y is drawn from the true distribution Q. This separates the forecast actually issued (P) from the distribution nature actually uses to generate outcomes (Q), which is exactly the distinction that propriety is built on.

A scoring rule is proper relative to a class of distributions when, for every true distribution Q in that class, the expected score S(P, Q) is optimized by setting P equal to Q. In plain terms: no other forecast beats telling the truth, in expectation. It is strictly proper when Q is the unique optimizer, so that no distinct distribution can tie the truth-telling forecast. The formal characterization from Gneiting and Raftery covers this across categorical probabilities, predictive densities, CDFs, quantiles, and intervals, which is why the framework generalizes so cleanly across forecast types.

Underneath this definition sits a convexity condition. The expected score, viewed as a function of the reported distribution, behaves like a concave entropy functional, and propriety falls out of that concavity. Strict propriety corresponds to strict concavity, which is what forces the optimum to be unique rather than merely tied. This connection to entropy and convex analysis is why proper scoring rules show up in statistical decision theory, information theory, and elicitation theory as the same underlying object wearing different names.

Two practical conventions matter once you start implementing scores rather than just defining them:

  • Orientation: some rules are stated as rewards (higher is better) and others as losses (lower is better); affine transformations preserve propriety, but sign flips change which direction counts as “good,” so document orientation explicitly.

  • Sample aggregation: the expected score S(P, Q) is a theoretical quantity; in practice you compute a sample average of S(P, y) over realized outcomes, which converges to the expected score as sample size grows but carries finite-sample noise that matters for small backtests.

  • Scale invariance: because affine transformations of a proper score remain proper, two scores that differ only by a constant or a positive scaling factor rank forecasters identically, even though their raw numbers differ.

  • Forecast-object matching: a rule proper for densities is not automatically proper for quantile forecasts of the same quantity, so the object being scored has to match the object the rule was designed for.

These conventions are not cosmetic. A researcher who mixes orientation (treating a loss as a reward) or aggregates scores across mismatched forecast objects can produce model comparisons that look rigorous but are quietly broken.

Common scoring rules: formulas, scope, and intuition

Three rules account for most applied work, and each has a distinct personality.

The logarithmic score is defined as the negative log density or probability assigned to the realized outcome: for a discrete outcome y with predicted probability p(y), the loss form is −log p(y). It is strictly proper, and minimizing it over a parametric family is mathematically identical to maximum-likelihood estimation, which is why every likelihood-based model is, implicitly, being scored with the log rule. The log score is local, meaning it only depends on the probability mass or density assigned to the outcome that actually occurred, not on how probability is distributed elsewhere. That locality has a sharp edge: log score’s sensitivity to near-zero assigned probabilities means that a forecaster who assigns a tiny probability to an outcome that then occurs is penalized severely, since the loss blows up as p(y) approaches zero. This makes the log score an effective detector of overconfidence.

The Brier score, also called the quadratic score, was built for categorical and binary forecasts. For a binary outcome with predicted probability p and realized outcome y in {0, 1}, the Brier score is (p − y)². It generalizes to multi-category settings as a sum of squared differences between predicted and actual class indicators. Unlike the log score, Brier is bounded and does not explode near zero, which makes it more forgiving of confident misses and more directly interpretable as a calibration-plus-resolution decomposition: squared error that splits into how well-calibrated the forecaster is and how much the forecaster’s predictions vary across cases.

The continuous ranked probability score (CRPS) extends this logic to continuous outcomes. It integrates the squared difference between the forecaster’s predictive CDF and the step-function CDF of the realized observation, across the whole real line. The Gneiting and Raftery characterization confirms CRPS is proper, and strictly proper whenever the forecast distribution has finite first moment. When the forecast is a point mass, CRPS reduces exactly to absolute error, which gives it an intuitive anchor: it behaves like a distribution-aware generalization of the mean absolute error. CRPS is distance-sensitive: probability mass placed near the realized outcome is rewarded more than probability placed far away, even if both are technically “wrong.” That is a meaningful contrast with the log score’s locality, and it is also why CRPS is essentially the integral of the Brier score, an L2 distance between forecast and observation CDFs that exists for any distribution with a finite first moment. It is particularly convenient for ensemble forecasts, since it can be estimated directly from a sample of ensemble members without needing a closed-form density.

Beyond these three, several related families extend the toolkit:

  • Spherical and pseudospherical scores are local like the log score but use power transformations instead of a logarithm, giving a tunable sensitivity parameter.

  • Energy scores generalize CRPS to multivariate outcomes by replacing absolute difference with a vector norm between sampled forecast draws and the realized vector.

  • Kernel scores build proper rules from a choice of positive-definite kernel, with CRPS and the energy score as particular cases.

Matching the rule to the forecast object is the decision that matters most in practice. A categorical pmf calls for the Brier score or the log score in its discrete form. A continuous density calls for the log score evaluated at the observed value. A full predictive CDF, especially from an ensemble or simulation, calls for CRPS. A quantile or interval forecast needs a quantile-specific or interval-specific proper scoring rule such as the pinball loss, which is a different object from a density and should not be scored with CRPS or the log score directly.

Mathematical foundations: entropy, Bregman divergences, and representations

The theoretical backbone connecting all of this is a representation result: expected scores behave as concave, entropy-like functionals of the reported distribution, and propriety is the condition that this concave functional is optimized exactly at the truth. This is sometimes called a Savage representation, after the broader decision-theoretic result that any proper scoring rule can be derived from a convex function via a subgradient construction. The arXiv treatment of proper scoring rules for estimation and forecast evaluation lays out representation theorems showing the equivalence between propriety and concavity or convexity conditions, alongside kernel-score constructions that recover many standard examples.

This convexity link is not an abstraction researchers can ignore. It is the mechanism that produces Bregman divergences from scoring rules. Every strictly proper scoring rule has an associated divergence measuring the “distance” between the reported distribution and the true one, and that divergence is a Bregman divergence generated by the convex function underlying the score. The log score’s associated divergence is the Kullback-Leibler divergence, which is the special case most researchers already know by name, but the same construction works for any convex generator, producing a different divergence for each choice.

Kernel-score construction extends this further. Given a positive-definite kernel on the outcome space, there is a canonical way to build a strictly proper scoring rule from it, and CRPS and the energy score both arise as specific instances of this construction applied to different kernels. This is useful beyond theoretical tidiness: it means a researcher who needs a proper score for a multivariate or non-standard outcome space can often construct one directly from a suitable kernel rather than searching for a bespoke formula.

The practical payoff of all this machinery is a single implication worth holding onto: strict propriety is equivalent to strict convexity of the underlying generator, and strict convexity is what guarantees a unique optimum. Without strict convexity, you can end up with a scoring rule that is merely proper, where multiple distributions tie at the optimal expected score, which weakens its usefulness as an estimation target because gradient-based optimization has no single point to converge to.


Diagram linking scoring rules and convexity

How to choose a scoring rule for evaluation or training

Picking a score is a short decision process, not a matter of taste.

  1. Identify the forecast object you actually have: a categorical probability vector, a predictive density, a full CDF, a quantile, or an interval. The score must be strictly consistent for that specific object, not merely “proper in general.”

  2. Decide whether you care more about exposing overconfidence or about rewarding near-misses. The log score is local and penalizes overconfidence sharply near zero probability; CRPS is distance-sensitive and gives partial credit for probability mass placed close to, but not exactly on, the outcome.

  3. Check whether your evaluation needs to handle ensembles or simulated draws rather than closed-form densities. CRPS is estimable directly from samples, which makes it a natural fit for ensemble-based or simulation-based forecasts.

  4. Consider computational and robustness constraints. If your model has an intractable normalizing constant, a homogeneous or local scoring rule can sidestep that problem entirely, since it does not require evaluating the full normalized density.

  5. Decide whether you need a composite or weighted score, for example when certain parts of the outcome space (tails, specific categories) matter more than others for your application.

The trade-offs compress into one line each: the log score is local and unforgiving of near-zero misses, which makes it a strong overconfidence detector; Brier is bounded and interpretable through calibration-resolution decomposition; CRPS is distance-aware and well-suited to continuous or ensemble forecasts where “close” should count for something.

Pro Tip: Before writing any evaluation code, state out loud which forecast object you are scoring; most propriety bugs come from silently switching between a density, a CDF, and a sample-based approximation mid-pipeline.

A short checklist before committing to a score: What object does your model actually output? Do you need the score for evaluation only, or also as a training loss? Does your data include ensembles or single point estimates? Is a normalizing constant tractable? Does the application care more about tail misses than about average distance?

Using scoring rules for estimation and model training

A scoring rule is a loss function the moment you minimize its sample average over model parameters, and this is where the theory connects directly to estimation practice. The clearest case is the log score: minimizing the sample average of −log p(y; θ) over θ is exactly maximum-likelihood estimation. Every time a researcher fits a parametric model by maximizing likelihood, that fit is, by construction, log-score minimization, inheriting all the properties, strengths, and the overconfidence penalty, that come with it.

CRPS and kernel scores extend this to distributional learners that do not output a simple parametric density. A model producing an ensemble of plausible outcomes, a quantile forecaster, or a simulation-based generative model can be trained by minimizing sample CRPS directly, since CRPS is computable from samples without requiring a closed-form likelihood. This matters for architectures where likelihood is intractable or undefined, where kernel and energy scores give a path to training that log-likelihood cannot.

Recent empirical work complicates the assumption that any strictly proper rule is interchangeable as a training objective. Experimental comparisons across strictly proper training rules found that different proper training objectives can produce distinct calibration and bias profiles in finite-sample ML training, with Brier-trained and log-trained models behaving differently even when both are theoretically unbiased in expectation. In one such experiment, the Brier-trained model achieved the lowest Brier score while the log-trained model achieved the lowest calibration error, a result the authors flag as dependent on single-seed experimental variability rather than a settled ranking. The practical lesson is that theoretical interchangeability of proper rules does not guarantee identical finite-sample behavior, so the choice of training objective should be validated empirically for the specific model and dataset rather than assumed from theory alone.

Score-based estimation also has a specific niche worth naming directly: situations with intractable normalizing constants. Homogeneous and local scoring rules let you estimate parameters and perform model selection without ever computing the normalizing constant, which makes them practical for Bayesian model comparison under improper priors, where the marginal likelihood is undefined or prohibitively expensive to compute.


Using scoring rules for estimation and model training — overview diagram

Computation, implementation notes, and pitfalls to avoid

Computing CRPS in practice has two paths. When the predictive distribution has a closed form, such as a Gaussian or a known parametric family, CRPS has closed-form expressions in terms of that distribution’s CDF and density. When the forecast is an ensemble of samples, CRPS can be estimated directly from the sample, using the pairwise-distance formulation that avoids ever constructing an explicit CDF, which is one reason CRPS is popular for simulation-heavy forecasting pipelines.

Orientation conventions in software are a recurring source of silent bugs. The scikit-learn model evaluation documentation uses a higher-is-better convention for scorers, which means losses are frequently negated in naming, such as neg_log_loss, so that cross-validation routines that maximize a scorer still end up minimizing the underlying loss. Carrying an unnegated loss into a maximization routine, or vice versa, produces a model selection process that silently optimizes the wrong direction.

A short set of implementation habits avoids most of the damage:

  • Clip or floor predicted probabilities before taking a logarithm, since an exact zero probability assigned to an outcome that occurs produces an infinite log-score penalty.

  • Use log-sum-exp style numerically stable formulations when probabilities come from softmax outputs, to avoid underflow in very small probability regions.

  • Compute CRPS from samples only when the reported forecast object is genuinely a sample-based distribution, not a post-processed or smoothed version of one.

  • Document orientation (loss vs reward) at every stage of a pipeline that compares models across different scoring functions.

Pro Tip: Treat any smoothing step applied to a forecast before scoring as a change to the forecast object itself; scoring the smoothed output as if it were the original declared forecast is a quiet way to break propriety.

That last point deserves emphasis because it is easy to miss. Smoothing a submitted forecast before scoring it can destroy propriety unless the reporter’s declared forecast object matches the postprocessed object being scored. If a model reports raw ensemble members but the evaluation pipeline applies a kernel-density smoother before computing CRPS, the score no longer measures what the model actually reported, and the propriety guarantees no longer apply.

Recent research and empirical comparisons (2024–2026): what changed and open questions

Recent review work positions proper scoring rules as doing double duty: evaluators of forecast quality and estimators for model training, with the 2025 treatment of proper scoring rules for estimation and forecast evaluation framing both roles through the same entropy and kernel-score machinery described above. That dual framing matters because it means the same theoretical object that ranks forecasters in a leaderboard can, with minimal modification, become a training loss for the next model generation.

The more unsettled territory is empirical. The 2026 experimental comparison of strictly proper rules found that five strictly proper rules all incentivize truthful reporting in theory, yet produced measurably different calibration and bias profiles when actually used as training objectives, with the authors explicitly cautioning that results may be sensitive to single-seed experimental variability rather than representing a stable ranking across rules. Open questions that follow directly from this include how sensitive these differences are to sample size, whether tail behavior under different rules converges as data grows, and how computational cost scales when kernel or energy scores replace simpler closed-form losses in large training runs.

For practitioners, the honest takeaway is to treat theoretical propriety as a necessary condition for a sound training objective, not a sufficient one, and to validate finite-sample behavior with held-out calibration checks before committing to a rule for production model training.

Implications for prediction-market engineers and quant teams

Choosing a score is not an academic exercise when it feeds a trader-skill leaderboard or a Smart Money signal. A skill metric built on the log score will flag overconfident traders harshly for near-miss calls, while one built on CRPS will reward traders whose probability mass lands close to outcomes even when it is not exactly right, and those are different definitions of “good at forecasting” that will rank the same trader differently.

Backtests face the same choice. A cross-venue arbitrage signal evaluated with a mismatched scoring rule can look stronger or weaker than it actually is, simply because the scorer does not match the forecast object the signal produces. Computing these scores at scale requires distributional inputs across venues, which is the layer Assymetrix’s Data API is built to supply: normalized, cross-venue price and trade data from Polymarket, Kalshi, and Limitless that can feed directly into a scoring pipeline rather than a bespoke per-venue parser.

The practical note for model pipelines: pick the scoring rule before building the evaluation dashboard, not after, since the choice shapes which trades your backtest rewards; see this Probability Calibration Trading Guide for Traders for more on calibration and score selection.

— Dean

Sources

  • Strictly Proper Scoring Rules, Prediction, and Estimation (Gneiting & Raftery, 2007)

  • scikit-learn model evaluation documentation

FAQ

What are scoring rules?

A scoring rule is a function that assigns a numerical score to a probabilistic forecast once the outcome it predicted is observed, used to evaluate or train forecasters. The rule is proper when the forecaster’s expected score is optimized by reporting the true distribution, which is the property that makes scoring rules useful for both evaluation and estimation, as formalized by Gneiting and Raftery.

How do you interpret a CRPS score?

CRPS measures the distance between a forecaster’s predictive CDF and the realized outcome by integrating squared CDF differences, and it reduces to plain absolute error for a point forecast. It is distance-sensitive, so probability mass placed near the eventual outcome scores better than mass placed far away, even when both forecasts miss the exact value, as described in the CRPS framework from Gneiting and Raftery.

What is a scoring procedure?

A scoring procedure is the practical process of applying a scoring rule: matching the rule to the forecast object (pmf, density, CDF, or quantile), computing the score for each realized outcome, and aggregating scores across a sample to compare forecasters or models. Getting the procedure right depends on consistent orientation (reward versus loss) and on scoring the forecast object exactly as it was reported, without smoothing or reformatting it first.

What is the logarithmic scoring rule?

The logarithmic scoring rule, or log score, is the negative log probability or density assigned to the realized outcome, and it is strictly proper. It is local, meaning it only depends on the probability given to the actual outcome, and minimizing it is mathematically equivalent to maximum-likelihood estimation, with near-zero assigned probabilities producing severe penalties for confident misses.