Five tables behind a bot that has been polling Polymarket since October 2025. What each one records, how deep it really goes, and what it can honestly answer.
table rows since alerts 144,692 23 Oct 2025 every sharp price move detected price_samples 288,406 20 Aug 2026 raw bid, ask and spread market_census 248,564 22 Aug 2026 whole catalogue, daily market_resolutions 2,422 22 Aug 2026 outcomes, captured at settlement poll_log 22,633 20 Aug 2026 proof the instrument was running
One of these spans ten months. The other four are a week old. That distinction does more work than any number on this page, so it goes first.
| Month | Price moves recorded | |
|---|---|---|
| Oct 2025 | 21,033 | |
| Nov 2025 | 82,620 | |
| Dec 2025 | 33,116 | |
| Jan 2026 | 438 | alerting broke |
| Feb 2026 | 0 | nothing recorded |
| Mar 2026 | 0 | nothing recorded |
| Apr 2026 | 2,499 | fixed late April |
| May 2026 | 627 | |
| Jun 2026 | 21 | pagination bug |
| Jul 2026 | 31 | pagination bug |
| Aug 2026 | 4,307 |
94.5% of all 144,692 rows fall in the first three months. February and March 2026 are empty. June and July together hold 52 rows, because a pagination bug had shrunk the tracked universe to a few hundred markets without reporting an error.
So the correct description is ten months of calendar span, roughly four dense months, 144,692 detected moves across 14,242 distinct markets on 152 days that recorded anything at all. That is still an unusual dataset. It is not a continuous series, and any chart of activity over time drawn from it is mostly a chart of my own outages.
One row per detected repricing. The useful property is not the size: the row is written before any of the publishing filters run, so the table keeps every candidate that was rejected alongside the 858 that were published.
That makes it a record of editorial decisions rather than just market activity. You can replay any day and ask which filter killed a given market, which is how most of the bugs on the API notes page were found. I am not aware of another public dataset shaped like this.
288,406 rows across 10,665 markets, written whenever a price moves two points. It keeps the raw bid and ask, which matters more than it sounds: a 3% bid against a 77% ask averages to a confident-looking 40% midpoint, and without the underlying quote there is no way to tell that apart from a real price.
This is the highest-quality thing in the database and it is one week old. Everything it can currently support is cross-sectional.
Seven daily snapshots of every listed market, roughly 35,000 to 37,500 per day, with about 87% carrying a two-sided book. parent_slug is what makes it possible to see that the catalogue is really about 7,130 events rather than 33,000 independent markets.
2,422 outcomes captured as markets settle. Captured live rather than backfilled, because backfilling does not work here: a resolved market is omitted from the Gamma slug lookup unless you already know it closed, which made 13,312 of 14,090 markets look deleted.
One row per poll. It exists only to answer "was the instrument running", which is the question that separates a quiet market from a broken bot. Section 01 is legible because of this table. It replaced a per-market heartbeat that would have cost 215,904 rows a day.
| Question | Answerable |
|---|---|
| How is volume distributed across the catalogue | yes |
| What share of listed markets have a real book | yes |
| How wide are spreads by price level | yes |
| Where does volatility sit relative to volume | yes |
| Do sports and news repricings run on different clocks | yes |
| Are prices calibrated on sports and crypto | yes |
| Are prices calibrated on news and politics | no, sample too small |
| Is liquidity trending over months | no, one week |
| How fast does the catalogue turn over | no, walk noise |
| Did activity change month to month | no, the gaps are mine |
The four unanswerable ones are all the same problem, and none of them need code. They need the newer tables to run clean for sixty to ninety days. That puts a genuine time series, an honest churn figure, and a news-market calibration result somewhere around mid-November.
The value here is shape, not size. Ten months of anything sounds impressive until someone runs the GROUP BY in Section 01. What is actually unusual is narrower and more defensible: a log of rejected candidates, raw bid and ask on a wide slice of the catalogue rather than midpoints, and outcomes captured at settlement on a platform where they cannot be recovered afterwards.
Every number on this page was recomputed from the live database while writing it. Two claims that I expected to include were removed in the process: a catalogue churn figure that turned out to be measuring walk completeness, and a calibration result about news markets that was really a result about football.
All figures recomputed from the live database on 27 August 2026.
Gent Blaku · x.com/_GentB · linkedin.com/in/gentblaku
The bot is @p0lywhales. Not affiliated with or endorsed by Polymarket.