The Oracle Problem

This post was originally published on May 17, 2019, and sent to Messari Pro subscribers.

Trust - or lack thereof - is the reason why we put up these slow, clunky databases called blockchains. If you want efficiency, many centralized services work just fine. Venmo works great for sending payments and AWS works great for running web apps. But there are circumstances where users are willing to sacrifice efficiency in order to reduce the level of trust in third parties. Bitcoin is an obvious example where users generally pay higher fees and deal with waiting for a certain number of confirmations in order to transact using a censorship-resistant asset. Money is a clear use case that benefits from a trustless system, but it’s not the only one.

Another use case we have seen emerge is decentralized finance (DeFI), which seeks to make new financial products and infrastructure that are censorship resistant. There’s a problem though. With Bitcoin there is no reliance on any external data. As long as computational energy is expended on the network, it will continue to operate. This is not the case for many of decentralized applications, though. How does an Augur market know who won the election? How does a MakerDAO CDP know the price of Ether dropped below the liquidation ratio? These applications all rely on third parties, outside the network, to provide this information. These “Oracles” introduce a degree of trust into blockchains. If incorrect data is fed into the system users face monetary losses, so users need to trust the source of their data. Because there are financial stakes on the line, there will always be an incentive to game the system to turn a profit. If a user wants to influence the outcome of a prediction market for example, they could theoretically send fake results to the network. Even without influence from bad actors it is often hard to get correct data. For these apps to be successful there needs to be a means of ensuring correct data inputs to maintain the integrity of the system.This is what is referred to as the Oracle Problem.

Oracles typically source information from a third party API and convert it to a format that can be read by the protocol. In order to lessen the risk of bad data, oracles often source from multiple inputs. If MakerDAO, for example, is using an oracle that uses 10 price providers, chances are it will provide accurate information most of the time. However, “most of the time” is not acceptable when there are tens of millions of dollars on the line. The possibility of the majority of price providers being inaccurate or the oracle itself being compromised will always exist.

Can it Be Solved?

Many creative solutions have been presented to solve this oracle problem.

• In Augur ($REP), market creators choose a designated reporter they believe will provide accurate information. In the event that they do not, anyone can dispute the outcome. Augur was one of the first to introduce the idea of a work token that gives the owner the right to provide a service to the network. Reporters (oracles) need to purchase this token, akin to a taxi medallion, to then receive tokens for their services or be penalized for misbehavior. An example of how this resolution mechanism works in action was the $2.8 million Augur market on the U.S. House elections. The question “Which party will control the House after 2018 U.S. mid-term election?” seems pretty straightforward. The democrats won, however the market expired 12/10/18 and the Democrats didn’t officially take control until January. The market settled Democrat, but was disputed and subsequently voted on by staking Augur’s REP token. Reporters opted for the intended outcome over the literal interpretation and those that voted Republican lost their stake.