How Kalshi Weather Contracts Actually Settle
You placed a contract on tomorrow's high temperature. Here's exactly how Kalshi decides if you're right.
Settlement source warning
Weather contracts do not resolve based on your favorite weather app. They resolve based on the exact source, location, and rule set named in the contract.
The source chain
Kalshi uses the named weather source chain in the contract terms. For weather markets, the audited data here points to a primary NOAA station feed, then named fallbacks if that feed is unavailable.
1. NOAA ASOS station data
2. NCEI Climate Data Online
3. NWS Daily Climate Report (CLI product)
What users expect
"The hottest moment of the day where I am."
"Whatever my weather app showed on the hourly chart."
"The temperature that felt most real to me locally."
What Kalshi measures
The highest temperature recorded at the designated station named in the contract terms, using the contract's stated observation and rounding rules.
Airport stations are common.
The designated station may not be your backyard. That mismatch is one of the main reasons traders think settlement is wrong when the contract actually followed its own source.
[Pending verification]
Example ASOS station tickers still need verification against live Kalshi contract terms. Check the specific market rules before assuming which station applies.
The part nobody explains well
Rounding, observation windows, and delayed data are where most trader confusion starts.
Temperature rounding
[Pending verification]
Contract-specific rounding behavior still needs verification against live Kalshi contract terms. Do not assume the headline number tells you how tenths are handled.
Observation window
[Pending verification]
The exact observation window should be read from the contract terms. Weather traders get burned when they assume the window matches their app's display logic.
Data delay risk
Real-time weather apps, archived climate databases, and exchange settlement feeds can disagree temporarily. If the primary feed is delayed or unavailable, the named fallback can matter more than what you saw intraday.
That does not automatically mean the market was cheated. It usually means the contract source chain was narrower than the weather information you were casually watching.
Illustrative walkthrough
This is a teaching example, not a verified live contract. It shows the logic chain you should apply before blaming settlement.
Why this section stays cautious
Exact station examples, window wording, and rounding behavior are pending verification against live Kalshi contract terms. This page is explaining the process honestly, not pretending we verified details we have not verified.
If you think settlement was wrong
Kalshi does not publish a formal trader dispute window. The audited oracle data describes trader escalation as support contact or Discord discussion, while final authority stays with the internal markets team.
Kalshi has no formal trader dispute mechanism. Traders may contact support or post in Discord, but Kalshi's internal markets team makes all final resolution decisions. An Outcome Review Committee (board committee) may be invoked at Kalshi's sole discretion.
Kalshi vs Polymarket trust model
Kalshi uses internal resolution authority tied to named contract sources. Polymarket global markets use an oracle-and-dispute flow with a challenge window and bond requirement.
Polymarket dispute note: 2-hour liveness/challenge period after a resolution is proposed. If disputed, a new proposal is requested. If disputed again, escalates to UMA DVM token-holder vote (48–96 hours). Bond required to dispute: $750 USDC.e. Polymarket US markets are resolved directly by the Markets Team.
Different system, different trust tradeoff. Kalshi is simpler to explain, but more centralized. Polymarket is more contestable, but harder for normal users to navigate.