The order book, hour by hour, since February 2026.

An hourly record of prediction market order book activity running from 2026-02-21T16 UTC — L2 snapshots, the price-change stream between them, trades, and the reference prices around them. Counted on 2 August 2026, 3,868 of the 3,872 hours up to that date were present. The four that are not, we name.

first hour
2026-02-21T16
granularity
1 hour
compressed
2+ TB
events
100B+

Hourly, with every gap named

Coverage starts 2026-02-21T16 UTC. Counted on 2 August 2026, 3,868 of the 3,872 hours up to that date were present — 99.90%. That count carries its date deliberately: this page is static, so it cannot check that ingestion is still running, and a percentage that climbed on its own would be an assertion rather than a measurement. The strip below measures elapsed time from the first captured hour to today — each tick is one day. The earlier hours come from an acquired and mirrored archive, the later ones from our own capture, which begins 30 July 2026.

FEB
MAR
APR
MAY
JUN
JUL
AUG
2026-02-214,129 hours elapsed2026-08-12

The 4 missing hours, in full: 2026-04-04T18 (never captured upstream), 2026-06-11T04 (upstream outage), 2026-06-11T05 (upstream outage), 2026-06-11T06 (upstream outage). They return 404 upstream — the recorder never captured them and no other prefix covers them, so nobody has them. We would rather list four defects than write the word “complete”.

Current order book event rate is on the order of ~100M events per hour. Across the run, 100B+ events is a conservative floor.

What is inside

Seven layers on the same hourly grid, so a book can be reconstructed and the context around it read at the same time. They do not all start together: the order book, trade and tick-size layers run from 2026-02-21T16, while reference prices and perpetuals are our own capture and begin 2026-07-31. Each row says so.

Data layers in the PolySimulator Market Data Archive
LayerCadenceContents
Order book — full snapshotshourlyComplete L2 book state per asset. In our own capture (from 30 July 2026) a median 91.9% of the assets active in an hour receive a full snapshot inside that hour, measured over the 41-hour cross-recorder window. The earlier acquired hours measure 8.6% on the same test and replay from the delta stream instead.
Order book — incrementalstreamThe price-change stream on the book between snapshots, so a book can be replayed forward from a snapshot. This is the densest layer, ~97% of all rows. Our own capture currently holds about 71% of the union of everything both recorders saw; the shortfall is queue saturation on the capture side, measured and being fixed.
TradeseventLast-trade events as they print, carrying price and size. This is the archive’s weakest layer and we would rather say so here than have you find it: against the independent recording, our own-era trade tape grades 31–40% complete and the root cause is still open. Cross-check it against on-chain fills before relying on it for the hours from 30 July 2026.
Tick sizeeventTick-size changes per market — the minimum price increment in force, which moves over a market’s life.
Reference pricesstreamUnderlying spot series and Chainlink TWAP reference prices — the series Up/Down markets actually settle on. This is our own capture and it starts 2026-07-31: it is hour-aligned to the book data from that date forward, and does not extend back to the February start. Day one carries a 37-minute hole.
PerpetualsstreamMarket data for all 29 perpetual instruments on the venue, five channels each. Capture went live 2026-07-31, so this layer is complete as an instrument class from that date — not before it.
Market metadatadaily → hourlyDaily market metadata and resolution snapshots. An hourly metadata layer is rolling out.

Hourly Parquet

zstd-compressed Parquet, partitioned by hour. The hour is the unit of the archive: partitions, quality certificates and coverage are all measured per hour. Some hours are currently written as several part objects rather than one file.

Documented column schema

Column names and types are stable and documented, so a reader written against one hour reads every hour. The schema is not yet published publicly — that is part of the access work, not a property you can check today.

Sorted layouttarget

Sorting rows by market turns “one market over a window” into a contiguous range read instead of a scan of the whole hour, and measures 8.72 bytes per row against 21.18 unsorted. It is implemented and switched off; live hours upload unsorted today.

Compaction to one file per hourtarget

Compaction merges an hour’s part objects into a single file. It has not run yet — hour 2026-07-31T10, for instance, is still 23 separate objects.

How we know it is good

Our own capture runs across sharded websocket connections, and a market that straddles two shards is recorded twice — which is why 1.234 envelopes arrive for every unique event. That is an artefact of the sharding, not a designed second path, and it is being removed at source. Deduplication then runs on a content key finer than the independent recording’s own event key — finer, so two genuinely distinct events are never folded into one — and that step has been proved to destroy nothing at full scale. Each figure below ships with the measurement behind it, including the ones that do not flatter us.

91.9%

Book snapshot coverage — our own capture

how measuredPer hour, the share of assets active in that hour that received a full book snapshot within it. Median over the 41-hour cross-recorder window, measuring our own capture (from 30 July 2026). The independent recording measured 8.6% on the same hours. The earlier, acquired hours — most of the archive by hour count — are a delta-stream record and are not snapshot-anchored this way.

1.234×

Envelope-to-unique-event ratio

how measuredMeasured row ratio against the independent recording over the 41-hour window: 27.52% of rows are duplicates, so roughly a third of unique events carry a second copy. This is a side-effect of markets being split across capture shards, not a designed second path, and it is being engineered away at source. Duplicates are removed by the deduplication step, which is the figure to the right.

0 / 17.1M

Keys destroyed by deduplication

how measuredA dedup-integrity check on one hour: of the 17,105,109 content keys the independent recording had that our deduplicated hour lacked, zero were present in our raw capture — every gap is a capture miss, none is a dedup loss. It proves the dedup step removes exact duplicates and nothing else; it does not claim we recorded everything the other recorder did.

41 h

Cross-recorder validation window

how measuredLength of the differential run, over hours separate from the single-hour dedup check above. The methodology and the per-hour metrics are retained as quality certificates rather than summarised away.

The 41-hour differential was run against an independent third-party recording of the same hours. Its methodology and per-hour metrics are retained as quality certificates rather than collapsed into a single pass/fail.

Questions

What is the PolySimulator Market Data Archive?

An hourly recording of prediction market order book activity running from 2026-02-21T16 UTC and still recording. Counted on 2 August 2026, every hour up to that date is present except four, which are named on the page. It holds full L2 book snapshots, the price-change stream between them, trades, and tick-size changes; underlying spot with Chainlink TWAP reference prices and data for 29 perpetual instruments run from 2026-07-31, not from the February start. It combines our own capture (from 30 July 2026) with an acquired and mirrored archive covering the earlier hours.

Can I access the data?

Not yet self-serve. We are talking to quantitative teams and researchers first, to learn which layers, windows and delivery shapes are actually worth building for. If you have a use for it, describe it — that is what shapes what we open up and in what order.

What formats and schema does it use?

Hourly zstd-compressed Parquet with a stable column schema, documented internally but not yet published publicly. Two format properties are targets rather than current state, and we would rather say so than let you find out on delivery: rows are not yet sorted by market, so a single-market read is still a scan of the hour, and compaction has not run, so some hours are several part objects instead of one file. Both are implemented and switched off rather than unbuilt.

How is quality verified?

Against an independent third-party recording of the same hours, in two separate exercises. First, a dedup-integrity check on one hour: that recording held 17,105,109 content keys our deduplicated hour lacked, and zero of them were present in our raw capture — so every one of those gaps is an event we never received, and none is a key deduplication threw away. Deduplication runs on a content key finer than the independent recording’s own event key, which is why distinct events are never collapsed into one. Second, a 41-hour differential over a different window, whose per-hour metrics — duplicate rate, book snapshot coverage, row ratios — are retained in full as quality certificates rather than summarised into a single pass or fail. Those metrics also record where we come off worse: our unique row count runs at 0.899× the other recorder’s and never exceeds it in any hour of the run.

Do you cover other venues?

Today the archive covers prediction market order book data, the reference price series around it, and 29 perpetual instruments. We have not published coverage beyond that. If there is a venue or an instrument class you need, tell us which one — demand is how we decide what to record next.

Who is behind this?

PolySimulator, a prediction market simulation platform founded in November 2025 at the Technical University of Munich. The archive started as the data we needed to run the simulator honestly, and kept running.

Tell us what you would do with it.

We are not selling anything on this page. We are trying to learn which layers, which windows and which delivery shapes are worth building for — and the fastest way to find out is to hear the actual research question.

Prefer email? Write to [email protected].

or write to [email protected]