Where a dashboard gets its data, and what it loses when that moves

A chart in this category is the last step of a pipeline, and the pipeline starts in one of three places. Either somebody asked the venue, or somebody asked an indexer that had already read the chain and decoded it, or somebody read the chain themselves. The chart looks the same in all three cases. What differs is how far back it can go, how fine the detail is at the far end, and what happens to it on the day the source changes shape — which on Polymarket has happened several times in 2026 alone.

Two neighbouring questions have their own pages and are not repeated here: what a volume figure means once you have it, in why two dashboards disagree on volume, and what the chain can and cannot say about a trader, together with the three clocks from mempool to index, in what wallet tracking shows. This page is about depth and continuity: where the history comes from, and where it stops.

How it works

The venue's own API: current, and forgetful

Both venues this page covers serve their own data, and that is the only source that carries what the venue itself decided — market metadata, rules text, resolutions, the book as it is right now. It is also built to serve the present, and the past is handled as a cost.

Kalshi moves its past behind a cutoff. Its documentation says it plainly: "To keep the live API fast and responsive, Kalshi partitions exchange data into live and historical tiers." For markets, candlesticks, trades, orders and positions, anything older than a cutoff timestamp — resting orders and unsettled positions excepted — disappears from the ordinary endpoints and is served only by a parallel set under /historical/. "The cutoff timestamps will be regularly updated, advancing forward over time", and each data type has its own. Read on 27 September 2026, the live cutoff endpoint returned 00:00 UTC on 29 July 2026 for trades, settled markets and positions, and 00:00 UTC on 13 September 2026 for orders. So on that day the live trade endpoint reached back about two months, and a dashboard written against it had been losing its oldest day, every day, without an error. The mechanics of fetching both halves are in how to get resolved market history.

Polymarket keeps fine detail for 30 days. Its price-history reference is specific: the max interval "returns full history at 12-hour buckets by default", explicit buckets of three or twelve hours "also cover full history", and "finer widths return only the last 30 days". A dashboard started today can draw a minute-by-minute chart of last week and a twice-a-day chart of last year. It cannot draw the first from the second, and no amount of paging on the venue's side changes that. The same reference gives the retention underneath as floors, not promises: one-minute data for at least 7 days, five-minute for at least 60, thirty-minute for at least 90, and three- and twelve-hour data kept permanently.

Pagination is a depth limit as well. Polymarket's v1 Data API pages by offset, and the migration guide notes that "offset stops at 10,000 rows"; in August 2025 the changelog cut the maximum offset on /trades and /activity to 1,000. A backfill that pages by offset reaches a ceiling and stops, and the stop looks like the end of the data. The v2 routes released on 4 September 2026 page by cursor instead, and the market and event listings gained cursor ("keyset") variants in April 2026 for the same reason.

No history endpoint returns a past order book. Kalshi's historical set covers markets, candlesticks, trades, fills, orders and positions. Polymarket's history is a price series. The depth behind a price at a past moment exists only if somebody recorded it while it was live — which is the whole product of PolyOrderbooks, and why its paid plans are priced by lookback window.

And "live" has a lag of its own. Kalshi's reference notes that "there is typically a short delay before exchange events are reflected in the API endpoints", and publishes an endpoint that gives an approximate indication of how current that data is.

An indexer: what the contracts emitted, for as long as someone runs it

On a venue that settles on a public chain, a second layer exists: somebody reads every block, decodes the events the exchange contracts emit, and stores the result in a form a query can use. A subgraph, a curated SQL table and a streaming pipeline are all this, with different interfaces.

On Polymarket the venue's own data service is one of them. The Data API's freshness endpoint, GET /v2/status, describes its own ingestion as "one crawl cursor per (contract, event)" and reports "how far behind chain head what you are reading is". Read at 07:18 UTC on 27 September 2026 it listed 162 cursors on Polygon and a serving lag of two seconds. That is a good reading, and the point is that a reading exists: the wallet, position and profit figures Polymarket itself serves are an indexer's output, with an indexer's failure modes, and the venue has published the gauge for them.

Third-party indexers sell the same thing with a different retention promise. Polymarket's own data resources page points builders at Goldsky, Dune and Allium for "trades, balances, positions, and redeems". Goldsky's Polymarket documentation offers order-filled, orders-matched, balance and position datasets streamed into your own database, "including all historical data" — a backfill from the first block, delivered somewhere you control. Dune is the batch form: curated tables that its card records as running minutes to hours behind the chain, readable in SQL, and gated by plan.

An indexer only sees the contracts it was told to watch. This is the property that matters most for history, and it bit on 28 April 2026. That day Polymarket moved to "new Exchange contracts, a rewritten CLOB backend, and a new collateral token (pUSD)", with "no backward compatibility after go-live" and every resting order wiped. The current contracts page lists the V2 exchange addresses and pUSD. The public subgraph repository, read on 27 September 2026, still lists the V1 exchange address and the USDC.e token in its networks.yaml, and its main branch was last committed to on 8 January 2026. Polymarket may well run updated deployments elsewhere; the repository does not say. But an indexer built from that configuration keeps running, keeps answering queries, and has seen no exchange fill since the cutover. Nothing errors. The chart just goes flat.

And an indexer lasts as long as its host does. The Graph's hosted service, where many public subgraphs used to live, is gone: "As of June 12th, 2024, the hosted service is no longer active. All queries are now powered by The Graph Network." Every dashboard that queried a hosted-service endpoint stopped on that date unless somebody moved it. The same failure at the scale of one product is Brier.fyi, whose repository records the nightly pipeline being paused in January 2026 while the site kept serving the last numbers it had.

The chain itself: complete, and only half the story

Underneath both sits the chain, and it is the one source that does not forget: every settled fill, split, merge and redemption since the first block is in it, and anyone with an archive node can re-derive it. Artemis's methodology names archive nodes and raw block feeds as its path for on-chain venues, rather than a venue-reported figure; OrcaLayer indexes Polygon itself rather than consuming another product's leaderboard; Convexly sells a reconciled read of one wallet with the block it was reconciled at.

What the chain does not have is anything that never became a transaction — the book, the quotes, the cancelled orders — because Polymarket matches off chain and settles on chain. That is the other half of the story and it is told in full in what wallet tracking shows. For depth and continuity the consequence is short: the chain is complete for what it holds, and a pipeline that reads it directly still has to know which contract addresses and which collateral token to read, which is the V2 problem again one layer down.

Kalshi has no second or third layer at all. It is a regulated exchange with no public chain behind it, so every Kalshi figure on every dashboard came from Kalshi — its API, or its own public reporting — and the history a Kalshi dashboard can show is what the venue still serves plus whatever somebody recorded before it moved behind the cutoff.

Which layer a product is on

A product rarely says, but most leave enough to tell.

• Venue API: Kalshi figures everywhere; market metadata, rules and resolution state everywhere, including from the Gamma API; anything labelled live that updates within seconds. Depth limited by the venue's cutoff and resolution windows.
• Indexer: Polymarket wallet, position and profit screens; anything built on Dune, Goldsky or a subgraph. Polymarket Analytics carries a Goldsky logo in its footer. Depth as long as the indexer's configuration and host.
• Own read of the chain: Artemis, OrcaLayer, Convexly, and the snapshot Prediction Market Analysis ships with the collectors that produced it. Depth as long as the operator keeps paying for the node.
• Unstated: Lychee advertises a multi-year archive and, as its card records, names no upstream source for it.

What has already gone missing

None of these is hypothetical. Each is a dated entry in a vendor's own changelog or documentation, and each changed what a dashboard built the week before could show, usually without an error.

Two of those deserve a second look because they fail in the direction nobody checks.

The closed default made a dashboard smaller, not broken. A market count, a category breakdown or a resolved-market accuracy chart built on the default listing kept returning a well-formed answer on 9 April 2026 — just an answer about open markets only. A number that falls is easy to read as a quiet week.

The V1 cutover made an indexer silent, not wrong. Every row it had stayed correct. It stopped growing. A dashboard reading it showed a market that had stopped trading, on the day the venue reopened on new contracts.

The Kalshi row is different in kind: nothing was removed, it was moved, and the documentation says where. The loss is only for a pipeline that never asked. The same is true of Polymarket's offset ceiling, which is documented next to the cursor route that replaces it.

What it costs

Reading the present is mostly free. Keeping the past is where the money goes, and it is priced in three different units, taken from the cards named and, for Dune's gating, from its own documentation.

• Nothing, if you started recording in time. The venue APIs are free to read. A process that saves every trade and every book update from the day it starts owns a history nobody can move behind a cutoff. The cost is the process, and the fact that it cannot go back before its own first day.
• Per gigabyte, if you need ticks from before you started. Predexon bills tick downloads from a prepaid balance: 40 USD per GiB of compressed Parquet for Polymarket, 80 USD for Kalshi ticks and Kalshi book snapshots. Its own worked figure puts a full day of Polymarket at about 13 GiB, roughly 520 USD.
• Per window of lookback, if you need the book. PolyOrderbooks records one-second books for Polymarket's crypto markets and sells the past by depth: three days free, then 19, 29, 39 and 49 USD a month for 30, 60, 90 and 120 days. Anything older is an enterprise conversation, and anything it did not record does not exist anywhere.
• Per plan, if the indexer is somebody else's. Dune's documentation marks several curated tables as gated — Polymarket positions, lifecycle actions and hourly candles, and Kalshi per-fill trades and hourly candles — and its card records the data licence as internal use only on every plan below Enterprise.
• Free, once, as a snapshot. Prediction Market Analysis ships a pre-collected archive of both venues' trades — MIT-licensed code, no stated licence for the data, and no tagged releases, so which vintage you hold is something you record yourself.

Every one of these is a copy made by somebody who started recording before you did. That is the whole of what is being sold.

What you can do about it

Ask any dashboard three questions before trusting its history. A product that has done the work answers each in a sentence.

1. Which layer is this chart reading — the venue's API, an indexer (whose, and on which host), or its own read of the chain?
2. How far back does it go, and at what resolution at the far end? A year of prices at 12-hour buckets and a year at one minute are different claims.
3. What would it show if its source stopped? If the answer is "the last value, unchanged", the chart cannot tell you it has stopped.

Read the source's own gauge. Polymarket publishes one: GET /v2/status on the Data API reports its serving lag, its ingestion cursors and the most lagged of them, with the age of the reading itself. Kalshi publishes the cutoffs at GET /historical/cutoff and a timestamp for how current account data is. A dashboard built on either can print that number beside its chart; one that does not is asking you to assume it is zero.

If you are building, route by date rather than by endpoint. On Kalshi, read the cutoff first and send anything older to the historical endpoints, then merge — the venue's own migration guide says to "query both the live and historical endpoints and merge the results". On Polymarket, page by cursor rather than offset, pass closed=true whenever closed markets belong in the answer, and request price history at the resolution the venue will actually keep.

Pin what your indexer watches, and check it against the venue. Keep the contract addresses and the collateral token your pipeline reads in one configuration file, and compare it with the venue's contracts page whenever the changelog mentions contracts. The V2 cutover is the model failure: the day it happens is the day the chart goes flat.

Record the part nobody keeps. If depth, quotes or minute-level prices matter to you, start a recorder now, from the venue's stream, and store what it sends. That history begins on the day you start it, which is the argument for starting it before you need it. The streaming feeds collection lists the cards with a stream to record from.

Subscribe to two changelogs, not twenty. The venue's and your indexer's. Every row in the table above is recorded in one or the other, and the V2 cutover was announced eleven days before it took effect.

Pick the product by where it reads, not only by what it shows. The analytics and dashboards listing carries, per card, what each product reads and what it cannot see — which is the fastest way to find out whether the history in front of you is the venue's, an indexer's, or somebody's own copy.