Polymarket resolution explained

Polymarket resolution explained: this guide walks through the end-to-end lifecycle from reporting to redeeming outcome tokens, the UMA optimistic-oracle dispute stage, and the practical implications for traders. You’ll learn what happens on-chain and off-chain, which steps are gasless for users, and the timing and risks that matter for arbitrage and position management.

Key takeaways

• Resolution begins with an outcome report and can enter an optimistic UMA dispute period before final settlement.
• While outcome tokens are ERC-1155 CTF assets, splitting/merging/redeeming and order placement are gasless for users via the Relayer.
• Disputes, oracle delays, partial fills and settlement timing create real risks even when prices imply a mathematical edge.
• Know the sequence: report → dispute window (UMA) → finalization → redeem winning tokens for pUSD.

What "resolution" means on Polymarket

On Polymarket, resolution is the process that converts tradeable outcome tokens into redeemable funds. For binary and multi-outcome markets, an oracle ultimately determines which outcome(s) resolve YES. When an outcome is final, each winning token becomes redeemable for $1.00 of pUSD; losing tokens are worthless.

Markets use the Gnosis Conditional Token Framework (CTF) for outcome tokens. Those tokens act like any ERC-1155 holdings: you can trade them on the CLOB, transfer them, or combine them with split/merge operations. The key difference at resolution is that the oracle’s final report unlocks the CTF redeem flow that turns winning tokens into pUSD.

The reporting step: who reports and why it matters

Resolution starts when a reporter submits an outcome to the oracle system. Polymarket uses the UMA optimistic oracle for reporting. A submitted report names the outcome that the reporter believes is correct and starts the clock for the next stage.

Why this matters:

• The report is the first public signal that the market’s event has reached a resolvable state. Traders monitoring order books can respond immediately.
• Reports are visible in Polymarket’s UI and via the Gamma API, so arbitrage bots and human traders can detect them programmatically.

UMA optimistic-oracle dispute window (what it is, not how long)

After a report is posted, UMA’s optimistic model allows a dispute window during which challengers can post counter-evidence. If a dispute is raised, the optimistic flow pauses and UMA resolves the disagreement per its process.

Important practical points:

• The dispute window introduces uncertainty. A market that appears resolved can be re-opened for investigation if UMA receives a dispute.
• Because the exact timing and implementation details of UMA’s procedures are external to Polymarket, traders should treat any market in or near the dispute phase as carrying resolution risk.

Note: The system prompt specifies UMA is used but does not provide the dispute-window length. See the Notes section for that gap.

Finalization and redeeming CTF tokens

Once the oracle’s process completes and the outcome is final, the market is finalized on-chain. At that point users can redeem winning ERC-1155 outcome tokens for pUSD via the CTF redeem operation.

Practically on Polymarket:

• CTF operations (split / merge / redeem) are handled through the Polymarket Relayer, so they are gasless to you.
• Redeeming turns each winning token into $1.00 of pUSD, which you can then withdraw or use to split into new positions.

If you hold a complete set of outcome tokens prior to resolution, redemption is straightforward: you only receive pUSD for the winning leg(s). If you hold partial positions, only the corresponding winning tokens redeem.

Common resolution edge-cases traders see

• Disputed finalizations: UMA disputes can delay settlement and temporarily prevent redemption. That affects liquidity and can trap capital.
• Partial fills and order execution: an order filled partially before resolution can leave you long certain tokens and short others; ensure you track fills to avoid unexpected exposure.
• Tick-size and price updates: tick size changes near resolution may alter available orders; the WebSocket emits tick_size_change events that matter for bots.
• Fee and reward effects: maker fees are zero; taker fees vary by category. Fees and builder-attribution (if you route through a Builder) affect net outcomes but do not change the oracle settlement process.

Never assume a settled market cannot be reopened if UMA triggers a dispute flow. Always confirm the market status before initiating any CTF redeem operation or large transfers.

How this affects arbitrage and endgame strategies

For intra-market arbitrage (buying a set when Σ bestAsk < $1.00), resolution mechanics are central: your theoretical profit converts to pUSD only after finalization and redeem. That means timing, oracle dispute risk, and settlement delays matter as much as order execution.

Practical rules of thumb:

• Treat the spread as a mathematical edge only after you’ve accounted for fees, slippage, and dispute risks. Always enumerate these risks before labelling a trade as arbitrage.
• For endgame strategies (near-resolution prices like $0.95–$0.99), be especially cautious: smaller margins and UMA disputes can turn a short-term play into a loss.
• Use Polymarket’s APIs and the Market WebSocket to monitor reports, tick_size_change, best_bid_ask, and last_trade_price in real time.

Monitoring resolution programmatically

APIs and feeds to watch:

• Gamma API (https://gamma-api.polymarket.com): market and event metadata, including resolution-related fields. Use the /markets endpoint with cursor-based pagination.
• Data API (https://data-api.polymarket.com): positions, trades, and open interest for tracking fills and exposure.
• Market WebSocket (wss://ws-subscriptions-clob.polymarket.com/ws/market): real-time book, price_change, best_bid_ask, last_trade_price, and tick_size_change. PING every 10s; subscribe with custom_feature_enabled to get best_bid_ask.

Combine these feeds to detect a report, watch for UMA dispute signals in the UI or data feed, and hold off on final accounting until the market status is final.

Checklist: what to do when a market reports

• Confirm the reported outcome in Gamma and the Polymarket UI.
• Pause automation that assumes immediate finality until UMA’s dispute phase completes.
• Track open orders and fills; cancel or adjust if necessary to avoid unintended exposure.
• After finalization, redeem winning tokens via the UI, SDK, or your Relayer-integrated flow.

How this affects your trading

Resolution is the final bottleneck between trade execution and realized pUSD. For active traders and arbitrageurs, that means you must manage three linked risks: execution (fills and slippage), oracle resolution (reports and disputes), and settlement timing (redeem and withdrawals). Successful execution requires both fast market-side tooling and conservative assumptions about dispute risk.

If you build automation, log every fill and watch the WebSocket channels listed above. Treat markets in or near a reported state as higher risk until UMA clears them.

Closing note: Polymarket resolution explained should give you the operational checklist and the mental model to manage settlement risk. Use the APIs and WebSocket to monitor events, remember that CTF redeem is gasless through the Relayer, and always account for dispute windows before you assume a trade has converted into pUSD.

Frequently asked questions

Who reports outcomes on Polymarket?

Polymarket uses the UMA optimistic oracle for outcome reporting. Reports are submitted to UMA and are visible in Polymarket’s UI and APIs; UMA handles any subsequent disputes per its process.

What happens during the UMA dispute window?

After a report, UMA allows a dispute period where challengers can contest the reported outcome. If challenged, UMA pauses optimistic settlement and proceeds through its dispute-resolution flow, which can delay redemption of winning tokens.

Are CTF operations gasless on Polymarket?

Yes. Polymarket sponsors gas via its Relayer. Split, merge, redeem, transfers, and order placement are gasless to the end user because they are routed through the Relayer.

Can a market be reopened after it looks resolved?

Yes. If UMA receives a dispute, a market that appeared resolved can be reopened or delayed pending UMA’s resolution. Treat any market in or near the dispute phase as carrying resolution risk.

How can I programmatically detect a report or dispute?

Use the Gamma API for market metadata and the Market WebSocket (wss://ws-subscriptions-clob.polymarket.com/ws/market) for real-time events like price_change, best_bid_ask, last_trade_price, and tick_size_change. Combine those feeds with Data API endpoints to monitor positions and fills.