Oracle Infrastructure: Chainlink Proposal

Chainlink is fundamentally a trust based system as far as I understand it. To be clear, I believe that using VWAP of various exchanges is good but if those exchanges report prices directly using their exchange reporter key there is no need for the chainlink to be an intermediary. For several tokens DEX liquidity may be even greater than CEX liquidity and no chainlink nodes are needed there either.

There are fixes that we should make to the way the open price feed reports data potentially leading to an “Open Price Feed V2”. The primary current shortfall of the open price feed is the failure to incorporate volume data such that the computation of a VWAP with signed and verified data is possible.

1 Like

Exchanges signing their data is an off-chain process, but you still need an oracle mechanism to deliver this data reliably on chain. In the current open price feed design, there are no direct financal incentives to perform this as the relayers aren’t paid, while Chainlink nodes are directly incentivized to post data on-chain, even during network congestion and high gas fees.

Generating VWAP on-chain isn’t currently possible because you need to know each exchange’s volume, which would require exchanges to host another signed API endpoint. Consider the lack of exchanges who sign their price data in the first place (we’ve seem to hit wall on this front), so this doesn’t seem to be feasible in the short or medium term.

To me, it all boils down to the fact that Chainlink can provide the full market coverage we need today with minimal developmental considerations or costs. For us to develop the same level of market coverage based on upon the current design while ensuring reliable delivery is expensive, time consuming, and full of unknowns, especially given the lack of signed exchange APIs


Hi everyone, I wanted to provide an update on the progress that has been made regarding the implementation of this proposal. We have created a pull request on the Compound github
here which includes a new contract, ChainlinkPriceOracle that implements PriceOracle so that it is compatible with Comptroller's current implementation.

The pull request also provides unit tests and the steps Compound governance would need to take should this proposal be accepted by the community. This initial pull request is intended to gather feedback from the community, so we encourage anyone who is interested to take a look through the code and provide any suggestions you may have.

We have also deployed all the necessary contracts onto the Kovan testnet to test the deployment process and showcase how this integration would work in practice. We’ve included all the contract addresses in the pull request. If there is anything else the community wants to see, let us know as we are more than happy to help.

For the next steps once we get enough feedback, we’ll be creating additional integration test scenarios and simulate changes with a patch to test all the edge cases. We’ll then aim to get an independent audit of the integration and begin testing on the Ethereum mainnet for further security assurance. After all of this testing is done and reviewed by the community, we can move towards generating an on-chain proposal for the Compound community to vote upon and create test simulations of the proposal finalizing on a forked testnet.

I believe the community should also start discussing what kind of governance method they would like to have over the price feeds, as discussed before, Chainlink’s price feeds can be extremely flexible in the way they’re governed/coordinated and we will leave these discussions in the hands of the community.

Thank you to all of you for your support so far and we look forward to any feedback you have so we can move forward on all this.


Thank you, Johann, and the Chainlink team for publishing the contracts on Kovan for the community to review.

The Compound community needs to decide what to do with the admin key for each price feed. We have four options:

  1. We could set the admin to the burn address. This means we wouldn’t be able to update the contracts in any way. If we wanted to change something, it would require launching a new contract and using governance to remove the old market and add the new one.
  2. We could set the admin key to the regular Compound governance key. This would allow the community to update the contract if needed. Any change the community might want to implement would take the full length of a regular governance proposal.
  3. We could set the admin to the Compound Community Multisig that is currently used for borrow caps. If something arose and we needed to act fast, this would be much faster than the normal governance process.
  4. We could use the existing Chainlink multisig, and that exists in the current Chainlink markets.

Personally, I think using the Compound Community Multisig that is currently being used for borrow caps is a good middle solution. I haven’t brought this up with the multsig holders, so we would need to confirm they are okay with that responsibility. Otherwise, I think we should set it to the Compound governance key.

Admin Key Vote
  • Burn address
  • Compound Governance
  • Compound Community Mutlisig
  • Chainlink Multisig

0 voters


as a member of the community multisig i have to say that giving this to the community multisig is extremely too much power, if it would give the ability to change price by upgrading the contract etc.


I, also as a member of the community multisig think that this is giving too much power. However, if that is what the community wants, we can assure to be very transparent about what is happening

1 Like

Hey guys, I’m writing this post which I initially sent on the Discord governance channel as a hope that it will help answer the thoughtful questions which have been asked by the community as well as some of the possible doubts which some of you might have. We’re discussing a very key and important aspect for the protocol security here, hence I want to take the time to give as many details and information for the Compound community to be able to reach an informed decision on this topic. It’s great to be having these conversations which in my view are always a positive sum game for the DeFi space and its security.

The specification of our oracle networks is described within our documentation (e.g. Chainlink Decentralised Data Model), covering when updates occur, the contracts used, and how the network is kept decentralized. Keep in mind, the documentation describes how our mainnet price feeds currently work. This architecture was made to be fully modular for any community or DAO who would want to start running/coordinating their own Chainlink data feeds. Hence, things such as the proxy contract which allow for the network to be upgraded to the latest release of the feeds could be removed from this architecture if the Compound community doesn’t want the multisig to own this kind of power. Having an admin key on the oracle network is not strictly required, but an important consideration is that while new network contracts can be deployed, this takes time to pass governance so having this capability of upgradability can be a large advantage. For instance, if the Compound community wanted to scale up the number of nodes on a feed for a market which grew in value, they would have to redeploy a new contract with more node operators and then pass an on-chain governance vote to point to this newly deployed contract. The process could create delays which could result in unintended consequences.

The role of the multisig admin key is essentially the one of a group of coordinators. Oracle networks are inherently complex as they combine multiple non-deterministic off-chain data points. Unplanned events can and do happen (huge gas spikes, issues with data sources, etc…) In these situations, the coordinators can efficiently prevent these events from adversely affecting the network through the necessary changes. These coordinators would also be able to add/remove nodes, for instance as the value on Compound grows, it can add more and more reputable entities with a proven on-chain performance history to the set of oracles powering the price feed, scaling up the network’s security. Again, this is not a requirement, price feeds can and will work without a multisig, however it’s just about assessing the risks you’re willing to take here. Both approaches do bring about their own set of challenges. This is all about incentives in the end, right now, the assumption is that the multisig owners for Compound would have way too much at stake in the system (COMP token exposure) for them to be malicious here. As Wayne mentioned on Discord, an attack by them would likely not result in any net benefits for them and would destroy both the implicit stake they have in the system as well as their reputation. This is an important point to consider in regards to the likelihood of such adversarial admin key usages. However, as mentioned before, the multisig is not a requirement and the Compound community can go with whichever approach that is preferred based on the security assumptions and trust model that is desired.

The requirement for nodes to post price data on-chain is based upon the economic incentives of being a Chainlink node in both the short term and the long term. In the short term, nodes who fail to post prices would not get paid and would eventually get removed from the price feed for their non-activity (either by the multisig coordinators or the deployment of a new price feed to replace the previous). Medium to long term the nodes would harm their reputation as a service provider in both the Chainlink network and any other external services they provide (nodes on mainnet include traditional enterprises like Deutsche Telekom’s T-Systems and premium data providers like Kaiko). I think it’s important to emphasize this point can also be seen in the current Open Oracle design as it’s a trust based assumption regarding Coinbase: e.g Coinbase has an incentive to not act maliciously or carelessly as this would affect their main business. This trust dynamic based on reputation and revenue is the same for the Chainlink nodes, e.g. why would Deutsche Telekom’s T Systems act maliciously in a way that could adversely impact their company which generates $100B+ billion in revenue a year? However with the system we’re proposing, we’re counting on many different independent parties in different industries, distributed geographically across many different jurisdictions and with a plethora of different business models. Hence, the risk here is very distributed which makes an overall takedown of the network far less likely than relying on one single category of providers.

Additionally, the loss of reputation would result in the opportunity cost of losing all future revenue in the Chainlink Network (nobody would choose to include or keep an unreliable node in their feeds), representing a strong financial incentive to continue publishing prices to capture this growing revenue. Historically, looking at the performance of Chainlink node operators over the past two years, the financial incentive structure has worked as designed with nodes publishing on-chain updates even during extreme network congestion (1,500 gwei) and downtime events like when Infura went offline. This historical on-chain data can be reviewed on independent analytic services like Chainlink Market and, which can be used to determine which nodes have the strongest economic incentive to continue their services into the future as well as monitor the current performance of selected nodes in all price feed networks they participate in.

Chainlink price feeds also support historical circuit breakers to prevent the consumption of any potential outlier data points by comparing a new price update to previous updates, without the downsides of DEX based TWAPs which can become inaccurate during market volatility due to the time delay. A circuit breaker isn’t a requirement but it can provide an additional safety net if it is a desired feature. Our main worry right now around DEX based circuit breakers which we would like to make clear is that in the case of a flash crash, a TWAP would be an extremely lagging indicator, meaning it would give an outdated stale price point, preventing people from liquidating collateral on time. Hence, if a token falls 50% in 30 minutes, liquidators won’t be able to liquidate positions in time as the TWAP will show a huge deviation with the primary price feed, causing a false positive to occur. This could result in the whole platform becoming under collateralized. So, I would advise to be very careful about circuit breakers and if you decide to use one here. I am happy to discuss this further as I understand there’s nuances at play here when upgrading a critical component of Compound’s infrastructure, but I wanted to provide some additional clarity on where we are coming from.

Ultimately, I want to make it clear that our attention is and always has been to offer these Chainlink price feeds and oracle networks as a neutral technology that communities such as Compound can shape and build around your needs however you feel like it. Compound could go with a multisig or without, similarly you could go with a circuit breaker or without, this is entirely up to you and the community, depending what risk assumptions are willing to be taken.

Our goal here is to provide our experience and expertise as a project that has been working exclusively on oracles with developers and researchers for 4 years, to create the most modular, redundantly secured technology for DeFi to grow and succeed. Hence, we want to advise and share our experience and what we think is the best approach for Compound. However, this is all in the hands of the community and we will assist you in whichever path you deem is best for your protocol. Everyone on this forum has a stake in making sure Compound grows to a trillion dollar protocol and beyond, not only for the sake of the community but for the whole of the DeFi space and the creation of a new more inclusive and economically fair financial system. We’re here to assist you in this path and adventure in making this a reality and hope our contribution can be the establishment of a fully fledged and secure price feed system which will allow the Compound community to achieve its ultimate vision as a money market protocol.


I think giving admin key powers to the community multisig makes the most sense here. It provides the most amount of flexibility. After a Chainlink integration is complete, we can monitor if the selected nodes are performing as expected and change them out if needed. At a later point in time, we can reconvene to see if this setup should change and switch admin key powers over to Compound Governance, which is slower to react but still has the ability to change oracle network attributes. I don’t think we should remove the admin key altogether as I believe it is better to have it and not need it, rather than to need it and not have it. Open to what others have to think as well.

I appreciate you posting this info Johann, provides a lot of insight into Chainlink’s current architecture and design rationale. I think an integration with Chainlink would greatly increase the security of the Compound protocol all around. I simply see a lot of flaws with the current oracle used by Compound as it relies on just Coinbase for data as well as the other proposed Medianizer design as it cannot provide market coverage and dilutes high quality data with low quality data. I would like to see Compound to grow into a multi trillion dollar protocol and to do so, it needs a good oracle solution.


How about allowing the community multisig the ability to invalidate the reporter, and that’s it.


@TennisBowling Would love your input

Would it also also be possible to have the admin keys default to Compound Governance to vote on regular operation (selection of feeds/scale up number of nodes) and have backup keys held by by the Community Multisig incase emergency intervention is needed?

Also, I think the community via governance vote would be needed to set ground rules for the use of the admin key in any case it’s given to the Compound Community Multisig members.


This wouldn’t help because, in an emergency, the mutlisig would also need to deploy a fix.

So revert back to coinbase pro. A multisig could then steal the system. It’s too much power.

Reverting to Coinbase won’t work if the coin isn’t on there.

Maybe we could add an emergency function that the multisig could call that would revert to using Chainlink’s main oracles that Aave and others use. That way the multisig can’t update the contracts to something unexpected.


I’m glad to see others voicing their support in adding Chainlink to the Compound protocol, I think it’s the right long term move. In regards to multisig, it looks like most people are leaning towards either the community multisig or the governance contract. If the former gets chosen by the community as the desired solution, I’d like to voice my interest in becoming one of the signers to help improve the multisig’s decentralization and therefore price feed security. For context, I was a pre-seed investor in Compound in November 2017. If I am added to the Compound community multisig, I will faithfully relay the community’s sentiments in my contributing transactions within the multisig process.


That’s a great point. When we add more assets that will be a problem. Maybe our internal oracle infrastructure will have some competition.

1 Like

Hi all,
Katherine here from, an independent analytical service to Chainlink. We’re thrilled by the proposed integration, and we can assist by providing insights into the security and reliability offerings of the Chainlink network. We’re here to provide that additional context to the Compound community about Chainlink as a solution - to help you understand the value of secure feeds.

We understand that there is so much value being secured by some of these data feeds, so it is important for you to do due diligence and really assess the price feeds and individual oracles that are supporting those feeds to ensure that you’re comfortable and willing to proceed with the integration.

As Johann mentioned, Chainlink has deployed all the necessary contracts onto the Kovan testnet to test the deployment process. Once the feeds are up on Ethereum mainnet, you will be able to visualise them on For example, check out the ETH/USD feed that is utilised by Synthetix and several other protocols. You can visualise how many (and which) oracles are securing that individual feed, and if there have been any deviations or failures on that feed. You can view round specific information, such as the price returned by each oracle on the feed, and if the returned prices deviated from the aggregated price. This provides the Compound community insights to understand the security guarantees of the data provided by the Chainlink network.

Johann touched upon the performance of Chainlink nodes during downtime events like when Infura went offline. During this outage, the Chainlink network and its node operators showed incredible resilience. For those interested, we provided an autopsy of the event here.

Depending on what your community decides to do with the admin key for each price feed, you’re absolutely right in assuming you can utilise, to conduct due diligence on all of the verified Chainlink nodes, and hand pick specific nodes that meet your use case. Our homepage provides a list of the top ten best performing oracles. Explore the individual profiles of each Chainlink oracle and evaluate their reliability through visualising their on-chain performance (such as their average latency when responding to requests).

Our goal is to provide a premium experience for you to do your research on the quality of node operators for your integration. We can provide any insight you’d like to derive from the Chainlink network. We’re happy to assist in any way, to help ease the integration.


Update: 3/31/2021

After a lot of community feedback and debate, a number of changes have been made to the proposal since I first posted it.

  1. Compound Governance is going to be the admin on the contracts. That gives the community the ability to add/remove reporters for each market. Governance will also be the admin on the main oracle contract that controls which markets to support.

  2. An emergency function will exist for each market that the Compound Community Multisig controls. In the unlikely event that something happens with one of the oracle contracts that requires immediate intervention, the emergency function will switch the price feed to the Chainlink v2 contracts that are widely used in DeFi.

  3. After a lot of debate and we’re going to continue using Uniswap v2 as an anchor. Once v3 launches, we’ll upgrade the contracts for v3 and send it to governance for approval.

The plan is to publish the revised contracts on testnet in the coming weeks for the community to review. Once feedback has been implemented, we’ll send the contracts for audit. After the audit, we’ll move towards governance.

High level: The oracles that Aave, Sythentix, and others use are Chainlink v2. Those have an admin multisig that Chainlink and other stakeholders control. The system we’re developing is purpose-built for Compound. The community controls admin permissions, emergency functionality, anchor specifications, reporters per-market, and who the reporters are. We are essentially swapping Open Oracle/Coinbase for a community-designed version of Chainlink and maintaining the Uniswap anchor.


Thanks for the update @getty. Excited to see all of these efforts coming to fruition!


I think this is a good way to do it, nice progress.