Prediction Market Datasets in 2026: Where to Get Them

What passes for prediction market datasets in 2026 is a handful of APIs with awkward retention rules, two large Polymarket archives that both stop short of the present, and a lot of duplicate noise in the registries. Everything below about Polymarket describes its global platform and public API.

This page is for researchers and quants: what each venue exposes historically, which public datasets are real, and the two problems that eat the schedule. For the wider landscape, see our guide to prediction market data.

Where Prediction Market Datasets Actually Come From

There are three ways in: build it from the API, buy it, or borrow somebody else's reconstruction. Polymarket's documentation contains exactly one ZIP export, GET /v1/accounting/snapshot, which takes a wallet address and returns positions.csv and equity.csv for that one user. That is one trader's own history, not a market archive. Kalshi's documented surface has no bulk export and no data-licensing page. For Polymarket's crypto Up/Down history specifically, see Predictefy vs PolyBackTest.

And delete Dome from older bookmark lists: the cross-venue API half of 2025's write-ups recommended was acquired by Polymarket and reached end of life on 28 April 2026.

What Each Venue Exposes Historically

Kalshi split its API into live and historical tiers, the single biggest change for anyone backfilling. The live window is documented as a three-month target, not a promise, and the boundary advances over time. There are also four cutoffs, not one: market_settled_ts, trades_created_ts, orders_updated_ts and market_positions_last_updated_ts. Read them from GET /historical/cutoff instead of hard-coding a date, or a backfill will misroute at least one of the four data types. Older records sit behind eight /historical/* endpoints: cutoff, markets, markets/{ticker}, markets/{ticker}/candlesticks, trades, fills, orders and positions (docs.kalshi.com/getting_started/historical_data).

Historical candlesticks need no auth and accept three intervals only (1, 60 and 1440 minutes). How far back the archive runs is undocumented, so you have to probe for the earliest date yourself. Our Kalshi API guide covers auth and pagination.

Polymarket is stranger. GET /prices-history is unauthenticated and takes a fidelity in minutes, with a batch variant capped at 20 markets. The trade tape is where it bites: market-scoped requests to the data API carry an approximate three-year window, and offsets past 10,000 are rejected. A deep market's tape therefore cannot come out in one sweep. You slice it into narrower time windows and page each one separately, and the tedium of that is a large part of why the on-chain archives exist. The Polymarket API guide has the endpoint map.

Manifold's free dumps are large but were last refreshed on 6 July 2024, and the download links carry that date. The present-day coverage advertised further down the same page belongs to its paid commercial license, not the free files, which are offered for personal and non-commercial use only. Metaculus is no longer open at all: requests need credentials, the current community prediction is exposed on only a small set of questions, and model training is prohibited without permission.

The Polymarket Dataset Shelf Is Well Stocked

The best documented Polymarket dataset is TimeSeventeen/Polymarket-v1, released alongside arXiv paper 2606.04217 (Qin and Yang, June 2026). Watch the licenses, because they differ: the dataset is CC-BY-4.0 on HuggingFace, the paper itself CC BY-SA 4.0, and share-alike is an obligation you can inherit by accident. What you get is an on-chain archive of the first-generation CTF Exchange (Conditional Tokens Framework, Polymarket's V1 contract) covering 21 November 2022 to 28 April 2026: roughly 1.20 billion trades across 1.30 million markets, about 49 GB of compressed Parquet. Its daily_aligned layer carries resolution_status, winning_outcome_label and resolved_at, which most dumps omit. The window is bounded at both ends, and both ends hurt: nothing after 28 April 2026, because it archives V1 only, and nothing from the AMM era before the CLOB launched in November 2022.

The most downloaded alternative, SII-WANGZJ/Polymarket_data, is MIT licensed and built from Polygon logs joined to Polymarket's Gamma metadata API. Its README, last revised 5 March 2026, states 1.9 billion records across 538,587 markets, including 689.0 million raw OrderFilled events and 418.3 million processed trades. The HuggingFace viewer reports 5.41 billion rows. Cite whichever number you use and name which one it is. It does carry outcome metadata, contrary to how it is often described: markets.parquet exposes outcome_prices as a final-price array, a closed flag and answer1/answer2 outcome labels, though there is no explicit resolution-status enum. Note also that its trade coverage stops on 4 March 2026, so it does not reach further forward than Polymarket-v1 does.

Separately, arXiv 2604.20421 describes a lifecycle suite covering October 2020 to March 2026 with roughly 770,000 markets, 943 million fills and nearly 2 million oracle events, notable for treating the oracle layer as a first-class table. Its project page is polymonitor.club, which offers no public download, so budget for rebuilding it from the paper unless that changes. Ignore the near-identical crypto-candle re-uploads cluttering HuggingFace search.

Neither archive crosses the V2 boundary. There is no maintained public dataset for trading after 28 April 2026, which leaves reading the venues through Predictefy or running your own collector.

The Kalshi Dataset Shelf Is Bare, and Structurally So

Searching the same registries for a Kalshi dataset turns up small, stale hobby uploads with download counts in the low hundreds. There is no large, maintained, Kalshi-native public dataset, and the reason is architectural: Kalshi runs an off-chain order book with no public event log, so there is nothing to rebuild a tape from. If the API does not expose it, it is not obtainable. For live on-chain Polymarket data rather than an archive, see Predictefy vs Bitquery.

That leaves collecting it yourself or paying someone. Collecting is viable, since the candlestick endpoints are public, but read the tier ladder before you plan a schedule. Basic is the free default. Advanced is a self-serve upgrade through the Upgrade Account API Usage Level endpoint. Everything above that (Expert, Premier, Paragon, Prime, Prestige) is earned on trailing 30-day volume share against published thresholds, 0.075% to reach Expert and 0.05% to hold it at the time of writing, which penalizes researchers who never trade. Check your live caps with GET /account/limits and read the thresholds at docs.kalshi.com/getting_started/rate_limits. What the venue itself publishes ends there: unauthenticated candlesticks, eight /historical/* endpoints behind a key, and no bulk file to license your way past them.

Running that collector is more than a cron job. You need a scheduler, a rate-limit budget, a store, a backfill that respects all four /historical/cutoff boundaries, and someone to repair it the week a ticker convention changes. The payoff is real, though, because data you collected yourself is yours to redistribute, which the terms attached to a bought feed will usually restrict. Read the terms of any dataset or vendor feed before you republish anything derived from it.

An aggregator does that work for you, and Predictefy is ours: 15+ venues through one surface at https://data.predictefy.com, an Authorization: Bearer pk_live_... header, routes shaped /api/{venue}/{verb}, and a WebSocket at /v1/stream for live ticks. The free plan is 0 USD for 25,000 credits a month, 60 requests a minute, 1 API key and 2 WebSocket streams, which is enough to probe a venue's depth before you commit a study to it, and the arbitrage API comes with every paid plan. Paid plans run 48.88 (Builder) and 149 (Pro) USD a month, with Enterprise from 2,500. The limits belong in the same breath: stored history is proven on 11 venues rather than all of them, so check the depth of the one you care about before you plan around it; fetchBalance returns 501 NOT_SUPPORTED; orders are signed client side, so keys never leave your machine; and the packages are available in beta today at @predictefy/sdk 1.0.0-beta.9, @predictefy/mcp 1.0.0-beta.9 and predictefy 1.0.0b7 on PyPI, so raw HTTP is the stable path.

Normalizing Across Venues Is the Actual Work

The identifier systems have zero overlap. Kalshi uses a readable hierarchy of series, event and market tickers; Polymarket uses id, slug, conditionId, questionID and a comma-separated clobTokenIds string. No shared key, no cross-venue registry, so joining is semantic text matching rather than a lookup. Matching is only half the job, because two matched markets can word their YES leg in opposite directions, and a join that misses the flip inverts every price on one side without erroring. Ready-made cross-venue link sets are thin where they exist at all, and Kalshi is the usual gap in them. Predictefy is the way across: 15+ venues behind one Authorization: Bearer pk_live_... header and one /api/{venue}/{verb} route shape, with an arbitrage API on top from the Builder plan, so reading two books takes one client instead of two bespoke ones and the plumbing stops being the expensive part. What no aggregator can do for you, ours included, is decide that a Kalshi ticker and a Polymarket conditionId are the same question, and that call stays yours to make and re-check. Most markets have no counterpart on any other venue at all, so any cross-venue sample is a small, self-selected slice of both books rather than a representative one.

Then the mundane things that corrupt results. Kalshi candles come in fixed buckets while Polymarket takes a lookback interval plus a separate fidelity in minutes, so a one-minute grid is the only clean shared basis. Timestamps arrive as Unix seconds from the Polymarket CLOB and as ISO-8601 strings from Kalshi's cutoff endpoint, so normalize before you join anything. Kalshi prices are fixed-point to six decimals; Polymarket's are floats. And prices-history is not a trade tape: it is a sampled series, so realized volatility computed off it measures the sampler as much as the market. Our Polymarket Python tutorial shows the difference.

Resolution Metadata Is Where Studies Break

If your question involves outcomes rather than prices, this matters more than the rest of the page. On Kalshi the authoritative settlement_sources array lives on the Series object, not the Market object, which carries no series ticker either, so you join market to event to series to learn what decided the contract. The status enum includes disputed and amended, so a study treating every settled price as final will swallow amended outcomes without noticing.

Polymarket resolves through UMA's optimistic oracle instead: a proposer posts a bond (750 pUSD at the time of writing, pUSD being the dollar-denominated token Polymarket pays winnings in), a two-hour challenge window runs, and a second dispute escalates to a token-holder vote lasting around 48 hours. Undisputed markets settle in about two hours, disputed ones in four to six days. Governance can move any of those four figures without warning, so re-read docs.polymarket.com/concepts/resolution before you build a timing assumption on them. The Gamma fields you would reach for (resolutionSource, umaResolutionStatus, resolvedBy) are all nullable. A settlement source pre-registered in a CFTC contract filing and a post-hoc adjudication by bonded strangers produce variables that share a name and mean different things, so pooling them without a venue effect is a modeling error rather than a cleaning one.

Frequently Asked Questions

Conclusion

Acquisition is the easy part, and everyone underestimates the rest. Pulling candles is an afternoon; reconciling identifiers, polarities, time grids and two incompatible resolution regimes is the project. If you want a default: calibration work whose sample can end before May 2026 starts with Polymarket-v1, and anything past the V2 cutover or spanning Kalshi runs through Predictefy or a collector you maintain yourself. Stream it either way instead of downloading, since Polymarket-v1 is about 49 GB and load_dataset("TimeSeventeen/Polymarket-v1", streaming=True) is enough to start poking at the schema. Read every license before you redistribute anything, which is a legal question, and nothing here is legal or investment advice. If you are still picking a vendor, our roundup of the best prediction market APIs and SDKs is the faster way in.