Building a medianizer

Compound NEEDS to improve the current oracle infrastructure as a matter of safety and growth. I think it is evident to users that the current solution is not ideal and not close to ideal. The event that occurred in November with Dai liquidations was preventable. Little has been done to prevent the situation from happening again with Dai or any other markets. In addition to preventing the November event from transpiring again, I think it is also in the protocol’s best interest to improve the oracle situation so Compound can safely support more assets.

Based on the conversation that has been had on the forum and Discord, the community is uncertain what the next steps are to improving the situation. I have seen discussion of adding Chainlink as an oracle provider, Makerdao’s oracle, additional exchanges, and decentralized exchanges as price feeds. There is no consensus on what is to be trusted.

While I am confident in using Compound and store assets on the platform, I think the protocol would greatly benefit from investing in better oracle infrastructure in the long-run. While the Open Price Feed built by the Compound team does a good job getting prices from exchanges onto the blockchain, it has no logic to average the prices or weight them by significance. We are fortunate enough to have many high-quality exchanges, both on and off-chain, that we should be utilizing.

I think the best next step is to build a medianizer (following Makerdao’s lead) that can handle multiple price feeds. To make the task less daunting, I suggest the first implementation tries to utilize Coinbase Pro, Okex, and Uniswap prices. The medianzier will need to consider when the last price of each of these sources is made so that it omits stale prices. The solution should also allow more price feeds to be added on at a later date.

Unfortunately, I lack the skills (learning) necessary to build this idea, but the community will likely reward who is ever successful if someone/group were to build it. Although I lack the technical skills, I know a good amount about incentives, liquidations, and exchanges, and I am willing to lend a hand in any way I can to make this improvement happen. I will also send personally $5k of COMP token to whoever successfully implements this, and if you are unsuccessful but can get to a full proposal, I will send $1k of COMP.

All questions, comments, and concerns are welcomed and encouraged. If you are an individual who is interested in building this and are unsure if the protocol will compensate and how much they might compensate you, please post those questions here and DM me if you want more certainty. While I am just 1 person and sub 200 votes, I would strongly advocate for a 1000 COMP ($220k) grant to whoever implements this successfully by building and implementing a long-lasting solution.


Increasing the number of price references is also important, but it is not a measure against instantaneous spikes and drops.

Can’t Compound add a time lag before liquidation?


I am not sure I understand your point. Are you saying that the protocol should have more sources to get price info from? If so, that is part of the plan here. We need first to build the system to handle multiple sources, but we can add more sources once we have that.

1 Like

Adding some additional thoughts about how to structure this:

I think there are two routes to building this medianizer.

  1. Modify the Open Price Feed to become just a tool to get prices from exchanges and post those prices to a separate contract that is the medianizer.

  2. Modify the Open Price Feed to have a medianizer built-in and modify the medianizer to accept onchain prices.

There very well could be a better third option. If you have a different idea please feel free to share it.

1 Like

To recap the proposal, are you suggesting that instead of arguing about which price source to switch to, we’d first build the infrastructure that would allow us to add new price sources to be medianized, and then worry about which price source (Maker, Chainlink, …) should be added?

1 Like

Correct, we need to first build the infrastructure to support more price sources and then we can talk about adding many more.

I definitely appreciate you stepping up @getty and taking initiative here, putting your own COMP on the line no less!

That said, this seems like a lot of development time, effort, and complication that could be avoided by using Chainlink, which we know will vastly improve the oracle situation with minimal development consideration or risk to the protocol.

Again, I applaud you taking initiative on this much-needed oracle improvement and think this is a step in the right direction, however I’m not convinced the juice is worth the squeeze when there are better/simpler solutions available.


I have looked into this.

In order to remain truly decentralized I believe we can fetch plenty of source on chain.
For example I can fetch prices from the chain all day for free by using read-only calls to many DEX. We can fetch many of them at no cost and implement the appropriate correlation

Why not let the community decide what source (on chain) they consider trustworthy and which correlation factor they consider safe. Best example was the Dai case. A value that high above average source at the time and over time should have been correlated as a rejected value. Especially for Dai. I’m not expecting it to change that much so it should have a low factor.

The sources can be updated over time if one becomes untrusted by the community. Or new feeds are born and approved.

This would cover the reading part at no cost.

Now as for state changing calls to record the prices. I would rather have a Comp incentive to do so for the Compound Protocol and by the community. This is, in my opinion the best way to achieve a long term solution that rely on a common decision.

This would also turn Compound into a real decent community maintained price feed.

1 Like

I think this is the right approach. We know the current oracle system is not the protocol’s ideal state. Having the ability to modularly add new oracle sources is a step in the right direction.

It’d be great if we get feedback from protocol devs on feasibility and cost/benefit.


Well I know this is something I can do. It’s just a matter of integration to the protocol and community response.


I think using any one source is not the right decision. As well, I am certain governance would not vote in favor of switching to Chainlink. That being said, I do think we could use Chainlink as part of the medianizer (I don’t know how this would work), and the community would be more likely to use Chainlink if it was part of a larger system.

I like the medianizer idea a bit more because it is less complex and already proven to be safe, but I think this idea is positive. If you were to build this and out and implement this successfully, I would be thrilled to reward you for it.

Chainlink is not really one source, as the price is calculated as an average from several sources. For example, the DAI/USD price is delivered by 7 different sources (DAI/USD). Why not use a ready and proven solution instead of building a new one?

Why would “governance” not vote for switching to Chainlink? It would be nice to hear the arguments of the guys with the largest voting power. This time BEFORE the proposal is created.


the question is why WOULD you use chainlink? you need to pay link and trust on top. chainlink is quite susceptible to human error. we could just add more price feeds to the open oracle.

I don’t think you have to pay LINK, if you use the oracle prices.

What exactly do you mean by this?

1 Like

There is a litany of reasons listed in this thread. However it boils down to the fact that Chainlink provides an immediate and comprehensive oracle solution that doesn’t require all this time and development, which could present unnecessary complications/risk within the protocol.

Just pulling from a few more exchanges will not provide adequate market coverage, and you don’t have to trust any single entity but a decentralized network of Chainlink nodes.

Regardless, I definitely agree with @cryptix in that it would be nice to hear an argument from those with the largest voting power.


Reposting my thoughts from Discord:

It seems like there is not only a critical flaw in the system (the false liquidation attack vector is still open) but that this same flaw is also hamstringing developments and improvements to the protocol. To me it seems like fixing both of these (and addressing victims of the previous attack) should be priority number 1. If the push is coming from Coinbase as investors then they are shooting themselves (and every other COMP holder) in the foot here. Let me know if I’m missing something though.

For clarification it seems to me that this breaks down to 2 issues which would both be solved with a different oracle mechanism (third party or custom built). The false liquidation attack vector and the hard coupling to a single centralized entity bottlenecking development.


Hi guys. Want to jump in quickly. I do think having medianizer will help with security significantly, both by adding more data sources and reducing systematic risk from relying on a small number of tech infrastructures. I’m happy to take on the work to implement the code and go through audit to make this happen.

Also, Band Protocol has open oracle implementation already live and we are excited to join as a reporter if the community agrees to it :slight_smile:


I’m a fan of Chainlink and I think it should be included as one of the sources. Though, having a single oracle categorically exposes the protocol to single point of failure risk – no matter how many feeds are aggregated into Chainlink, there’s still only a single feed that reaches Compound. This recent issue would be addressed but the oracle problem as a whole will remain. It’s important that we take a wholesome approach in addressing the oracle issue, not just a reaction to the events during the Thanksgiving week.

That’s why I think Getty’s proposal is the right approach: this proposal allows the protocol to have multiple sources of oracles and that is much needed.


This! We could implement chainlink into the open oracle/medianizer and also add more dex/cex then we could be well off.


While multiple oracles may sound like a good idea, mixing high quality and low quality data is like mixing wine and vinegar…it just ends up worse.

Let’s say we mixed 1) Chainlink, whose nodes source from an array of premium data providers who take volume/liquidity into account 2) an oracle that fetches prices from a preselected array of exchange APIs, and 3) a single data source or exchange API.

It’s not hard to imagine a highly volatile scenario where Chainlink is reporting a volume-adjusted market-wide price of $500, the pre-selected exchange array is reporting $400 due it covering only small percent of total market volume, and the single source reporting a price of $0 due an outage caused by the volatility. This scenario would result in a median of $400, or even worse…a mean of $300.

Again, I see how it sounds like a good idea on the surface, but mixing sources of various quality, calculation methods etc. is not ideal and can threaten the integrity of the overall system.