Market Closing Times for Quants: Trust Settlement, Not End Dates

For prediction market backtests and bots, the correct closing signal is settlement_ts and status, not the venue-published endDate. A market closing times dataset covers three distinct moments: scheduled close, trading close, and final settlement. We build and normalize these fields across venues, and the rule holds everywhere: trust settlement, not schedule.

TL;DR:
Store scheduled, operational, and settlement timestamps separately in UTC, preserve original venue values, and retain updated_time and source_version for audit and reproducible backtests.
Treat a market without a populated settlement_ts as unresolved; closed only means trading stopped, and Kalshi also uses settlement_value_usd as its authoritative settlement indicator.
Join candles to market metadata by venue and market_id, tag the settlement_ts candle as resolution, and freeze signal inputs before settlement using a safety buffer.
Calculate realized PnL from settlement_value_usd, not the last traded price, and reconcile settlement records against final candle closes after each refresh.

Assymetrixdata.assymetrix.comUse Reliable Cross-Venue Market DataAssymetrix brings prediction market data from Polymarket, Kalshi, and Limitless into a unified API for research and trading tools.Explore the Data API

1. Canonical schema: fields to store and why each matters
2. Mapping venue data to the canonical schema
3. Common data hazards and engineering practices to avoid them
4. Practical integration patterns and query examples for backtests and bots
5. Quant and trader use cases that depend on precise closing times
Why closing-time precision keeps failing in practice
Getting normalized closing-time data through a unified Data API
FAQ
Sources

1. Canonical schema: fields to store and why each matters

A reliable market closing times dataset needs a fixed set of fields, each serving a distinct computation. Mixing them up is the most common source of backtest errors we see in production pipelines.

market_id (string): a canonical identifier that stays stable across venue renames or re-listings.
venue (string): the originating exchange, needed for cross-venue joins and reconciliation.
market_start_time and market_end_time (timestamp, UTC): the scheduled window as published by the venue at listing time.
open_time and close_time: operational timestamps that can be updated by the venue after a market’s initial listing.
settlement_ts (timestamp): the moment a market’s outcome was actually determined, the field to treat as authoritative.
status (enum): lifecycle state, typically active, closed, determined, or finalized/settled.
resolved_outcome, updated_time, source_version: fields that support reconciliation when upstream data changes.

market_end_time answers “when was this scheduled to close.” close_time answers “when did new orders stop.” settlement_ts answers “when did this market’s outcome become final,” and it is the field that belongs in PnL calculations and resolution labeling. Every timestamp should be stored in UTC, with the original venue-published value preserved alongside the normalized one so that corrections can be audited rather than silently overwritten.

2. Mapping venue data to the canonical schema

Cross-venue normalization starts with knowing which upstream table owns which fact. Dune’s prediction_markets.markets table serves as the cross-venue dimension, carrying market_end_time, settlement_ts, and status side by side, and it explicitly flags that Polymarket’s published end date is often inaccurate for historical outcome calculations.

prediction_markets.markets: the cross-venue dimension table; use settlement_ts and status, not market_end_time, for resolution logic.
kalshi.market_details: holds lifecycle metadata including open_time and close_time, with close_time capable of reflecting later venue updates rather than the original listing value.
polymarket_polygon.ohlcv_hourly: hourly candles that forward-fill no-trade hours and pin the closing price to the settlement value on the resolution hour.

The working rule of thumb: treat market_end_time as a scheduling hint, and treat settlement_ts paired with status as the field pair that determines whether a market’s outcome is actually final.

3. Common data hazards and engineering practices to avoid them

Settlement timestamps separated from contract end dates

The single most expensive mistake in this space is conflation: treating a scheduled endDate as if it were the final resolution timestamp. This causes backtest label leakage, because a position that looks closed at the scheduled hour may still be open, pending, or reversed before true settlement. It also corrupts PnL calculations that reference a price snapshot from before the actual outcome was determined.

Lifecycle nuance compounds the problem. Kalshi’s market_details schema defines a status vocabulary that includes finalized, determined, inactive, closed, active, and initialized, and uses settlement_value_usd as the authoritative settlement indicator rather than any single timestamp alone. A market can be “closed” to new orders while still awaiting a “determined” or “finalized” state, and bots that treat “closed” as equivalent to “settled” will act on incomplete information.

Build an explicit status state machine rather than inferring lifecycle from timestamps alone.
Run nightly reconciliation jobs comparing settlement_value_usd or settlement_ts against the final candle close.
Store source_version and updated_time on every row so corrected upstream fields can be traced and backfilled.
Keep audit logs of status transitions, with alerts fired on any transition into or out of “determined.”
Flag markets with delayed settlement and apply a safety buffer before automated systems act on them.

Pro Tip: Treat any market without a populated settlement_ts as unresolved, regardless of what its scheduled close_time suggests.

4. Practical integration patterns and query examples for backtests and bots

A workable architecture joins the canonical market dimension to hourly candle data on (venue, market_id), then uses settlement_ts to mark which candle bar represents the true resolution event rather than relying on bar position alone.

Join canonical market metadata to ohlcv_hourly on venue and market_id, then tag the bar containing settlement_ts as the resolution bar.
For backtest entry signals, freeze decisions at t <= settlement_ts - safety_buffer so no feature computation leaks information from after resolution.
Compute realized PnL from settlement_value_usd rather than the last traded price, since the last trade can predate the actual determination.
Run a streaming layer for live status updates, paired with a periodic full historical refresh that captures corrected settlement_ts values pushed upstream after the fact.
After every refresh, run data quality asserts: no null settlement_ts on rows marked finalized, no close_time earlier than open_time, no orphaned market_id values.

This pattern works whether the consumer is a backtesting engine replaying history or a live bot gating new positions against markets that are not yet genuinely closed.

5. Quant and trader use cases that depend on precise closing times

Reproducible backtests depend on freezing both settlement_ts and source_version, so a result computed today can be regenerated months later even after upstream corrections. Latency and arbitrage detection compares settlement_ts timing across venues covering the same real-world event, using candle pin timing as a secondary confirmation signal.

Time-to-resolution: a feature built from the gap between current time and expected settlement, useful for decay-weighted signal construction.
Pre-close volume surge: volume concentrated near close_time often signals information asymmetry worth modeling separately from mid-market activity.
Cross-venue settlement lag: comparing settlement_ts for equivalent markets across venues surfaces latency arbitrage windows.
Auditability: canonical IDs paired with source_version are what let a published result be rerun and verified rather than taken on faith.

Why closing-time precision keeps failing in practice

Most backtest failures we encounter trace back to one root cause: a pipeline treated a scheduled close as a settled outcome. The fix is rarely more data. It is almost always a missing status check or a settlement_ts field that was never actually plumbed through from the venue source to the application layer.

Teams that adopt a canonical schema early spend far less time debugging phantom PnL discrepancies later. The lesson scales: normalize the lifecycle fields before writing a single line of strategy logic, not after a trade goes wrong.

— Dean

Getting normalized closing-time data through a unified Data API

Normalized settlement_ts, lifecycle status, and canonical market IDs are available across leading prediction market venues through a single integration, built on a substantial historical trading dataset. Engineers designing execution safeguards around these timestamps can also review risk management setup practices for automated order controls and safety buffers.

Review the Data API documentation, or see the real-time and historical feed guide and Python integration examples to request a sample export.

FAQ

What is a market closing times dataset?

It is a structured dataset covering a prediction market contract’s scheduled close, trading close, and final settlement timestamp, rather than a single closing field. The distinction matters because a market’s scheduled close and its actual resolution can differ by hours or more.

Why shouldn’t I trust the venue’s endDate field?

settlement_ts paired with status reflects the actual resolution event and should be used instead for historical outcome calculations.

How do OHLCV candles handle market resolution?

Hourly candle tables like polymarket_polygon.ohlcv_hourly forward-fill no-trade hours and pin the close price to the settlement value on the resolution-hour bar. This gives backtests a reliable anchor point for labeling the bar where a market’s outcome actually became final.

What lifecycle statuses should a dataset track?

A robust schema tracks at minimum active, closed, determined, and finalized or settled states, mirroring the vocabulary used in Kalshi’s market_details table. Treating “closed” as equivalent to “settled” is a common error since a market can stop accepting orders well before its outcome is determined.

Does a Data API provide these normalized fields?

A Data API provides normalized settlement_ts, lifecycle status, and canonical IDs across Polymarket, Kalshi, and Limitless for developers and quant teams. Pricing details and access tiers are available on the Data API page.

Sources

Market Closing Times for Quants: Trust Settlement, Not End Dates

For prediction market backtests and bots, the correct closing signal is settlement_ts and status, not the venue-published endDate. A market closing times dataset covers three distinct moments: scheduled close, trading close, and final settlement. We build and normalize these fields across venues, and the rule holds everywhere: trust settlement, not schedule.

TL;DR:
Store scheduled, operational, and settlement timestamps separately in UTC, preserve original venue values, and retain updated_time and source_version for audit and reproducible backtests.
Treat a market without a populated settlement_ts as unresolved; closed only means trading stopped, and Kalshi also uses settlement_value_usd as its authoritative settlement indicator.
Join candles to market metadata by venue and market_id, tag the settlement_ts candle as resolution, and freeze signal inputs before settlement using a safety buffer.
Calculate realized PnL from settlement_value_usd, not the last traded price, and reconcile settlement records against final candle closes after each refresh.

Assymetrixdata.assymetrix.comUse Reliable Cross-Venue Market DataAssymetrix brings prediction market data from Polymarket, Kalshi, and Limitless into a unified API for research and trading tools.Explore the Data API

1. Canonical schema: fields to store and why each matters
2. Mapping venue data to the canonical schema
3. Common data hazards and engineering practices to avoid them
4. Practical integration patterns and query examples for backtests and bots
5. Quant and trader use cases that depend on precise closing times
Why closing-time precision keeps failing in practice
Getting normalized closing-time data through a unified Data API
FAQ
Sources

1. Canonical schema: fields to store and why each matters

A reliable market closing times dataset needs a fixed set of fields, each serving a distinct computation. Mixing them up is the most common source of backtest errors we see in production pipelines.

market_id (string): a canonical identifier that stays stable across venue renames or re-listings.
venue (string): the originating exchange, needed for cross-venue joins and reconciliation.
market_start_time and market_end_time (timestamp, UTC): the scheduled window as published by the venue at listing time.
open_time and close_time: operational timestamps that can be updated by the venue after a market’s initial listing.
settlement_ts (timestamp): the moment a market’s outcome was actually determined, the field to treat as authoritative.
status (enum): lifecycle state, typically active, closed, determined, or finalized/settled.
resolved_outcome, updated_time, source_version: fields that support reconciliation when upstream data changes.

market_end_time answers “when was this scheduled to close.” close_time answers “when did new orders stop.” settlement_ts answers “when did this market’s outcome become final,” and it is the field that belongs in PnL calculations and resolution labeling. Every timestamp should be stored in UTC, with the original venue-published value preserved alongside the normalized one so that corrections can be audited rather than silently overwritten.

2. Mapping venue data to the canonical schema

Cross-venue normalization starts with knowing which upstream table owns which fact. Dune’s prediction_markets.markets table serves as the cross-venue dimension, carrying market_end_time, settlement_ts, and status side by side, and it explicitly flags that Polymarket’s published end date is often inaccurate for historical outcome calculations.

prediction_markets.markets: the cross-venue dimension table; use settlement_ts and status, not market_end_time, for resolution logic.
kalshi.market_details: holds lifecycle metadata including open_time and close_time, with close_time capable of reflecting later venue updates rather than the original listing value.
polymarket_polygon.ohlcv_hourly: hourly candles that forward-fill no-trade hours and pin the closing price to the settlement value on the resolution hour.

The working rule of thumb: treat market_end_time as a scheduling hint, and treat settlement_ts paired with status as the field pair that determines whether a market’s outcome is actually final.

3. Common data hazards and engineering practices to avoid them

The single most expensive mistake in this space is conflation: treating a scheduled endDate as if it were the final resolution timestamp. This causes backtest label leakage, because a position that looks closed at the scheduled hour may still be open, pending, or reversed before true settlement. It also corrupts PnL calculations that reference a price snapshot from before the actual outcome was determined.

Lifecycle nuance compounds the problem. Kalshi’s market_details schema defines a status vocabulary that includes finalized, determined, inactive, closed, active, and initialized, and uses settlement_value_usd as the authoritative settlement indicator rather than any single timestamp alone. A market can be “closed” to new orders while still awaiting a “determined” or “finalized” state, and bots that treat “closed” as equivalent to “settled” will act on incomplete information.

Build an explicit status state machine rather than inferring lifecycle from timestamps alone.
Run nightly reconciliation jobs comparing settlement_value_usd or settlement_ts against the final candle close.
Store source_version and updated_time on every row so corrected upstream fields can be traced and backfilled.
Keep audit logs of status transitions, with alerts fired on any transition into or out of “determined.”
Flag markets with delayed settlement and apply a safety buffer before automated systems act on them.

Pro Tip: Treat any market without a populated settlement_ts as unresolved, regardless of what its scheduled close_time suggests.

4. Practical integration patterns and query examples for backtests and bots

A workable architecture joins the canonical market dimension to hourly candle data on (venue, market_id), then uses settlement_ts to mark which candle bar represents the true resolution event rather than relying on bar position alone.

Join canonical market metadata to ohlcv_hourly on venue and market_id, then tag the bar containing settlement_ts as the resolution bar.
For backtest entry signals, freeze decisions at t <= settlement_ts - safety_buffer so no feature computation leaks information from after resolution.
Compute realized PnL from settlement_value_usd rather than the last traded price, since the last trade can predate the actual determination.
Run a streaming layer for live status updates, paired with a periodic full historical refresh that captures corrected settlement_ts values pushed upstream after the fact.
After every refresh, run data quality asserts: no null settlement_ts on rows marked finalized, no close_time earlier than open_time, no orphaned market_id values.

This pattern works whether the consumer is a backtesting engine replaying history or a live bot gating new positions against markets that are not yet genuinely closed.

5. Quant and trader use cases that depend on precise closing times

Reproducible backtests depend on freezing both settlement_ts and source_version, so a result computed today can be regenerated months later even after upstream corrections. Latency and arbitrage detection compares settlement_ts timing across venues covering the same real-world event, using candle pin timing as a secondary confirmation signal.

Time-to-resolution: a feature built from the gap between current time and expected settlement, useful for decay-weighted signal construction.
Pre-close volume surge: volume concentrated near close_time often signals information asymmetry worth modeling separately from mid-market activity.
Cross-venue settlement lag: comparing settlement_ts for equivalent markets across venues surfaces latency arbitrage windows.
Auditability: canonical IDs paired with source_version are what let a published result be rerun and verified rather than taken on faith.

Why closing-time precision keeps failing in practice

Most backtest failures we encounter trace back to one root cause: a pipeline treated a scheduled close as a settled outcome. The fix is rarely more data. It is almost always a missing status check or a settlement_ts field that was never actually plumbed through from the venue source to the application layer.

Teams that adopt a canonical schema early spend far less time debugging phantom PnL discrepancies later. The lesson scales: normalize the lifecycle fields before writing a single line of strategy logic, not after a trade goes wrong.

— Dean

Getting normalized closing-time data through a unified Data API

Normalized settlement_ts, lifecycle status, and canonical market IDs are available across leading prediction market venues through a single integration, built on a substantial historical trading dataset. Engineers designing execution safeguards around these timestamps can also review risk management setup practices for automated order controls and safety buffers.

Review the Data API documentation, or see the real-time and historical feed guide and Python integration examples to request a sample export.

FAQ

What is a market closing times dataset?

It is a structured dataset covering a prediction market contract’s scheduled close, trading close, and final settlement timestamp, rather than a single closing field. The distinction matters because a market’s scheduled close and its actual resolution can differ by hours or more.

Why shouldn’t I trust the venue’s endDate field?

settlement_ts paired with status reflects the actual resolution event and should be used instead for historical outcome calculations.

How do OHLCV candles handle market resolution?

Hourly candle tables like polymarket_polygon.ohlcv_hourly forward-fill no-trade hours and pin the close price to the settlement value on the resolution-hour bar. This gives backtests a reliable anchor point for labeling the bar where a market’s outcome actually became final.

What lifecycle statuses should a dataset track?

A robust schema tracks at minimum active, closed, determined, and finalized or settled states, mirroring the vocabulary used in Kalshi’s market_details table. Treating “closed” as equivalent to “settled” is a common error since a market can stop accepting orders well before its outcome is determined.

Does a Data API provide these normalized fields?

A Data API provides normalized settlement_ts, lifecycle status, and canonical IDs across Polymarket, Kalshi, and Limitless for developers and quant teams. Pricing details and access tiers are available on the Data API page.

Market Closing Times for Quants: Trust Settlement, Not End Dates