How resolution oracles submit settlement data to prediction markets

02 September 2026

A prediction market needs a way to settle. Someone must report what actually happened. That job falls to oracles - systems that submit resolution data to smart contracts.

The UMA optimistic oracle provides one working model. It relies on a proposer-disputer dynamic. Anyone can propose a settlement answer, and that person posts a bond, a deposit of tokens that sits as collateral. The proposed data becomes the provisional truth unless someone challenges it.

Here is how it works. A proposer submits a price request answer to the DVM (Data Verification Mechanism); the answer includes the resolution data for a market - say, the winner of an election or whether a temperature target was met. A challenge window opens. Typically this lasts two hours on L2 chains or longer on Ethereum mainnet. During that window, any participant can dispute the proposal. To dispute, that person must also post a bond. If no one disputes, the proposal becomes canonical and the proposer gets the bond back, plus a reward drawn from the market's fees. If someone does dispute, the case escalates to UMA's decentralized voters. Those voters, staking UMA tokens, decide the correct answer. The losing side forfeits its bond. The winning side gets the bond plus fees.

The beauty is in the incentive alignment. Proposers are motivated to tell the truth; lying would invite a dispute and loss of the bond. Disputers are motivated to catch lies. Both sides risk capital on honesty.

Once the oracle submits the final settlement data, the market contract consumes it. The contract checks the oracle's stored answer. If the answer matches outcome A, all tokens representing outcome A become redeemable for the payout. Tokens for the losing outcome become worthless. The redemption mechanism is already covered elsewhere on this site. The oracle's job ends when the data lands on-chain. The market math takes over.

Contrast this with Chainlink data feeds for sports events. Chainlink uses a decentralized network of node operators. Those nodes fetch data from multiple APIs and aggregate it. The median of their reports gets posted on-chain as a single price or score. There is no challenge window. There is no bond. The data is considered final upon submission because the network itself is designed for constant, reliable updates. For sports, this works well: scores change in real time, you do not want a two-hour dispute window during a basketball game, and you want the score updated every minute.

But the tradeoff is trust. Chainlink nodes are permissioned. You must trust that a majority of them report honestly. The UMA model trusts no single party; it trusts economic incentives. If data is controversial or hard to source, the optimistic oracle handles it better. If data is simple and frequent - like a sports score - Chainlink is faster.

What happens when the oracle submits erroneous data? In a UMA system, the dispute window catches honest mistakes or malicious proposals, and voters correct them. In a Chainlink system, erroneous data sits until the next update. The market may settle incorrectly if the error occurs at the final moment. Some markets add a "referee" safety hatch - an admin key that can override the oracle. That introduces centralization.

The market contract itself remains agnostic about the oracle's reliability. It merely reads the oracle address it was initialized with and calls a function like getPrice() or getOutcome(). The developer chooses the oracle. The user trusts that choice.

For prediction markets using UMA, the typical flow is: market creator deploys a contract pointing to the UMA OptimisticOracleV3 (or V2). When the market expires, any user proposes a settlement price via the oracle. The window opens. If no dispute, the price is written and the market contract then triggers payout calculations. If a dispute occurs, the UMA voters resolve it, which can take two to three days.

The UMA system makes it permissionless. Anyone can propose. Anyone can dispute. The bond amounts must be high enough to deter frivolous challenges but low enough not to block honest proposals. Typical bonds are 0.1% to 1% of the dispute size. The market creator sets these parameters at deployment.

You do not need to know the bond mathematics to use the market. You only need to know that the settlement will happen eventually - the oracle guarantees it.

Chainlink's approach is simpler to integrate. The market contract just imports the AggregatorV3Interface and reads the latest round. No bonding. No dispute windows. The node operators are paid in LINK tokens per data delivery. The cost is lower per update, but the trust model is different.

For a prediction market builder, the choice depends on the market's duration and data complexity. Short-lived sports markets lean toward Chainlink. Long-running political or financial markets lean toward UMA. Both work. Both have been used in production.

The key takeaway is that settlement data does not appear magically. An oracle submits it. A contract consumes it. The incentives behind the oracle determine whether the data is trustworthy. Prediction markets only work if the settlement is reliable. The oracle is the weakest link in that chain. Understanding how it submits data - and what happens when it goes wrong - matters more than any token price.

Back to prediction markets