Polymarket Weather Market Resolution: How Your Bet Gets Settled

Step 1: The Market Closes

Every Polymarket daily temperature market has a specified end time — the point after which no new orders can be placed or filled. For daily high-temperature markets, this is typically end-of-day local time for the city in question, or shortly thereafter.

What “closes” means:

• No new limit orders accepted.
• No new fills on existing orders.
• Existing positions are locked in.

The close time is specified in the market's metadata and on the Polymarket UI. Critically: the market may close before the day's maximum temperature has been observed. A market closing at midnight UTC for a New York high-temperature market has a cutoff earlier than midnight New York local time — meaning the market can close while the afternoon observations are still being finalized. Read the specific close time for each market.

Step 2: The Data Is Finalized

After the market closes, the resolution process waits for the source data to be finalized. For Polymarket daily temperature markets, this means the Wunderground daily record for the named airport station.

Wunderground displays two types of temperature data for a station:

• Hourly observations — updated in near-real time from METAR reports.
• Daily summary — the finalized maximum temperature for the calendar day, which typically appears several hours after midnight local time once all ASOS/METAR data for the day has been processed and quality-controlled.

The market cannot resolve until the daily summary is finalized. This is why resolution often occurs not immediately at market close, but 2–8 hours afterward — the proposer waits for the Wunderground daily maximum to be confirmed before submitting.

Why This Matters

If you're checking an in-progress market in the late afternoon and the current METAR maximum reading is 73°F, that's not the resolution temperature. An end-of-day ASOS quality-control pass might adjust that reading, or a late-day temperature spike might push it to 74°F. The finalized daily maximum on Wunderground's station page, after the day's data is closed, is the definitive number.

Traders who bet based on intraday METAR observations and don't account for potential end-of-day adjustments occasionally get surprised.

Step 3: The UMA Proposer Submits

With data finalized, a proposer submits the resolution to UMA's Optimistic Oracle. This is the on-chain mechanism that Polymarket uses for all non-crypto market resolution.

A proposer is an Ethereum address that:

1. Deposits a bond (typically 750 USDC) as collateral.
2. Submits a transaction to the UMA OptimisticOracle contract, asserting which outcome should resolve YES.
3. Waits for the liveness window to expire.

Since August 2025, Polymarket has operated under UMA's MOOV2 (Multi-Oracle Optimistic Oracle v2) system, which restricts who can submit resolution proposals to a whitelist of approximately 37 vetted addresses. This replaced the previous open-proposal system, which had been susceptible to incorrect or premature proposals from arbitrary addresses.

If you are not on the proposer whitelist, you cannot submit a resolution. If no whitelisted proposer acts within a reasonable window, markets can stall — though this is rare for daily temperature markets, which have objective and easy-to-verify outcomes.

Step 4: The Liveness Window (2 Hours)

After the proposer submits an assertion, a 2-hour liveness window opens. During this window, any address can dispute the assertion by:

1. Calling the dispute function on the UMA contract.
2. Posting a dispute bond (equal to the proposer's bond).
3. Triggering the next stage of the resolution process.

If no one disputes within 2 hours, the assertion is accepted as final and the market resolves automatically.

What Happens If You Dispute

If a dispute is filed:

• The original assertion is invalidated.
• A new proposal request is opened.
• A different whitelisted proposer can submit a new assertion.
• If that assertion is also disputed, the question escalates to UMA's Data Verification Mechanism (DVM) — a token-holder vote that typically takes 2–4 days.

In practice, daily temperature markets are almost never disputed. The data source is objective (Wunderground), the temperature is clearly in one bucket or not, and the proposer bond is at risk if the assertion is wrong. The system creates strong incentives for accurate proposals.

The rare exceptions: markets where the station data is briefly unavailable at time of proposal, causing a proposer to submit on incomplete data; and markets where the temperature lands exactly on a bucket boundary, causing genuine ambiguity about which bucket applies.

Step 5: Settlement and Payout

Once the liveness window expires without dispute (or after a DVM vote resolves any dispute), the market settles on-chain:

• The winning bucket's YES holders receive $1.00 per share.
• All other buckets' YES holders receive $0.00 per share.
• All NO holders of the winning bucket receive $0.00 per share.
• All NO holders of losing buckets receive $1.00 per share.

Settlement is automatic — you don't need to do anything. The USDC flows to your wallet directly via the Conditional Token Framework smart contract.

Typical time from market close to settlement: 2–8 hours for standard markets with prompt finalization. In the occasional edge case (data delay, dispute), this extends to 4–7 days.

The Temperature Reading: What Counts and What Doesn't

This is the most technically specific part of resolution, and misunderstanding it has cost traders money.

Wunderground's Finalized Daily Maximum

The resolution uses Wunderground's finalized daily summary temperature for the named station — not any of the following:

• Intraday METAR temperature (the current temperature at any given hour).
• The National Weather Service official daily maximum for that station (NOAA NCEI).
• A different airport in the same city.
• The city-center reading from any weather service.
• Any temperature reported before the daily summary is finalized.

The specific Wunderground page is the station's page (e.g., wunderground.com/weather/KLGA for LaGuardia), and the resolution value is the maximum temperature shown in the day's summary once finalized.

The Rounding Rule

Temperatures resolve to whole degrees in the market's specified unit. A reading of 23.4°C resolves to 23°C. A reading of 22.9°C also resolves to 22°C. This is truncation, not rounding — and it's specified in the market rules.

At bucket boundaries, this matters enormously. If the market has a 23°C and a 24°C bucket, a reading of 23.9°C is in the 23°C bucket, not the 24°C bucket. A reading of 24.0°C is in the 24°C bucket.

This truncation rule creates a specific edge case: the “boundary temperature” scenario, where a reading of 24.9°C might look like it's “close to 25” but resolves firmly in the 24°C bucket. Bots that model rounding vs. truncation differently will make different trades near bucket boundaries.

Retroactive Revisions

Wunderground's finalized daily summary occasionally gets revised after initial posting — quality control can adjust a reading post-hoc if a sensor error is detected. The Polymarket market rules state that revisions after the daily summary is finalized will not be considered for resolution. The first finalized reading is the authoritative one.

This means: if Wunderground initially shows 73°F as the daily max, the market resolves to the 73°F bucket, and a subsequent NOAA revision showing 72°F as corrected doesn't change anything for resolution. The initial finalized Wunderground reading controls.

Common Resolution Questions and Edge Cases

What if the station data is unavailable?

If the resolution station has a data outage and Wunderground does not show a finalized daily maximum, the market cannot resolve immediately. The proposer must wait for data to become available. In rare cases (sustained sensor failure, station maintenance), markets have stalled for several days. When data eventually appears, the market resolves normally.

The market rules typically include a fallback provision: if the primary station is permanently unavailable, Polymarket may designate an alternative data source. This has occurred rarely and was adjudicated through the UMA dispute process.

What if the temperature is exactly on a bucket boundary?

If the resolution station shows exactly 70°F and the buckets are 69–70°F and 71–72°F, the temperature falls in the 69–70°F bucket (it landed at 70, which is within that range). Market descriptions specify whether buckets are inclusive or exclusive at boundaries — read carefully. Most Polymarket temperature markets use inclusive lower bound and exclusive upper bound: the 69–70°F bucket covers 69.0°F to 70.9°F (before whole-degree truncation is applied).

What if I disagree with the resolution?

You can file a UMA dispute within the 2-hour liveness window by posting the required bond. The dispute triggers a new proposal request. If you believe the proposer used the wrong data source (e.g., they pulled a non-finalized reading), the dispute mechanism is the correct path.

If the 2-hour window has already passed and the market has settled, resolution is final. There is no appeal mechanism after settlement.

Does the proposer have to be human?

No. Many whitelisted proposers are automated systems. The proposer bot checks the Wunderground page for the named station, reads the finalized daily maximum, determines which bucket it falls into, and submits the assertion. This is faster and less error-prone than manual resolution — and it's why most daily temperature markets resolve within a few hours of market close.

Why You Should Understand This Before Trading

Resolution mechanics seem like a back-office concern, but they directly affect trading decisions in at least three ways:

1. Timing your exit. Understanding that resolution takes 2–8 hours after close means you know when to expect your USDC back. If you need capital for another market, you know the earliest it's available.

2. Trading near bucket boundaries. If the forecast shows 70.4°F and the market closes at midnight, you're technically in the 70°F bucket by truncation. A model that rounds to 71°F instead of truncating to 70°F will make a different trade.

3. Understanding station specificity. If you've been checking the wrong station (city-center rather than airport), you might trade a bucket that's correct for the wrong measurement. Resolution uses the named station, full stop.

4. Dispute risk. If you hold a winning position and a proposer asserts the wrong outcome, you have exactly 2 hours to dispute. If you're not monitoring and the window closes, you lose. Systematic traders automate resolution monitoring for exactly this reason.

The Full Timeline: From Close to Payout

A Note on MOOV2 and What Changed

Prior to August 2025, any Ethereum address could submit a resolution proposal to UMA's OptimisticOracle for Polymarket markets. This created problems: bad actors submitted premature or incorrect proposals (sometimes intentionally to trigger disputes, sometimes due to error), and the 2-hour window was occasionally not enough time for correct information to surface.

The MOOV2 transition, formalized via UMIP-189, restricts proposal rights to ~37 whitelisted addresses — a curated set of entities who have demonstrated reliability and posted larger bonds. The tradeoff: resolution is now faster and more reliable, but depends on the continued activity of whitelisted proposers. If all whitelisted proposers become inactive for a given market, it could stall.

For daily temperature markets in practice: MOOV2 has worked reliably. The objective nature of temperature data (check Wunderground, read the number) means reliable proposers have no reason to make errors, and the market has not seen meaningful resolution failures since the transition.

Related articles

• Polymarket Weather Markets Explained: How Daily Temperature Trading Works
• Polymarket Weather Predictions: How the Odds Are Set
• How to Trade Polymarket Weather Markets: A Complete Guide