How to Choose an Oracle That's Right for Your dApp

Oracles are for now the only way to get data that sits outside the blockchain to the network. It is not a case of getting decentralized external data, but a case of getting external data at all. Blockchain applications can't read prices from Yahoo finance, for example, but they can with an oracle solution. With oracles, they can also aggregate data from a myriad of sources so that the data used by smart contracts is as decentralized and as safe as possible.  

Without oracles providing information about relevant prices, financial operations in a decentralized ecosystem wouldn’t be possible. But there’s more to oracles than data provision – they also protect against manipulations. 

dApps would not exist without oracles

Blockchains cannot communicate with the exterior world, so any decentralized application (dApp) that needs to interact with off-chain data, be it medical records or supply chain data, will need an oracle solution to assess what happened outside of the blockchain. The road to the data being decentralized also isn’t a quick switch. This a process on its own, from making the code publicly available to enabling reviews of your smart contract. The data coming in from the oracle is just one piece of the puzzle.

The majority of DeFi Web3 apps would not exist without oracles. But outside of DeFi, the dependence on oracles varies based on the type of app you want to build. For instance, if the insurance industry was to explore opportunities in DeFi and decentralized insurance were to become more prevalent, the blockchain wouldn’t know if an accident occurred or if a plane didn’t take off. This data will need to be placed on the blockchain application.

You can do this in one of two ways. The first way is to use centralized applications (apps) and rely on that one entity to provide this data. The problem is if the one CEX that you base your price on is hacked or exploited, then the components of your protocol that rely on that data will be influenced. Option two is the decentralized path, with oracles that have nodes or validators behind the process. These nodes validate the accuracy of the data and then serve it to the blockchain application or the smart contract. 

Cost and performance considerations for oracles

dApps will use the existing oracle infrastructure but find oracles specifically geared toward the data they desire. When choosing an oracle for your dApp, you have to determine how trustworthy the oracle is by looking at how many nodes are behind it. Bigger oracles will be more trustworthy, but they’re also more expensive. This price or monthly premium will depend on what your dApp does and how quickly and securely you want to obtain the information. If you’re in the financial market, working with lending and borrowing and there is a misalignment of prices, this money can be repaid at a much lower rate and exploit the entire app. 

In terms of improving existing processes, nodes should agree on a median value. This will make the process more secure and efficient, which is vital if you want data that is delivered quickly and is not tampered with. Assess the performance of the oracle, in terms of how quickly it delivers the data and how consistent the data is. A business could have multiple nodes, but if the oracle data is delivered by a single node, this oracle could manipulate the data. Oracles should also be cheaper, as one of the biggest challenges with oracle protocols is that they’re expensive, especially for smaller DeFi projects that have small grants or rely on hackathon money. On the other hand, companies that can afford bigger oracles with a lot of nodes consume more resources and, therefore, need a large payout or they could simply shut down. There’s a balancing act happening here, and it’s not easy to get it right. 

The fine line between security and trust 

Oracles are protocols built on the blockchain, so the biggest security concern is if the protocol has a bug or a flaw, which isn’t uncommon since it’s software. That flaw can be exploited for the benefit of actors trying to manipulate prices or trying to gain value from the protocols that are relying on that oracle for data. If the process of gathering data from the nodes is not well designed or there aren’t checks in place, the nodes serving the data to the protocols can become malicious and serve bad data. 

How the node is set up on an oracle also matters. You could manage your nodes through staking – incentivizing nodes to produce valid data through user fees, but then protocols need to decide how much stake is provided and whether it can be economically exploited or not. In other words, can someone come and buy a lot of tokens and take control of the oracle solution? For bigger oracles, these kinds of attacks are less economically viable.  

The alternative to oracles would be the blockchain serving as an oracle because the chain itself has the capacity to provide data outside of the network through various systems. This option would be more convenient because then you don't have to rely on a protocol that’s a niche on the blockchain. However, this puts pressure on validators. It also makes security more complex, because you don’t know how it will play out over the long term. This could be too complex for smaller businesses and may lead to a lack of decentralization. DeFi has gone from using one node to validate data to thousands of nodes, but in the future, oracles may be built into the blockchain, or something entirely different from oracles may even exist. 

Always have a fallback solution in DeFi

Oracles are vital if there is to be mass adoption of DeFi. They offer security and a reliable data point that everyone can trust. Having an oracle solution ensures that your protocol is built in a certain way with validators and checkpoints that you know bring credible, trustworthy data to the blockchain. There’s no doubt that protocols should use oracles, the main concern is what type of oracle or the specific niche or solution you want. In an attempt to avoid bugs, it wouldn’t even be too far-fetched to consider having more than one oracle, as a protocol should always have a fallback solution.