Predict.fun Historical Data Guide cover

Predict.fun Historical Data: Candles, Orderbook & Trade History for Quants

Where to get Predict.fun historical data: candles, orderbook depth, and trade history for BNB Chain’s prediction market. What the official API covers, what it doesn’t, and how resolution actually works.

Written by Convex Lake Research Team
· 8 min read
#predict-fun#historical-data#candles#orderbook#quant

Predict.fun launched in December 2025 on BNB Chain and has since become the third-largest prediction-market protocol by TVL, per DefiLlama, with cumulative volume past $2.5 billion. It's also the official prediction-market provider inside the Binance app, which gives it a distribution advantage no other venue in this space has: anyone with Binance installed can browse and trade its markets without leaving the app, gas sponsored. For researchers, the interesting part isn't the volume number. It's that Predict.fun runs real equity markets alongside its crypto ones, on the same 15-minute Up/Down structure, and the two behave nothing alike once you actually pull the data.

Written for quants, researchers, and developers who want programmatic access, not a trading dashboard.

What Predict.fun historical data actually includes

Predict.fun's own developer docs (dev.predict.fun) cover orders, orderbook structure, and authentication in detail. What they don't document on the FAQ page is historical or bulk data access at all — no retention policy, no backfill endpoint, no mention of candle intervals. That's not a criticism of the exchange; a CLOB's core API is built for live trading, and historical research access is a separate concern most venues leave to themselves or to third parties.

What actually exists, pieced together from the live API and real captured data: markets carry metadata (condition IDs, token IDs, category, resolution timestamp), an onchain orderbook gives bid/ask depth per outcome token, trades are individual fills with maker/taker sides, and candles aggregate price and volume into OHLC-style bars per market. Markets run on a central limit order book with a maker/taker matching engine, settled onchain, which is a meaningfully different structure from Polymarket's AMM-adjacent design or Kalshi's regulated-exchange model.

Predict.fun historical data schema. Convex Lake fields; see /docs for the current reference.

Data typeKey fieldsTypical use
Candlestimestamp, open, high, low, close, volume. One file per market, open through resolution.Price history, calibration research
Tradestimestamp, price, size, maker/taker side, outcome tokenVolume analysis, execution research
Orderbookbid/ask levels per outcome token, timestamp, size at each levelSlippage modeling, liquidity research
Resolution metadataoutcome, resolution timestamp, oracle used (UMA or Chainlink, depending on market type)Calibration studies, resolution-mechanism research

Field names reflect Convex Lake's current schema at time of writing. Check convexlake.com/docs for the live reference before integrating.

Predict.fun's official API vs. third-party providers

The official API splits across two environments: api.predict.fun on BNB mainnet, which requires an API key issued through the Developer Console, and api-testnet.predict.fun, which doesn't require one at all. Both are rate-limited to 240 requests per minute. Authentication runs through either a standard EOA wallet or Predict.fun's own smart-wallet account (a Privy-based "Predict Account"). A WebSocket feed at wss://ws.predict.fun/ws handles live updates; Python, TypeScript, and Rust SDKs all exist.

That covers live trading well. It's thinner on exactly the thing a backtest or calibration study needs: no documented bulk historical export, no stated data-retention window, no candle-interval reference beyond what you can infer from the live orderbook and trades endpoints. If your question is "give me every BTC 15-minute market's full price history for the last six months," the official docs don't point to a direct answer.

Comparing Predict.fun historical data sources

Source typeAccess requirementOrderbook depthSetup effortBest for
Predict.fun official APIAPI key via Developer Console (mainnet); none needed on testnetLive book; no documented bulk historical archiveYou build storage, pagination, backfill logicTeams building directly against live trading, not historical research
Onchain indexers (e.g. Envio-based feeds)Depends on indexer; typically self-serviceFull depth, reconstructed from chain eventsRequires running or querying a GraphQL indexerTeams comfortable working from raw onchain event data
Third-party scrapersAccount with the providerVaries — often snapshot-based, not full depthMinimal, pre-builtQuick exploratory pulls, not execution-sensitive backtests
Convex LakeAPI key, self-serviceBatch and real-time orderbook snapshots, trades, candlesREST API, documented endpointsResearch spanning Predict.fun plus other prediction and crypto-options venues under one schema

How Predict.fun's resolution mechanism affects the data

Predict.fun doesn't use one oracle for everything. Per the platform's own rollout, most markets resolve through UMA's Optimistic Oracle — anyone can propose an outcome with a bond, and it stands unless challenged within a window. Its 15-minute BTC markets resolve differently: Chainlink price feeds, specifically Chainlink's DataLink product sourcing from Binance's order books. That's a narrower feed than Chainlink's standard multi-exchange aggregation methodology, a distinction covered in more depth in our resolution-sources research.

For anyone doing calibration work, this matters directly: a dispute-based oracle (UMA) and a continuous price feed (Chainlink) resolve on different timeframes and against different failure modes. A market that resolves via UMA can, in principle, sit in a challenge window; a Chainlink-resolved market settles the moment the feed crosses the threshold. Pooling both market types into one Brier-score sample without accounting for that is mixing two different resolution processes under one number.

Predict.fun's market structure: crypto and stocks on the same template

Predict.fun runs 15-minute Up/Down markets on both crypto and real equities, under the stock_15min/qa_stock_updown and crypto-equivalent ticker types, and the two don't behave the same way once you pull real data.

Crypto Up/Down markets (BTC, ETH, BNB) carry full open/close price data on every resolved file and resolve close to 50/50 overall. Stock Up/Down markets, covering real tickers including AMZN, AVGO, GOOGL, META, MSFT, MU, NVDA, SPCX, and TSM, carry the categorical outcome only — no price data populates on any resolved stock file in Convex Lake's own captured history. That's a genuine structural gap, not a trading-behavior difference, and it most likely traces to equities data licensing being more restricted than the crypto feeds already powering Predict.fun's other markets. Anyone building a strategy or research pipeline around Predict.fun's stock markets specifically needs to know up front that direction is all this dataset gives you; magnitude has to come from elsewhere.

Downloading and querying Predict.fun historical data via API

A typical query flow through Convex Lake:

  1. Get an API key. Self-service, no BNB wallet or Predict.fun account needed. Generate one on the API Keys page and send it as x-api-key on every request.
  2. Pick a venue and market. Requests are scoped with exchange=predictfun plus a market identifier and date or timeframe.
  3. Pull the file. Download endpoints return the requested trades, orderbook, or candle file for that market and date.
  4. Store and join. Land files in your own storage and join on market/condition ID across trades, candles, and orderbook data.

A minimal example against Convex Lake's candles endpoint:

curl -O -J -H "x-api-key: do_YOUR_KEY" \
  "https://api.convexlake.com/candles?exchange=predictfun&ticker=btc&market=<market-id>&date=2026-09-15&slug=<slug-from-info>"

Field names and exact query parameters differ slightly by endpoint. Check the API docs for the current reference before building against it.

Common research and backtesting use cases

Calibration research uses candle price history through resolution to check whether Predict.fun's pricing adds real information over an uninformed guess, and whether that holds equally across its UMA- and Chainlink-resolved markets. Cross-venue comparison sets Predict.fun's BTC/ETH/BNB pricing against Kalshi and Polymarket's equivalent short-dated crypto markets, since all three run structurally different designs (strike ladder, threshold range, and clean Up/Down windows respectively) on the same underlying asset. Directional-bias testing checks whether Predict.fun's 15-minute windows show any real hour-of-day or day-of-week edge, something worth testing carefully given how easily correlated same-day price moves can look like a time-of-day pattern that isn't really there. Liquidity research looks at how trading concentrates by symbol and time of day on a venue that's barely a year old and still finding its active-hours pattern.

Data quality pitfalls to watch for

Stock markets carry no price-magnitude data. As covered above, only the Up/Down outcome is recoverable for Predict.fun's equity markets in Convex Lake's own captured history. Don't assume a stock file will behave like a crypto file with the same ticker structure.

Two different oracles resolve two different market types. Mixing UMA-resolved and Chainlink-resolved markets into one calibration sample without tracking which is which conflates a dispute-based resolution process with a continuous-feed one.

BNB Chain finality and indexing lag. Onchain settlement means resolution timestamps depend on block confirmation, not just an exchange's internal clock. Worth checking how a given data source handles that gap before trusting timestamps to the second.

A young venue's history is short by construction. Predict.fun launched in December 2025. Any "historical" archive, from any provider, only covers the period since launch, and most third-party capture started even later than that. Don't expect multi-year history here the way you might for Deribit.

Binance-app distribution may skew activity patterns. With Binance's own user base able to trade Predict.fun markets without leaving the Binance app, trading-hours and volume patterns here may reflect Binance's broader user geography rather than a prediction-market-native audience specifically — worth checking before assuming findings transfer from Kalshi or Polymarket's user bases.

Glossary: key terms in Predict.fun historical data

CLOB (central limit order book) is Predict.fun's market structure: maker limit orders sit on the book until a taker order matches against them, as opposed to an AMM's continuous pricing curve. Condition ID is the onchain identifier for a specific market's outcome set. UMA Optimistic Oracle resolves most of Predict.fun's text-outcome markets: a proposed answer stands unless challenged within a bond-backed dispute window. Chainlink DataLink resolves Predict.fun's 15-minute BTC markets specifically, sourcing price data from Binance's order books. Calibration measures how closely a market's implied probability matches its actual resolution rate across many markets. Brier score is the standard scoring rule for that, where lower is better.

FAQ

Does Predict.fun's official API provide historical data? Not in a documented, bulk sense. The official API and its FAQ cover live orders, orderbook structure, and authentication, but don't document a historical-data endpoint, retention policy, or candle-interval reference. Third-party providers, including Convex Lake, fill that specific gap.

Do I need a BNB wallet to get Predict.fun historical data from a third-party provider? No. That requirement applies to Predict.fun's own API (EOA wallet or Predict Account) and to trading on the platform itself. A provider API key doesn't require a wallet or onchain account.

Does Predict.fun have historical price data for its stock markets? Outcome data only, based on Convex Lake's own captured history — no open/close price populates on resolved stock-market files, unlike Predict.fun's crypto markets, which carry full price data. Treat Predict.fun's stock markets as direction-only for research purposes.

How are Predict.fun markets resolved? Depends on the market type. Most resolve through UMA's Optimistic Oracle (a proposed outcome stands unless disputed within a bond-backed window). Its 15-minute BTC markets resolve via Chainlink price feeds instead, specifically Chainlink's DataLink product sourced from Binance's order books.

How far back does Predict.fun historical data go? Not far, by construction: the platform launched in December 2025. Any provider's archive only covers the period since it started capturing data, which for most third parties is later than launch itself.

Is Predict.fun the same as Predict.fun's integration inside the Binance app? Same platform, two access points. Predict.fun runs independently at predict.fun and dev.predict.fun; since April 2026 its markets are also browsable and tradeable directly inside the Binance app, with Binance Wallet sponsoring gas costs for that path specifically.

Getting started with Convex Lake's Predict.fun historical data

Convex Lake covers Predict.fun alongside Kalshi, Polymarket, Limitless, and Deribit under one API, batch and real-time: orderbook snapshots, trade history, candle data. One schema instead of stitching together five. See the API docs for the current endpoint reference, or get in touch for access.

Convex Lake

A comprehensive financial technology platform for prediction market data and quantitative analytics

Resources

Company

© 2026 Convex Lake. All rights reserved.