Polymarket
Polymarket resolution rules that determine payouts
Polymarket resolution applies a market’s rules to determine the redeemable value of its outcome tokens. UMA-resolved markets use bonded proposals and a challenge process, while Chainlink TWAP-resolved up-down markets compare defined price observations. A market’s end date, a proposed result, and a finalized payout represent different states. Redemption follows the recorded payout after resolution. Disputes can extend that wait, and some binary markets allow split payouts instead of a full winning or losing outcome.
Topics on this page
Bottom line: A market’s end date establishes resolution eligibility; its finalized payout determines what the held outcome tokens can redeem for.
Resolution rules define the condition behind each token
Each market’s resolution rules identify the evidence that counts, the relevant end date, and the treatment of ambiguous cases. The title provides a readable question, while the detailed condition establishes the payout criteria. A headline or announcement may concern the same event without satisfying the precise condition that the market defines. A holder’s exposure follows that precise condition, including any qualification that changes whether the outcome counts.
An event can group several markets, each with its own Yes and No positions. Resolution concerns the individual market condition behind those tokens. Reading only the event’s broader topic can leave out a qualification that changes a particular market’s result. The outcome identifier therefore matters alongside the wording.
The end date establishes eligibility for resolution
The stated end date identifies when a market becomes eligible for resolution under its rules. It doesn’t establish that a proposal already exists or that redemption has begun. On the UMA route, the challenge clock follows a proposal, so time since the underlying event and time remaining to challenge are different measurements. A holder who needs access to collateral by a particular moment faces that timing constraint. An estimate for an undisputed proposal also doesn’t cover the extra steps that a contested case can require.
The specified oracle determines the resolution route
UMA’s Optimistic Oracle handles markets that resolve through proposals and challenges. A proposer submits an outcome, and other participants can contest it within the applicable window. Chainlink TWAP-resolved up-down markets use a defined price comparison instead. A TWAP is a time-weighted average price over a specified lookback window. On that price-based route, the asset pair, start time, and duration identify the relevant observations. Its resolution follows those defined inputs.
Polymarket Protocol V2 can support other resolution mechanisms, so the protocol version alone doesn’t identify the oracle that governs a market.
A bonded UMA proposal opens a challenge window
The UMA proposal process gives participants a two-hour window to challenge a submitted outcome. Anyone can propose by selecting an outcome, posting the required bond, and submitting the proposal to the oracle. A correct, undisputed proposal returns the proposer’s bond and earns a reward. An incorrect or premature proposal can cost the proposer the entire bond. That exposure makes proposing a separate decision from holding outcome tokens. The proposal expresses a candidate result, and the remaining challenge period determines whether it can stand without another round. It doesn’t make winning tokens immediately redeemable when the submission arrives.
A counter-bond puts the proposed outcome in dispute
A disputer posts a counter-bond equal to the proposer’s bond to challenge a UMA outcome. The dispute changes the resolution path and puts the counter-bond at risk. Relevant evidence concerns the market’s actual condition, its specified resolution source, and any applicable clarification. Disagreement with the trading price doesn’t establish a different answer to that condition. Participation in the dispute process also differs from continuing to hold a position: the participant takes on bond exposure alongside any outcome-token exposure. A first dispute opens another proposal round; escalation to a token-holder vote requires a second disputed proposal.
Two disputed proposals move the case toward UMA voting
A holder awaiting redemption from a market that uses UMA needs a final outcome for the condition behind their tokens. With no dispute, a proposal can stand after its challenge window. A dispute changes that path: the first opens another proposal round, and a second escalates the question to UMA’s Data Verification Mechanism (DVM). Debate and voting then add time before the market can record a final payout.
| UMA stage | Timing and condition for progression |
|---|---|
| Initial outcome proposal | A proposer submits an outcome and posts the required bond. |
| First challenge period | A two-hour window; a dispute opens another proposal round. |
| Second outcome proposal | Another proposal follows the first dispute and faces its own challenge period. |
| Second challenge period | A two-hour window; another dispute escalates the case to the DVM. |
| Evidence and debate | A 24-48-hour debate period follows escalation. |
| UMA token-holder vote | Voting takes approximately 48 hours after debate. |
Before treating a position as redeemable, match the market’s finalized onchain payout to the held tokens’ condition and outcome. A proposal record shows the suggested answer; the finalized payout establishes what the tokens can redeem for. Changing the dispute status changes the route to that result, even when the underlying event remains the same.
UMA’s decision can accept or reject the proposal
A UMA vote can accept the original proposal or reject it, with rejection requiring a new proposal. A Too Early outcome means the event hasn’t concluded for resolution purposes. That outcome doesn’t establish a final winning payout simply because the vote itself has finished. A Too Early decision concerns the timing of the resolution request; it doesn’t declare the market’s underlying condition false.
The debate and voting durations describe parts of an escalated process. They don’t create a fixed payment deadline for every disputed market. A second proposal that survives its challenge window avoids the voting route, while a rejected proposal requires further action before resolution.
Chainlink TWAP fixes the comparison for up-down markets
For a Chainlink TWAP-resolved up-down market, the starting observation sets the price to beat, and the ending observation supplies the final price. Both come from the same Chainlink TWAP stream. The market specifies the asset pair, start time, and duration that select those observations. A final price above the starting value resolves Up, and a lower final price resolves Down. This mechanism applies the defined comparison without UMA’s proposal-and-dispute process. A trader’s preferred exchange price doesn’t replace the specified observations.
In these Chainlink TWAP-resolved markets, a final price equal to the price to beat resolves Up.
The TWAP lookback determines how each observation averages prices; the market duration determines the opening and closing observation times. An instantaneous quote from another moment can differ from that average. Comparing another displayed crypto price with the resolution inputs requires matching the relevant stream and times.
Additional context clarifies unforeseen cases
Polymarket can publish an Additional context clarification when unforeseen circumstances make a market’s wording ambiguous after trading begins. These clarifications appear onchain through a bulletin board contract, and UMA proposers and voters should consider them. A clarification must preserve the question’s fundamental intent. Its presence doesn’t itself settle the market or replace the applicable resolution process. Clarification requests belong in Polymarket’s Discord #market-review channel.
Market structure determines full and split payouts
A full winning payout gives each winning outcome token 1 pUSD, while losing tokens pay zero. Some binary markets can instead record a split payout, with each side receiving its assigned share. In the rare Unknown/50-50 UMA outcome, each token redeems for 0.50 pUSD. This UMA result means neither outcome applies; a dispute alone doesn’t determine the payout fractions.
Negative-risk markets do not use split payouts. Their mutually exclusive group resolves exactly one constituent market to Yes and the others to No. This concerns each market’s result: No tokens still pay when their own market resolves No. An event that merely contains multiple markets doesn’t automatically establish this relationship; the markets must belong to a negative-risk group.
The same outcome payout applies to tokens bought at different entry prices, so a split settlement can produce different holder returns.
Redemption exchanges outcome tokens for collateral
After resolution, redemption exchanges outcome tokens for the recorded collateral payout in pUSD, the USDC-backed token on Polygon. CTF markets use Conditional Tokens, while Polymarket Protocol V2 markets hold outcome balances in PositionManager. Both track ERC-1155 outcome balances, but their identifiers and integration paths differ. Matching the position system preserves the connection between the held tokens and their recorded payout.
Protocol V2 integrations can read PositionManager’s
getPayout
for a specified position ID and amount. The amount and returned payout use six-decimal base units. The call can revert for an unresolved position, while zero can be a valid losing payout for a positive amount. V2 negative-risk results can also derive from group state without an individual
ConditionResolved
event. For those positions, the absence of that event alone doesn’t establish an unresolved payout.
Resolution also ends trading in that market. Before that point, a sale depends on the market remaining tradable for the account and on available order-book liquidity. Selling exchanges tokens at an executable price; redeeming applies the final payout. When resolution is final, the next relevant action concerns redeeming the correct holdings through their supported position system.
Questions and answers
-
Must I post a UMA bond to redeem outcome tokens?
- A token holder doesn’t have to become a proposer or disputer to redeem a resolved position. UMA bonds apply to those oracle roles. Redemption uses the held outcome tokens and the final payout recorded for their market. The position system determines the applicable redemption operation.
-
Where should dispute evidence go during UMA’s debate period?
- Evidence can go to UMA’s Discord channels #evidence-rationale and #voting-discussion during the debate period. This stage follows escalation after the second disputed proposal. Posting material contributes to the debate; it doesn’t itself finish the token-holder vote or establish the market’s final payout.
-
Who receives the bond award when UMA upholds a dispute?
- When a DVM vote favors the disputer, that participant receives their counter-bond back plus half the proposer’s bond. This distribution concerns the participants who posted bonds. It doesn’t automatically pay every trader holding losing tokens. Outcome-token redemption separately follows the market’s recorded payout.
-
Does a closed market status prove that its payout is final?
- A closed trading status alone doesn’t establish a final payout. The closed field covers markets that have resolved or otherwise closed, with no further trading possible. The market’s resolution state and recorded payout determine redemption eligibility.
-
How does a 50/50 payout differ from a 50% displayed probability?
- A 50/50 payout assigns 0.50 pUSD to each outcome token, while a 50% displayed probability expresses market pricing. The displayed percentage can change as users trade. It doesn’t establish the oracle’s final decision or entitle both sides to a split redemption; the recorded resolution determines that payout.
-
Does approving AutoRedeemer guarantee immediate redemption?
- In Polymarket Protocol V2, approving AutoRedeemer alone doesn’t schedule a redemption. An authorized operator can redeem the full balance of each submitted position and return pUSD to the same holder. Approval grants that permission; it doesn’t establish that the redemption has executed.
Last updated: