- Reprice lagQuestion
- ~20 Hz cryptoResolution
- Event vs captureClock
- Event studyApproach
A prediction market is a probability that updates when the world changes. The interesting question is not whether it updates but how quickly, does the book snap to a new price within a second of a scheduled event, or does it drift there over minutes? With high-frequency snapshots bracketing events with known times, that lag is something you can measure rather than guess at.
Two caveats frame this whole piece. We measure when the order book reprices, the moment best bid, best ask, and mid start moving toward a new level, which is the market’s reaction, not the instant the news crossed a wire. And the precision of that measurement is bounded by the capture rate, which is roughly 20 Hz on crypto and slower elsewhere. Inside those limits, the method is clean and anyone can reproduce it.
What “incorporation speed” actually means
Pick an event with a known time, a crypto market’s settlement bell, a scheduled release, a kickoff. Define the new fair value the market should move toward. Then watch how the mid price closes the gap from its pre-event level to that target, and clock how long it takes. The shape of that move is the signal: a clean step, a smooth glide, or an overshoot-and-correct each tell a different story about how the market processes the same information.
The reprice step
A sharp move in mid price right after the event time is the book agreeing fast, information priced in within a handful of snapshots.
- Sharp mid move
- Few snapshots wide
- Fast agreement
The drift
When the move stretches over many snapshots, the market is converging gradually, information leaking in rather than landing at once.
- Gradual convergence
- Many snapshots wide
- Leak, not jump
The defensive pause
Spread widening and depth thinning right at the event often precede the reprice, makers stepping back before they re-quote.
- Spread blows out
- Depth pulls
- Reprice follows
The two clocks, and why both matter
Every snapshot carries two timestamps. event_timestamp is when Polymarket emitted the change; capture_timestamp is when we processed it. For measuring how fast the market itself reacts, you align and bracket on event_timestamp, that is the market’s own clock, and it keeps your processing pipeline out of the measurement. capture_timestamp is not noise to discard, though: the gap between the two is the capture latency, and reporting it honestly tells your reader how much of any tiny lag is the market and how much is the plumbing.
event_timestampPolymarket emit time, the alignment axiscapture_timestampWhen we processed it, bounds the latency claimmid_priceWhat you watch converge to the new levelsequence_numberGap detection so a missing tick is not read as calm
Running the measurement
- 1Choose events with known times so you can bracket each one with a pre-event and post-event window on a common axis.
- 2Pull high-frequency snapshots across each window, ordered by time, and align them on event_timestamp.
- 3Define the target level the market should move toward, then measure how the mid price closes the gap and how many snapshots that takes.
- 4Stack many events to get a distribution of reprice lags, one event is anecdote, the spread across dozens is the finding.
We time the book, not the news
The clean version of this claim is narrow on purpose. We measure when the order book reprices, captured at roughly 20 Hz on crypto. We do not observe the instant a headline hit a wire or a block confirmed, so the lag you measure is book-to-book reaction, not wire-to-book. Stating that boundary is what keeps the result a measurement instead of a marketing line.
What faster or slower actually tells you
- A fast, clean reprice suggests a liquid, attentive book where the new probability is uncontroversial, the market agreed quickly.
- A slow drift can mean genuine disagreement, thin participation, or information that arrives in pieces rather than all at once.
- An overshoot that corrects is worth flagging separately, it is the market reacting and then walking part of it back, not a single move.
- Sampling rate caps your resolution: a reprice that completes inside one capture interval will look instantaneous, so report the rate alongside the lag.
The question is never whether the market updates. It is how long the book takes to agree, and with two timestamps on every snapshot, that interval stops being a guess.
Time a reprice yourself
Pull bracketed event windows with the historical guide, or replay an event tick by tick to watch the mid move.
Frequently asked questions
What does “information incorporation speed” measure on a prediction market?
It measures how long the order book takes to reprice after a scheduled event, the time for best bid, best ask, and mid price to move from their pre-event level toward the new fair value. You bracket events with known times at high frequency and clock how quickly the mid closes that gap.
Should I align on event_timestamp or capture_timestamp?
Align on event_timestamp, Polymarket’s own emit time, so your processing pipeline stays out of the measurement and the same event lines up across markets. capture_timestamp is still useful: the gap between the two is your capture latency, which bounds how precise the reprice-lag claim can honestly be.
Does this tell me when the news actually broke?
No. We capture when the order book reprices, not when a headline crossed a wire or a block confirmed. The lag you measure is book-to-book reaction, captured at roughly 20 Hz on crypto. It is a proxy for incorporation speed, and being explicit about that is what keeps it rigorous.
Why does the snapshot rate limit the result?
Your timing resolution can’t be finer than your capture interval. A reprice that finishes inside one snapshot gap will look instantaneous regardless of how fast it truly was. Crypto samples near 20 Hz, sports near 2 Hz, and slower categories slower still, so report the rate alongside any lag figure.