Oracle Infrastructure: Chainlink Proposal

Ideas
43

I love seeing all this progress being made! This is looking really good for the Compound protocol.

3 Likes
44

Thank you for update and transparency on this proposal’s progress

3 Likes
45

I hope the proposal can be realized soon

3 Likes
46

I really love this approach. Great progress and excited to see this come to fruition.

2 Likes
47

Awesome effort getty! Will definitely get behind this once it’s put to vote

3 Likes
48

Thanks for all of your hard work on this @getty!

I am convinced that an upgrade is necessary and I haven’t seen any preferable alternative.

Signaling my support and I will encourage the rest of StanfordCrypto to support it as well.

4 Likes
49

Polychain is largely supportive of this proposal as a short-term solution.

We definitely echo some concerns about Chainlink: It’s effectively a semi-trusted system that has been very slow at taking steps to enhance cryptoeconomic security (still no staking, random shuffling of nodes, few integrations of primary data sources). Generally, we don’t find this model to be aligned with COMPs values… However, a semi-trusted oracle that works is better than a decentralized oracle with insufficient guarantees. Additionally, the fact that the COMP community will be able to select reporters and will have control over the admin multisig is a reasonable tradeoff. We should treat these reporters as trusted parties, and, of course, should prioritize selecting reporters who are aligned with the Compound Protocol.

Overall, we still think the medianizer route is the optimal solution, but building out the Compound community’s version of Chainlink is a step in the right direction, as this will then enable Chainlink to be safely used in a medianizer built by the COMP community (along with centralized exchange data (signed off-chain) & eventually price data from liquid DEXs).

Big thanks to @getty for taking the lead on this.

6 Likes
50

First, want to thank @getty for the hard work he’s put in to research.

Historically, Chainlink was rejected by the Compound Labs team for the following reasons:

  1. Smart contract risk surface
  2. Manual administration (risk of error)
  3. Reliance on third-parties to post prices (with no guarantees that they would be posted accurately, or at all)

In its current form, the suggested approach is a security risk to the protocol, and I will be voting against it.

Simply put, the “core” Chainlink is safer than an offshoot.

  1. Creating an offshoot introduces new contracts / risks
  2. The manual administration is shifted from a dedicated organization, to a decentralized one. Compound governance moves slowly, and is poorly equipped to be rotating reporters, whether through a 7-day governance process, or a multi-sig. This idea is madness.

The risks of Chainlink can be offset in other ways; including it as part of a median, or anchoring it to Uniswap or the current system. Carefully designed, this can abate the risk of prices not being posted, or posted incorrectly.

6 Likes
51

If you read both of the LINK whitepapers you will know that every argument you mentioned above has been debunked. Instead you pretend. Compound is deliberately undercutting their systems to extract rent of it using flashbots among other means. They don’t want to integrate chainlink because it means honesty and they can’t profit from that.

This is the critical moment in time to decide whether trust wins or not, and people like Leshner are a roadblock.

52

After discussing the proposal with Robert, we have come up with an adjusted plan that he, Polychain, and blck will support.

The high-level idea is:

  1. We are going to use the main Chainlink oracles instead of building our own.

  2. The Uniswap anchor will be tightened to 15%. (I am going to do some research, but 15% is what we’re going with as of now)

  3. USDC and USDT are going to be continued to be pegged at 1. If someone wants to use USDT as collateral in the future, they will need to add an oracle.

  4. If a Chainlink price is outside of the anchor, it will not update. We will add an additional feature that will allow the community multisig to choose to use the Uniswap price.

The Chainlink team will get started on this change, and I’ll follow up with more details and docs as we have them.

Overall I think this is good news, and I am excited about the progress.

8 Likes
53

Thanks for the update @getty. I’m pleased to hear we are honing in on an oracle implementation that has broad community support. FWIW I tend to agree with Robert in that Compound governance’s 7-day process is not ideally suited to manage reporters, and going with a “core” solution is the safer bet.

Looking forward to the next update!

4 Likes
54

@getty I’m very excited to hear this! Thanks for the hard work everyone. :slight_smile:

Please let me know how I can help with this.

1 Like
55

Hey everyone, this post is a follow up on the recent developer call we had describing the proposal to switch the current oracle mechanism to Chainlink price feeds combined with a Uniswap anchor acting as a safety net.

This proposal is based on the feedback of Compound community members. Today, I want to describe the implementation we put in place and ensure everyone understands the workflow this new oracle system will have if voted in. The last part of this post will also contain links to testing contracts we’ve deployed on mainnet.

Current Mechanism

First off, I would like to give a quick description of the current system so we all have shared context. The UniswapAnchoredView (UAV) is currently configured with multiple markets, each containing the name, cToken, underlying token, Uniswap V2 pool data and conversion data. Prices are posted to it via a configured reporter. If it is believed that the reporter account has been compromised (private keys stolen, etc.), there is a function called invalidateReporter(), which can be called by the reporter which permanently switches over to the Uniswap V2 TWAP prices.

Signed prices are posted to the UniswapAnchoredView regularly, by the reporter. During this transaction, the following steps occur:

  • Signatures are verified
  • For each posted price:
    • Update the Uniswap V2 TWAP window if due
    • Update the anchor price
      • If posted price is within threshold of anchor price: store the posted price
      • Else, if posted price is outside of the threshold: store the anchor price

New Community Proposal

UniswapAnchoredView Modifications

The community indicated their desire to switch over to Chainlink production price feeds in place of the current reporter. They also indicated a desire to keep a Uniswap Anchor as a safety net to remain in place. Hence, our current proposal modifies the existing architecture whilst maintaining the same anchor mechanism. This architecture is very much optimized to give compound users low gas costs.

The key differences are:

  • Prices will now be pushed from production aggregators, each responsible for a single asset. They call the validate() function, which replaces the postPrices() function. This change is so that the UAV conforms to the AggregatorValidatorInterface , which production aggregators are compatible with.
  • The Compound community multisig will be able to failover single markets, on a per-market basis. In this scenario (as in the current architecture) the Uniswap V2 TWAP price is used as the failover. Function: activateFailover(bytes32 symbolHash)
  • The community can also reverse this failover. Function: deactivateFailover(bytes32 symbolHash)

Price Feeds

Usually, contracts that consume price feeds read the data from an AggregatorProxy contract, which itself reads the price from an underlying OffchainAggregator contract. This proxy pattern is used so that the underlying aggregator can be upgraded without disruption of service for contracts that consume prices from the proxy. More information on this model in the docs: https://docs.chain.link/docs/architecture-decentralized-model/#contracts-overview

UniswapAnchoredView's anchor mechanism relies on prices being pushed to it, not read, so reading from aggregator contracts (as shown in our initial proposal: https://github.com/compound-finance/compound-protocol/pull/105) is not feasible. However, OffchainAggregator contracts enable a validator to be set. Every price transmission that the aggregator receives from nodes is passed to the validator via the validate() function. This is the entry point for the modified UAV. Upon deployment, production aggregators will have their validator set to point to the UAV.

Adding new markets

Given how UniswapAnchoredView is written, any changes (like adding a new market) requires a fresh deployment with a new configuration, which then goes through governance to be set as the oracle in the Comptroller.

An example: If the community deploys a new UAV, the OffchainAggregator of each asset would need to have its validator changed to push prices to the new UAV. Changing the validator would mean that the old UAV no longer receives prices from the aggregator. A transition period exists where both UAVs need to have prices pushed to them so that:

  • Service is not disrupted on the existing UAV.
  • The new UAV can be tested and have its prices verified on-chain before being accepted by governance.

To solve this challenge, we have created the ValidatorProxy contract to sit in between each OffchainAggregator and the UniswapAnchoredView . For the most part, this contract just forwards validate() calls from the aggregator to the UAV. However, It also supports a “proposed” validator (a second UAV), which it also pushes prices to when it is set.

Simple Architecture

This image describes 4 asset prices being pushed to the UniswapAnchoredView. It does not include the anchor mechanism that is performed during the validate() call on the UAV.

Screenshot 2021-05-07 at 12.03.52
Screenshot 2021-05-07 at 12.03.52860×1144 145 KB

Uniswap Anchor Flow

This anchor mechanism has not changed in our proposal. Here is a flowchart (might need to zoom in on this one) representation of the BAT/USD price being posted to it via the validate() function:

UAV_Validate2x_(2)
UAV_Validate2x_(2)2488×5536 738 KB

Mainnet Tests

To test the modifications to the UAV and the overall architecture, we deployed the contracts to mainnet and tested them using a node network providing prices for the UNI/USD market over the course of roughly 2 days. Here are the addresses:

Code

UniswapAnchoredView

Chainlink has forked the Compound open-oracle repo to make the proposed changes to the UniswapAnchoredView. This PR is being used for internal reviews and can be seen here: https://github.com/smartcontractkit/open-oracle/pull/1.

Once this has been audited in the coming few days, Chainlink will open a pull request from our fork to the Compound open-oracle repo.

ValidatorProxy

Initial PR: https://github.com/smartcontractkit/chainlink/pull/4265

Second PR: https://github.com/smartcontractkit/chainlink/pull/4301

Aggregators

Chainlink aggregator code can be found in the libocr repo: https://github.com/smartcontractkit/libocr

Conclusion

This should be it with all the details for this proposal, if you have any questions please reach out here, I’ll be happy to answer it. We’re looking forward for a long term collaboration with the Compound community and making sure we can help build out the best oracle system available for Compound to keep being a leader in the money market space through the use of secure and accurate oracles. As Uniswap v3 gains momentum we will be looking to work with the community in upgrading to its oracles as a new safety net mechanism and have already started coordinating this process with their team.

9 Likes
56

Thanks to @Johann_Eid for writing this up, and to everyone for the hard work that’s gone into the proposal thus far. The amount of effort that’s gone into it is impressive, and makes me very optimistic about this collaboration.

The price oracle is hugely important to the protocol, which makes it one of the most difficult pieces to change, especially in terms of convincing governance that its safe and correct. Personally, I see the value that switching to Chainlink could provide to the protocol, but its important we uphold a level of scrutiny for any changes being made. After discussing with some colleagues, I would like to voice a few remaining questions/concerns from Compound Labs about the current architecture.

The first question is about the set of aggregators and the redundancy of the price posting. How will the set of aggregators be managed? It seems we would need to deploy a new UniswapAnchoredView each time, and have some knowledge of the validator set of Chainlink. What would be the process for choosing these validators, getting their addresses, and keeping the list updated? This could be a huge burden on governance, which it isn’t really designed to be able to handle, and probably couldn’t do well. We think a solution here could be to use the shared Chainlink on-chain price feed, and the UniswapAnchoredView contract could be poked to read updates from it.

The second question is around adding new markets. The main concern is that the proposed process for adding assets might also be too difficult to manage. Governance would now need to get all the individual validators to add the new asset first, and a new view is deployed with a transition period? The proxy does avoid the need to update the oracle in the Comptroller, but adds gas costs to every transaction utilizing a price. It’s worth nothing that the protocol actually used to use a proxy, prior to Open Oracle. If the protocol were to use the existing Chainlink feed however, this might also be less of a problem?

If we don’t have a clear understanding and agreement about how these things will be managed, I would worry that governance would likely reject the current proposal. Since we don’t want to see any wasted effort, it would be great to make sure this is architected around processes that governance can manage and will accept immediately.

It’s exciting to see the progress here, and I have faith in our ability to resolve these remaining open questions effectively :raised_hands:.

5 Likes
57

Thank you for that feedback.

Great question, this was part of the talks we had between the community. At first, the idea was to have governance or the community multisig manage this directly and select specific validators. As you’re pointing out here, this process could have been quite cumbersome and time consuming for the governance process. We found that the best way forward would be to utilize the existing Chainlink price feeds that a lot of protocols are already relying on like Aave, Synthetix, and others. These feeds already have a process in place to manage the selection of oracle nodes and data providers for each price feed. Since it’s the core focus of Chainlink Labs and they’ve been doing it for years, the process is very robust and thorough so I believe it will be good to lean on their experience here.

Whenever a new market needs to be added, it will be up to the proposer to create a new Uniswap Anchor View contract. The UAV would just need to point to the ValidatorProxy address for the price feed we need. The protocol already needs to launch a new Uniswap Anchor View in the current system anytime a new asset is added so it would be quite similar to what we have today.

To add a new asset to the system I believe we will have to follow the following steps

  1. Community Proposal: the proposer should start a forum post where they outline why a coin should be added to the protocol, define the protocol parameters of the asset, and gather sufficient interest in the proposal.
  2. Price Feed: once it is clear the community wants to list the asset, a price feed can be launched. Based on the assets Chainlink currently supports (https://data.chain.link/) I believe most assets we vote in will already have a corresponding price feed already live. Otherwise, the Chainlink network can easily deploy a new one like it’s been doing with its current users before us.
  3. Launch: The proposer will be responsible for launching a new Uniswap Anchor View. Adding an asset to the protocol will be a one-vote process where the new ctoken is added, and the Uniswap Anchor View contract is updated.

This process will need some fine tuning and like everything new will require some learning and adaptation, but the protocol will have the ability to list more assets instead of waiting on Coinbase for support and hoping that the volume there is good enough for us to get it listed.

Based on the community discussions I have had, this proposal has enough support for it to pass. I think we should see this as a first step towards improving the oracle system which I aim to improve and make the oracle system more reliable and easy to use. With the launch of Uniswap v3 the Chainlink guys have already discussed their willingness to work with us in adding it as a circuit breaker and proposing some new code there as the v3 volume grows.

5 Likes
58

I have some questions/concerns about the suggested architecture, and to echo @jared think there needs a higher level of scrutiny before making such a large transition. Basic information and descriptions (in addition to code) would be extremely useful here.

In the status quo, updating prices is a non-privileged function; in this suggested approach, there appears to be a validator role; who or what controls this function? If there is already a “fresh” aggregator price, will this validator slow down the process of “pushing” a price?

Why does this contract need to exist at all? It adds a friction to switching UAVs, and a dependency on a single address. Does it also duplicate the “AggregatorProxy” pattern? Who is responsible for rotating validators?

Does this proposed system use the existing offchain-aggregators, that are already in use by other projects, or create duplicates?

Were other approaches considered? The “push” model only existed in order to get signed price data on-chain in the first place; it adds inefficiencies here, and there should be no reason or constraint to try to use the existing UAV pattern. As an alternative, consider:

The UAV has a public function to update anchors; getUnderlyingPrice reads the current price from an AggregatorProxy, and returns it if it is within the anchor.

2 Likes
59

We found that the best way forward would be to utilize the existing Chainlink price feeds that a lot of protocols are already relying on like Aave, Synthetix, and others.

Maybe I am missing something then in the materials that were shared above, but it looks to me (looking at the actual contracts), that there is a list of reporters statically included in the view who are allowed to call validate, and this is going to be difficult to manage. I would be glad to be shown otherwise.

Launch: The proposer will be responsible for launching a new Uniswap Anchor View. Adding an asset to the protocol will be a one-vote process where the new ctoken is added, and the Uniswap Anchor View contract is updated.

Again, I don’t see this looking at what’s actually being proposed (and happy to know if I am missing something). It looks to me like the list of included reporters will then need to actively post separately to this view contract, which means those reporters need to start reporting the new asset, which I believe would need to be communicated to them as well somehow.

2 Likes
60

Good questions

In the current open oracle design used in production today, the postPrices function is not explicitly privileged, only prices given by the reporter can update the contract. In this proposal, the validator is deemed to be the UAV contract itself, which validates the data is being sent from the correct Chainlink Price Feed.

Every time a price feed updates its on-chain aggregator contract with the freshest value, it also updates the UAV contract with this same data, thereby providing the Compound protocol data as soon as it arrives on-chain. With this design, there is no need for a relayer as data being pushed to the UAV happens in the same transaction as the Chainlink Price Feed update. Additionally, the Uniswap TWAP value is updated if it has become stale during this transaction.

I believe you are referring to the ValidatorProxy, that contract routes price data from the relevant aggregator contracts to the UAV contract (occurs in a single transaction). The addition of this proxy contract is key to ensuring not only the current UAV contract used by the Comptroller is updated but also any newly deployed UAV contract that governance wants the Comptroller to reference going forward. This proxy contract design makes the process of upgrading to a new UAV contract (such as when adding a new asset) much simpler, with significantly less risk of downtime when the switch occurs. Therefore, Compound governance can operate on its own time frame as the UAV proxy contracts ensure both the current and future UAV contracts are updated.

The reason why the UAV contract is being used is that the community wanted to use a TWAP value from Uniswap v2 as an anchor to check for devitations, just as the system does today for additional protection. Using the existing contracts will make the transition easier as the community is comfortable with code they already know and have had live with for a long time.

The AggregatorProxy contract makes prices readable by consumers using a pull model. The ValidatorProxy contract pushes price data directly to the UAV, where it can then be pulled by the Comptroller at any time. The Chainlink Labs team will be responsible for managing the oracle node-set in the underlying aggregator contract, but the validator address would always be the current UAV contract defined in the Comptroller (determined by Compound governance). Please keep in mind that the additional costs associated with pushing the data are handled by the node operators and won’t affect the Compound users.

This is correct; it would be leveraging the existing Chainlink Price Feed networks used by other protocols such as Sytnetix and Aave (as shown on https://data.chain.link). There is no duplication of feeds.

A pull approach was considered for this proposal, but the community preferred a solution that was much closer to the existing UAV contract used today. We do agree with this approach as it will be much easier to have a transition with a model that the community already knows and is familiar with.

In the existing solution, there is a single reporter which is the only entity that affects what prices are stored in the view. This proposal uses Chainlink Price Feeds, where each market has a reporter that can push prices. These reporters are the Chainlink price feed aggregator contracts (updated by a decentralized network of nodes), which each push through a ValidatorProxy (seen in the whiteboard diagram above).

This is where the ValidatorProxy contracts come into play. They enable a second UAV to be deployed, where the price of a single price feed can be pushed to the existing UAV and the new UAV without disruption of service. The ValidatorProxy is a reporter on both UAVs for a specific market.

Here is a good resource to see how the price is updated: https://ethtx.info/mainnet/0x06dad1a4215d510aa18ee21999216877c4ca5ea37b042088b8565eca6c210571

8 Likes
61

Thanks for the explanations @getty :muscle:. So the reporters are expected to be a set of contract addresses - I didn’t appreciate that distinction initially, glad you called it out. In practice though still, how does governance choose this set and under what conditions do you think we might change it? I think this is the part we need to be really clear on and walk through how it would work

EDIT: Now I see, each market is a reporter here https://data.chain.link, so modifying assets is changing reporters IIUC :chart_with_upwards_trend:

3 Likes
62

The contracts have been deployed!

Contract Address/UniswapAnchorView config:

Reported Prices
The proposed UniswapAnchoredView has prices pushed to it by production Chainlink Price Feeds, each through a ValidatorProxy (a reporter). The frequency of the updates depends on a number of triggers, namely:

  • Deviation threshold - when a price is witnessed to have moved more than x% of the previously reported price.
  • Heartbeat threshold - If x minutes have passed without an update.

More information can be found on data.chain.link. Example: ETH / USD.

Price update events can be witnessed on the Etherscan events tab.

Market Configurations
The configuration of each market in the new UAV (which is mostly similar to the current one).

  • cToken - address
  • underlying - address
  • symbolHash - bytes32
  • baseUnit - unit256
  • PriceSource - priceSource
  • fixedPrice - unit256
  • uniswapMarket - address
  • reporter - address (new)
  • reporterMultiplier - unit256 (new)
  • isUniswapReversed - bool

reporter and reporterMultiplier are new.

  • reporter is the address that submits prices for a particular cToken. This is always a ValidatorProxy contract that is called by a price feed aggregator contract for each relevant price update posted by Chainlink oracle nodes. In this case, 0xeBa6F33730B9751a8BA0b18d9C256093E82f6bC2 is the reporter of the price of BAT.
  • reporterMultiplier is used to transform the price reported by the reporter to the correct base unit that the UniswapAnchoredView expects. This is required because Chainlink Price Feeds report prices with different decimal placement than the UniswapAnchoredView.

Here is a breakdown of all of the configs

ETH
  • cToken: 0x4Ddc2D193948926D02f9B1fE9e1daa0718270ED5
  • underlying: 0x0000000000000000000000000000000000000000
  • symbolHash: 0xaaaebeba3810b1e6b70781f14b2d72c1cb89c0b2b320c43bb67ff79f562f5ff4
  • baseUnit: 1000000000000000000
  • priceSource: 2
  • fixedPrice: 0
  • uniswapMarket: 0xB4e16d0168e52d35CaCD2c6185b44281Ec28C9Dc
  • reporter: 0x264BDDFD9D93D48d759FBDB0670bE1C6fDd50236
  • reporterMultiplier: 10000000000000000
  • isUniswapReversed: true
USDC
  • cToken: 0x39AA39c021dfbaE8faC545936693aC917d5E7563
  • underlying: 0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48
  • symbolHash: 0xd6aca1be9729c13d677335161321649cccae6a591554772516700f986f942eaa
  • baseUnit: 1000000
  • priceSource: 1
  • fixedPrice: 1000000
  • uniswapMarket: 0x0000000000000000000000000000000000000000
  • reporter: 0x0000000000000000000000000000000000000000
  • reporterMultiplier: 1
  • isUniswapReversed: false
DAI
  • cToken: 0x5d3a536E4D6DbD6114cc1Ead35777bAB948E3643
  • underlying: 0x6b175474e89094c44da98b954eedeac495271d0f
  • symbolHash: 0xa5e92f3efb6826155f1f728e162af9d7cda33a574a1153b58f03ea01cc37e568
  • baseUnit: 1000000000000000000
  • priceSource: 2
  • fixedPrice: 0
  • uniswapMarket: 0xA478c2975Ab1Ea89e8196811F51A7B7Ade33eB11
  • reporter: 0xb2419f587f497CDd64437f1B367E2e80889631ea
  • reporterMultiplier: 10000000000000000
  • isUniswapReversed: false
WBTC
  • cToken: 0xC11b1268C1A384e55C48c2391d8d480264A3A7F4
  • underlying: 0xC11b1268C1A384e55C48c2391d8d480264A3A7F4
  • symbolHash: 0xe98e2830be1a7e4156d656a7505e65d08c67660dc618072422e9c78053c261e9
  • baseUnit: 100000000
  • priceSource: 2
  • fixedPrice: 0
  • uniswapMarket: 0xBb2b8038a1640196FbE3e38816F3e67Cba72D940
  • reporter: 0x4846efc15CC725456597044e6267ad0b3B51353E
  • reporterMultiplier: 1000000
  • isUniswapReversed: false
USDT
  • cToken: 0xf650C3d88D12dB855b8bf7D11Be6C55A4e07dCC9
  • underlying: 0xdac17f958d2ee523a2206206994597c13d831ec7
  • symbolHash: 0x8b1a1d9c2b109e527c9134b25b1a1833b16b6594f92daa9f6d9b7a6024bce9d0
  • baseUnit: 1000000
  • priceSource: 1
  • fixedPrice: 1000000
  • uniswapMarket: 0x0000000000000000000000000000000000000000
  • reporter: 0x0000000000000000000000000000000000000000
  • reporterMultiplier: 1
  • isUniswapReversed: false
UNI
  • cToken: 0x35A18000230DA775CAc24873d00Ff85BccdeD550
  • underlying: 0x1f9840a85d5af5bf1d1762f925bdaddc4201f984
  • symbolHash: 0xfba01d52a7cd84480d0573725899486a0b5e55c20ff45d6628874349375d1650
  • baseUnit: 1000000000000000000
  • priceSource: 2
  • fixedPrice: 0
  • uniswapMarket: 0xd3d2E2692501A5c9Ca623199D38826e513033a17
  • reporter: 0x70f4D236FD678c9DB41a52d28f90E299676d9D90
  • reporterMultiplier: 10000000000000000
  • isUniswapReversed: false
COMP
  • cToken: 0x70e36f6BF80a52b3B46b3aF8e106CC0ed743E8e4
  • underlying: 0xc00e94cb662c3520282e6f5717214004a7f26888
  • symbolHash: 0xb6dbcaeee318e11fe1e87d4af04bdd7b4d6a3f13307225dc7ee72f7c085ab454
  • baseUnit: 1000000000000000000
  • priceSource: 2
  • fixedPrice: 0
  • uniswapMarket: 0xCFfDdeD873554F362Ac02f8Fb1f02E5ada10516f
  • reporter: 0xE270B8E9d7a7d2A7eE35a45E43d17D56b3e272b1
  • reporterMultiplier: 10000000000000000
  • isUniswapReversed: false
ZRX
  • cToken: 0xB3319f5D18Bc0D84dD1b4825Dcde5d5f7266d407
  • underlying: 0xe41d2489571d322189246dafa5ebde1f4699f498
  • symbolHash: 0xb8612e326dd19fc983e73ae3bc23fa1c78a3e01478574fa7ceb5b57e589dcebd
  • baseUnit: 1000000000000000000
  • priceSource: 2
  • fixedPrice: 0
  • uniswapMarket: 0xc6F348dd3B91a56D117ec0071C1e9b83C0996De4
  • reporter: 0x5c5db112c98dbe5977A4c37AD33F8a4c9ebd5575
  • reporterMultiplier: 10000000000000000
  • isUniswapReversed: true
BAT
  • cToken: 0x6C8c6b02E7b2BE14d4fA6022Dfd6d75921D90E4E
  • underlying: 0x0d8775f648430679a709e98d2b0cb6250d2887ef
  • symbolHash: 0x3ec6762bdf44eb044276fec7d12c1bb640cb139cfd533f93eeebba5414f5db55
  • baseUnit: 1000000000000000000
  • priceSource: 2
  • fixedPrice: 0
  • uniswapMarket: 0xB6909B960DbbE7392D405429eB2b3649752b4838
  • reporter: 0xeBa6F33730B9751a8BA0b18d9C256093E82f6bC2
  • reporterMultiplier: 10000000000000000
  • isUniswapReversed: false
TUSD
  • cToken: 0x12392F67bdf24faE0AF363c24aC620a2f67DAd86
  • underlying: 0x0000000000085d4780B73119b644AE5ecd22b376
  • symbolHash: 0xa1b8d8f7e538bb573797c963eeeed40d0bcb9f28c56104417d0da1b372ae3051
  • baseUnit: 1000000000000000000
  • priceSource: 1
  • fixedPrice: 1000000
  • uniswapMarket: 0x0000000000000000000000000000000000000000
  • reporter: 0x0000000000000000000000000000000000000000
  • reporterMultiplier: 1
  • isUniswapReversed: false
LINK
  • cToken: 0xFAce851a4921ce59e912d19329929CE6da6EB0c7
  • underlying: 0x514910771af9ca656af840dff83e8264ecf986ca
  • symbolHash: 0x921a3539bcb764c889432630877414523e7fbca00c211bc787aeae69e2e3a779
  • baseUnit: 1000000000000000000
  • priceSource: 2
  • fixedPrice: 0
  • uniswapMarket: 0xa2107FA5B38d9bbd2C461D6EDf11B11A50F6b974
  • reporter: 0xBcFd9b1a97cCD0a3942f0408350cdc281cDCa1B1
  • reporterMultiplier: 10000000000000000
  • isUniswapReversed: false
SAI
  • cToken: 0xF5DCe57282A584D2746FaF1593d3121Fcac444dC
  • underlying: 0x89d24a6b4ccb1b6faa2625fe562bdd9a23260359
  • symbolHash: 0x4dcbfd8d7239a822743634e138b90febafc5720cec2dbdc6a0e5a2118ba2c532
  • baseUnit: 1000000000000000000
  • priceSource: 0
  • fixedPrice: 5285000000000000
  • uniswapMarket: 0x0000000000000000000000000000000000000000
  • reporter: 0x0000000000000000000000000000000000000000
  • reporterMultiplier: 1
  • isUniswapReversed: false
REP
  • cToken: 0x158079Ee67Fce2f58472A96584A73C7Ab9AC95c1
  • underlying: 0x1985365e9f78359a9B6AD760e32412f4a445E862
  • symbolHash: 0x91a08135082b0a28b4ad8ecc7749a009e0408743a9d1cdf34dd6a58d60ee9504
  • baseUnit: 1000000000000000000
  • priceSource: 2
  • fixedPrice: 0
  • uniswapMarket: 0x8979A3Ef9D540480342AC0F56e9D4c88807b1CBa
  • reporter: 0x90655316479383795416B615B61282C72D8382C1
  • reporterMultiplier: 10000000000000000
  • isUniswapReversed: false

Compound Community Multisig Ownership
The owner of the proposed UniswapAnchoredView has the power to activate and deactivate the failover mechanism for each market. This was implemented based on community feedback and in case any low liquidity market on Uniswap v2 needs to be deactivated.

Currently, the community multisig is not the owner. However, the current owner has proposed a transfer of ownership in this transaction. To obtain ownership, the multisig must call acceptOwnership() at the proposed UniswapAnchoredView address: 0x34aB75D077c148F1eCAa435e7125c16842A0AeA3

Trail of Bits Audit
Trail of Bits was commissioned for audit of the contracts. Here is a link to it: link

Next Steps
Now that everything is deployed and ready for a vote the community can review the changes. I am aiming to create a governance proposal Tuesday the 1st or Wednesday the 2nd. Feel free to shoot me a message on Discord or post your questions/comments here.

11 Likes