How Are Polymarket Markets Resolved?

A prediction-market headline describes a question. Its resolution rules define which evidence settles it. Before you interpret a price or write a strategy, identify those rules and the resolution source for the exact market.

Polymarket international's current documentation describes two sources: UMA for prediction markets and Chainlink time-weighted average prices for specified up-down markets. It is therefore incorrect to assume every market goes through the same oracle or dispute path. This article reviews that distinction as of October 13, 2026.

Start with a saved rules record

Keep the market identifier, rules, relevant timestamps, named evidence source, and any edge-case wording together. The title alone is not a sufficient specification. A contract about an announcement, a completed event, or an observed price can ask a different question even when the headlines look similar.

For a research dataset, preserve the wording that was available at each decision time. Later knowledge of the outcome must not leak into the strategy's earlier inputs. If the rules are ambiguous, make that uncertainty explicit rather than silently choosing the interpretation that makes the backtest look better.

The UMA proposal and challenge path

The documented UMA process starts with an outcome proposal and bond. A challenge period allows a dispute; an unchallenged proposal can resolve the market. A further disputed proposal can escalate to a UMA token-holder vote. Inspect the current market parameters for bonds and timing rather than hard-coding an old tutorial's values.

This structure separates the real-world event from the recorded resolution. Do not treat a news alert, a proposal, and a final outcome as interchangeable states. Your research ledger should be able to represent a pending or disputed outcome without booking a final payout prematurely.

Some up-down markets use a price rule instead

The documented Chainlink TWAP path compares a final reference price with the starting price-to-beat for the specified interval. It does not use UMA's proposal-and-dispute process. Check the exact rule, reference feed, interval, and tie condition for the market rather than substituting a last trade or your own price sample.

An independent price feed is useful for diagnosis, but a difference from your feed does not by itself establish a resolution error. First reconcile the instrument, observation method, units, and timestamps. A point price and an average over a window answer different questions.

Keep ordinary, disputed, and exceptional outcomes distinct

For ordinary binary outcomes, the documentation describes winning and losing tokens redeeming at one dollar and zero respectively. It also describes a possible unknown or 50/50 outcome in the UMA dispute process. Do not assume every terminal record is an ordinary YES or NO settlement.

Model the stated outcome that actually applies. Marking a position at a displayed price is different from redeeming it after resolution. Neither a near-certain quoted price nor the end of a scheduled event proves that redemption is already available.

Check clarifications and the precise venue

Polymarket's documentation allows additional context that does not change a question's fundamental intent. If a clarification matters to your interpretation, preserve it with its publication time and revisit affected assumptions. Avoid presenting an old rules screenshot as today's complete specification.

Polymarket US is a separate exchange with separate documentation and rules. Do not carry international oracle mechanics, token handling, or market identifiers into a US integration without verifying that venue's actual contract documentation.

A reproducible resolution checklist

• Save the exact question, full rules, market identifier, and resolution source.
• Separate event time, close time, proposal time, final resolution, and redemption.
• Preserve pending and disputed states rather than forcing a binary answer early.
• Check any special payout and tie handling before calculating returns.
• Record clarifications and distinguish information available then from information learned later.

Banger's public beta is paper-only; its documented hosted backtesting workflow is for Kalshi. The comparison here explains research risks across venues. It does not announce public Polymarket live execution or imply that a paper result proves a real account's settlement and redemption path.