In June 2024, a Polymarket contract asked whether a preponderance of evidence suggested Barron Trump was involved in creating the $DJT memecoin. The question ran through UMA, Polymarket's decentralised oracle, and the token holders who vote on disputed outcomes resolved it NO. That should have been the end of it. Instead Polymarket did something rare and controversial: it overruled its own oracle, said publicly that he was "involved in some way," and refunded the traders who had bet YES. A result the platform's own decentralised, supposedly final oracle had reached was reversed by the platform operator.
That episode is the clearest possible illustration of why the resolution layer matters, and of where authority on these venues really sits. When you buy a YES share at 62 cents, you are not really betting on the event. You are betting on how a specific process will judge the event when the deadline hits, and on whether anyone can step in over the top of that process afterwards. Get the event right and the resolution wrong, and you still lose. Anyone trading serious size on Polymarket or any onchain venue needs to understand this layer as well as they understand the odds themselves.
The job an oracle is actually doing
Every prediction market ends the same way: someone has to declare the winning side. On a regulated US venue like Kalshi, that someone is the exchange itself, working from pre-published resolution sources. On Polymarket, which lives on the Polygon blockchain and settles in pUSD, its USDC-backed collateral token, no central operator has that authority. The smart contract holding the money cannot read a newspaper. It cannot watch a football match. It needs an external input, and the mechanism that supplies that input is called an oracle.
Think of the oracle as the bridge between the real world and the code. The market contract asks a yes-or-no question. The oracle returns a yes-or-no answer. The contract then pays out accordingly, automatically, with no further human intervention. If the oracle returns the wrong answer, the wrong side wins. There is no appeals court above the smart contract.
This is why the design of the oracle is not a technical footnote. It is the load-bearing beam of the entire structure.
Why Polymarket uses UMA and what that means
Polymarket outsources its resolution to UMA, which stands for Universal Market Access. UMA is not a person or a company reading the news. It is what its designers call an optimistic oracle, and the word optimistic is doing serious work.
Here is the shape of it. When a Polymarket contract reaches its deadline, anyone can propose an answer by posting a financial bond in UMA's native token. The proposal enters a challenge window, usually a couple of hours long. If nobody disputes it in that window, the proposal is accepted and the market resolves. If someone does dispute it, the question escalates to a vote among UMA token holders, who read the evidence and cast their own verdicts. The majority side wins. The losing side forfeits its bond.
The optimism is the assumption that most questions have obvious answers most of the time. A US presidential election result, a football scoreline, a Federal Reserve rate decision: these are not ambiguous. Nobody needs to vote on them. The bond-and-challenge structure exists to catch the small fraction of cases where the answer is contested, and to give economically-motivated humans a reason to police the edges.
Our guide to how prediction market odds work covers the pricing side of Polymarket. The resolution side sits underneath all of it.
Where UMA has been controversial
The Barron Trump memecoin case is one example. There have been others. A market on whether Ukraine and Russia would agree a ceasefire by a certain date has been re-litigated more than once because the underlying event is fuzzy. A market on whether a specific politician would appear at a specific event has hinged on video timestamps. In each case, the challenge is not that UMA is broken. It is that human-drafted market questions have edges, and edges are where money gets made and lost.
UMA token holders vote on disputes, and those token holders are not neutral. They hold UMA. They can hold Polymarket positions. Critics argue this is a governance problem in slow motion; defenders argue that the bond structure and the reputation cost of bad votes create adequate discipline. Reasonable people disagree, and the disagreement is worth flagging when you place a trade on any contract with even mildly ambiguous wording.
The practical lesson is straightforward. Read the resolution criteria on any Polymarket contract before you buy. The tab is right there. If the criteria are vague, the oracle risk is real, and no amount of being right about the underlying event will protect you.
How Kalshi does it differently
Why does a CFTC-regulated exchange not use an oracle like UMA? Because it does not have to. Kalshi is a centralised operator, and US regulators require the exchange itself to define and apply resolution sources. Each Kalshi contract publishes its resolution source in advance: a specific government release, a named data provider, a designated wire service. When the event happens, Kalshi reads the source, applies the rules, and settles. If a user disputes the outcome, they raise it with Kalshi's compliance team, not with a token-holder vote.
This is faster, cleaner, and boringer, which are exactly the qualities regulators reward. It is also more centralised. If Kalshi makes a bad call, you have to argue with Kalshi. If UMA makes a bad call, you have to organise a governance response. Neither is fun. Our breakdown of how market resolution actually works walks through the mechanics on both sides.
The general point: an oracle is any process that turns real-world facts into a settlement value. On Kalshi that process is a compliance team and a data source. On Polymarket it is UMA. On smaller decentralised venues it might be a Chainlink data feed or a bespoke committee. The name of the process is less important than knowing which one you are trusting.
What can go wrong in practice
Oracle failures come in three flavours. The first is a wrong-answer resolution, where the correct outcome loses. This is rare on high-liquidity markets because the economic incentive to challenge a bad proposal is large. It is less rare on low-liquidity markets, where nobody is watching closely enough to spot the mistake in the challenge window.
The second flavour is an ambiguous question. The market asked something that turned out not to have a clean yes-or-no answer, and the oracle had to pick one anyway. Polymarket's conditional markets have had a few of these, particularly around political events that hinge on timing or on statements that were made in one form but not another. Our guide to conditional markets on Polymarket covers the structure.
The third flavour is deliberate manipulation. Someone with a large position tries to influence the oracle vote itself, either by acquiring UMA tokens or by flooding the challenge window with proposals. This has been theorised more than it has been observed, but the risk scales with the position size at stake.
None of this makes prediction markets uninvestable. It does mean that the resolution layer is a real source of risk, and it should be priced into your trades the same way you price fees and liquidity.
How to think about oracle risk as a trader
Start with the wording. Before you take a position, open the resolution criteria on the market page and read them like a contract, because they are one. Ask yourself: what specific event would have to happen for this to resolve YES? What would have to happen for it to resolve NO? Is there a state of the world where the answer is unclear? If yes, that ambiguity is the oracle risk, and you are the one bearing it.
Then look at the resolution source. If the market points to a named data provider, an official government release, or a wire service, the oracle's job is essentially clerical. If the market points to a nebulous concept like "credible reporting" or "public acknowledgement," the oracle's job is interpretive, and interpretive resolution is where disputes happen.
Finally, consider the deadline structure. Markets that resolve immediately after a scheduled event (an election, a match, a Fed announcement) tend to have clean resolutions. Markets that resolve on "by end of year" or "before X happens" timelines have more surface area for edge cases. Trade accordingly.
iPredicta tracks prediction markets across Polymarket, Kalshi and the regulated UK venues, surfacing not just prices but the underlying resolution structure of each contract. For serious traders, that context is where the edge lives, and it is what we spend our time explaining.
Frequently asked questions
What is an oracle in a prediction market?
An oracle is the process that turns a real-world event into the settlement value a prediction market pays out on. Because a smart contract cannot read the news or watch a match, it needs an external mechanism to declare the winning side. On centralised venues like Kalshi, the oracle is the exchange's own compliance team applying pre-published resolution sources. On Polymarket, the oracle is UMA, a decentralised system where anyone can propose an outcome by posting a bond and disputes are settled by token-holder votes. Whichever design a venue uses, the oracle is what actually decides who gets paid.
How does UMA resolve Polymarket contracts?
UMA uses an optimistic oracle design, meaning it assumes most proposed answers are correct unless someone challenges them. When a Polymarket contract reaches its deadline, a proposer posts a bond in UMA tokens along with their proposed outcome. A challenge window opens, typically a few hours long. If no dispute is filed, the outcome is accepted automatically and the market pays out. If a dispute is filed, the question escalates to a vote by UMA token holders, who review the evidence and decide the answer. The losing side of any dispute forfeits its bond, which is what gives participants a financial reason to police the system.
Can a Polymarket resolution be wrong?
Yes, resolutions can be contested, and there have been several controversial cases on Polymarket. The most cited example is the June 2024 market on whether a preponderance of evidence suggested Barron Trump was involved in creating the $DJT memecoin. UMA's token holders resolved it NO, and Polymarket then took the rare step of overruling its own oracle, saying he was "involved in some way" and refunding the traders who had bet YES. The episode cuts both ways: it shows that a decentralised oracle can reach a result the platform operator disagrees with, and that the operator retains the discretion to step in over the top of it. The best defence is to read the resolution criteria on every market before trading, and to avoid contracts with vague or interpretive wording where the risk of a contested outcome is materially higher.
Does Kalshi use an oracle like UMA?
No, Kalshi does not use a decentralised oracle because it does not need one. As a CFTC-regulated exchange, Kalshi is required to define and apply resolution sources itself. Each Kalshi contract specifies its resolution source in advance, typically a government data release, a named data provider or a designated wire service. When the event happens, Kalshi's compliance team reads the source, applies the rules and settles the contract. Disputes are handled internally through the exchange's compliance process rather than through token-holder voting. It is a more centralised design that trades transparency for speed and regulatory clarity.
Should I worry about oracle risk when trading prediction markets?
Yes, oracle risk is a real cost of trading and it should factor into every position you size. Before you buy any contract, open the resolution criteria and read them as if they were a legal document, because functionally they are. Check what specific event triggers a YES outcome, what triggers NO and whether there is any state of the world that is genuinely ambiguous. Look at the resolution source: named data providers and official releases carry less risk than interpretive language like "credible reporting." On smaller markets with thin liquidity, the risk that a bad proposal slips through the challenge window without being caught is meaningfully higher.