Inside UMA Oracle | How Prediction Markets Resolution Works

If you’re building a prediction market like Polymarket or researching how oracle-based resolution works on-chain, this post is for you.

In our previous deep dive, we explained how Polymarket’s central limit order book operates, how binary outcomes are traded, and how the conditional tokens framework is used to create and manage “YES” and “NO” shares.

This time, we will focus on what happens after trading stops. How do those “YES” and “NO” tokens turn into $1 or $0? Who decides whether an event actually happened, and how does that decision get verified on-chain?

This article breaks down how settlement works in prediction markets using UMA’s Optimistic Oracle, which powers Polymarket’s resolution process. You will see how outcomes are requested, proposed, disputed, and finalized, as well as what system components and contracts manage these processes.

Make sure to follow us on X to stay updated on our upcoming technical deep dives on protocol design and architecture 🌚

What resolution means in a prediction market

Let’s start with the basics. Resolution in prediction markets is what happens after a market closes. It’s the process that turns open positions into final payouts. In a binary prediction market like Polymarket, YES or NO tokens get a value based on whether the event actually happened. The blockchain can’t see off-chain events directly. To solve this, we need oracles to bring that information on-chain. Oracles, like the UMA optimistic oracle used by Polymarket, make prediction market resolution possible.

We’ve already covered how markets are created, CTF and YES/NO shares, CLOB, and how trading works in our Polymarket deep dive. So, we won’t go deep into them here. The core to know is that each event is a simple yes-or-no question. Tokens represent opposing predictions. The price of two tokens adds up to $1. In the following sections, we’re going to focus on what happens once the market closes.

The main steps in prediction market resolution are:

1. Market closes – trading stops at the scheduled timestamp.
2. Outcome determination – the system queries an oracle, what we’re going to cover today in this post.
3. Redemption – token holders claim payouts according to the verified outcome.

Why prediction markets need an oracle

We already mentioned that prediction markets depend on oracles to connect blockchain systems with real-world data. The blockchain cannot independently confirm off-chain events like election results or regulatory decisions, which makes oracles a core part of prediction market resolution. Oracles provide the verified outcome needed for on-chain settlement.

Requirements for oracle to support prediction markets resolution

An oracle in a prediction market must meet several requirements:

• Human-readable questions to avoid ambiguity in event phrasing.
• Dispute resolution that allows challenges to proposed outcomes before finalization.
• Finality so market participants can settle positions with confidence once disputes are resolved.

Polymarket uses the UMA Optimistic Oracle to finalize outcomes. Users can propose an outcome, challenge proposals, and escalate unresolved disputes to UMA’s Data Verification Mechanism (DVM) for a decision.

So, what is UMA Optimistic Oracle?

UMA, short for Universal Market Access, is an optimistic oracle built by Risk Labs. It lets smart contracts request and receive offchain data by verifying real-world outcomes through a request–propose–dispute cycle. It’s called “optimistic” because statements are assumed valid unless challenged.

How UMA Protocol Ensures Data Accuracy

The UMA protocol maintains accurate data through economic incentives rather than trust. Participants are rewarded for reporting correct information and penalized for incorrect or missing votes.

UMA uses the Schelling Point principle: independent voters are motivated to report the truth because they expect others to do the same. Attempting to submit false data would require controlling a majority of $UMA tokens, which is prohibitively expensive and would reduce the token’s value.

How UMA Prevents Manipulation

The system combines bonded proposals, disputes, and voting:

• Proposers post bonds and earn rewards for accurate data; bonds are lost if disputed successfully.
• Disputers post bonds and earn rewards for successful challenges.
• $UMA stakers vote on resolutions; accurate votes earn rewards, while incorrect or absent votes are slashed.

This structure makes dishonesty costly and keeps the UMA oracle resistant to manipulation.

Why UMA Optimistic Oracle works for prediction market resolution

Prediction markets, like Polymarket, need accurate outcomes for events that are often subjective or uncommon, such as elections, sports results, or protocol events. UMA’s oracle addresses key limitations of traditional oracles:

• Accurate information on request: Contracts can request specific data only when it’s needed.
• Handles unusual or detailed queries: Supports long-tail data like sports scores, election results, or security incidents.
• Multiple data types: Works with both objective data and intersubjective data, which is information widely agreed upon by observers but not strictly factual.
• Cost control: Most requests aren’t disputed (~98.5%), so only a small fraction requires on-chain resolution.
• Open participation: Decentralized design prevents any single actor from controlling outcomes.
• Aligned incentives: Honest proposals and disputes earn rewards; dishonest actions are penalized.
• Cross-chain compatibility: Can operate on multiple blockchains.

What is Intersubjective Data?

Intersubjective data is information that may not be purely objective but is still publicly verifiable and widely agreed upon by informed observers. It sits between hard facts and personal opinion. Examples include election outcomes, sports results, or whether a protocol suffered a security breach. Prediction markets resolution often relies on this type of data, making UMA’s optimistic oracle well-suited for handling it.

How UMA oracle is different from Chainlink

Unlike Chainlink, which continuously pushes data on-chain, UMA provides data only when a contract requests it. This request-driven approach reduces unnecessary on-chain activity and allows the oracle to support complex or intersubjective data types, which are common in prediction markets.

UMA, in fact, supports quite a wide range of use cases, from insurance protocols and cross-chain bridges to custom derivatives. Now we are only interested in one particular use case of prediction markets.

How UMA’s Optimistic Oracle Works in Prediction Markets

We already know that UMA’s Optimistic Oracle allows smart contracts to request and verify real-world information when it’s needed. It’s time to dig deeper and see how outcomes get verified.

Before the result is finalized, the data request goes through a structured verification process involving two core components of the UMA protocol — the Optimistic Oracle (OO) and the Data Verification Mechanism (DVM).

Each of these layers plays a specific role in how prediction markets resolve outcomes, with several participants taking part in the process: Asserters submit real-world statements, Disputers can challenge them, and UMA voters provide the final verification when disputes occur.

Core Participants and System Levels of Data Verification in UMA Protocol

To understand how UMA verifies outcomes for prediction markets, let’s look at the participants and layers involved in the process.

Core Participants

• Requester — A smart contract that needs data from the real world. For example, a Polymarket market contract acts as a requester when it asks, “Did Candidate X win the election?”
• Asserter — The participant who responds to the request by submitting a bonded assertion — a statement about the real-world outcome. The bond acts as collateral to ensure honesty.
• Disputer — The participant who can challenge the asserter’s statement during the liveness period if they believe it’s incorrect. They also post a bond when raising a dispute.
• Voters (UMA token stakers) — UMA stakers who participate in the Data Verification Mechanism (DVM). When a dispute is escalated, they vote to determine which side was correct.

System Levels of Data Verification

• Optimistic Oracle (OO) — The first verification layer that handles requests and assertions. It operates optimistically — assuming ‘honesty’ by default. If no dispute occurs within the liveness period, the assertion is accepted as correct, and the result is returned to the requester contract.
• Data Verification Mechanism (DVM) — The second and final layer that resolves disputes. When a challenge arises, UMA stakers vote to determine the truth. Their collective vote provides the verified result, which is then sent back through the OO to the requesting contract.

Together, these participants and layers form a hybrid verification system: fast when there’s agreement, and fully decentralized when there’s disagreement.

The workflow of outcome verification in UMA protocol

Now that we’ve covered the core layers and participants, let’s figure out how the process works. Let’s look at the diagram from UMA’s documentation.

As we can see, there are several steps in the workflow at each level. Let’s go through the process step by step.

The Process Step by Step:

1. Request submission
   A requester contract submits a data request to the Optimistic Oracle. The request defines the statement to resolve, the timestamp for the data point, and the resolution parameters referenced by the request.
2. Assertion posted by the asserter
   An asserter posts a bonded assertion to the OO. Each assertion includes five explicit fields: identifier, timestamp, claim, currency, and bond.
   
   • Identifier is the price identifier or event name being requested.
   • Timestamp is the time the asserted fact refers to.
   • Claim is ancillary data that provides context or clarifies the assertion.
   • Currency is an ERC20 token approved for use with the DVM and used for fees and rewards.
   • Bond is the collateral the asserter deposits to back the assertion.
3. Liveness period
   The OO starts the liveness period after the assertion is posted. This is the configured window during which disputers can challenge the assertion. Typical liveness windows vary by use case and commonly range from two hours to two days.
4. No dispute within the liveness period
   If no disputer raises a challenge during liveness, the assertion is accepted as correct by the OO and the result is returned to the requester contract.
5. Dispute initiated
   If a disputer believes the assertion is incorrect, they open a dispute by posting matching collateral. The disputed assertion is flagged for escalation to the DVM.
6. Escalation to the DVM
   The OO forwards the disputed assertion to the Data Verification Mechanism. The DVM coordinates a decentralized vote among UMA stakers to determine the correct outcome.
7. DVM voting: commit and reveal
   The DVM runs a two-stage vote. First, stakers submit a hash of their vote in the commit stage so votes remain private. After commit closes, stakers reveal their votes in the reveal stage and the DVM tallies results. Voting periods typically last between 48 and 96 hours.
8. UMIP references and vote interpretation
   Stakers use the price identifier’s UMIP to determine the methodology for deriving the vote result from off-chain sources and feeds. UMIPs define how to interpret data for that identifier and timestamp so votes follow a consistent rule set.
9. Vote finalization and collateral distribution
   After votes are tallied, the DVM produces the final result for the asserted identifier and timestamp. Collateral distribution follows the protocol rules: the losing side’s bond is partially redistributed to the winning side and part is retained by the protocol. For example, the winner may receive half of the loser’s bond while the remainder stays in the protocol, per current rules.
10. Slashing and non-participation
    Stakers who vote with the minority or who fail to reveal their vote may face slashing. Slashed stake is redistributed to the winning stakers and to the protocol according to the redistribution rules.
11. Result returned to the requester
    The DVM returns the verified result to the OO. The OO writes the final outcome to the requester contract so the market or application can settle positions.

So far, we’ve covered the high-level workflow of how prediction market outcomes are verified via UMA’s Optimistic Oracle. You’ve seen the key participants: Requesters, Asserters, Disputers, and UMA stakers,  and how the two system layers, the Optimistic Oracle and the DVM, interact to ensure data accuracy.

This overview gives you enough context to follow the finer details in the next sections. Let’s look at each layer more closely, explain the mechanisms behind assertions, disputes, and liveness periods, and explore how collateral, commit/reveal voting, and slashing work in practice.

How UMA Optimistic Oracle Layer works

According to the docs, UMA has two versions of the Optimistic Oracle: OOv2 and OOv3, each built for different use cases. Prediction markets, like Polymarket, use OOv2 to verify outcomes. So this is the version we’re going to focus on in this section and show how it works, how its components interact, and how prediction markets interact with optimistic oracles.

Most requests (~98.5%) are resolved at this layer without escalation, which makes the OO the cost-efficient first layer. But to understand how the verification happens, we need to look closer at the price identifier, query structure, and the smart contracts involved.

Price Identifiers and Query Structures in UMA Optimistic Oracle

Now, let's take a look at how the prediction market submits a request for outcome verification to UMA oracle. We're going to start with the queries and what type of queries are supported.

What is a price identifier?

A price identifier is a unique string that tells the UMA Optimistic Oracle what type of data to verify. It defines the kind of question the oracle should answer and determines how the results will be interpreted. In other words, it standardizes requests so voters, proposers, and disputers know exactly what they are evaluating. By defining the expected response format and structure of ancillary data, they ensure that the oracle can handle requests consistently.

Ancillary data is a JSON-like structure that adds context to the raw answer. It ensures the requester, oracle, and voters understand exactly what is being requested and how to resolve it.

UMA maintains a list of approved price identifiers for common use cases, which can be found in the UMA docs. For scenarios where the existing identifiers are insufficient, developers can propose new identifiers by submitting a UMIP (UMA Improvement Proposal).

For prediction markets, UMA has two main types of price identifiers: YES_OR_NO_QUERY for simple yes/no questions, and MULTIPLE_VALUES when you need a bunch of numbers in one go. Let’s break them down.

YES_OR_NO_QUERY

YES_OR_NO_QUERY (UMIP-107) is a way to handle simple yes/no questions. The oracle returns 1 for YES or 0 for NO, based on the question submitted. It’s used in prediction markets, insurance contracts, and other cases where a binary outcome is enough.

Structure

The main piece is ancillary data, a JSON-like object that provides context for the raw YES/NO answer. It usually includes:

• The question text – what voters are resolving.
• Outcome values – p1 for NO, p2 for YES, p3 for undetermined outcomes, and optionally p4 for early-expiration or pre-event requests.
• Optional flags – like earlyExpiration:1 for questions submitted before the event finishes.

Limitations

This works fine for single-outcome questions. But when an event has multiple outcomes, you need separate YES_OR_NO requests for each one. That adds cost and complexity because each outcome requires its own settlement.

MULTIPLE_VALUES

The MULTIPLE_VALUES price identifier (UMIP-183) allows a single UMA oracle request to report up to seven unsigned integers at once. This structure was created to handle multi-outcome events—like sports scores—without requiring separate YES_OR_NO requests for each outcome. By consolidating multiple values into one request, the protocol reduces gas usage and simplifies settlement for complex events.

The request’s ancillary data provides context and typically includes:

• Title and description: Describes the event, e.g., “Lakers vs. Celtics”
• Labels: Up to seven names corresponding to each integer value requested, e.g., ["Lakers", "Celtics"].
• Special values: Reserved integers indicate cases where the event is “too early” or otherwise unresolvable.

To encode multiple outcomes, the oracle packs the integers into a single int256 value. Each label corresponds to a 32-bit segment of the value, starting from the least significant bits. Unused positions are set to zero.

Special responses signal situations where the outcome cannot yet be determined:

• Too early: The event hasn’t occurred, returning a reserved minimum int256 value.
• No answer possible: The question cannot be resolved—due to invalid ancillary data or event cancellation—returning a reserved maximum int256 value.

This design allows prediction markets to handle multi-outcome events efficiently while maintaining precise and verifiable settlement logic.

How MULTIPLE_VALUES price identifier optimises gas for multiple outcomes markets

Unlike YES_OR_NO_QUERY, MULTIPLE_VALUES can handle multiple outcomes in a single request. This eliminates the need for multiple binary requests, reducing gas costs and simplifying settlement for events where several values are relevant.

What smart contracts are involved in prediction market resolution

In UMA’s system, several smart contracts take care of how data moves from a market’s request to an on-chain verified result. The process involves three layers: the application contract, which starts the request, the Optimistic Oracle V2 (OOv2) contracts, which process and finalize it, and DVM, which manages disputes.

At the top level:

• The application layer contract (prediction market contract) creates a request and uses the final result for settlement.
• OptimisticOracleV2.sol manages the full lifecycle of that request — from submission to resolution.
• Store.sol records all request-related data: collateral, timing, and current status.
• Finder.sol works as a registry that connects contracts inside UMA’s ecosystem.

Now, let’s break down how this flow plays out.

Prediction market contract on Application layer

The whole data resolution process starts at the application layer. When a market closes, prediction market contract sends a price request to the Optimistic Oracle. The request contains the event details, the expiration time, collateral type, and a liveness period — the time window for potential disputes.

The same contract also sets the bond amount — what proposers and disputers must lock up — and defines what should happen once the oracle provides the outcome. After the oracle’s result comes in, the contract uses it to settle long and short positions and release collateral.

Key Mechanics:

• Market Creation: Owner deploys a contract with parameters:
  
  • _pairName → names for long/short tokens.
  • _collateralToken → token backing the market.
  • _customAncillaryData → the question to resolve (YES/NO).
  • _finder → allows the contract to locate OOv2.
• Tokens:
  
  • Long tokens → exposure to YES outcome.
  • Short tokens → exposure to NO outcome.
  • Users can mint equal amounts of long/short tokens by depositing collateral.
• Oracle Interaction:
  
  • _requestOraclePrice() submits a price request to OOv2.
  • Configures liveness, proposer bond, and event-based type.
  • Enables callbacks priceSettled and priceDisputed.
• Settlement:
  
  • When OOv2 resolves the request, priceSettled is called.
  • Settlement price (0, 0.5, or 1) determines how much collateral long/short holders receive.
  • Users redeem or settle tokens to recover collateral according to the outcome.

OptimisticOracleV2 contract on the main processing layer

Once the request reaches the oracle, OptimisticOracleV2.sol becomes the main coordinator. It receives the request, allows users to post a proposed value, and manages disputes.

Workflow

1. Request creation

A new data request starts with requestPrice().

It defines:

• identifier — type of question (e.g., YES_OR_NO_QUERY).
• timestamp — when the event occurred.
• ancillaryData — the text of the question.
• collateralToken — token used for bonds and rewards.
• reward — incentive for whoever resolves the request.

After submitting, the requester can adjust parameters:

• setCustomLiveness() — how long a proposal must wait before auto-acceptance.
• setBond() — bond amount required for proposals.
• setEventBased() — marks the request as event-driven, typical for prediction markets

2. Proposal and dispute

Anyone can respond to an open request via proposePrice(), submitting a value (for instance, “YES” = 1, “NO” = 0) with a bond.

If someone believes that the answer is incorrect, they can call disputePrice() to challenge it, posting their own bond in return.

When a dispute occurs, the request pauses until resolution — ensuring only verified outcomes reach applications.

3. Resolution

If no dispute happens within the liveness window, the proposed value becomes accepted.

The requester or contract then finalizes it through settle(), which triggers any connected callbacks, such as priceSettled()in a prediction market.

If a dispute was raised, the process escalates to UMA’s broader verification system — though within OOv2, that escalation step remains abstracted from the requesting app.

Throughout this flow, Store.sol keeps all state data organized — including bonds, timestamps, and ancillary data that describe each query. Finder.sol ensures OOv2 can locate the right UMA components dynamically, keeping the system modular and upgradeable.

These contracts run a clear request–propose–dispute cycle that defines how off-chain information becomes verifiable on-chain. If no one challenges a value, it becomes final once the liveness period expires; if there’s a dispute, OOv2 pauses settlement until resolution, and the dispute escalates to DVM, which we will cover next.

​​Managed Optimistic Oracle V2 (MOOv2)

UMA recently introduced ManagedOptimisticOracleV2 (MOOv2) — a version of the oracle built for integrations that need tighter control over who can propose resolutions and how requests are configured.

Unlike the open OOv2, where anyone could propose an outcome if they post a bond, ManagedOptimisticOracleV2.sol introduces a management layer that limits this flexibility to improve reliability in large-scale prediction markets like Polymarket.

What MOOv2 Adds to UMA Optimistic Oracle

At its core, MOOv2 keeps the same request–propose–dispute flow but introduces role-based control and whitelisting to manage how requests are handled before and after they’re created.

Key methods include:

• addRequestManager() / removeRequestManager() – Grants or revokes the right to manage oracle parameters for a specific integration.
• setDefaultProposerWhitelist() – Defines a global list of addresses allowed to propose resolutions.
• requestManagerSetProposerWhitelist() – Lets the integration assign a custom whitelist for individual requests.
• requestManagerSetBond() and requestManagerSetCustomLiveness() – Allow the manager to adjust the proposal bond and liveness window within predefined limits.
• getManagedRequestId() – Generates a consistent ID for managed requests, used across overrides and whitelists.

How ​​Managed Optimistic Oracle Works

When Polymarket requests data, MOOv2 checks two whitelists:

1. Requester whitelist – ensures only approved contracts can make a request.
2. Proposer whitelist – ensures only vetted addresses can propose outcomes.

This means markets cannot be resolved by random users but only by a curated set of trusted proposers, reducing invalid or premature proposals that previously delayed resolution.

The right to dispute still remains open to anyone. This preserves decentralization in verification while improving reliability on the proposal side.

How MOOv2 is different from OOv2

The managed version helps large integrations balance openness and control.

In cases like sports or crypto markets, where outcomes are rarely subjective, having a smaller group of experienced proposers speeds up settlement and reduces unnecessary disputes.

In short, MOOv2 extends OOv2 with governance-aware tools, letting integrations manage proposer access, request parameters, and settlement configuration without modifying UMA’s core oracle logic.

That wraps up our walk-through of the Optimistic Oracle layer. We covered what a price identifier is and how ancillary data frames requests (YES_OR_NO_QUERY and the newer MULTIPLE_VALUES), the contracts that run OOv2 (OptimisticOracleV2, Store, Finder), the request → propose → dispute → settle flow, and the ManagedOptimisticOracleV2 extension that adds requester/proposer whitelists and per-request overrides for bonds and liveness.

Next, we’ll move to the final piece that steps in when disputes aren’t settled at the OO level — the Data Verification Mechanism (DVM) — and explain how UMA stakers vote, the commit/reveal process, and how collateral is redistributed after a vote.

UMA’s Final Layer of Dispute Resolution

Now that we’ve walked through the Optimistic Oracle contracts and prediction market resolution workflow, it’s time to move to the layer where UMA resolves disputes – the Data Verification Mechanism (DVM).

As we already know, this is where disputes that can’t be settled at the oracle level are escalated and verified by UMA tokenholders. DVM is UMA’s on-chain court. It relies on UMA token stakers who vote on disputed data using a commit–reveal mechanism based on Schelling point theory, where independent voters, acting in their best financial interest, are most likely to vote for the correct outcome. Let’s see how it works on a low level.

Core contracts of the data verification mechanism

The DVM code lives in the data-verification-mechanism folder.

The central contract is VotingV2.sol, which implements and extends several interfaces:

• OracleInterface
• OracleAncillaryInterface
• OracleGovernanceInterface
• VotingV2Interface

It also inherits from Staker.sol, which manages token staking and participation in dispute resolution.

Other contracts connected to VotingV2.sol include:

• VoteTiming.sol – defines commit and reveal intervals.
• Finder.sol – stores protocol-wide contract addresses.
• FixedSlashSlashingLibrary.sol – calculates and redistributes penalties.
• VotingToken.sol – represents the UMA token used for staking.
• ResultComputationV2 – aggregates and finalizes voting results.
• Previous Voting contract – used for data migration and reward retrieval.

Together, these contracts maintain UMA’s verification system.

Commit–reveal voting

Each voting round happens in two stages:

1. Commit phase – voters submit a hash of their vote, concealing their choice.
2. Reveal phase – voters publish the actual value, proving that it matches their earlier commitment.

This ensures that all votes are independent and prevents coordination or front-running. After the reveal phase, results are computed using the ResultComputationV2 library.

Staking and incentives in DVM 2.0

DVM 2.0, launched in early 2023, introduced a redesigned staking and reward system.

To participate, UMA tokenholders must stake their tokens. Stakers earn rewards in two ways:

• Base emissions — a fixed UMA amount is distributed per block to all stakers proportionally.
• Slashing redistribution — tokens slashed from inactive or incorrect voters are given to those who voted correctly.

This system encourages participation and careful voting. Base rewards are predictable, while slashing rewards depend on performance.

Slashing

Slashing ensures voters can’t passively earn without engaging. Every key user action — staking, unstaking, or withdrawing rewards — triggers an update via _updateTrackers(), which checks participation and applies penalties if needed.

Additionally, anyone can trigger slashing for any voter by calling updateTrackers(address voter). This keeps the system honest and eliminates free-riding. The penalty logic is implemented through FixedSlashSlashingLibrary.sol, which defines how much UMA is deducted and redistributed.

Delegation and recovery

The DVM 2.0 also introduced a vote delegation. A cold wallet can hold the staked UMA while a hot wallet performs voting actions, without access to the underlying stake. This design improves security for long-term participants.

A new emergency recovery system was also introduced. It allows the protocol to bypass the standard voting flow in case of a critical failure — ensuring that governance and oracle operations can continue even during emergencies.

Governance and voting conditions

To finalize votes, two quorum conditions must be met:

• GAT (God Awful Threshold) — a minimum fixed number of UMA tokens must vote.
• SPAT (Schelling Point Activation Threshold) — at least 50% of staked tokens must agree.

If these thresholds aren’t met, the vote “rolls” to the next round. After several consecutive rolls, the request can be deleted to prevent spam or stalled resolutions.

Wrapping Up

Here we end our exploration of how UMA’s Optimistic Oracle resolves prediction market outcomes.

We’ve seen that the system combines an initial optimistic verification layer with a decentralized dispute mechanism. Most outcomes resolve quickly, while disputed results are handled by UMA stakers in the Data Verification Mechanism. Incentives and slashing ensure participants engage actively and that verified results can be trusted for market settlement.

There’s more to the protocol, but for starters, we hope this post has given you a clear view of how resolution works in prediction markets.

For further reading:

• How Polymarket Works | The Tech Behind Prediction Markets
• UMA DVM 2.0 Overview
• How UMA’s Oracle Works
• UMA FAQs
• UMIPs on GitHub

Key takeaways:

How Prediction Markets Resolve Outcomes

Prediction market resolution converts open YES/NO positions into final payouts after a market closes. When a market ends, the platform queries an oracle to verify the real-world outcome. If the answer is undisputed, payouts are executed automatically. If challenged, the dispute escalates to UMA’s Data Verification Mechanism (DVM) for final determination.

What Oracle Does Polymarket Use?

Polymarket uses UMA’s Optimistic Oracle (OO) to verify event outcomes on demand. This request-driven model reduces unnecessary on-chain activity and allows the oracle to handle binary outcomes, multi-value events, and intersubjective data like election results or sports scores.

How UMA’s Optimistic Oracle Works

1. Request: A smart contract asks the oracle to resolve an event.
2. Propose: A proposer posts an answer with a collateralized bond.
3. Dispute Window: Others can challenge the answer during the liveness period.
4. Finalize: If no dispute occurs, the answer becomes final. If challenged, it escalates to the DVM, where UMA stakers vote to determine the verified outcome.

How Disputes Are Handled in Polymarket

• Anyone can dispute a proposed outcome by posting collateral.
• Disputed requests escalate to the DVM, UMA’s on-chain voting layer.
• UMA token stakers vote using a commit–reveal scheme, ensuring independent and secure results.
• Rewards and penalties incentivize truthful participation; incorrect votes are slashed.

What Resolution Means in a Prediction Market

• Converts YES/NO positions into final payouts after market close.
• Oracles bring off-chain events on-chain for settlement.
• Main steps: market closes → oracle determines outcome → token holders redeem.

Why Prediction Markets Need an Oracle

• Blockchains cannot verify off-chain events alone.
• Oracles provide verified outcomes for on-chain settlement.

Oracle Requirements for Prediction Markets

• Must handle human-readable questions.
• Allow disputes and escalation.
• Provide finality for confident settlement.

UMA Optimistic Oracle Overview

• Request–propose–dispute cycle assumes answers are correct unless challenged.
• Maintains data accuracy through economic incentives and the Schelling Point principle.
• Dishonest actors lose bonds; correct voters earn rewards.

Why UMA Works for Prediction Markets

• On-demand verification reduces unnecessary on-chain activity.
• Handles unusual, subjective, or intersubjective events.
• Supports multiple data types and cross-chain usage.
• Open participation with aligned incentives; dishonest actions penalized.

Query Structures and Ancillary Data

• YES_OR_NO_QUERY: Binary outcomes; ancillary data provides context.
• MULTIPLE_VALUES: Up to seven integers in one request; reduces gas for multi-outcome events.
• Ancillary data ensures consistency and clarity for proposers, disputers, and voters.

Contracts in Prediction Market Resolution

• Application Layer: Sends requests, receives outcomes, settles tokens.
• OptimisticOracleV2.sol: Handles request lifecycle, proposals, disputes, and final settlement.
• Store.sol: Tracks request state, collateral, and liveness periods.
• Finder.sol: Connects contracts dynamically within the UMA ecosystem.

Managed Optimistic Oracle V2 (MOOv2)

• Adds whitelists for requesters and proposers.
• Maintains the request–propose–dispute cycle with tighter control.
• Ensures reliability in large-scale markets like Polymarket while keeping disputes open to all.

Data Verification Mechanism (DVM)

• Final on-chain layer for disputed outcomes.
• UMA stakers vote using a commit-reveal scheme; incentivized via rewards and slashing.
• Commit–reveal prevents coordination and front-running.
• Voting thresholds: GAT (minimum UMA participation) and SPAT (≥50% agreement).
• Staking, delegation, and emergency recovery ensure security, participation, and continuity.

Incentives and Accountability in DVM 2.0

• Base emissions reward all stakers.
• Slashing penalizes incorrect or inactive voters, redistributed to correct voters.
• Delegation allows cold wallets to secure stake while hot wallets vote.
• Emergency recovery allows governance to continue in critical situations.

About Rock’n’Block

Rock’n’Block is a Web3-native development studio building production-grade blockchain infrastructure and decentralized applications, and prediction markets. We help founders launch high-performance markets faster, create UX that scales to millions of users, and ensure reliable, secure oracle integrations for accurate outcome resolution.

Follow us on X for more deep dives.

What we do:

• Build custom Layer-1 chains, DeFi protocols, and decentralized exchanges.
• Develop prediction markets and perpetual DEXes with order books, funding rates, margining, liquidations, and oracle integrations.
• Create blockchain data streaming solutions for real-time and historical market data.
• Implement chain-agnostic payment solutions and financial tooling for market participants.

With nearly a decade of hands-on blockchain experience, our team has supported products used by 71M+ DeFi users, reaching $2.5B in market cap, and helped partners raise $167M.

View Portfolio

We ♥️ Development