Skip to main content
Polymarket markets do not settle themselves. When a market’s event concludes, the outcome has to be reported on-chain and accepted before holders can redeem winning shares. Polymarket uses UMA’s Optimistic Oracle (V2) for that step, and the Bravado UMA API exposes the resolution lifecycle as both queryable data (REST) and a realtime stream (WebSocket).
UMA resolution is served from partner-api.bravadotrade.com, signed with HMAC authentication. The REST routes are part of the Data API and take your Data API credential (analytics.read); each successful response costs 1 credit. The WebSocket is part of Market Data and takes your Market Data credential (stream.read) on an active paid plan. You do not need a separate UMA key. Coverage today is Polymarket.

​
Choose your interface

The REST API is a Data API surface (analytics.read, 1 credit per response) and is split into two pages — the live window and all history. The WebSocket is a separate Market Data surface (stream.read, paid plan). They do not share a credential, and neither is a product of its own.

​
Coverage and history

Coverage is Polymarket’s UMA resolutions: requests from Polymarket’s UMA adapters for YES_OR_NO_QUERY markets, including NegRisk markets.
  • History (/uma/history/*) reads the complete record of oracle events, with from / to ranges, cursor paging and resolution_source provenance. A question that was re-requested returns its latest lifecycle and says how many there were.
  • Live window (/uma/question, /uma/market, /uma/recent, and the WebSocket) reflects what the realtime feed currently holds: about 7 days for settled questions and 14 days for open ones. A 404 there means the record is not retained; it does not prove the question never existed.
A market whose oracle request cannot be found is reported as resolution_source: "unknown", never as an empty or unsettled market. Consuming the live stream does not backfill earlier events; read /uma/history/recent for those.

​
The resolution lifecycle

The captured record can contain a proposal, an optional dispute and a final settlement.
1

Proposal

A proposer posts an outcome to the oracle with a bond. This is the proposed stage; answer carries the proposed result. A proposal observed before mining carries seen_pending: true and is provisional.
2

Challenge window

The proposal stays open for a fixed liveness period. If nobody disputes it, it becomes eligible to settle on the proposed answer.
3

Dispute (optional)

Any party may dispute within the window by posting their own bond (disputed stage). A disputed request escalates to UMA’s token-holder vote rather than settling on the proposer’s word.
4

Settlement

The final answer is written on-chain (settled stage, with the payout). Winning outcome tokens become redeemable at $1; losing tokens go to $0.
A market whose event has visibly concluded is not necessarily settled. Always confirm settled: true before treating a position as realized — an undisputed proposal can still be disputed until its challenge window closes.

​
Identifiers

Every lifecycle record carries two ids:
  • question_id — keccak256(ancillaryData), the UMA adapter’s question id. This is the stable, exact key for a resolution.
  • condition_id — the CTF condition id used everywhere else in Bravado to identify the market. Use it to join resolution state to positions and trades. On /uma/history/market it is always the real id; on the other routes it is derived from the question and is not reliable for NegRisk markets (see resolution_source).
The answer field classifies the oracle’s int256 price: yes, no, 50-50, too-early, or other; price_raw preserves the exact value.

​
Build around final settlement

  • Treat a concluded event and a redeemable position as different states. Confirm settled: true before presenting a resolution as final.
  • Allow for disputes: a proposed answer can change before final settlement.
  • Redeem positions only after settlement through the Trade API.

​
Next steps

  • REST — live window — lowest-latency reads of what is resolving right now, with a signed request and response fields (Data API, analytics.read).
  • REST — history — all history, from / to ranges, cursor paging and resolution_source provenance (Data API, analytics.read).
  • WebSocket — the live stream.read stream: connect, filter subscriptions and recover after disconnecting (Market Data).
  • Data API and Market Data — the two credentials and the other surfaces in each.