Reference price coverage and gaps on Polymarket

• Reference capture for BTC, ETH, SOL, XRP and DOGE began at 07:38:14 UTC on 2026-10-17
• Capture for BNB, HYPE and ZEC began later, at 11:52:55 UTC the same day
• A market that closed before its asset's capture start has no archived reference row for that window
• The point-in-time snapshot endpoint reports the age of the nearest reference observation, so gaps are detectable
• Per-asset captures run into the tens of thousands of rows each by 2026-10-17

Reference capture is a per-asset feed, and feeds are added over time. On 2026-10-17 the first five assets - BTC, ETH, SOL, XRP and DOGE - began recording at 07:38:14 UTC. BNB, HYPE and ZEC were added roughly four hours later, at 11:52:55 UTC.

The practical result is a hard boundary per asset. Markets that closed before an asset's capture start have no archived reference row, so their grade cannot be reproduced from reference data alone - only inferred from the market's own book.

A gap is any market window for which the reference endpoint returns no rows. The safest pattern is to pull the reference series for the exact window and treat an empty response as 'not gradeable from reference data' rather than 'price unchanged'.

The point-in-time snapshot endpoint makes this explicit. It returns the nearest reference observation at or before a requested timestamp and reports how old it is, so a large gap shows up as a large age rather than silently returning the wrong era's price.

Decide a policy up front. The two defensible choices are to drop any market whose window has no reference row, or to carry the nearest available reference value forward with an explicit staleness cap. Mixing the two within one study without recording which applies produces results that cannot be reproduced.

For historical work that spans the boundary, segment by asset. BTC and ETH have the longest coverage and the fewest gaps; BNB, HYPE and ZEC lose the first several hours of the day. Reporting a single blended coverage figure across all eight assets hides that difference.

A reference archive that adds assets over time will always show staggered start times. That is a property of how feeds are onboarded, not a data-quality failure. The archive flags it honestly by simply not having rows where capture did not run, rather than back-filling estimated prices.

That honesty is what makes the data trustworthy: an absent row means 'we did not observe this', which is a different and more useful statement than a guessed value.

import requests

BASE = "https://api.polyorderbooks.com/v1"
HEADERS = {"X-API-Key": "your-key"}
START, END = 1787486400, 1787486700

for asset in ("btc", "bnb"):
    r = requests.get(
        f"{BASE}/reference-prices",
        headers=HEADERS,
        params={"asset": asset, "kind": "twap",
                "start_ts": START, "end_ts": END},
    )
    r.raise_for_status()
    rows = r.json()["data"]
    status = "covered" if rows else "GAP - no rows"
    print(f"{asset}: {len(rows)} rows -> {status}")

The Starter plan is free, includes order books, prices, and metrics at 250ms resolution, with 3 days of history, 60 requests/min, 1,000/day, 1 free AI backtest, and 3 strategy backtests. No credit card required.

Paid data windows from $19/mo extend history to 30–120 days at higher throughput. Backtest AI add-on is +$19/mo or standalone at $29/mo.

• Reference price snapshots
• Point-in-time snapshot API
• Resolution, explained