Skip to content
EdgeLedger
0x0000…0096demo

You're viewing demo data.

Reading a Polymarket market page

How to read market metadata: question, end date, resolution source, dispute window, and the UMA oracle — and what can cause a market to resolve unexpectedly.

·8 min read·Compliance reviewed

Polymarket

A Polymarket market page packs a lot of information into a small surface. This guide walks through the metadata that defines the contract: the question and rules, the resolution source, the end date, the oracle, and the dispute window. Then it covers the handful of things that make markets resolve in ways traders don't expect — almost always foreseeable, usually only in hindsight.

Place this guide between Getting started and Placing your first trade in your reading order — knowing what you're trading matters before how you trade it.

The fields on every market page

Polymarket's UI evolves, but the underlying metadata fields are stable. Every market exposes the same handful of pieces.

The seven fields you should be able to read off any market page in under thirty seconds.

The seven fields to understand:

  1. Question. A plain-English ask. Read it twice — many "surprise" resolutions trace back to a trader misreading the question itself.
  2. End date. When trading closes. Distinct from when the market resolves — those can be hours or days apart.
  3. Oracle. Almost always UMA. Tells you who decides the outcome.
  4. Outcome tokens. Yes/No (or named outcomes for multi-outcome markets) and their current prices. Reads as implied probability.
  5. Resolution source. The authoritative reference the resolver should consult. "FOMC press release," "official BBC final score," etc. If the source field is vague, the resolution rules will be too — be cautious.
  6. Volume / Liquidity. How active the market is and how much depth sits in the book. Affects sizing more than spread does.
  7. Resolution rules. The full, often-multi-paragraph spec for how the market should resolve. Treat this as the controlling contract text, not supporting copy.

Resolution source

The resolution source is where the resolver looks to decide the outcome. Common shapes:

  • Specific official document or feed — "the FOMC's Sept 17–18 meeting statement," "the BBC's official match report," "the SEC's filing." These are the easiest to reason about; if the document exists and says X, the market resolves X.
  • A named website or organisation — "according to the WHO," "as reported by Reuters." Clear in spirit but more flexible in practice; watch for ambiguity if multiple stories conflict.
  • "Multiple credible sources" — flexibility for the resolver, uncertainty for you. Be more cautious sizing up.
  • Specific data feed (e.g., Chainlink price) — an automated read. Eliminates ambiguity but means the exact feed value is what resolves, not your interpretation of "the price."

If the source field doesn't appear at all on a market, that's a flag. Polymarket's better-curated markets always declare a source.

Resolution rules

The rules are the contract you're trading. Things to look for:

  • Edge cases. "By end of year" — UTC or local? Calendar or fiscal? "By June 30" — UTC midnight at start or end of June 30?
  • Tie-breakers. What happens if the source contradicts itself, or two sources disagree? Many rules name a tie-breaker.
  • Cancellation conditions. Some markets specify a YES/NO resolution if the underlying event is cancelled or postponed. Others void the market and refund. Both are reasonable; only one applies to any given market.
  • Reporting delay. "If the result isn't published by date X, the market resolves NO." This converts a non-event into a NO outcome even if the underlying event still might happen.

End date and timezones

Two dates matter for any market:

  • Trading end — the moment the order book closes. After this, no new positions; existing positions wait for resolution.
  • Resolution date — when the outcome is proposed and (assuming no dispute) finalizes. This is the trading-end date plus the dispute window plus any delay for the underlying event.

Polymarket displays times in UTC by default. If a market involves a real-world event with a regional timezone (an election in a country, a sports match), make sure the rules tie the outcome to a specific time zone, not a vague "by end of day" phrase.

The UMA optimistic oracle

Polymarket uses UMA's optimistic oracle to resolve markets. The shape of the process is the same for almost every market:

Most markets follow the top track and finalize within hours. Disputes drop into the lower branch and can take days.

How it works:

  1. The event happens. The real-world thing the market is about takes place (or, for "by date X" markets, the deadline passes).
  2. Someone proposes the outcome. Anyone can submit a proposal on-chain by posting a small bond. The proposal sits in a challenge window — typically 2 hours.
  3. If no one disputes, the proposal becomes final. This is the path almost all markets take. Once finalized, payouts can be claimed.
  4. If someone disputes, they post their own bond and the resolution moves to a UMA token-holder vote. This usually takes hours to a few days.

The "optimistic" part is step 3 — the system assumes proposals are correct unless challenged. That's both the speed advantage (most markets resolve fast) and the risk (a wrong proposal that no one challenges becomes the official outcome).

What can cause a market to resolve unexpectedly

The handful of patterns you'll see most often:

  • Ambiguous rules + a real-world edge case. A market for "will Senator X vote YES on Bill Y?" sounds clean, but Senator X might abstain, miss the vote, or change parties before the vote — none of which the rules anticipated. The proposal then has to make a call, and even a "fair" call surprises someone.
  • The resolution source changes its tune. A news outlet retracts a story; an election result is contested; a federal agency revises a number after release. UMA goes by what the source says now, not what it said at trading end.
  • The market scoping was tighter than you read. "Will the company file for bankruptcy in 2026?" can be Chapter 7 only, Chapter 11 only, or both — depending on the rules. Skim and you may be trading a different market than the one in your head.
  • A wrong proposal goes unchallenged. Rare on high-volume markets, more plausible on tail markets. The challenge window is short; a 2 a.m. proposal on a low-attention market can finalize before anyone notices.
  • A dispute pulls a "obvious" market sideways. Even when the outcome looks clear to most observers, a determined disputer posting a counter-bond escalates resolution into a token-holder vote — and the vote can go the other way.

What EdgeLedger surfaces

For each Polymarket position, EdgeLedger pulls the metadata above and keeps it next to your stake:

  • Resolution rules — copied verbatim, viewable from the position card.
  • End date — surfaced in trade history sort + filter.
  • Status — Trading / Pending resolution / Resolved derived from on-chain state.
  • Realized P&L — populated only after the market finalizes (i.e. after the dispute window closes or a vote completes).

Use the rules text inside EdgeLedger as a fast reference alongside the venue's current market page — it is intended to mirror the text the resolver will be reading.

Where to go next