Polymarket Weather Market Structure

Concrete, verified reference facts about Polymarket’s daily weather (temperature) markets, surveyed live via the Gamma API on 2026-06-07. These are stable API / market-structure facts that ground the weather-bet project — a Rust app that bets on these markets using a blend+calibrate weather-forecasting algorithm. This is the durable substrate; the betting/algorithm design decisions live in separate notes.

For Agents

Everything here was confirmed against live Gamma API responses on 2026-06-07. Numbers tagged “observed” (volume/liquidity/spread) are point-in-time snapshots and will drift; structural facts (bucket layout, neg-risk, ICAO resolution, whole-°C precision, endpoint shapes) are stable. Shared trading infrastructure (CLOB order books, wallet auth, on-chain fill decode, Telegram, deploy) overlaps with the sibling polymarket-fetch project — reuse it, don’t rebuild it.

Product

• Daily “Highest temperature in [city] on [date]?” and “Lowest temperature in [city] on [date]?” markets.
• Run daily across roughly 25–35 global cities.
• Next-day markets open ~1 day ahead — created the evening before the target date.

Event / market structure

• Each event = 11 mutually-exclusive temperature buckets, modeled as a neg-risk multi-outcome group.
• Buckets are 1°C wide with open-ended tails. Example — Seoul, June 8: "18°C or below", "19°C", "20°C" … "27°C", "28°C or higher".
• Each bucket is its own Yes/No market with its own CLOB order book.
• The bucket’s Yes outcomePrice = market-implied probability of that bucket resolving true.
• Yes prices across the 11 buckets form a discrete probability distribution that sums to ~1 — slightly under, due to spread / vig.

Quick Reference

One event → 11 buckets → 11 CLOB books. Read all 11 Yes outcomePrices and you have the market’s full implied distribution over next-day daily max (or min) temperature, in 1°C bins. The edge is your calibrated distribution vs. theirs.

Resolution

• Source: Wunderground, at a specific ICAO airport station per city — NOT the city center.
• Example (Seoul): resolves on Incheon Intl Airport Station (RKSI) — https://www.wunderground.com/history/daily/kr/incheon/RKSI ~50 km from Seoul, coastal. The city↔station gap is structural, not incidental.
• Resolves to the temperature range containing the highest temperature recorded at that station for the calendar day (for the “highest” markets; lowest analogously).

Precision

• Resolution measures temperatures to whole degrees Celsius (e.g. 9°C).
• That whole-degree value is the precision used to resolve.
• Therefore the resolved bucket = the rounded daily max (or min) temperature at the station.

Timing

• Cannot resolve until the first data point for the following date is published on Wunderground.
• Revisions to recorded temps are considered until that point.
• endDate is typically the next day at 12:00:00Z.

Liquidity & volume (observed 2026-06-07)

Snapshot — will drift

The figures below are a single 2026-06-07 reading. Use them for sizing intuition, not as fixed parameters.

• Per city/day volume: ~$30k–$280k. Examples: Seoul $272k\ast \ast ,Shenzhen\ast \ast$205k, Taipei $116k\ast \ast ,London\ast \ast$148k, NYC high $90k\ast \ast +low\ast \ast$49k.
• Per-bucket liquidity: ~$1k–$9k.
• Spreads: ~1¢ near the distribution mode, wider in the tails.
• Markets are flagged restricted: true, have neg-risk enabled, and carry openInterest in the tens of thousands.

Out of scope (illiquid / unsuitable)

• Rain / precipitation markets exist but are near-zero volume — e.g. “Will it rain in Central Park” = $13 volume.
• Long-range disaster / climate markets (hurricanes, Arctic sea-ice minimum, major volcano) exist but are single-outcome, low-frequency, and climatology-driven — not a daily, skill-rich, repeated-bet surface.

Why this is the edge surface (thesis)

The forecast target is well-defined and skill-rich: next-day daily MAX 2 m temperature at a specific ICAO/METAR station, rounded to whole °C. NWP next-day station Tmax RMSE is roughly 1–1.5°C, right at the 1°C bucket resolution — so calibrated probability mass actually moves between buckets.

Four reinforcing edges:

1. Station ≠ city systematic bias — the crowd anchors on the city; resolution is the airport station. The geographic/microclimate gap is exploitable.
2. Calibrated predictive distribution — a properly calibrated distribution from NWP ensembles vs. the market’s implied prices.
3. Whole-degree rounding + tight buckets — reward calibration; small distribution-shape differences map to tradeable price differences.
4. Daily cadence — ~25–35 cities × daily → hundreds of repeated bets → an edge that is statistically validatable rather than anecdotal.

API access notes

• Gamma API is public, no auth for reads.

Keyword search

GET https://gamma-api.polymarket.com/public-search?q=<term>&limit_per_type=100

Returns .events[] (keyword search).

Full event (the useful one)

GET https://gamma-api.polymarket.com/events?slug=<slug>

Returns the full event with .markets[]. Each bucket market exposes: outcomes, outcomePrices, bestBid, bestAsk, spread, clobTokenIds, liquidity, and a description carrying the resolution source (the Wunderground ICAO station + URL).

For Agents — field availability quirk

The event/market volume field IS populated in search results. But liquidity, volume24hr, and volumeNum are null in search — they are only present on the /events?slug= detail response. Plan two calls: search to discover slugs, then /events?slug= per event for the full book/liquidity picture.

Relationship to polymarket-fetch

The sibling polymarket-fetch Rust workspace already implements the Polymarket plumbing this project can lean on:

• Gamma API client patterns (the same gamma-api.polymarket.com host).
• CLOB order books + clobTokenIds handling.
• On-chain fill decode via Polygon OrderFilled logs (see copy-trade-lane) — relevant if/when execution moves on-chain.
• Telegram lifecycle notifications (telegram) and the deploy path on ops-vm (polymarket-fetch-deploy).

Wallet auth and order-placement infrastructure for actually betting (vs. polymarket-fetch’s read/copy posture) is a weather-bet design question still being decided — this note only captures the market facts, not those decisions.

Related

• weather-bet
• polymarket-fetch
• copy-trade-lane
• polymarket-fetch-deploy