Limitless is a central-limit-order-book prediction market built natively on Base, where orders match on-chain rather than off-chain with later settlement — a meaningfully different design from Polymarket's or Predict.fun's. That difference shows up directly in the data: every fill is itself a confirmed Base transaction, and the official API is built for live trading first, with historical and bulk analytics access a clear second priority.
Written for quants, researchers, and developers who want programmatic access, not a trading dashboard.
What Limitless historical data actually includes
Limitless's own developer docs (docs.limitless.exchange) organize the REST API into Authentication, Markets, Trading, System, Partner Accounts, and Portfolio. Historical prices exist, but they're listed under Trading alongside order management, not under any dedicated analytics or historical-data section — and there's no candlestick or OHLC endpoint, no bulk historical export, and no stated retention or depth limit anywhere in the official reference. That's a real, checkable gap, not an assumption.
What actually exists, pieced together from the live API and real captured data: each market runs separate Yes and No order books, not one shared book — a trade on one side needs its price read against that side's own book, not inferred from the other. Markets cover short-duration crypto Up/Down windows (hourly and daily) across BTC, ETH, BNB, DOGE, SOL, XRP, HYPE, XMR, and SUI, plus daily windows on real equities and ETFs (AMZN, GOOGL, META, TSLA, SPY, LMT, and SpaceX-linked contracts). Markets settle fully on-chain, with no liquidation risk on the exchange's side.
Limitless historical data schema. Convex Lake fields; see /docs for the current reference.
| Data type | Key fields | Typical use |
|---|---|---|
| Orderbook | bids/asks per outcome token, price, size, timestamp | Slippage modeling, liquidity research |
| Trades | timestamp, price, size, maker/taker side | Volume analysis, execution research |
| Candles | timestamp, open, high, low, close, volume per market | Price history, calibration research |
| Resolution metadata | outcome, resolution timestamp, oracle used (Pyth or Chainlink Data Streams, 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.
Limitless's official API vs. third-party providers
The official REST API sits at api.limitless.exchange, with a WebSocket feed at wss://ws.limitless.exchange for real-time orderbook and position updates. Public endpoints — market browsing, orderbook — need no credentials; authenticated endpoints use scoped API tokens with HMAC-SHA256 request signing (legacy static API-key headers are deprecated and no longer issued). Rate limits aren't published as specific numbers; exceeding one returns an HTTP 429 with a recommendation to honor Retry-After or back off exponentially, and the docs point higher-limit requests to Limitless's own support email.
That covers live trading and real-time streaming well. It's thin on exactly what a backtest or calibration study needs: no documented bulk historical export, no candle-interval reference, no stated history depth. If your question is "give me every BTC hourly market's full price history for the last three months," the official docs don't point to a direct answer — you're left querying on-chain event logs yourself, or going through a third party.
Comparing Limitless historical data sources
| Source type | Access requirement | Orderbook depth | Setup effort | Best for |
|---|---|---|---|---|
| Limitless official API | Scoped API token (HMAC-signed); public endpoints need none | Live book; historical prices exist but no bulk export or candle endpoint | You build storage, pagination, backfill logic | Teams building directly against live trading, not historical research |
| On-chain subgraphs (community-run) | Self-service, no Limitless account | Full depth, reconstructed from on-chain events (trades, positions, splits/merges) | Requires running or querying a GraphQL indexer | Teams comfortable working from raw on-chain event data |
| Third-party aggregators | Account with the provider | Varies — often price/odds snapshots, not full depth | Minimal, pre-built | Quick exploratory pulls, not execution-sensitive backtests |
| Convex Lake | API key, self-service | Batch and real-time orderbook snapshots, trades, candles | REST API, documented endpoints | Research spanning Limitless plus other prediction and crypto-options venues under one schema |
How Limitless's on-chain matching and resolution affect the data
Limitless matches orders on-chain on Base — each fill is itself a confirmed Base transaction, not an off-chain match settled later. Base's standard block time is 2.0 seconds, though Base's Flashblocks feature streams 200ms soft preconfirmations within that window, live on mainnet. That architecture detail matters for anyone reconstructing execution timing from this data: a trade's recorded timestamp reflects on-chain confirmation, and two fills in the same block can appear to happen "simultaneously" even when they didn't.
Resolution runs through two different oracles depending on market type. Pyth Network is the primary price oracle for most of Limitless's data-feed markets. Chainlink Data Streams was added in June 2026, specifically carved out for short-duration crypto markets — which were running around 19,000 markets a week by mid-2026. Which oracle actually prices a given market depends on its duration, not a single platform-wide choice; mixing both market types into one calibration sample without tracking which resolved against which oracle conflates two different resolution processes.
Limitless's market structure: one book per outcome, not one per market
A Limitless market isn't one order book — it's two, one for the Yes token and one for the No token, and a contract's price only means something read against its own side's book. This isn't a minor implementation detail: reconstructing a fill or simulating a trade against the wrong side's book produces a result that looks plausible but is simply wrong. Convex Lake's own research confirms this matters in practice — a prior study simulating realistic trade execution on Limitless found that getting this convention backwards for even one side of a market produced nonsensical, order-of-magnitude-wrong results before the fix (see our copytrading slippage research, which used real Limitless order-book archives for exactly this kind of reconstruction).
The same research found Limitless's hourly crypto markets have genuinely thin order books outside a liquid core: near-touch depth of a handful of shares is common in the back half of a market's life, with the next real resting liquidity sitting far out near the contract's extremes. Anyone building execution-sensitive tooling on Limitless data should expect that pattern, not assume continuous, evenly-distributed depth just because a market is listed.
Downloading and querying Limitless historical data via API
A typical query flow through Convex Lake:
- Get an API key. Self-service, no Base wallet or Limitless account needed. Generate one on the API Keys page and send it as
x-api-keyon every request. - Pick a market. Requests are scoped with
exchange=limitlessplus a market identifier and date or timeframe. - Pull the file. Download endpoints return the requested trades, orderbook, or candle file for that market and date.
- Store and join. Land files in your own storage and join on market ID across trades, candles, and orderbook data.
A minimal example against Convex Lake's orderbook endpoint:
curl -O -J -H "x-api-key: do_YOUR_KEY" \
"https://api.convexlake.com/orderbook?exchange=limitless&market=<market-id>&date=2026-09-15"
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 Limitless's pricing adds real information over an uninformed guess, and whether that holds equally across its Pyth- and Chainlink-resolved markets. Execution research simulates realistic order fills against real order-book depth rather than assuming a perfect fill at the midpoint — directly relevant given how thin Limitless's books can get late in a market's life. Cross-venue comparison sets Limitless's BTC/ETH/BNB pricing against Kalshi, Polymarket, and Predict.fun's equivalent short-dated crypto markets, since all four run structurally different designs on the same underlying asset. On-chain timing research looks at how Base's block time and Flashblocks preconfirmations affect the realistic latency of acting on or reacting to a trade.
Data quality pitfalls to watch for
Yes and No are separate books. Reading a trade's price against the wrong side's order book produces a plausible-looking but wrong result — confirmed directly in Convex Lake's own research before it was caught and fixed.
Thin depth late in a market's life. Near-touch liquidity can collapse to a handful of shares well before a market resolves, with the next real resting orders sitting far out near the extremes. A spread statistic or simulated fill price computed without checking actual depth can be badly misleading.
Two different oracles resolve two different market types. Mixing Pyth-resolved and Chainlink-resolved markets into one calibration sample without tracking which is which conflates a different-latency, different-source resolution process.
On-chain confirmation timing, not a trading-engine timestamp. A fill's recorded time reflects Base block confirmation. Two fills in the same block can look simultaneous even when their actual order differed.
No bulk historical export from the official API. Building a large backtest means either querying on-chain logs yourself or going through a third party — budget for that rather than expecting a single bulk download endpoint.
Glossary: key terms in Limitless historical data
CLOB (central limit order book) is Limitless's market structure: maker limit orders sit on the book until a taker order matches against them. On-chain matching means each fill is itself a confirmed blockchain transaction, not an off-chain match settled later — Limitless's design, as opposed to Predict.fun's off-chain-match/on-chain-settle model. Flashblocks are Base's 200ms soft preconfirmations, streamed within the standard 2.0-second block interval. Pyth Network and Chainlink Data Streams are Limitless's two resolution oracles, split by market duration. Calibration measures how closely a market's implied probability matches its actual resolution rate across many markets.
FAQ
Does Limitless's official API provide historical data? Not in a documented, bulk sense. Historical prices exist under the Trading endpoint group, but there's no candlestick/OHLC endpoint, no bulk export, and no stated retention limit. Third-party providers, including Convex Lake, fill that specific gap.
Do I need a Base wallet to get Limitless historical data from a third-party provider? No. That requirement applies to Limitless's own trading API (EIP-712 signatures against a Base-deployed contract) and to trading on the platform itself. A provider API key doesn't require a wallet.
Why does a market have two order books instead of one? Limitless prices Yes and No as separate tokens, each with its own book. A contract's price only means something read against its own side — reading it against the wrong book produces a plausible but incorrect result.
How are Limitless markets resolved? Depends on the market. Pyth Network is the primary oracle for most data-feed markets. Short-duration crypto markets added Chainlink Data Streams in June 2026 specifically for that use case.
How far back does Limitless historical data go? Limited by when a given provider started capturing it — the official API doesn't document a retention window, and on-chain history is only as complete as someone's indexer has captured since Limitless's own launch.
Getting started with Convex Lake's Limitless historical data
Convex Lake covers Limitless alongside Kalshi, Polymarket, Predict.fun, 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.