The design intention of oracles is to correctly report the truth, but they were never designed to determine what the truth actually is.
Written by: Aradtski
Translated by: AididiaoJP, Foresight News
For prediction markets, the "oracle problem" is actually not a real problem, and don't blame UMA - this conclusion might seem counterintuitive.
The "oracle problem" is one of the oldest problems in the crypto field; like everything, it can be traced back to the early Bitcointalk forum. In discussions about prediction markets, this issue has always been at the core: people expect oracles to provide the truth on-chain based on real-world outcomes and ensure the correct operation of on-chain financial programs.
The oracle problem has never been simple, but it seems even more tricky for prediction markets for several reasons. The most obvious one is that malicious oracle reports can have catastrophic consequences! Incorrect contracts can cause users' funds to be zeroed out.
Polymarket has had many controversial oracle rulings, some of which have even sparked strong user dissatisfaction, making them feel blatantly deceived:
- Will Zelensky wear a suit before July 1, 2025?
- Israel's military operations in Syria
- Winner of the 2024 Venezuelan presidential election
- LayerZero's airdrop
- Did Barron participate in Shkreli's Trump meme coin
- Approval of Ethereum ETF
- Will Sam Bankman-Fried go to jail?
- Will Trump tweet?
- Israel's invasion of Lebanon
- Is the gold in Fort Knox missing?
- Will the Titan submersible be found?
- Will the US and Ukraine sign a mineral mining agreement by the end of the month?
...and many more such examples.
Every market has its unique story and a group of innocent users who were caught off guard. In a few markets, the funds involved reached millions or even tens of millions of dollars. Usually, most bets pour in after the related event, just to bet on how the UMA oracle will rule on the event.
How should we solve this problem?
As practitioners in the crypto field, our first reaction is: "Well, to solve this problem, we must make oracles trustless and decentralized, right?"
However, this is not actually the case. For prediction markets, doing so doesn't make much sense. It might sound strange at first, but please hear me out.
We need to clearly distinguish between regular oracle data sources and event oracles:
A) Price data sources (regular): Liquidity prices have a clear definition, and the truth is widely accepted. Disputes over liquidity asset prices are rare because their definition has been broadly understood for hundreds of years; prices are usually the price of the last trade or the mid-price in an active market.
Even in extreme situations, where order books of a few exchanges become empty or distorted, participants still know the actual market price of these liquidity assets. Moreover, even in high volatility scenarios where all order books become very sparse and market prices are unclear, this is only temporary, and oracle price data sources can usually pause and resume shortly after without causing serious impact on DeFi protocols.
In short, price data source oracles need to worry about activity and how to filter malicious reports. But they don't need to worry about the definition of "price".
B) Event data sources: Event oracles don't need to worry about activity. They indeed need to worry about malicious reports, but most importantly, they must focus on definition problems. For price data source oracles, the definition of "market price" is implicit, known, widely understood, and permanent. However, the definitions of events in prediction markets are human-made, and the definitions of each event are vastly different. For event oracles, the problem of "truth itself" often exists at the most basic level.
When reporting event results, the oracle problem pales in comparison to the definition problem. Prediction markets can have the most honest, trustless, decentralized, and neutral oracles, but if there are fundamental logical disputes about which result should be reported, then decentralized oracles are like frosting on a cake without the cake itself - meaningless.
In other words, since the birth of the crypto field, oracles have been designed to correctly report the truth, but have never been designed to determine what the truth actually is.
When clearly defined hypotheses collapse, oracles become useless.
Let me relax a bit and take a step back.
How did we get to this point?
It's understandable that oracles have always been designed based on clearly defined hypotheses. The market needs data sources for prices, TVL (Total Value Locked), interest rates, sequencer runtime, etc., which are reproducible empirical data sources.
The principles described by Vitalik in a 2014 blog post titled "SchellingCoin: A Minimal Trust Universal Data Source" are still the basis for all oracle protocols: if everyone knows what the Schelling point value is and participants are confident about what others might report, the protocol can reward those who report values close to others and penalize outliers, as they can be assumed to be malicious or lagging.
However, if there is no obvious Schelling point, the entire design collapses.
In summary, for prediction markets, the oracle problem is actually not an oracle problem, because crypto oracles were never designed for things like world events.
Now, if trustlessness and decentralization are not important for prediction market oracles because the most common disputes are definition disputes, what is important? How can we improve?
Recognize these two practical guiding principles:
Oracle participants need to directly stake in the long-term success of the platform. This is a well-known basic principle in consensus mechanisms, but for some reason, it has always been overlooked. A proprietary, centralized Polymarket oracle is more preferable than an external "decentralized" UMA oracle composed of hired capital.
Definition! Definition! And still definition! The importance of oracles is secondary to providing rigorous definitions for events. In the many controversies of Polymarket, almost all roots are continuous neglect of definitions.
Acknowledge that the real world is not perfect; even if the initial definition is written well, it may miss some edge cases. In such cases, clarification should be provided immediately to prevent the problem from further deteriorating.
Most importantly, scoff at those trying to sell you complex decentralized oracle mechanisms. I guarantee they haven't solved the real problems plaguing prediction markets.
