Optimistic oracle

"Oracle" is one word in this sector for two mechanisms that have almost nothing in common. A price-feed oracle publishes a number on a schedule, and a market settles on whatever it printed — Limitless resolves most of its markets that way, from Pyth and a Chainlink average. An optimistic oracle publishes nothing on its own. It waits for somebody to claim an answer, and then waits again to see whether anyone objects.

How it works

UMA's documentation describes four stages, and the names are exact.

1. Request. A contract asks a question. On Polymarket that contract is the UMA CTF Adapter, which sends the request when a market is initialised.
2. Proposal. Somebody answers it and posts a proposer bond, refundable if the proposal is judged correct.
3. Challenge period. The proposal is pending, and anyone can dispute it by posting a bond of their own. The adapter's README puts this liveness period at about two hours.
4. Settlement. If no dispute arrives, the proposal is settled as correct and the proposer gets the bond back plus a reward.

That fourth step is the whole of the word optimistic. The answer is assumed right, and it becomes final because the window closed, not because anything verified it. What keeps it honest is the price of being wrong: a correct disputer is paid out of the forfeited proposer bond.

When somebody disputes

A dispute goes to UMA's Data Verification Mechanism, which the documentation calls a Schelling point: staked token holders commit secret votes over 24 hours and reveal them over the next 24, each trying to vote with the majority, because a missed or minority vote is slashed — 0.1% of the stake per vote under DVM 2.0.

A round can also fail to decide anything. A vote has to clear two quorums, a fixed amount of UMA voting (5 million at DVM 2.0's deployment) and a share of staked tokens voting and agreeing (65%), and if it misses either it rolls into the next round. After four rolls the request becomes deletable. The published durations describe a vote that resolves the first time.

Polymarket adds one more layer on top. Its adapter treats the first dispute as a reset — a fresh request goes out and the proposal round starts again — and only a second dispute reaches the vote, which the README says returns data after 48 to 72 hours.

Who may propose is a setting, not a property

UMA ships more than one version of the contract, and the parameters that decide who takes part live in the version, not in the idea. UMIP-189, created on 29 July 2025, approved a ManagedOptimisticOracleV2 for Polymarket's use, upgradable through a two-of-two multisig held by Polymarket and Risk Labs. It gives an owner address control over the default proposer whitelist and the bounds on bond and liveness, and a request manager the power to revise an unproposed request's bond, liveness and whitelist. UMA governance keeps the controls it has over the standard contract. Nothing in the proposal lets the managed contract change what the vote decides.

UMA's post of 12 August 2025 described the result: proposals restricted per request to a whitelist, disputes still open to anyone. Its follow-up of 8 November 2025 dates enforcement from 5 September and makes the scope explicit — Polymarket decides which markets use a whitelist, and Risk Labs curates the default list from each address's recent proposal accuracy, refreshed monthly. So on a whitelisted Polymarket market the open part of the process is the objection, not the answer.

What the catalogue records

markets.resolution_source is a sentence precisely so that this mechanism can be named, and of the ten cards in prediction-market venues, one names it: Polymarket's international platform. Polymarket US mentions it for the opposite reason — same brand, and the exchange decides. Every other card in the corpus that mentions the optimistic oracle is a tool built on Polymarket data — an API, a dashboard, a trading client — and most of them set resolution_source to null, because they resolve nothing and inherit whatever UMA settles.

Why it matters here

You will read "resolved by an oracle" as "resolved by a feed". A feed-settled market settles at the deadline. An optimistically settled one starts a clock at the proposal, and a dispute restarts it. How long each branch takes on each venue is in who decides how a prediction market resolves; this page is about why the branches exist.

You will read "undisputed" as "verified". It means nobody posted a bond against it in time. That is a real safeguard on a busy market and a thinner one on a quiet market, and the design cannot tell the two apart.

You will compare venues on the idea instead of the parameters. Two markets on the same oracle can differ in bond, window and who may propose, because those are set per request by whoever administers the integration. A venue page that says "UMA" has told you the family, not the terms.

Your data tool is only as current as the oracle. A card that sets resolution_source: null still reports an outcome, and that outcome arrives after the challenge window — or after a reset and a vote. Some data tools, Predexon among them, expose the proposals and disputes themselves, which is the only place a pending answer is visible before it is final. Getting resolved market history covers what that does to an outcome column.

It is the opposite of how a regulated US exchange resolves. There the exchange determines the outcome itself and its determination is final under a filed rulebook — see designated contract market. Choosing between the two is choosing between a process a stranger can enter by posting a bond and one that nobody outside the exchange can enter at all.