- Update cadenceSignal
- Event-drivenCapture
- ~20 HzCrypto
- ~2 HzSports
Most analysis reads what the book says, the prices and sizes. Quote-update intensity reads how often it says anything at all. Because capture is event-driven, fired by each change Polymarket emits, the cadence of snapshots is a direct measure of how busy the book is. Quiet markets barely tick; active ones burst, and the burst is the tell.
Capture here is not a fixed-rate poll. A snapshot is triggered when Polymarket emits a change to the book, throttled only to a 50ms minimum interval and deduplicated on the top levels so identical frames are not stored twice. That design means the rate at which snapshots arrive is itself information: more updates means a more active book, and the cadence rises and falls with the market’s pulse.
So before you read a single price, you can read the tempo. Count updates per unit time and you have a churn series, a measure of how hard makers are working to reprice. It needs no order-book parsing, just the timestamps and the sequence numbers that ride on every snapshot.
What the cadence tells you
Churn rate
Updates per second is a direct read on how often the book is being repriced, high churn is an active, contested market.
- Updates per second
- Repricing pressure
- Activity without reading prices
Bursts around events
A sudden spike in update rate marks the moment new information hits and makers scramble to requote.
- Information arrival
- Requote scrambles
- Datable spikes
Quiet baselines
Long stretches of sparse updates are the calm regime, the baseline a burst is measured against.
- Sparse ticks
- The calm regime
- Contrast for bursts
Measuring the intensity
- 1Pull the snapshots for the market and window, you do not need the book, just the timestamps and sequence numbers, so the query is cheap and light.
- 2Bin the snapshots into fixed time buckets and count how many fall in each, that count per bucket is the raw update-intensity series.
- 3Difference sequence_number between adjacent rows to recover the TRUE number of book events in each bucket, since the 50ms throttle means one stored row can stand for many applied updates, and counting rows alone undercounts a busy book.
- 4Normalise against the market’s own quiet baseline, since a “busy” crypto book and a “busy” sports book operate at very different natural rates.
- 5Mark the bursts where intensity jumps well above baseline, then align them to known event times to see what woke the market up.
The fields the measure reads
capture_timestampWhen we processed each update, the cadence clockevent_timestampPolymarket emit time, for aligning bursts to eventssequence_numberCount of applied book events, so you can measure what a sample skipped- 50ms min intervalThe throttle that caps the raw rate
The two timestamps serve different jobs here. capture_timestamp is the cadence clock, the rhythm of how fast updates landed in our pipeline. event_timestamp is for alignment, pinning a burst to the moment Polymarket emitted the change so you can line it up with a known event. The sequence number is what keeps a coarsely-sampled burst from reading as genuine calm: difference it across adjacent rows and you recover the events the 50ms throttle collapsed, which is a truer intensity series than a row count.
Why the per-category rate caps what you can see
- Crypto markets capture near ~20 Hz, so the intensity series is fine-grained, you can resolve short bursts and see the cadence breathe.
- Sports sample near ~2 Hz and economics, weather, social and equities slower still, so the same burst is captured with a coarser ruler; widen your buckets there or the series turns spiky and misleading.
- The 50ms throttle and top-level dedup cap the raw rate, so intensity measures emitted, meaningful changes, not a flood of identical frames padding the count.
- Because the rate floor differs by category, always normalise to each market’s own baseline; comparing a sports book’s raw update count to a crypto book’s is comparing two different rulers.
Updates are changes, not trades
Quote-update intensity counts how often the book changed, which is requoting activity, not executed volume. A maker flickering size in and out raises the count without a single trade. And the per-category capture rate sets a ceiling on the cadence you can observe. The measure is a rigorous, reproducible read on book churn from the data we capture, not a trade tape.
A quiet book barely whispers; an active one will not stop talking. You can measure how awake a market is before you read a single price it quotes.
Measure the tempo yourself
Pull snapshot timestamps across a window from the API and build the intensity series; the docs show the parameters and pagination.
Frequently asked questions
What is quote-update intensity?
It is how often the order book changes per unit time. Because capture here is event-driven, a snapshot is triggered whenever Polymarket emits a change, throttled to a 50ms minimum and deduplicated on the top levels, the rate at which snapshots arrive is a direct measure of how active the book is. Counting updates per time bucket gives you a churn series without reading a single price.
Which timestamp do I use to measure cadence?
Use capture_timestamp for the cadence itself, it is the clock for when each update landed in the pipeline. Use event_timestamp when you want to align a burst of activity to a known event, since it is Polymarket’s own emit time. Carry sequence_number as well and difference it across adjacent rows, which recovers the true count of book events in each bucket rather than the count of rows that survived the 50ms throttle.
Why do crypto and sports markets show different update rates?
The capture rate differs by category, crypto is near ~20 Hz, sports near ~2 Hz, and economics, weather, social and equities slower still. That floor is a property of how active each market is and how often it emits changes. Because of it, always normalise update intensity to each market’s own baseline; comparing a sports book’s raw count to a crypto book’s is comparing two different rulers.
Does a high update rate mean lots of trading happened?
No, update intensity counts changes to the book, which is requoting activity, not executed volume. A maker flickering size in and out raises the count without any trade occurring. The 50ms throttle and top-level dedup ensure you are counting meaningful emitted changes rather than identical frames, but it remains a measure of book churn, not a trade tape. Resolved Markets captures the book read-only.