Prediction markets look simple from the outside: a question has a “Yes” side and a “No” side, people trade, then one side wins.

But the part that often matters most happens after the trading: resolution. Who decides the answer? Which source counts? What happens if the event is messy, delayed, disputed, or not quite covered by the headline?

That is where prediction markets can become confusing, even for reasonable users. A market title may feel clear in normal language, while the actual payout depends on a more specific mechanism: the written rules, the verification source, the official data or statement accepted by the platform, and sometimes a proposal/dispute process.

This article is meant to save that research step. We’ll look at how outcomes are actually decided on Kalshi and Polymarket, what the official docs say, how edge cases work, and why intuition can sometimes fail when a market moves from “what happened in the world?” to “what exactly does this contract resolve to?”

1. The basic resolution stack

A useful way to understand prediction-market resolution is to separate three layers:

  1. The market title — the short, readable version of the question.
  2. The market rules — the exact criteria, deadline, edge cases, and verification source.
  3. The resolution mechanism — the process the platform uses to turn the rules and evidence into a final outcome.

Most confusion comes from mixing these layers together.

The title tells you what the market is about. The rules tell you what must be true for Yes or No to pay. The resolution mechanism tells you who or what makes that final call.

Part of the truth is that the title is not the full contract. Another part is that real-world events are often messier than a clean Yes/No question. The interesting part is how each platform handles that mess.

2. Kalshi: contract terms, verification source, determination

Kalshi is closer to a regulated event-contract model. Each market has terms, rules, and a stated way to verify the outcome.

Kalshi’s help center says a market’s rules explain the outcome being measured, the timeline, and the verification source used to determine the result. It also notes that the rules summary is not the entire rules text, so the full contract terms matter when there is ambiguity.

In practical terms, Kalshi resolution usually comes down to this sequence:

market closes → Kalshi checks the contract terms → Kalshi uses the specified source/information → Kalshi determines the outcome

That source can matter a lot. A trader may be looking at news coverage, social media, or common understanding of an event, while the contract points to a specific agency, dataset, index, official announcement, or other verification source.

Kalshi also says outcome determination can take from one hour to more than twelve hours after market closure, often depending on when the source data arrives. It also notes that an open or undetermined market is not itself evidence that the criteria have or have not been met.

So the key Kalshi question is not only:

Did the thing happen?

It is:

Did the thing happen in the way this contract defines, by the deadline, according to the named source?

That framing does not make every outcome feel satisfying. But it explains why the official source and exact terms can matter more than the broad headline.

3. Polymarket: rules plus UMA’s optimistic oracle

Polymarket works differently. Its help center says markets resolve according to the rules on the market page, but the final resolution process uses UMA’s Optimistic Oracle.

“Optimistic oracle” sounds technical, but the basic idea is simple:

someone proposes an answer → others can challenge it → if unchallenged, it stands → if challenged, UMA resolves the dispute

Polymarket describes the flow roughly like this:

  1. A market outcome is proposed, with the proposer posting a bond.
  2. The proposal enters a challenge period.
  3. If nobody challenges it, the proposed outcome becomes valid.
  4. If someone disputes it, the issue enters UMA’s dispute process.
  5. UMA token holders can vote on the correct outcome.
  6. Once UMA finalizes the result, Polymarket says the outcome is immutable.

Polymarket’s docs currently describe a two-hour challenge period after a proposed resolution. Its dispute docs also explain that a challenged proposal can lead to outcomes such as the proposer winning, the disputer winning, the proposal being too early, or the market resolving as unknown/50-50.

This is one of the biggest differences from a normal centralized platform. On Polymarket, the question is not only what the market rules say. It is also whether the proposed answer is challenged and how UMA's process handles that challenge.

4. Why common sense and rule text can diverge

This is the softer but important part: many disputes are not caused by users being careless. They happen because everyday language and contract language do different jobs.

Everyday language compresses meaning. It lets people say “X happened” without spelling out every edge case.

Market rules have to do the opposite. They need to specify:

  • what counts as evidence;
  • which source is authoritative;
  • what deadline matters;
  • what happens if the source is delayed or revised;
  • what happens if the event partially happens;
  • what happens if the answer cannot be determined cleanly.

That is why a user can have a reasonable intuition and still be surprised by the result. The user may be thinking about the real-world story. The resolution system is trying to apply a narrower decision rule.

This is also why the most useful question is often not “was the outcome fair?” at first. It is:

What exact mechanism produced this outcome?

Once you know that, you can judge the outcome more clearly.

5. Edge cases: unknown, too early, and 50/50 outcomes

Not every market cleanly resolves into a normal Yes or No.

UMA’s Polymarket verification docs describe return values for YES/NO-style questions. In simplified terms:

  • YES is usually represented by 1.
  • NO is usually represented by 0.
  • UNKNOWN or “cannot be determined” can be represented by 0.5.
  • A separate “too early” style value can be used when the event is not ready to be resolved yet.

Polymarket’s dispute docs explain this in user-facing language: “Too Early” is for proposals where the underlying event has not happened yet, and “Unknown/50-50” is for rare cases where none of the other options are appropriate.

This matters because users often expect every market to eventually become a clean binary answer. But some disputes are really about whether the available evidence is enough to answer the question at all.

6. How to read a market before assuming the outcome

If a market could become contentious, the most useful checklist is short:

1. What source decides the answer?

Look for the named source. Is it a government agency, sports league, court filing, official statement, data provider, oracle process, or something else?

2. What exactly must happen?

Read the criteria literally. Small wording differences can matter.

3. What is the deadline?

Many surprises come from something happening just before or just after the cutoff.

4. What are the edge cases?

Look for language about delays, cancellations, revisions, ambiguity, source outages, “unknown,” or “too early.”

5. What is the resolution process?

On Kalshi, look at the rules and verification source. On Polymarket, look at the rules plus the UMA proposal/challenge/dispute process.

7. Why this matters for traders

Resolution mechanics are not just fine print. They are part of the trade.

A market can look mispriced because people disagree about the event. But it can also look mispriced because people disagree about how the rules will be applied.

Sometimes the edge is not only predicting the world correctly. It is understanding how the platform will translate the world into a market outcome.

That is the reason to read beyond the title. Not because the user is wrong to rely on intuition, but because prediction markets turn messy events into formal decisions — and the mechanism behind that decision can change who gets paid.

How Catalyst fits

Catalyst is built around this same habit: when a prediction-market chart moves, the useful question is not just “what happened?” but “what rule, source, event, or resolution mechanism made traders reprice?” The product helps users inspect market moves with context faster, but the core discipline is the same: understand the mechanism behind the market.

// Catalyst

Understand why a market moved

Catalyst helps prediction-market users connect chart moves to the rules, sources, events, and context behind them — directly on Polymarket and Kalshi.

get started →

Source notes