Ask three prediction markets the same question and you will usually get three different answers. The same election, the same match, the same Fed decision — priced at 62% on one venue, 66% on another, 71% on a third. If you have read our guide to probability divergence, you know those gaps are structural, not a bug. But they leave a practical problem: when someone asks "what do prediction markets say?", which number do you quote?
Crypto solved this problem years ago. Nobody quotes "the Bitcoin price on one exchange" — they quote an aggregate. CoinGecko and CoinMarketCap became the industry's reference layer precisely because a single canonical number, computed transparently across venues, is more useful and harder to manipulate than any one venue's print.
The CoinRithm Reference Probability is that layer for prediction markets: one canonical prediction market price per real-world question, computed across every real-money venue that prices it, and always displayed with the two numbers that keep it honest — how many venues stand behind it, and how far apart they are.
TL;DR
- The Reference Probability is a liquidity-capped weighted median of the same question's probability across matched real-money venues (Polymarket, Kalshi, Limitless, Smarkets, PredictIt).
- It is a median, not a mean — a thin order book or a manipulation attempt on one venue cannot drag the number.
- Play-money and forecast platforms (Manifold, Metaculus) are never blended in — real-money
prediction market consensus oddsonly. - It is always shown with venue count and spread ("62% · 3 venues · ±4 pts"). The spread is the disagreement signal; the badge never pretends venues agree.
- On multi-outcome events (elections, tournaments), the reference names the leading outcome it refers to.
- It recomputes roughly every ten minutes and is free to read on every event page, the compare view, and the public data API.
Why one venue's number is not enough
Each prediction market is its own small economy. Different fee schedules, different user bases (US-regulated on Kalshi, global crypto-native on Polymarket, UK-centric on Smarkets), different collateral, different resolution fine print, different liquidity. Those differences produce persistently different prices for what is economically the same question — the polymarket kalshi average odds you would naively compute can hide a 10-point disagreement.
Quoting any single venue therefore imports that venue's biases. Quoting a naive average is worse in a different way: a venue with $40 of open interest gets the same vote as one with $4 million, and a single wash-traded outlier can move your "consensus" several points. An honest aggregate has to answer three design questions: which venues count, how much does each venue's voice weigh, and what happens when one voice lies?
The methodology, step by step
1. Match the question across venues. Our aggregator continuously matches events that price the same real-world question across venues — the same pipeline that powers the cross-market compare view. Matches are approved conservatively (a wrong match would merge two different questions), then connected into clusters: every venue's listing of one underlying question.
2. Real money only. Only venues where prices are backed by money at risk enter the reference: Polymarket, Kalshi, Limitless, Smarkets, and PredictIt. Manifold's play-money odds and Metaculus's forecaster aggregates are valuable signals — we display them alongside — but blending them into a money-backed number would misrepresent what the number is. This is the same honesty line our stats page draws for volume.
3. One voice per venue. If a venue lists the question more than once, its entries are collapsed first (median of its own probabilities, largest of its liquidity). No venue gets to vote twice.
4. Liquidity-capped weighted median. Each venue's voice is weighted by its liquidity — but clamped: a floor (about $1,000) so a small venue still counts, and a cap (about $50,000) so one deep book cannot drown everyone else. Across those weighted voices we take the median, not the mean. This is the manipulation-resistance core: to move a prediction market weighted median, you must move the middle venue, which means moving real money on multiple books simultaneously. A mean can be dragged by one outlier; a weighted median shrugs it off.
5. Binary and multi-outcome questions. For Yes/No questions, the reference is the Yes side's probability. For multi-outcome events — election winners, tournament champions, nominees — the reference compares outcomes across venues by name and quotes the shared outcome with the highest cross-venue probability, naming it explicitly: "Argentina 34% · 3 venues · ±2 pts". You always know which outcome the number refers to.
6. Spread is part of the product. The reference never appears alone. Venue count says how many independent markets stand behind the number; spread (the gap between the highest and lowest venue) says how much they disagree. A reference of "62% · 4 venues · ±3 pts" and one of "62% · 2 venues · ±19 pts" are very different pieces of information, and we show you the difference every time.
7. Fresh, and honest about freshness. The number recomputes with every aggregation cycle — roughly every ten minutes — and only exists while the underlying markets are open. There is no stale reference on a resolved question.
What the Reference Probability is not
It is not a prediction of ours — no model, no opinion, no adjustment. It is a summary of what real-money markets currently believe, nothing more. It is not investment advice. And it does not claim venues agree when they do not: that is exactly what the spread is for. When venues disagree sharply, the honest answer to "what do prediction markets say?" is "about 62%, but they disagree by 19 points" — and that is literally what we print.
It is also not an average of everything with a probability attached. A prediction market aggregator that silently blends play money into real-money odds is quoting a number nobody can trade. Ours never does.
Where to find it
- Event pages — the indigo reference badge above the cross-venue comparison on any matched event, e.g. among today's markets.
- Compare view — every matched cluster on the compare page carries its reference beside the divergence badge.
- Public API — the
referenceProbabilityfield on the event detail endpoint, free and keyless, withvenueCount,spreadPoints, andoutcomeNameincluded so downstream users inherit the honesty guarantees. - AI agents — the
pm_data_eventtool in the CoinRithm MCP server returns the same field, so agents can quotecombined prediction market probabilitywith provenance.
If you are new to how these prices work in the first place, start with how prediction market probabilities work; if you want to understand the gaps the reference summarizes, the divergence guide is the companion piece. And to see which venues feed the number, our platform comparison covers each one's strengths.
FAQ
Is the Reference Probability just an average of the venues?
No. It is a liquidity-capped weighted median. A mean can be dragged several points by one thin, stale, or manipulated venue; a median requires moving the middle of the distribution — real money on multiple books — to budge. Weights are clamped so no single deep venue dominates and no tiny venue is silenced.
Why are Manifold and Metaculus excluded?
Because nothing is at stake there in money terms. Manifold uses play money and Metaculus aggregates forecasts — both interesting, neither tradable. Blending them into a real-money number would make it mean nothing. We show them separately on event pages instead.
What does the ± spread mean?
It is the gap in percentage points between the highest and lowest venue in the cluster. A small spread means venues genuinely agree; a large one means they disagree — often for the structural reasons covered in our divergence guide. The reference is always displayed with it.
Which outcome does the number refer to on multi-outcome events?
The badge names it. On Yes/No questions the reference is the Yes probability. On elections, tournaments, and other multi-outcome events it is the shared leading outcome across venues, shown by name — "Argentina 34%" — never an unlabeled number.
Can I use it programmatically?
Yes — it rides the free public event endpoint (referenceProbability with probability, venueCount, spreadPoints, kind, outcomeName) documented on the API page, and the MCP pm_data_event tool for AI agents. Attribution appreciated; the methodology above is the contract.
