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.
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.
"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."
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.
Rounding, observation windows, and delayed data are where most trader confusion starts.
[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.
[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.
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.
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.
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, but final resolution remains internal.
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: Global Polymarket markets use UMA-style challenge mechanics.
Different system, different trust tradeoff. Kalshi is simpler to explain, but more centralized. Polymarket is more contestable, but harder for normal users to navigate.
