Towards better price oracle schemes, Part I

Price oracles are a crucial necessity, but also a great weakness for DeFi. Most DeFi projects use centralized oracles with no fallback, which means that they are a single point of failure. In this post, I will do a deep dive into oracles, especially decentralized ones, and provide multiple potential solutions to problems facing protocols that use them.

This is part I in a II-part series on oracles. This part talks about various oracle solutions and the risks they pose. It lays the groundwork for part II, which will go more in-depth about how both various oracles and governance can be exploited.

TLDR

If you can’t be bothered to read the whole blog post, which is fine, here are some important takeaways:

• Centralized oracles shouldn’t be used as-is, they can be manipulated by private, and more importantly, state actors easily.
• Decentralized oracles are hard to do properly.
• A decentralized oracle should never take the face value of a single source. some kind of sanity check is mandatory.
• Having a centralized oracle with a fallback to a decentralized one is usually an acceptable trade-off.
• Fallbacks should be implemented so they’re not too aggressive or too passive.
• If DAO governance is used, make sure you don’t have conflicts of interest.

The current state of oracles

Centralized oracles (mostly chainlink) are used by almost all top DeFi protocols. In my opinion, this is a rather reckless thing to do, as all protocols that use chainlink, with no good fallback, are at their mercy. No project that relies on external centralized services can rightfully claim to be decentralized.

The only big protocol that’s truly independent is Maker. They make up around 30% of DeFi TVL with their oracle solution.

Why centralized oracles are so widespread

When creating a DeFi protocol that needs to get price data, it’s important to make sure that the data is as recent as possible and as resistant to manipulation as possible. Decentralized oracles face the same trilemma blockchains do. If you prioritize speed, you lose security in the form of manipulation, and vice versa.

One of the main reasons behind chainlink’s dominance is that its seen as a good compromise between speed and security. Chainlink is fast and has a strong brand, so it’s seen as a safe bet. It’s also very easy to integrate chainlink into your protocol.

How dangerous are centralized oracle schemes?

We have already established that centralized oracles that can be gamed by a small number of entities are bad. But how dangerous is this? We’re going to focus on chainlink for our analysis, as it is the biggest centralized oracle securing the most TVL.

To get a definitive answer of the risks involved we need to look at how chainlink works. According to the chainlink docs, each data feed is updated by chainlink node operators. These node operators communicate with each other in a process called OCR (Off-chain reporting). They then come to a consensus on what price should be posted on chain by signing a message that contains their suggested price. When they reach consensus, the transaction that contains the price update gets sent if the price of the underlying asset moves by a certain threshold from the last update or if a certain amount of time since the last update has passed (known as the heartbeat threshold).

The OCR committee for the ETH/USD price feed on mainnet at the time of writing consists of 31 oracles. If enough members of the committee cooperate to pass the quorum, the price can be set arbitrarily. For reference, here are the members currently present on the committee:

Why don’t committee members collude?

As a private group of actors, the potential reward for price manipulation is not worth the risk. There is a social contract associated with being a chainlink node operator. If you manipulate the price, you will be kicked out of the committee. And as all of the operators are established businesses, it will reflect very badly on their reputation.

In my opinion, DeFi protocols should be designed to be fully sovereign and autonomous. A protocol should work the same way today and in 100 or more years. Having a single, centralized point of failure adds systemic risk to the entire protocol.

Decentralized oracles

Before we get into how decentralized oracles work, it is important to mention that there are generally 2 major types of decentralized oracles:

• Optimistic oracles
• Fully on chain oracles

While other oracle solutions fall outside of these categories, they are not decentralized, despite what their marketing might suggest.

Optimistic oracles

Optimistic oracles work on a similar principle to optimistic rollups, “True until proven false”. The two biggest players in the optimistic oracle game are UMA and Tellor. While both of these projects have their unique features, they are very similar in the way they work.

To post data on the chain, a reporter must post a stake. When data gets requested, a reporter sends the data to the chain, along with a timestamp. This is to help with solving disputes, as the data reporter can’t lie about the price at a certain timestamp.

After a certain period has passed, the data becomes finalized. If the data gets disputed, there is a mechanism to determine if the data reporter lied. If it’s determined that the reporter lied, the request gets removed from the chain, and the reporter gets punished, usually by slashing his stake. If the vote, however, gets rejected, the disputer loses his stake. Here’s a diagram of how the process works for UMA:

Optimistic oracle security

All major optimistic oracles have a perfect track record when it comes to security. But that however doesn’t mean that an attack is impossible. An attacker could potentially perform a denial of service attack on an optimistic oracle. This would be executed by the attacker knowingly submitting the wrong price. The data would then get challenged and the attacker would lose their stake. If the attacker has enough money, they can potentially keep submitting misleading data so the price never gets finalized.

On chain price oracles

On chain price oracles are different from other oracle solutions in that they don’t consume off chain data. All of the data they process is fully on chain, meaning that the oracle can’t lie in the same way other oracle solutions can. This, however, doesn’t mean that the oracle cannot be misleading. In fact, on chain oracles are very susceptible to manipulation.

The way on chain oracles work is by getting a quote from a decentralized exchange (Like uniswap, curve…) and running that price through a TWAP (time-weighted average price). With the advent of Uniswap V3, this has become much easier. Before V3, on chain TWAP oracles had to query the spot price every n blocks and update that on chain. Thankfully, all Uniswap V3 pools can act as TWAP price oracles, making the whole process non-interactive, and way more gas efficient.

TWAP oracle security

While they are by far the most decentralized and trustless oracle solution, they are potentially more prone to manipulation than other oracles.

That is because the oracle is, in a way, secured by the liquidity pool of the underlying assets. Assets with a lot of volume have a lot of liquidity. This means that it potentially takes tremendous amounts of capital to manipulate the price to where it would impact the oracle. This also works in reverse, as pools with less liquidity are much easier to manipulate.

TWAP oracles for assets with a lot of liquidity can have a very fast period, while smaller ones must be increased. This makes TWAP oracles a very good solution for liquid assets, but a potentially sub-optimal one for small assets.

Quick recap

To recap:

• Centralized oracles currently do work, but that may change in the future due to regulatory or other reasons
• Decentralized oracles should work indefinitely, but you may trade off speed for security for less liquid assets

Here’s how the various oracle solutions discussed fit on the trilemma triangle(?):

… But what if you didn’t need to trade speed for security in the long term?

Fallbacks

Fallbacks are a way to ensure that a protocol can still function even in the case of a centralized oracle failure. The idea is that if the centralized oracle starts misbehaving, the protocol will use a decentralized one as a fallback.

The biggest project, that I’m aware of, that has an autonomous fallback is Liquity. Liquity’s fallback kicks in and the protocol starts using tellor if:

Chainlink price has not been updated for more than 4 hours.
Chainlink response call reverts, returns an invalid price or an invalid timestamp.
The price change between two consecutive Chainlink price updates is >50%.

These conditions are rather extreme, and if the worst happens, the transition period will be painful for users of the protocol. However, it does insure that the protocol will indeed keep working.

Fallback activation

Good fallback activation is critical for any protocol that is planning to implement fallbacks. It needs to be designed in such a way that it doesn’t get activated by accident and minimizes pain during the transitional period. Getting this right is incredibly hard.

So how do you make sure your fallback doesn’t activate on accident? Who can you trust in the worst-case scenario?

Well, the right answer is no one, but it’s a bit more involved than just that. First, we have to take a look at the potential scenarios where a fallback might trigger. Let’s take a look at how a hypothetical lending protocol called “Lendify” should implement such a scheme.

Game theory of fallback activation

Let’s say the protocol implemented a fallback scheme. It would use a centralized oracle in normal circumstances and a decentralized oracle as a fallback. “Lendify” wants to make sure the fallback activates only when the centralized oracle is feeding it garbage data.

But how would it go about figuring that out? In reality, there is no good way to know this. The blockchain is an abstract space completely separate from everything else. It only knows what it’s told, and if it’s only told lies it will accept that as the truth. The best way to enforce truth on the blockchain is through economic guarantees. If the participants need to have skin in the game, in the form of money, then the system becomes much more resilient to manipulation.

Using a TWAP oracle as a sanity check

When using a centralized oracle provider and a TWAP oracle as a fallback, the reported prices of both would be compared. If they don’t match up, the system would activate the fallback when a certain threshold is reached. As we’ve established, there is no way we can be 100% sure what the right price is in such a system. But we can rely on economic guarantees.

apologies in advance for this diagram, apple numbers is the best tool I had at my disposal

If lendify decides to use a TWAP oracle as a sanity check, they would have to rely on the fact that:

• The economic cost of attacking the oracle is less than the profit,
• and that both oracles won’t get manipulated at the same time.

If both oracles get manipulated at the same time, there would be no way to fallback to a TWAP oracle. This also goes back to our first point, economic security. If the payout is less than the cost, the protocol should remain secure.

Using optimistic oracles as a sanity check

Using optimistic instead of TWAP oracles for fallback activation would be rather similar. The only difference the system needs to account for is optimistic oracle finality.

If the price between the centralized and optimistic oracles does not match, the system can enter into a state where it waits for the price of the optimistic oracle to finalize before switching to it. Depending on the implementation, this will take time, and there is a risk of a DOS, but a misleading price should never get finalized.

Occam’s razor solution to fallbacks

While it’s nice to theorize about DeFi protocols completely devoid of human input, so far they’ve proven to be very impractical. I have no doubts that one day most of DeFi will be completely autonomous, but I also think that we can’t take off the training wheels(in the form of DAOs) quite so soon.

As it’s most often the case, the simplest solution is often the best one. While it may seem like a 180 from the previous sections, using DAO governance might be the least painful solution to getting fallbacks right. Focal point game theory dictates that when multiple parties are faced with a decision with little communication between them, most will come to the same mutually beneficial solution. Things rarely happen in such a way that people can’t take precautions against potential risks that arise. Giving a DAO the power to change an oracle is a very useful, and necessary, tool to hedge against oracle risk.

But there is a caveat. As we’ve recently seen from the coinbase takeover of MakerDAOs PSM, misaligned incentives can potentially be fatal. It is critical to have non-conflicting incentives when designing governance. Going in depth requires going on a huge tangent and that’s going to require a whole post for itself.

Conclusion

In conclusion, centralized oracles such as Chainlink dominate the DeFi space and pose a risk to the overall decentralized nature of protocols that rely on them. While Chainlink’s strong brand and ease of integration make it a popular choice, its centralized nature means it is vulnerable to manipulation by both private and state actors.

While decentralized oracle solutions such as optimistic oracles and fully on-chain oracles offer an alternative, they come with their trade-offs and challenges. It is important for DeFi protocols to carefully consider the use of oracles and strive for full autonomy and sovereignty to minimize systemic risk.

To see examples of how one would attack the various oracles described here, check out part 2 (coming soon)