How to Track Probability Shifts Across Prediction Markets

What does a probability shift mean on a prediction market?

A binary contract pays 100 cents if the event happens and 0 if it does not, so the price is the probability, in cents. A YES contract at 62 cents is the market saying roughly 62%. When it trades at 66 cents an hour later, the crowd has revised its forecast up four points.

The complication is that there is no single number called "the price." There are three, and they often disagree:

• Best bid. The highest price someone will actually pay. The number you can sell into.
• Best ask. The lowest price someone will actually sell at. The number you can buy at.
• Midpoint. The average of the two. A convenience, not a trade, and not a real quote when one side is missing.

The legs are linked. On a Kalshi binary, NO_ask equals 100 minus YES_bid, so a zero YES bid makes the NO leg cost 100 cents. An empty bid side is not cosmetic, it propagates straight through to the other side of the same market.

So a shift is narrower than "the number changed." It is the executable price moving, on a book that had both sides at the time, by more than that market's own spread.

Why do prediction market price trackers show false moves?

Because they log midpoints, and a midpoint needs both sides of the book. Across 5,000 live Kalshi markets, 18.1% had no bid at all. On those, the only quote is an unmatched ask, so when a maker widens it by three cents a midpoint tracker records a shift. Nothing shifted, no money moved, and there was never a price at which you could have sold. It gets worse at the cheap end: under 5 cents, 41% of markets had no bid, while in the 25 to 50 cent band, 0% did.

The second cause is one threshold applied everywhere. Median spread on two-sided Kalshi books was 5.1 cents, and that median hides a huge range. Sorted by 24 hour volume, the median spread was 8 cents under 100 contracts and 1 cent above 10,000. The widest books measured were scalar economic markets, with KXUSCPIYEAR at 57 cents. A flat 4 cent alert is deafening on a liquid market and silent on a wide one.

How do you tell a real probability shift from noise?

Four filters, in this order. Each is cheap, and each kills a class of false alerts.

1. Qualify the book first. No bid means no probability. Skip the market, or flag it as one-sided and watch how long it stays that way.
2. Compare like to like. Bid against previous bid, ask against previous ask. Never bid against ask, and never midpoint against midpoint when the book gained or lost a side between samples.
3. Set the threshold from the market's own spread. A move smaller than the spread is quote drift, not news. Use the live spread, with the volume band as a fallback.
4. Require persistence. Hold the new level across two updates before calling it a shift. A print that reverts is inventory management.

One unit warning: Kalshi volume is counted in contracts and Polymarket volume in US dollars, so never divide one by the other or rank them in the same column.

How often do prediction market prices change?

Two clocks decide it: how fast the venue's markets resolve, and how much money is working the book. On speed, none of Kalshi's 274 crypto series runs shorter than 15 minutes. Polymarket runs 5 minute, 15 minute and hourly Bitcoin windows, with the 5 minute heading reading "BTC Up or Down 5m", and five minute contracts on BTC, ETH, SOL, XRP and HYPE.

On money, the fastest clock is the emptiest. Five minute traded volumes seen were 18 USD, 78 USD and 229 USD, many at 0 USD, while hourly windows ran 8.4K, 10.1K, 12.5K and 46.6K USD. The market that reprices most often carries the least conviction behind each reprice.

The practical consequence is request budget. Poll 200 markets individually every five seconds and that is 40 requests a second, or 2,400 a minute, against a Free plan limit of 60 a minute. You are forty times over the line and you still miss every move between polls. Streaming inverts it: you are told when something changed, and you spend nothing while the book is quiet.

How do you track price changes across prediction markets in one place?

The hard part is not one venue, it is 15+ of them. Each has its own identifiers, price units, definition of a market, and auth, so going venue by venue means writing that adapter over and over, then rewriting it whenever one changes a field.

Predictefy collapses that into one normalized schema. 15+ venues arrive in the same shape, so the only thing that changes between requests is the venue segment in the path:

curl -H "Authorization: Bearer pk_live_..." "https://data.predictefy.com/api/kalshi/{verb}"

curl -H "Authorization: Bearer pk_live_..." "https://data.predictefy.com/api/polymarket/{verb}"

For live tracking, connect to the WebSocket rather than looping over those requests:

wss://data.predictefy.com/v1/stream

Compute your shifts from live bids and asks rather than midpoints that 18.1% of 5,000 live Kalshi markets cannot even quote. That is the difference between a tracker that alerts you and one you learn to ignore.

Client packages are available in beta: @predictefy/sdk and @predictefy/mcp at 1.0.0-beta.3 on npm, predictefy at 1.0.0b2 on PyPI. Pin exact versions, because the latest tag points at a beta. The MIT licensed MCP server runs with npx -y @predictefy/mcp, and no tool in it both builds and submits an order.

Can you get historical probability data for prediction markets?

Partly. Stored history is proven for 11 venues, not all 17. For the rest, the only history you get is the history you record, so a shift tracker should write to storage from its first minute.

Store four things on every capture, not one: the best bid in cents (null when there was none), the best ask in cents, the timestamp in UTC, and a two-sided flag telling you later whether that row was a real quote.

An archive of midpoints cannot be repaired afterward. Six months on, you cannot tell which rows were genuine 62% readings and which were an unmatched ask on an empty book. Raw bids and asks cost almost nothing to keep and let you re-derive any measure later, including spread, the input to your noise threshold.

What does it cost to track probability shifts across venues?

A one-person tracker across a handful of venues fits inside Free. The arbitrage API is free as well, which matters here: a cross-venue shift and a cross-venue price discrepancy are the same measurement from two angles, one asking what changed, the other asking where venues disagree now.

What are the limits of a prediction market data API?

Three limits worth knowing. History coverage is 11 venues, not 17. fetchBalance on the hosted API intentionally returns 501 NOT_SUPPORTED, so do not design a dashboard that expects balances from the reads API. And there is no generic server-side signing route, because orders are signed client side.

That last one matters if your tracker acts when a shift fires. Execution is a separate, isolated, non-custodial service at its own origin, not the reads API, with routes under /v1/exec/{venue}/orders/... for build, submit, cancel, modify and refresh. Every write takes an Idempotency-Key, which is what you want when an alert loop fires twice on one shift, and default caps are 100 USD per order and 1,000 USD per key per rolling 24 hours.

Frequently Asked Questions