Polymarket Orderbook Archive archive.pendulumflow.com

Archive audit

We audit this corpus rather than assert it is complete. The method is published here before the results exist, so the results can disagree with us, and a check that has not run yet says so and nothing else. The per-hour checks re-run as hours are published; the record this page reads was written 2026-10-10T02:26Z.

Results: how complete is each corpus, measured against the chain

These are the audit's first published results. Every figure below is measured against on-chain fills for the same hour, by a program that reads the chain and never reads the archive. v3 is our own capture, merged from several machines.

Six hours were drawn per corpus, and the hours were written down before anything was measured. That is the whole reason these numbers are worth reading, and it is also their limit: six hours is a floor, not a sample large enough to describe a corpus. Nothing here is a population rate.

CorpusHoursTraded markets FoundRatioMissing
v3 (ours) 620,735 20,7351.0000 0
AG6 620,601 20,5540.9977 47
pmxt/v2 620,900 18,1970.8707 2,703
pmxt/v1 625,780 16,7560.6500 9,024

Ranked: v3 > AG6 > v2 > v1. This is the first time these four corpora have been graded against the same independent record.

Were those hours ordinary ones?

Six hours per corpus is a floor rather than a sample, and that was published before anybody could say whether the six were typical hours. Now they can be. The denominator, markets with at least one on-chain fill, has been read for every hour from 2026-02-21 00:00 to 2026-08-31 23:00 UTC. That is 4,608 hours. 4,592 of them have a denominator; the 16 that do not are listed below. It reproduces all 24 of the denominators in the table above exactly. Two readings, taken weeks apart, no disagreement.

CorpusHours with a denominatorMedian traded Drawn medianDraw vs era Drawn hours sit at
v3 (ours) 3313,389 3,440+1.5% 20th to 89th
pmxt/v2 2,7733,643 3,482-4.4% 17th to 61st
pmxt/v1 1,2964,131 4,247+2.8% 13th to 94th

Hours with a denominator are the calendar hours in each era, minus the hours for which the record we read carries no rows. That is a gap in the record, not a quiet venue: the hours are listed below, and for eleven of them a second index of the same contracts shows fills throughout. They are not file counts; those are in the mirrored eras section below.

No draw's median sits more than 4.4% from its era's median, so none of these results rests on quiet hours. v3 (ours) and pmxt/v1 each reach down to the 20th percentile or lower and up to the 89th or higher.

pmxt/v2 is the exception worth naming. Its six hours stop at the 61st percentile, so this corpus has not been measured on a genuinely busy hour, and the worst of the six is its busiest. Six hours cannot settle it. It is noted because quiet hours flatter a corpus.

16 hours the denominator could not account for

The on-chain fill record we read has no rows at all for 16 hours inside that range, in 3 windows. We are not publishing them as zero. A denominator of zero does not produce a missing ratio, it produces a confident one.

No rows forHoursTraded, hour before Traded, hour after
2026-04-28 00:00 to 2026-04-28 10:00 11 3,559 76
2026-08-26 05:00 to 2026-08-26 06:00 2 347 1,183
2026-08-31 07:00 to 2026-08-31 09:00 3 948 1,458

The archive-wide median is 3,737 markets an hour, which is what makes the last two columns worth reading. 2 of them are entered from an hour already far below it and left through another one that is still far below it, which is the shape of a venue winding down and coming back: 2026-08-26 05:00 and 2026-08-31 07:00. Our own capture is thin or absent across both too. The exchange published its own record of both: see the venue incidents for 2026-08-26 05:00 and 2026-08-31 07:00 above.

2026-04-28 00:00 does not fit that story. The hour before it traded 3,559 markets, an ordinary hour, and then 11 hours hold nothing at all. pmxt/v2 carries 223 to 379 MiB of orderbook for each of them, which is an ordinary quiet-ish hour of book traffic, and a venue does not stream that much book while matching nothing for 11 hours running. It is a hole in the record we read, not a quiet venue. The chain produced fills through every one of these hours: a second, independent index of the same contracts shows 1,000 to 1,800 fills an hour straight through. The record we read for the denominator changes source at 2026-04-28T00Z, and these eleven hours were never loaded into the new source. They will be re-read from the chain. Until then these hours have no denominator. read from a second index of the same contracts, 2026-09-02 These hours are unmeasured, not quiet, and anyone deriving their own coverage figures from this archive should treat them as such.

We predicted v2 would be complete. It was not.

Before any measurement, the audit predicted that v2-era capture, both pmxt/v2 and our own union, would come back with zero missing markets, and named the falsifier in advance: any non-phantom missing market in a v2-era hour.

pmxt/v2 failed it in all six hours, with 2,703 missing markets. An earlier pilot hour had read a perfect 1.000000 and that turned out to be the hour, not the corpus, which is exactly what a conveniently chosen hour does when it is allowed to speak for a population, and exactly why the pilot pair was excluded from this draw before any number existed.

Our own union capture is the only one that held the prediction: 6 of 6 hours at exactly 1.0000. The failed prediction is published beside the one that held.

v1: the phantom fills do not explain it

Roughly half of v1-era fills are phantom, 46.0% to 48.1% across the six drawn hours, and the obvious question is whether that explains v1's low score. It does not, and the check is simple.

In all 24 drawn hours, 0 markets have only phantom fills. Every traded market has at least one real fill. So the set of genuinely traded markets is identical to the traded set, and v1's gap survives the split untouched. A phantom fill rate is a property of fills; it cannot explain a market that is missing, because that market traded for real.

A second check agrees. Over the 5 usable hours where v1 and v2 overlap, v1 lacks 41.93% of the markets v2 holds in those hours. v2 lacks 2.28% of the markets v1 holds. Chain side and corpus side share no input and point the same way. One hour, 2026-04-15/09, is excluded by name: the v1 object for this hour holds zero rows, and an empty hour is an absent hour rather than a missed market.

AG6 against pmxt/v2, on the hours they share

The two v2-era corpora can be graded against each other as well as against the chain. Over the 7 hours both cover, on the same 26,249 traded markets: AG6 0.9972 (73 missing) against pmxt/v2 0.9896 (272 missing).

The set difference has to be split by whether the market traded, and it is the whole of the AG6 finding. 47 traded markets are in pmxt/v2 and not in AG6, against 4,298 untraded ones. A missing untraded market is a breadth difference; a missing traded market is a capture hole. Added together they would say AG6 is missing 4,345 markets. 4,298 of those never traded in the hour.

Over the 7 shared hours AG6 lacks 73 traded markets against the chain. 47 of those are present in pmxt/v2; the other 26 are absent from both. The 47 traded markets AG6 missed in its six drawn hours, above, is a different count over different hours.

v2 improves across its own span, so no single v2 figure means anything alone

0.4524 at 2026-06-19/07 and 0.9939 at 2026-08-02/02: the shape of a capture being built out. Quote a v2 ratio without its hour and you have said nothing.

Every hour, with its denominator

The ratio is shown beside the traded count it divides, because 0.9994 over 3,478 traded markets and 0.9939 over 3,460 are different claims, and the per-hour denominators vary several-fold inside a single corpus.

CorpusHourTraded markets RatioMissing
v3 (ours)2026-08-18/14 3,8171.0000 0
v3 (ours)2026-08-18/23 2,9571.0000 0
v3 (ours)2026-08-19/00 3,1611.0000 0
v3 (ours)2026-08-19/03 2,8971.0000 0
v3 (ours)2026-08-19/15 4,1851.0000 0
v3 (ours)2026-08-19/23 3,7181.0000 0
AG62026-08-11/23 2,9590.9980 6
AG62026-08-13/01 3,2330.9978 7
AG62026-08-13/18 4,2430.9967 14
AG62026-08-14/01 2,9230.9990 3
AG62026-08-14/10 3,4450.9977 8
AG62026-08-14/12 3,7980.9976 9
pmxt/v22026-06-19/07 3,7910.4524 2,076
pmxt/v22026-07-17/05 3,1830.9400 191
pmxt/v22026-07-21/16 3,5740.9664 120
pmxt/v22026-07-24/21 3,3880.9244 256
pmxt/v22026-08-02/02 3,4600.9939 21
pmxt/v22026-08-08/06 3,5040.9889 39
pmxt/v12026-02-23/23 3,4780.9994 2
pmxt/v12026-03-12/17 5,2150.7168 1,477
pmxt/v12026-03-12/18 4,7680.6804 1,524
pmxt/v12026-03-20/00 4,1590.3224 2,818
pmxt/v12026-03-21/09 4,3340.4742 2,279
pmxt/v12026-04-15/01 3,8260.7585 924

Pre-registration 5ae4e8765d601145, draw 02a94091dea9c11f, measured 2026-08-31. 24 of 24 drawn hours reported, none dropped and none re-drawn.

Venue incidents

Times the exchange itself stopped or degraded. An hour can be tiny because the venue paused trading rather than because we missed anything, so those hours are recorded here rather than among our own gaps. Each entry opens to what the venue published, what we measured, and what we are not claiming.

Trading degraded for eighteen minutes, 2026-09-23T18:06Z to 2026-09-23T18:24Z

1 hour

1 hour of v3/ is affected: 2026-09-23T18.

What the venue recorded. Trading degraded on the predictions CLOB; investigating at 18:06, resolved at 18:24, 18:06 to 18:24 UTC, naming Predictions, Trading API (CLOB). Their record.

What we measured.

  • Hour 2026-09-23T18 holds 124,066,530 rows, against 137,879,019 at T17 and 123,436,325 at T19, with all five machines contributing and every minute present. Read from the hour's own record once the merge landed; when this entry was first written the merge was running 30 to 80 minutes behind and no figure was available.
  • The venue's window covers eighteen minutes of one hour; on 11 September a forty-one-minute window of the same class left its hour at about 60% of its neighbours.

What we are not claiming.

  • That the eighteen-minute window shows in the row count. T18 sits between its neighbours, so if the degradation thinned the feed it did so by less than the ordinary hour-to-hour variation.
  • That anything was lost. Nothing here measures completeness.

Perpetuals maintenance, on a market this archive does not record, 2026-09-22T08:00Z to 2026-09-22T08:46Z

1 hour

1 hour of v3/ is affected: 2026-09-22T08.

What the venue recorded. Perpetuals scheduled maintenance, filed by the venue as an incident, 08:00 to 08:46 UTC, naming Perpetuals. Their record.

What we measured.

  • Nothing moved here. Hour 2026-09-22T08 holds 106,527,702 rows between 103,930,007 at T07 and 114,157,354 at T09.
  • All seven products are present and none of them is empty.
  • The venue's record names Perpetuals components only. This archive records the prediction-market CLOB.

What we are not claiming.

  • That the two markets share nothing. One ordinary hour is an absence of movement rather than a proof of isolation.
  • That this hour is verified. Only that the venue had maintenance on another market and our hour looks like its neighbours.

Trading paused by degraded block production on Polygon, 2026-09-19T19:38Z to 2026-09-19T20:20Z

2 hours

2 hours of v3/ are affected: 2026-09-19T19, 2026-09-19T20.

What the venue recorded. Trading paused; the venue attributed it to degraded block production on Polygon PoS delaying transaction confirmations, and cited Polygon's own incident, 19:38 to 20:20 UTC, naming Predictions, Trading API (CLOB), Clob Websocket, Websocket (RTDS), Markets and Position data, On-chain settlement (Polygon RPC). Their record.

What we measured.

  • Hour 2026-09-19T19 holds 52,580,510 rows and T20 86,535,699, against 127,709,593 at T21 and 131,548,869 at T22: about 41% and 68% of the hours after, recovering from the cancel-only afternoon before this pause began.
  • The venue's window covers the last twenty-two minutes of T19 and the first twenty of T20; both hours are also recovering from the earlier incident, so neither figure is this pause's alone.
  • All seven products are present in both hours and none of them is empty.

What we are not claiming.

  • That anything was lost. A paused venue emits little; nothing here measures completeness.
  • That the shortfall in these hours belongs to this pause rather than to the recovery from the cancel-only window that ended at 18:58. The two overlap in effect and cannot be separated from row counts.

Trading degraded, then cancel-only mode, 2026-09-19T16:54Z to 2026-09-19T18:58Z

3 hours

3 hours of v3/ are affected: 2026-09-19T16, 2026-09-19T17, 2026-09-19T18.

What the venue recorded. Trading degraded across the CLOB, both websocket transports, market data and on-chain settlement; the venue moved to cancel-only mode at 17:59 while it found the root cause, and re-enabled trading at 18:58, 16:54 to 18:58, cancel-only from 17:59 UTC, naming Predictions, Trading API (CLOB), Clob Websocket, Websocket (RTDS), Markets and Position data, On-chain settlement (Polygon RPC). Their record.

What we measured.

  • Hour 2026-09-19T17 holds 4,652,601 rows and T18 8,877,520, against 140,933,886 at T16 and 154,303,063 at T15: about 3% and 6% of the hours before. T16, which the window enters at 16:54, is ordinary.
  • The venue's window covers all of T17 and the first fifty-eight minutes of T18. Two hours at a few percent of their neighbours is what a book with no new orders looks like from inside.
  • All seven products are present in all three hours and none of them is empty.

What we are not claiming.

  • That anything was lost. In cancel-only mode the book changes only by cancellation, so there was little to emit; nothing here measures completeness.
  • That the two records of 19 September are one event. The venue filed them separately and gave the second a different cause; this register keeps them apart.

Perpetuals maintenance, on a market this archive does not record, 2026-09-17T08:00Z to 2026-09-17T08:32Z

1 hour

1 hour of v3/ is affected: 2026-09-17T08.

What the venue recorded. Scheduled perpetuals maintenance for a component release, 08:00 to 08:32 UTC, naming Perpetuals. Their record.

What we measured.

  • Nothing moved here. Hour 2026-09-17T08 holds 104,583,570 rows between 101,817,430 at T07 and 112,316,211 at T09.
  • All seven products are present and none of them is empty.
  • The venue's record names Perpetuals components only. This archive records the prediction-market CLOB.

What we are not claiming.

  • That the two markets share nothing. One ordinary hour is an absence of movement rather than a proof of isolation.
  • That this hour is verified. Only that the venue had maintenance on another market and our hour looks like its neighbours.

Scheduled CLOB maintenance, no downtime expected, 2026-09-15T04:00Z to 2026-09-15T04:30Z

1 hour

1 hour of v3/ is affected: 2026-09-15T04.

What the venue recorded. Periphery services of the CLOB updated; the venue expected no downtime and named API-key creation and deletion as the only exposure, 04:00 to 04:30 UTC, naming Predictions, Trading API (CLOB). Their record.

What we measured.

  • Nothing moved here. Hour 2026-09-15T04 holds 97,604,681 rows between 107,559,133 at T03 and 104,163,231 at T05: inside the night's ordinary range.
  • All seven products are present and none of them is empty.

What we are not claiming.

  • That the maintenance cost us nothing. A 9% step down from the hour before is not distinguishable from ordinary variation at this scale.
  • That this hour is verified. Only that the venue announced maintenance expecting no downtime and our hour sits inside the night's range.

Trading degraded for forty-one minutes, 2026-09-11T16:22Z to 2026-09-11T17:02Z

2 hours

2 hours of v3/ are affected: 2026-09-11T16, 2026-09-11T17.

What the venue recorded. Trading degraded on the predictions CLOB; the venue reported a fix in progress at 16:22 and resolution at 17:02, 16:22 to 17:02 UTC, naming Predictions, Trading API (CLOB). Their record.

What we measured.

  • Hour 2026-09-11T16 holds 73,157,491 rows and T17 93,268,067, against 121,970,982 at T15 and 127,991,978 at T18: about 60% and 73% of their neighbours.
  • The venue's window covers the last thirty-eight minutes of T16 and the first two of T17. The shortfall sits in the hour the window mostly covers, which is the right order.
  • All seven products are present in both hours and none of them is empty.

What we are not claiming.

  • That anything was lost. Degraded trading emits less; nothing here measures completeness.
  • That the shortfall divides by the clock. Volume is not flat across an hour.

Perpetuals maintenance that overran, on a market this archive does not record, 2026-09-08T22:02Z to 2026-09-09T00:38Z

3 hours

3 hours of v3/ are affected: 2026-09-08T22, 2026-09-08T23, 2026-09-09T00.

What the venue recorded. Scheduled perpetuals maintenance with up to an hour of downtime, completed at 23:10, then unexpected downtime from 00:16 until 00:38, 22:02 to 23:10, then 00:16 to 00:38 UTC, naming Perpetuals. Their record.

What we measured.

  • Nothing moved here. Hours 2026-09-08T22, T23 and 2026-09-09T00 hold 87,559,933, 87,040,564 and 101,800,404 rows, between 86,386,524 at T21 and 104,747,362 at T01: the evening's ordinary rise.
  • All seven products are present in each hour and none of them is empty.
  • Every line of the venue's record names Perpetuals components. This archive records the prediction-market CLOB.

What we are not claiming.

  • That the two markets share nothing. They share a venue, and three ordinary hours are an absence of movement rather than a proof of isolation.
  • That these hours are verified. Only that the venue had maintenance overrun on another market and our hours look like their neighbours.

Venue paused trading, then twice more in cancel-only mode, 2026-09-03T17:06Z to 2026-09-03T21:35Z

5 hours

5 hours of v3/ are affected: 2026-09-03T17, 2026-09-03T18, 2026-09-03T19, 2026-09-03T20, 2026-09-03T21.

What the venue recorded. Delayed open order read responses; trading paused, resumed through a cancel-only window, then returned to cancel-only when the degradation came back, 17:06 to 21:35, paused from 17:06, cancel-only until 19:35, cancel-only again from 19:58 to about 20:34 UTC, naming Predictions, Trading API (CLOB). Their record.

What we measured.

  • Hour 2026-09-03T17 holds 9,048,653 rows against 112,072,991 in the hour before, which is 8.1%. The venue paused trading at 17:06, six minutes into the hour.
  • 2026-09-03T18 holds 471,243 rows, 0.4% of the hour before the pause. It is the smallest hour this archive has published, and it carries no last_trade_price rows at all.
  • All four capturing machines agree closely through the trough. On best_bid_ask their row counts sit within 62 rows of each other: b 10,232, c 10,170, e 10,202 and h 10,220, read from the merge's per-machine counts. Machines that disagree point to a capture problem. Machines that fall together point to the venue.
  • Volume returns in steps that follow the venue's own notes: 18,988,322 rows at T19 with trading resumed at 19:35, then 26,126,479 at T20 after cancel-only was re-entered at 19:58, then 73,141,554 at T21, with the incident resolved at 21:35. T22 holds 96,514,485 and is ordinary.

What we are not claiming.

  • That anything was lost. Trading was stopped or restricted for most of this window, so these hours record a market that was not moving rather than a feed we failed to read.
  • A row count for what a normal 2026-09-03T18 would have held. The hours either side give a range; a number inside it would be a guess.
  • That the components map exactly. The venue named Predictions and Trading API (CLOB) on this incident and did not name a websocket. A trading pause stops book updates whatever the transport, but the linkage is inference from the timeline.

Venue paused trading for about twenty minutes, 2026-09-03T13:07Z to 2026-09-03T13:26Z

1 hour

1 hour of v3/ is affected: 2026-09-03T13.

What the venue recorded. Delayed open order read responses; trading paused while a fix was applied, 13:07 to 13:26 UTC, naming Predictions, Trading API (CLOB), Clob Websocket, Websocket (RTDS), Markets and Position data, On-chain settlement (Polygon RPC). Their record.

What we measured.

  • Hour 2026-09-03T13 holds 57,699,611 rows against 98,720,762 in the hour before and 109,024,340 in the hour after, which is about 56% of its neighbours.
  • The venue paused trading at 13:07 and re-enabled it at 13:26, so roughly nineteen minutes of the hour did not trade, which is the right order of magnitude for what the hour holds.
  • All seven products are present and none of them is empty. A short pause inside an otherwise ordinary hour looks exactly like this.

What we are not claiming.

  • That anything was lost. The venue stopped trading for the pause, so there was little to emit during it; nothing here measures completeness.
  • That the shortfall divides neatly by the clock. Volume is not flat across an hour, so nineteen minutes of pause is not automatically a third of the hour's rows, and we have not tried to model it.

Venue investigated order-cancellation problems, 2026-09-03T11:41Z to 2026-09-03T12:11Z

2 hours

2 hours of v3/ are affected: 2026-09-03T11, 2026-09-03T12.

What the venue recorded. Users reporting issues with cancelling predictions orders, 11:41 to 12:11 UTC, naming Predictions, Trading API (CLOB). Their record.

What we measured.

  • Nothing moved here. Hour 2026-09-03T11 holds 96,375,928 rows and 2026-09-03T12 holds 98,720,762, either side of a 91,225,295 hour at T10 and a 109,024,340 hour at T14. Both are ordinary.
  • All seven products are present in both hours and none of them is empty.
  • The venue never paused trading for this one. Its updates run from investigating at 11:41 to resolved at 12:11 with no pause and no cancel-only window, which is consistent with hours that look untouched.

What we are not claiming.

  • That nothing reached us. Order cancellation is a venue-side operation and a book we record can absorb a cancellation problem without a visible change in row count. Ordinary volume shows only that volume was ordinary, not that every message arrived.
  • That these hours are verified. Only that the venue filed a record and our two hours look like their neighbours.

Venue restart, then a paused database migration, 2026-09-01T22:30Z to 2026-09-02T04:58Z

6 hours

6 hours of v3/ are affected: 2026-09-01T22, 2026-09-01T23, 2026-09-02T01, 2026-09-02T02, 2026-09-02T03, 2026-09-02T04.

What the venue recorded. Delayed open order read responses traced to database replica lag; an emergency CLOB restart, then a longer paused window to apply a fix with their infrastructure provider, opened 20:21 on 1 September, restart 22:30 to 23:54, trading paused again 01:30 to 04:58 UTC, naming Predictions, Trading API (CLOB). Their record. They filed Scheduled Emergency CLOB maintenance, the paused window inside the incident separately, 01:30 to 04:57 on 2 September: that record.

What we measured.

  • Hour 2026-09-01T22 holds 53,564,796 rows and 2026-09-01T23 holds 26,833,332, against 81,079,941 and 80,010,651 in the two hours before. The venue began its restart at 22:30 and reported it complete at 23:54.
  • 2026-09-02T00 holds 79,077,228 rows, an ordinary hour, which matches the venue's 23:54 note that trading had resumed with no degradation present.
  • Trading was paused again at 01:30. 2026-09-02T01 holds 38,438,499 rows, then 2026-09-02T02 holds 302,168 and 2026-09-02T03 holds 256,990, about 0.3% of the hours either side.
  • Through both of those hours the file carries no last_trade_price rows and no tick_size_change rows at all: not one trade printed and not one tick size moved, on any of the capturing machines.
  • 2026-09-02T04 holds 6,482,726 rows. The venue re-enabled trading at 04:58, and 2026-09-02T05 holds 84,016,893, back to the ordinary level.
  • Machine b contributed nothing anywhere in this window, and that is not part of this event: b was in an outage of its own from 2026-08-29T03 to 2026-09-02T10, measured on our own listing, and it returns at 2026-09-02T11 with 63,580,563 rows.

What we are not claiming.

  • That anything was lost. The venue paused trading, so for most of this window there was little to emit; these hours record a stopped market. The venue's timeline supports that reading. It is not a measurement of completeness.
  • That the whole venue incident is in these hours. It opened at 20:21 and both 2026-09-01T20 and T21 hold ordinary volume, so whatever the venue was investigating before the restart did not reach the feed we record.
  • A row count for what these hours would have held. The hours either side give a range; a number inside it would be a guess.
  • That the cause is ours to state. The venue names database replica lag and a fix applied with their own infrastructure provider; we measured volume, not their databases.

Venue maintenance on a market this archive does not record, 2026-09-01T07:30Z to 2026-09-01T09:30Z

3 hours

3 hours of v3/ are affected: 2026-09-01T07, 2026-09-01T08, 2026-09-01T09.

What the venue recorded. Scheduled maintenance on Perpetuals, 07:30 to 09:30 UTC, naming Perpetuals. Their record.

What we measured.

  • Nothing moved here. Hours 2026-09-01T07, T08 and T09 hold 83,523,925, 91,294,797 and 90,146,633 rows, between 80,704,036 at T06 and 87,297,116 at T10. Every one is ordinary.
  • All seven products are present in all three hours and none of them is empty.
  • The components the venue named are Perpetuals ones. This archive records the prediction-market CLOB, so there is no route from that maintenance to these files.

What we are not claiming.

  • That the two markets share nothing at all. They share a venue and some infrastructure, and a hard enough failure in one could reach the other. Nothing here measures that; the hours simply do not move.
  • That these hours are verified. Only that the venue filed a record and our three hours look like their neighbours.

Venue paused trading, cancel-only mode, 2026-08-31T23:09Z to 2026-09-01T01:07Z

2 hours

2 hours of v3/ are affected: 2026-08-31T23, 2026-09-01T00.

What the venue recorded. Delayed open order read responses; trading paused and put in cancel-only mode while a fix was applied, 20:28 to 01:07, with trading paused from 23:09 and resuming about 00:59 UTC, naming Predictions, Trading API (CLOB). Their record.

What we measured.

  • Hour 2026-09-01T00 holds 2,873,621 rows against 82,220,563 in 2026-08-31T22, which is 3.5%.
  • The fall is bounded on both sides by ordinary hours: 2026-08-31T22 holds 82,220,563 and 2026-09-01T01 holds 77,127,738.
  • 2026-08-31T23 holds 18,807,687 rows. The venue paused trading at 23:09, so about nine minutes of that hour traded normally, which is the right order of magnitude for what the hour holds.
  • The three machines capturing that hour fell together and their shares of the total are unchanged, which is what a venue-side fall looks like and not what a capture failure looks like.
  • The fourth machine, b, contributed nothing here, and that is not part of this event: b was in an outage of its own from 2026-08-29T03 to 2026-09-02T10 and is absent from the ordinary hours either side of this one too. It neither supports the reading nor weakens it.
  • Polymarket's own status page records the pause at 23:09 UTC, cancel-only mode until about 00:59, and resolution at 01:07. Our volume returns in the hour beginning 01:00.

What we are not claiming.

  • That anything was lost. The venue paused trading, so for most of this window there was little to emit; these hours record a quiet exchange. The venue's timeline supports that reading. It is not a measurement of completeness.
  • That the earlier part of the venue's incident cost us anything. It opened at 20:28 and the three hours before the pause hold ordinary volume, so whatever was degraded then did not reach the book feed we record.
  • A row count for what a normal 2026-09-01T00 would have held. The hours either side give a range; a number inside it would be a guess.
  • That the components map exactly. The venue named Predictions and Trading API (CLOB); it did not name the websocket. A trading pause stops book updates whatever the transport, but the linkage is inference from the timeline.

Venue stopped trading for four hours, 2026-08-31T06:30Z to 2026-08-31T10:47Z

5 hours

5 hours of v3/ are affected: 2026-08-31T06, 2026-08-31T07, 2026-08-31T08, 2026-08-31T09, 2026-08-31T10.

What the venue recorded. Trading paused while a fix was applied, with the resumption target moved twice, then cancel-only before trading resumed, opened 06:23, trading paused 06:30, cancel-only from 10:24, trading resumed 10:40, resolved 10:47 UTC, naming Predictions, Trading API (CLOB). Their record.

What we measured.

  • Hours 2026-08-31T07, T08 and T09 hold 586,290, 152,120 and 164,650 rows against 67,017,001 at T05. They are the three smallest hours in this archive.
  • All three carry no last_trade_price rows and no tick_size_change rows at all: not one trade printed and not one tick size moved across four hours.
  • The edges match the venue's clock. 2026-08-31T06 holds 34,771,810 rows with trading paused at 06:30, half the hour; 2026-08-31T10 holds 24,515,856 with trading resumed at 10:40, and T11 holds 78,295,791, ordinary.
  • All seven products are present in every one of these hours. An hour of a stopped market is thin, not incomplete.

What we are not claiming.

  • That anything was lost. The venue had trading stopped for four hours, so these hours record a market that was not moving. The venue's timeline supports that reading. It is not a measurement of completeness.
  • A row count for what these hours would have held. The hours either side give a range; a number inside it would be a guess.
  • That the pause explains every row. A stopped market still publishes book state, and 152,120 rows in an hour is not zero; what it is, precisely, is not something a row count answers.

Venue in cancel-only mode for about half an hour, 2026-08-31T00:40Z to 2026-08-31T01:12Z

2 hours

2 hours of v3/ are affected: 2026-08-31T00, 2026-08-31T01.

What the venue recorded. Cancel-only mode while the venue investigated and monitored, 00:40 to 01:12 UTC, naming Predictions, Trading API (CLOB). Their record.

What we measured.

  • Nothing moved here. Hour 2026-08-31T00 holds 70,343,250 rows and 2026-08-31T01 holds 70,623,581, with 76,726,719 at T02 and 67,017,001 at T05. All of them are ordinary for that day.
  • The venue never stopped trading for this one. It went to cancel-only at 01:06 and resolved at 01:12, six minutes later.
  • All seven products are present in both hours and none of them is empty.

What we are not claiming.

  • That nothing reached us. Cancel-only restricts what traders may do rather than stopping the book, so an incident can pass through these hours without moving a row count. Ordinary volume shows only that volume was ordinary.
  • That these hours are verified. Only that the venue filed a record and our hours look like their neighbours.

Venue paused trading for about half an hour, 2026-08-30T17:55Z to 2026-08-30T18:29Z

2 hours

2 hours of v3/ are affected: 2026-08-30T17, 2026-08-30T18.

What the venue recorded. Trading paused while the venue investigated, then cancel-only while a fix was monitored, opened 17:36, trading paused 17:55, cancel-only from 18:18, resolved 18:29 UTC, naming Predictions, Trading API (CLOB). Their record.

What we measured.

  • Hour 2026-08-30T18 holds 46,850,021 rows against 104,652,783 in the hour after and 112,493,488 two hours before, which is about 45%. Trading was paused or cancel-only for the first 29 minutes of it.
  • 2026-08-30T17 holds 92,420,855 rows against 112,493,488 in the hour before, about 82%. Only the last five minutes were paused, so most of that shortfall sits in the nineteen minutes the venue spent investigating before it stopped trading.
  • All seven products are present in both hours and none of them is empty.

What we are not claiming.

  • That anything was lost. Trading was stopped or restricted for the affected minutes, so there was less to emit; nothing here measures completeness.
  • That the 17:36 to 17:55 shortfall is measured degradation. Volume varies hour to hour, and 82% of one neighbour is inside the range an ordinary hour can reach. The reading is consistent with the venue's own timeline; it is not proof of it.

Venue maintenance on a market this archive does not record, 2026-08-28T08:00Z to 2026-08-28T08:40Z

1 hour

1 hour of v3/ is affected: 2026-08-28T08.

What the venue recorded. Scheduled maintenance on Perpetuals, announced 03:30, ran 08:00 to 08:40 UTC, naming Perpetuals. Their record.

What we measured.

  • Nothing moved here. Hour 2026-08-28T08 holds 91,750,623 rows between 87,770,186 at T07 and 94,625,150 at T09. It is the middle of its own neighbourhood.
  • All seven products are present and none of them is empty.
  • The components the venue named are Perpetuals ones, and this archive records the prediction-market CLOB.

What we are not claiming.

  • That the two markets share nothing. They share a venue and some infrastructure; the hours simply do not move, which is not the same as proving they could not.
  • That this hour is verified. Only that the venue ran maintenance on another market and our hour looks like its neighbours.

Scheduled CLOB maintenance, 2026-08-28T04:00Z to 2026-08-28T05:00Z

1 hour

1 hour of v3/ is affected: 2026-08-28T04.

What the venue recorded. Scheduled CLOB maintenance, 04:00 to 05:00 UTC, naming Predictions, Trading API (CLOB). Their record.

What we measured.

  • Hour 2026-08-28T04 holds 73,504,293 rows against 92,385,857 at T03 and 86,205,517 at T05, which is about 82% of its neighbours and the largest step down of any maintenance hour here. That is the same ratio as 2026-08-30T17, which sits inside a trading pause.
  • All seven products are present and none of them is empty.

What we are not claiming.

  • That the maintenance caused the step. An hour of scheduled CLOB maintenance holding 18% fewer rows is suggestive and it is not a measurement: ordinary hours reach that far apart on this corpus, and we have not modelled the distribution well enough to say otherwise. The hour is marked because the volume moved, not because the cause is settled.
  • That this hour is verified. Only that the venue ran an hour of CLOB maintenance and our hour is the lowest of its neighbours without being outside their range.

Scheduled maintenance, no downtime expected, 2026-08-27T04:00Z to 2026-08-27T05:00Z

1 hour

1 hour of v3/ is affected: 2026-08-27T04.

What the venue recorded. Scheduled maintenance the venue announced as expecting no downtime, 04:00 to 05:00 UTC, naming Predictions, Trading API (CLOB), Clob Websocket. Their record.

What we measured.

  • Nothing moved here. Hour 2026-08-27T04 holds 85,332,325 rows between 98,384,227 at T03 and 90,062,434 at T05, and T06 and T07 hold 82,676,868 and 83,813,609. It sits inside the day's own range.
  • All seven products are present and none of them is empty.

What we are not claiming.

  • That the maintenance cost us nothing. It named the CLOB websocket, which is a feed we read, and a 13% step down from the hour before is not distinguishable from ordinary variation at this scale. We are not reading it either way.
  • That this hour is verified. Only that the venue announced maintenance expecting no downtime and our hour sits inside the day's ordinary range.

Venue maintenance, feed interruption, 2026-08-26T04:03Z to 2026-08-26T07:57Z

4 hours

4 hours of v3/ are affected: 2026-08-26T04, 2026-08-26T05, 2026-08-26T06, 2026-08-26T07.

What the venue recorded. Scheduled CLOB maintenance, planned for about ten minutes, extended twice, 04:00 to 07:30 UTC, naming Predictions, Trading API, CLOB Websocket. Their record.

What we measured.

  • All four capture hosts fell to a small fraction of their normal rate together, with their shares of the total almost unchanged.
  • Hour 2026-08-26T04 holds 4,489,228 rows against a preceding-four-hour mean of 110,296,775, which is 4.1%.
  • A public REST route no collector uses, checked from outside our infrastructure at 07:19 UTC, was returning live trades 0.4 to 1.5 minutes old while all four collectors read a fraction of their normal rate. That shows the venue trading at the moment we looked, in the recovery tail; it does not establish continuous trading across the whole window.
  • Capture recovered without anything being restarted.
  • Polymarket's own status page records scheduled CLOB maintenance from 04:00 to 07:30 UTC, naming CLOB Websocket among the affected components. Our measured cliff at 04:03 and recovery at 07:57 sit either side of it.

What we are not claiming.

  • How much was actually lost. For most of this window the exchange itself was down, so there was little to receive and the archive is probably close to complete with respect to what existed. That is a reasonable inference, not a measurement.
  • What we missed in the degraded tail. From about 06:56, when Polymarket reported restoring databases and trading still degraded, until our recovery at 07:57, the venue was emitting and we were not receiving. That is the genuine loss and we cannot enumerate it.
  • Any row count, for either part. The window is bounded and the shortfall is uncounted. We do not publish an estimate.
  • Whether the gap can be backfilled. Trades settle on-chain, so a reconstruction may be possible, but nobody has attempted it.

A day of trouble on a market this archive does not record, 2026-08-24T08:40Z to 2026-08-24T21:50Z

12 hours

12 hours of v3/ are affected: 2026-08-24T08, 2026-08-24T09, 2026-08-24T10, 2026-08-24T11, 2026-08-24T13, 2026-08-24T14, 2026-08-24T15, 2026-08-24T17, 2026-08-24T18, 2026-08-24T19, 2026-08-24T20, 2026-08-24T21.

What the venue recorded. Perpetuals maintenance in the morning, then trading degraded three times through the afternoon and evening, maintenance 08:40 to 11:24, degraded 13:30 to 15:06, 17:17 to 17:49 and 18:20 to 21:50 UTC, naming Perpetuals. Their record. They filed Perpetuals trading degraded separately, 13:30 to 15:06: that record. They filed Perpetuals trading degraded again separately, 17:17 to 17:49: that record. They filed Perpetuals trading degraded a third time separately, 18:20 to 21:50: that record.

What we measured.

  • Nothing moved here, across thirteen hours. 2026-08-24 runs from 81,264,765 rows at T07 to 118,714,551 at T17, rising through the day as an ordinary Monday does, and no hour inside any of the four windows steps out of that.
  • All seven products are present in every hour of the day and none of them is empty.
  • Every record the venue filed that day names Perpetuals components. This archive records the prediction-market CLOB.

What we are not claiming.

  • That the two markets share nothing. They share a venue and some infrastructure, and thirteen ordinary hours are an absence of movement rather than a proof of isolation.
  • That these hours are verified. Only that the venue had a bad day on another market and our hours look like their neighbours.

Venue paused trading for about forty minutes, 2026-08-22T13:13Z to 2026-08-22T13:51Z

1 hour

1 hour of v3/ is affected: 2026-08-22T13.

What the venue recorded. Trading paused, then monitored before it resumed, 13:13 to 13:51 UTC, naming Predictions, Trading API (CLOB). Their record.

What we measured.

  • Hour 2026-08-22T13 holds 46,837,802 rows against 100,618,094 at T12 and 112,526,418 at T14, which is about 44% of its neighbours.
  • The pause ran 13:13 to 13:51, so about 38 of the hour's 60 minutes were stopped, and the hour holds a little under half of what its neighbours do.
  • All seven products are present and none of them is empty.

What we are not claiming.

  • That anything was lost. Trading was stopped for the pause, so there was less to emit.
  • That the shortfall divides by the clock. Volume is not flat within an hour and we have not modelled it; the two numbers are simply consistent.

Order retrieval endpoint, degraded and resolved in a second, 2026-08-19T11:23Z to 2026-08-19T11:23Z

1 hour

1 hour of v3/ is affected: 2026-08-19T11.

What the venue recorded. Order retrieval endpoint experiencing degraded performance, 11:23:40 to 11:23:41 UTC, naming Predictions, Trading API (CLOB). Their record.

What we measured.

  • Nothing moved here that this record explains. 2026-08-19T11 is depressed at 39,165,622 rows, and the trading outage that ended at 10:58 that morning already accounts for it.
  • The venue's own record opens and closes in the same second, which is what a mis-filed or immediately-withdrawn entry looks like.

What we are not claiming.

  • That it was nothing. A one-second record is a statement about their filing, not about their systems, and we cannot tell the two apart from outside.
  • That this hour is verified. Only that the venue filed a record here and our hour is already explained by the outage before it.

Trading outage, order submissions failing, 2026-08-19T09:19Z to 2026-08-19T10:58Z

3 hours

3 hours of v3/ are affected: 2026-08-19T09, 2026-08-19T10, 2026-08-19T11.

What the venue recorded. Trading outage with order submission failures, 09:19 to 10:58 UTC, naming Predictions, Trading API (CLOB), Clob Websocket. Their record.

What we measured.

  • Hours 2026-08-19T09 and T10 hold 3,718,747 and 4,314,742 rows against 76,783,640 at T08. That is under 6% of the hour before, and outside the four hours of 2026-08-31 they are the smallest hours in this archive.
  • Recovery is visible in the hour it happened. The venue resolved at 10:58 and T11 holds 39,165,622 rows, about half of T12's 76,246,087, which is what a market that came back two minutes before the hour began looks like.
  • All seven products are present in all three hours and none of them is empty.

What we are not claiming.

  • That anything was lost. Order submissions were failing at the venue, so there was less to trade and less to emit.
  • That T11's half-strength hour is fully explained by the recovery. The venue also filed a separate one-second record at 11:23 that morning, and neither we nor they say more about it than that.

Venue infrastructure maintenance, 2026-08-19T04:00Z to 2026-08-19T05:30Z

2 hours

2 hours of v3/ are affected: 2026-08-19T04, 2026-08-19T05.

What the venue recorded. Announced infrastructure updates, run as maintenance, announced 17:30 on 18 August, ran 04:00 to 05:30 UTC, naming Predictions, Trading API (CLOB), Clob Websocket. Their record.

What we measured.

  • Hour 2026-08-19T04 holds 8,385,686 rows and T05 holds 18,503,704, against 81,334,982 at T03 and 68,791,034 at T06. That is 10% and 23% of the hours either side.
  • The window matches the shape: the maintenance ran the whole of T04 and the first half of T05, and T05 holds about twice what T04 does.
  • All seven products are present in both hours and none of them is empty.

What we are not claiming.

  • That anything was lost. The venue named the CLOB websocket among the components under maintenance, so there was less to receive; these hours record a market that was largely stopped.
  • A row count for what these hours would have held. The hours either side give a range; a number inside it would be a guess.

1. Book snapshot cadence

A per-asset snapshot census. First result below. One hour so far, not the whole corpus.

Measured on v3/2026-08-24/05: 396,261 book snapshots across 260,054 distinct assets, a mean of 1.52 each. The distribution is the finding:

Snapshots for one asset in the hourAssetsShare
exactly 1246,04294.6%
exactly 29,8093.8%
3 or more4,2031.6%

The busiest 1% of assets hold 31.7% of all snapshots, and the single busiest received 3,210, about one a second. So the snapshots are heavily concentrated on a few active assets.

What this means if you are reconstructing depth. For roughly nineteen assets in twenty there is no cadence within the hour at all, there is one snapshot. You must carry price_change deltas forward from that single anchor, and there is no periodic re-snapshot to correct drift against. That is a stronger statement than the note about snapshots being "periodic rather than continuous", and it is the practical shape of the limitation.

The PMXT era is not the same, and the difference is large

The same census on pmxt/v2/2026-06-15T12: 142,804 book snapshots across 48,324 assets, a mean of 2.96 each.

Snapshots for one asset in the hourpmxt/v2v3
exactly 127.3%94.6%
exactly 240.6%3.8%
3 or more32.1%1.6%
assets seen48,324260,054

If you carry an analysis across the era boundary, this will bite you. In pmxt/v2 most assets are re-snapshotted two or three times an hour; in v3 most are snapshotted once. Any measure that depends on how often the book is re-anchored, drift between snapshots, time-weighted depth, how stale a reconstructed book is, changes at the boundary for reasons that have nothing to do with the market.

v3 also sees 5.4× more assets in its hour, and that matters because spreading the same capture effort over five times as many assets would on its own produce fewer snapshots each. The market did not grow by 5.4×.

Measured against the on-chain CLOB fills, independently indexed, on 2026-08-30, counting the assets that actually traded on each whole day:

On chain2026-06-15 2026-08-24
assets with at least one fill 39,382 45,227
fills 6,537,771 4,318,313

Whole days rather than the census hours, because the two censuses fall at different times of day. The traded universe grew about 1.15× while the archive's view of it grew 5.4×, and fills fell over the same period. The census hours make the point more sharply still: the August hour, where the archive saw 5.4× more assets, had fewer assets trading than the June one (4,989 against 7,743).

So the gap is mostly breadth of subscription, not a bigger market. That is the remainder after market growth is accounted for rather than something counted directly: an asset can be open and quoted all day without a single fill, so the traded count is a floor on the tradeable universe and not its size.

What it does not establish. Whether the snapshot cadence itself reflects the venue's own behaviour or our capture of it is not determined. The archive alone cannot tell those apart. It is one census hour per era, and two days on chain. Neither figure should be read as a defect count.

2. Volume and trade under-reporting from the de-duplication

Cross-check per-market daily trade counts and volumes against the independently indexed on-chain CLOB fills. This separates de-duplication loss from capture gaps.

Scope: pmxt/v2/ and v3/ only, and this is not a choice. The join key is the on-chain transaction_hash carried on trade events. pmxt/v1/ records no trade events at all: only price_change and book_snapshot, with no transaction_hash column. So roughly 0.567 TiB of this archive, 2026-02-21 to 2026-04-15, cannot be reconciled against chain fills by any method. That is a property of what was captured then, not a gap in this audit.

Results: not yet run. The scope is settled above; the cross-check itself has not been made, and section 3 says what the published files alone cannot reach.

3. De-duplication key collisions

How much you lose if you de-duplicate on the natural key. First result below. One hour of pmxt/v2/. It answers part of the question.

Measured on pmxt/v2/2026-06-15T12:

ProductKeyRowsCollapsed
price_change market + asset_id + price + size + side + timestamp 49,856,803163 (0.0003%)
last_trade_pricetransaction_hash alone 22,8550

The largest group of identical price_change rows was two. Every trade in the hour carried a distinct, non-null transaction_hash, so it is a safe de-duplication key and a safe join key to on-chain fills. The price_change figure is a lower bound: collisions were counted within 2,000,000-row chunks, so any pair straddling a chunk boundary is not in it.

What this cannot reach, which is most of the original question. It measures duplicate keys that remain in the published file. It says nothing about events PMXT's own de-duplication removed before publishing, those are not in the file to be counted, and no amount of reading it will make them appear. This audit was prompted by a report that about 4 events in 96 were duplicates on the live feed. That figure was taken before PMXT's own de-duplication and cannot be compared with a count taken after it. Answering the real question needs a source we do not have.

Markets held, against markets traded

The coverage ratio above asks how many traded markets have a book. This asks the other question: how many books a corpus holds for every market that actually traded. The two are computed from different counts, and they rank the four corpora in the same order.

A high number means broad capture. It recorded markets nobody traded that hour, so the archive can answer what a quiet market looked like, not only a busy one. A low number means it followed the action: what it holds can still be trusted, but there is nothing there to ask about anything else.

CorpusHeld per tradedRange across hours Against our own capture
v3 (ours) 51.8x 42.2x to 59.3x the benchmark
AG6 38.8x 33.5x to 43.2x 1.3x fewer books per traded market
pmxt/v2 no single figure 5.1x to 33.7x 2.8x fewer books per traded market
pmxt/v1 no single figure 3.1x to 8.2x 13.2x fewer books per traded market

2 corpora carry no single figure, because breadth changed too much across their own span for a median to describe any state they were in. pmxt/v2 runs 5.1x to 33.7x. Their own audit pages show the hour-by-hour series. Breadth is not completeness: a bigger number says nothing about whether the markets that did trade have books.

The machines that recorded this

Hours under v3/ are heard by more than one machine at once, and the merge keeps the union of what they heard. This is how much of the audited archive each one was present for. Which machines are live today, which are retired, and how well each one performed is on the witnesses page; every letter below links there.

MachineWhereHours heardFirst hour Share
hGermany 1,103 2026-08-24T0588.0%
cLondon, GB 860 2026-08-23T2168.6%
eAshburn, US 629 2026-08-27T0550.2%
gOregon, US 598 2026-09-05T0947.7%
fVirginia, US 424 2026-09-05T0933.8%
iHelsinki, FI 409 2026-09-22T1032.6%
bCanada 318 2026-08-18T1425.4%
aClifton, US 303 2026-08-18T0624.2%
kGermany 280 2026-09-22T1522.3%
mLondon, GB 228 2026-09-29T2318.2%
nVirginia, US 124 2026-10-04T079.9%
oLondon, GB 124 2026-10-04T079.9%
jGermany 2 2026-09-22T130.2%

Hours heard and share are measured, read back from the same completeness record as the coverage table above, over the 1,253 checked hours that record which machines contributed. The Where column is declared, not measured: it is a fact about our own machines, so it carries no measured-on date. We do not publish who hosts these machines: it would tell somebody where to aim, and it tells you nothing about the data.

Hours absent from the published range

No hour inside the published range is absent: the served hours run consecutively from the first to the last, with no holes. This is derived from the listing on each request, not asserted here.

The mirrored PMXT eras

4 hours across the mirrored PMXT eras have no file. These are absent at PMXT's source. PMXT's own origin was asked on 2026-09-02: it answered 404 for these hours and served every neighbouring hour we checked, so they are absent at source, not missed by our mirror. We mirror those prefixes unmodified and did not remove them.

PrefixHours heldAbsent
pmxt/v1/ 1,283 of 1,284 2026-04-04T18
pmxt/v2/ 2,835 of 2,838 2026-06-11T04, 2026-06-11T05, 2026-06-11T06

Counted on 2026-08-28 from each prefix's published SHA256SUMS.txt, endpoints inclusive. These eras are finished, so this is a fixed measurement rather than one derived on each request.

Per-hour coverage, v3/

How many hosts heard each hour

Several capture hosts run in different data centres and the merge combines what they heard. 16 hours heard by 6, 742 hours heard by 5, 283 hours heard by 4, 67 hours heard by 3, 118 hours heard by 2, 27 hours heard by 1, of 1253 attested.

These count the hosts that contributed rows. An hour's manifest also carries a witnesses field, and it is a different measure - it records which hosts were set up to record the hour, so it can name one that supplied nothing. Where the two differ, the count here is the smaller. More on the difference.

27 hours were recorded by one machine alone. Nothing corroborates those hours, so treat that data with more caution than the rest: 2026-08-18T06 → 2026-08-18T13 (8 hours), 2026-08-20T14 → 2026-08-21T02 (13 hours), 2026-08-21T15, 2026-08-22T12, 2026-08-23T00 → 2026-08-23T03 (4 hours).

1253 of the 1272 hours under v3/ have been read from the archive itself and given a verdict: all 60 minutes present in the union of the seven products, and the first and last event within 5 seconds of the hour's edges. The verdict appears beside each row in the listing. The newest 19 are not measured yet and read audit pending in the listing, which means we have not looked at them - not that they are complete.

Hours publishedmeasuredcomplete partialcould not classify
1272 12531243 100

The partial hours, named

Every partial hour is named below. An hour can hold all sixty minutes and still be partial: that means capture began late or ended early by more than the five-second tolerance, which the first and last event columns show.

The identifiers are the capture machines. Each machine that records the feed has a short stable identifier, and where an hour was heard by more than one, their identifiers appear together in a single cell. They are the same identifiers the source_witness column carries.

Hour (UTC)Minutes presentFirst eventLast eventMachines expected
2026-08-18T0644/6006:16:07.97106:59:59.999a
2026-08-18T1360/6013:00:00.00013:59:52.889a
2026-08-18T1460/6014:00:41.53214:59:59.999ab
2026-08-20T1758/6017:00:00.00017:59:59.978b
2026-08-20T1858/6018:00:00.00518:59:54.611b
2026-08-20T1956/6019:00:40.36619:59:59.999b
2026-08-20T2042/6020:00:00.00020:59:59.999b
2026-08-21T0057/6000:00:00.00000:59:59.999b
2026-08-21T0257/6002:00:00.00202:59:59.999b
2026-10-08T0459/6004:00:00.00004:59:59.999himno

Machines expected is the manifest's witnesses field: the machines set up to record the hour, not the ones that contributed rows to it.

Measured on 2026-10-10T02:26:49+00:00 by a separate program that counts the events in each hour itself, rather than trusting the count the merge wrote. It counts them from the merge output rather than from the published file. Those hold the same events, so the verdict above is about this hour's data either way, but it is not a read-back of the object you download.

The object you download has its own check, and it is a better one for the job. Every hour's directory carries a SHA256SUMS covering exactly that hour's files, so verifying a download is sha256sum -c SHA256SUMS.txt in the directory you fetched into, with no need to pull the whole archive's ledger. The same digests are in the hour's manifest and in the corpus-wide ledger if you want every hour at once. The program that produced it is identified by sha256 5bf30658bb552b75…, so a later attestation made by a changed program is distinguishable from this one.

What “complete” does not mean. It means every minute of the hour carried at least one event across the seven products, and that capture started and stopped within five seconds of the hour's edges. It does not mean no rows were lost. Several independent capture hosts feed each hour and the same event is often seen by only one of them, so a host can be absent for a whole hour while the others still cover every minute. The hour is then labelled complete and is genuinely missing rows. That is not hypothetical: on 2026-08-24 one host processed no events for over two hours, and our own capture audit found the remaining hosts covered every minute of the affected hours. The rows only that host would have contributed are gone, and re-merging cannot recover them because they were never exported. The size of that loss is bounded but has not been measured. We will publish a number when we have counted it, not before.

This measurement counts minutes, not rows, and no per-hour verdict on this page should be read as a claim about row completeness.

What this does not say. It does not say the archive is complete. It says how many hours met a stated rule, and it names the ones that did not. An hour absent from the audit reads audit pending. We have not looked yet, which is not a synonym for complete. The archive has grown since this attestation ran: 19 of the 1272 published hours have not been measured yet, and read as audit pending.

Known losses in our own capture

Rows we know are missing from hours that are otherwise published. One is counted. Two are bounded in time but not counted, and the page says so rather than estimating them. None of them is coming back from our own capture. Where a rebuild from the chain might be possible, the entry says so.

HourProductsRows lostStatus
v3/2026-08-26/04–07/ all unknown not established
v3/2026-08-24/16/ new_market, market_resolved unknown not recoverable
v3/2026-08-24/12/ new_market, market_resolved 428 not recoverable

2026-08-26T04–07

From 04:02Z on 2026 August 26 all four capture hosts fell to a small fraction of their normal rate together, with their shares of the total almost unchanged. Four separately hosted collectors on four networks moving in lockstep is a common cause rather than four faults, and the common element is the websocket feed layer. Polymarket has since published their own record of it. Their status page lists scheduled CLOB maintenance from 04:00 to 07:30 UTC, planned for about ten minutes and extended twice, naming CLOB Websocket among the affected components. That is the feed we read. Our measured cliff at 04:03 and recovery at 07:57 sit either side of their window.

For most of this window the exchange itself was down, so there was little to miss, and the archive is probably close to complete with respect to what existed. That is a reasonable reading of their record, not a measurement we made. From about 06:56, when Polymarket reported restoring databases with trading still degraded, until our own recovery at 07:57, the venue was emitting and we were not receiving. That part is a real loss.

Hours from 2026-08-26T04 are marked small in the listing, and that marker deliberately does not distinguish a quiet market from a capture failure, because from the outside it cannot. This entry is that distinction. The window ran from 04:03Z to 07:57Z, about three hours and fifty-four minutes, and it is closed. Capture recovered on its own, with nothing restarted. That is a second sign the fault was on the venue's side.

We cannot enumerate what the tail cost. Knowing when a window opened and closed is not knowing how many rows fell into it, and we do not publish an estimate. Whether any of it can be rebuilt from on-chain settlement has not been established either way.

Status: window closed 07:57Z, shortfall still uncounted.

This window has not been counted. Trades from it settled on-chain, so a partial reconstruction may be possible. Nobody has attempted one.

2026-08-24T16

A capture host stalled at 16:38 and did not recover before the hour ended. Its queue of lifecycle events was held in memory, and the process crashed at 18:13:38Z while still wedged, so everything queued and unwritten went with it. Unlike the hour below, these events never reached any store.

Lifecycle events between 16:38 and 17:00 are absent from this hour and the shortfall cannot be counted. The only record of them was the memory that was lost. Market data for the hour is unaffected.

Status: never, see below.

This one was never counted and never can be. The events were destroyed before anything recorded them, so there is no source to re-read. There is no number to publish.

2026-08-24T12

A capture host stalled and recovered inside this hour. 428 lifecycle rows reached our database but were never written to the exported files. They were counted while they still existed; the database partition holding them was dropped at 16:00:53Z, about twelve minutes later, and a dump attempted afterwards found nothing. Re-merging cannot recover them because the staged files never held them either.

The hour is published and its market data is intact. This is a shortfall in new_market and market_resolved only. If you are counting market creations or resolutions in this hour, it is short by 428 rows and no number we publish can make that good.

Counted 2026-08-24T15:48:26Z, from the upstream database, before it expired. We cannot re-verify this number. The source it was read from no longer exists. It is recorded here as testimony, with the time it was taken, rather than presented as something we could reproduce on request.

Rows that are missing but not lost

Hours published with fewer capture hosts than were actually recording them. Unlike the table above, these can be made good, and this section removes itself as they are.

2026-08-23T12 to 2026-08-24T04

17 hours between 2026-08-23T12 and 2026-08-24T04 are still short, by the latest coverage check. Hours already rebuilt drop off this list on their own.

A fourth capture host was recording these hours, and the merge that produced them did not include it. Its files were never lost: they are still held, and the hours can be rebuilt with them.

These hours are real and complete in the sense the coverage check measures (every minute is present) but they carry the rows of three capture hosts where four were listening. Most rows are heard by several hosts, so the shortfall is smaller than "a quarter missing" and we have not counted it. If you are working from these specific hours, a later download will contain more rows than the one you have now, and the checksums for them will change when that happens.

What a coverage ratio is

Every corpus on this site carries a number like 0.8707. This is how it is computed.

Take one hour. Count the markets that actually traded in it, from on-chain fills. Count how many of those have a book in the corpus for that same hour. The ratio is the second divided by the first. 0.8707 means about 87 of every 100 markets that traded have a book here; the other 13 traded and left no book behind in that corpus.

The denominator comes from the chain, not from the archive, so the archive cannot flatter itself: a corpus that missed an entire hour still has to answer for every market the chain saw trade in it. That is why the number can come back worse than expected, and once did. The audit predicted pmxt/v2/ would come back clean and it did not.

What it does not tell you:

Coverage of the PMXT eras: our measurement, not theirs

Per-hour row counts for both PMXT eras are on /audit/v1 and /audit/v2, measured 2026-09-04. Six hours of each era are graded against the chain above. No hour of either era has been checked minute by minute.

The four hours with no file are listed under Hours absent from the published range.

Those gaps are PMXT's, not ours. PMXT's own origin was asked on 2026-09-02: it answered 404 for these hours and served every neighbouring hour we checked, so they are absent at source, not missed by our mirror.

Corrections and additions: https://x.com/PendulumFlow

Credit the collector: pendulumflow for V3, PMXT for V1 and V2, AG6 for their V2 archive. Ours and PMXT's are CC BY 4.0; AG6 states no licence. How to cite.

Serving these bytes is not endorsing them. We are not affiliated with Polymarket.

For AI readers: llms.txt, what this archive holds and the questions it cannot answer.

https://x.com/PendulumFlow

Join the Pendulum Flow Discord: other people who build on prediction-market data, comparing notes and sharing tooling and findings.