event_timestampClock 1capture_timestampClock 2- Pipeline latencyDifference
- Emit timeBacktest on
A snapshot records two moments: when Polymarket emitted the book change, and when we processed it. Keeping both is not redundancy, the first is the clock that keeps a backtest honest, the second tells you how fresh the data was, and their gap is a latency measurement you would otherwise have to guess at.
It is tempting to collapse a snapshot down to one timestamp. Resist it. event_timestamp is when the change actually happened at the source; capture_timestamp is when it reached our pipeline. They answer different questions, and latency-sensitive research needs both.
What each clock measures
event_timestamp
Polymarket’s own emit time, the instant the book change occurred at the source, before any transit.
- Source-of-truth time
- The alignment axis
- What you backtest on
capture_timestamp
When our pipeline processed the event. It tells you how fresh the row was when it landed.
- Processing time
- Freshness signal
- Operational view
Their difference
Subtract one from the other and you have measured end-to-end pipeline latency for that very snapshot.
- Per-row latency
- No estimation
- Distribution, not a guess
Backtest on emit time, not processing time
When you replay history, your decisions must be made on information that actually existed at that moment. event_timestamp is that moment, the time the change was real in the market. Order and bracket your backtest on it, and a simulated decision can only ever see what was knowable then.
The wrong clock leaks the future
If you align a backtest on capture_timestamp, processing jitter quietly shifts events around in time, and a slow-to-process update can appear to arrive after something it actually preceded. Anchoring on event_timestamp removes that leakage: the order of events matches the order they happened in the market.
When capture_timestamp is the right clock
Capture time is not the backtest clock, but it is not noise either. It is the right lens for operational questions: how fresh is the live feed, how does latency behave under load, is one category lagging another. For those, capture_timestamp, and its distance from event_timestamp, is exactly what you want.
- 1For backtests and event studies, order and bracket everything on event_timestamp so no decision sees the future.
- 2For latency monitoring, take capture_timestamp minus event_timestamp per snapshot and study the distribution, not just the mean.
- 3For point-in-time lookups, ask for the book as of a moment and read back the most recent prior snapshot, never a later one.
- 4For freshness gates, pair capture timing with crypto_price_age_ms to know how current the spot stamp was too.
The fields in play
event_timestampSource emit time, the no-lookahead axiscapture_timestampPipeline processing time, freshnesssequence_numberOrders events when timestamps tie- UTC ·
msBoth clocks share one precise scale
Both timestamps are UTC at millisecond precision, so they sit on one scale and subtract cleanly. Where two events share an emit time, the sequence number breaks the tie, so ordering stays unambiguous even at the resolution where the two clocks blur together.
- Latency is a distribution, report the spread and the tail, because the worst-case row is what bites a latency-sensitive strategy.
- A point-in-time query searches back from your timestamp, returning the most recent prior snapshot, by construction it cannot hand you the future.
- Preserving both clocks is what lets the same archive serve a no-lookahead backtest and an operational latency audit without re-capture.
- Never reorder a series on capture time when the question is about the market, that is how lookahead sneaks in unnoticed.
One clock tells you when the market moved; the other tells you when you found out. Confusing them is how a backtest learns to cheat.
Replay without lookahead
The backtesting tools order on emit time for you; the quant research page covers latency and point-in-time workflows.
Frequently asked questions
What is the difference between event_timestamp and capture_timestamp?
event_timestamp is when Polymarket emitted the book change at the source; capture_timestamp is when our pipeline processed it. The first is the market’s own clock, the second is our processing clock, and the gap between them is the end-to-end latency for that snapshot.
Which timestamp should I backtest on?
event_timestamp. Ordering and bracketing a backtest on the source emit time guarantees a simulated decision only ever sees information that actually existed at that moment. Aligning on capture_timestamp lets processing jitter shift events in time and can leak the future into the past.
Is capture_timestamp useful for anything then?
Yes, it is the right clock for operational questions. Subtract event_timestamp from it to measure pipeline latency per snapshot, monitor feed freshness, or check whether one category lags another. It just should not be the alignment axis for research about the market itself.
How do point-in-time lookups avoid lookahead?
A point-in-time query searches backward from the timestamp you give it and returns the most recent snapshot at or before that moment, looking up to an hour prior. Because it can only return a prior record, it cannot hand you a snapshot from the future of your query time.