Fix the Compound oracle problem

The so called “DAI liquidation event” has shown, that the open oracle, which is used by Compound, has weaknesses. The root cause is, that the oracle uses only one price source, which is Coinbase. The effect is, that the Coinbase prices are used in Compound, even if they deviate largely from the rest of the market. The Uniswap price is used to define a +/- 20% bounding, but as seen, this doesn’t solve the problem.

Imo the only stable solution is, to use several price sources and calculate an average over these sources. Chainlink does exactly this and is used successfully by Synthetix, Aave and others. In the case of DAI/USD chainlink uses 7 price sources, as you can see here.

If Chainlink would have been used as the Compound price source for DAI, the averaged price would have been 1.068, if one price source would have delivered 1.3 like Coinbase and the 6 other sources 1.03, which was the price outside of Coinbase. Any large deviations by some sources are just ironed out.

Beside the above mentioned benefit, using Chainlink would also solve two other disadvantages of the open oracle:

  1. When adding new markets to Compound you are not limited to the coins which are offered by the Coinbase API. Chainlink offers prices for a much large range of coins.
  2. You are no longer dependent on volunteers to post the current prices to the blockchain, which leads to outdated prices. With Chainlink prices are updated regularly automatically.

If you want to read more details about Chainlink, check this posting of @ChainLinkGod.

Any reasons, why Chainlink shouldn’t be used?


Averaging over low-liquidity sources is not a security improvement. Furthermore, Chainlink’s oracle design is not good as it has unnecessary layers of obfuscation. Compound’s Open Oracle is much better, and while I agree the current view would be improved by adding other sources to medianize from, this is not the issue that caused the liquidation event so it does not address the problem and is only a distraction. More here DAI Market Risk

1 Like

You sound like a real oracle expert. Could you please explain in more depth, why you think, that the open oracle is a much better design?

It is a better design because it is simple and transparent, exchanges sign the price feeds, liquidators are incentivized to post on-chain, and medianizing from high-liquidity sources is the way to add other high liquidity markets. Chainlink is a bad oracle design because the company is incentivized to obfuscate the problem and in doing so adds other layers (aggregators, link nodes) that increase attack surface.

That’s interesting. Do you know of any successful attack on Chainlink oracles?

There have already been issues with the unnecessary layers that Chainlink adds, as ocurred with the 6-hour downtime in ETH prices back in March

The reason other money markets that use chainlink may have not had a market manipulation attack is because none of them have debts that exceed market liquidity by such vast amounts. If they ever grow to a point equivalent to the current Compound outstading DAI debt in relation to market liquidity, they will face the same market manipulation risks, and other new risks that relate to the unnecessary layers mentioned above.

Okay, thanks. The linked article doesn’t report an attack but an issue caused by high gas prices. I think, this is a weak point of any oracle, not only Chainlink.

1 Like

I don’t think so, as in the Compound oracle design it is liquidators that are naturally incentivized to pay the (high) gas fees. One of the problems with adding the unnecessary layers that Chainlink does is precisely that incentives are not as clearly and directly aligned.

Chainlink does not take a simple average over exchanges. As I describe in this post, Chainlink oracles fetch data from multiple data aggregators who each provide full market coverage by aggregating from all trading environments (CEXs + DEXs), taking into account volume, liquidity, and time differences between exchanges. Pulling data directly from exchanges and taking a median is not a good way to design an oracle because you’re not taking into account volume shifts across exchanges or new exchanges appearing and capturing a significant amount of the volume. Market coverage is a very nuanced topic and there is a reason why Chainlink doesn’t attempt to create a data quality product and instead focused on the data delivery mechanism. I describe more on the topic of market coverage in this response thread to Hayden from Uniswap.

This is simply not true and a bit disingenuous. Chainlink simply wants to provide the DeFi ecosystem with the most secure price oracle solution with the highest quality data and this involves pulling from data aggregators who have full time monitoring teams to ensure manipulation is prevented 24/7. Taking a simple median from a select few exchanges is simply not an adequate oracle solution as it will always be vulnerable to market coverage issues and manipulation attacks around volume shifts and consolidations. As I described in the post linked above, the three layers of aggregation (data level, node level, network level) prevents any single source of truth. Relying on a single source of true is what played a significant factor in the $100M false liquidations of Compound users, and at the very least made the attack much easier and cheaper to pull off.

All decentralized oracles (including Maker and others) went down that day because of extreme Ethereum network congestion that had never happened at that level before. Since then, the transaction manager in Chainlink nodes have been completely revamped to prevent such network congestion issues. When DeFi summer hit and gas prices spiked to 500+ gwei, Chainlink price feeds continued to operate without issue and all applications (Aave and Synthetix included) received accurate data in a timely manner. Pointing to Black Thursday at this point is a bit like pointing to the Shanghai DOS attacks and saying Ethereum isn’t reliable because of it. It was indeed an issue, but it was fixed and made the network stronger against such attacks/issues into the future.

I think you’re missing the key point of market coverage. The issue with Compound’s oracle during this DAI manipulation attack was that it did not report the true market wide price. If an attacker manipulates the entire market (across every single exchange), then yes all oracles would be affected at that point, but that’s only because the true market wide price was changed, but that’s not what happened during this event, only a single exchange (Coinbase) was manipulated. That’s the nuance here, market coverage raises the cost of attack to highest degree possible, and while it doesn’t prevent market manipulation altogether, but does make it as expensive as possible and ensures protocols always receive the true market wide price.

These are not “unnecessary layers” but layers of redundancy to ensure smart contracts always receive price data that reflects the true market wide price and not that of a single or a few exchanges. As I described in my proposal, Chainlink is directly secured by cryptoeconomics through an opportunity cost of losing future income if a node is malicious, as well as losing their reputation as an DevOps infrastructure provider. This is why we have never seen a successful attack against the Chainlink network, because the incentives work and ensure correct data is always posted on-chain.

I hope you and the rest of the Compound governance community reconsider, because if the Compound oracle and its lack of market coverage is not fixed, then oracle issues will continue to appear and will be a waste of time, money, and mental energy to fix every time it happens. Adding more exchanges to the Open Oracle will not solve the problem, because it still won’t provide adequate market coverage for a protocol securing $3B in user deposits. Compound needs the market wide price, just as Aave receives today. This is not a Chainlink shill, this is coming from a DeFi user who does not want to see Compound get exploited due to the lack of market coverage in its oracle. Oracle security is nuanced topic and I’m happy to discuss further.