This proposal completes RFP 15: Dynamic COMP reward distribution as well as fixes a few bugs.

## Split COMP rewards distribution

### Problem

At the moment, the COMP rewards rate for any single market is applied at the same rate for both suppliers and borrowers. This creates undesirable market conditions such as, but not limited to, negative interest rates when borrowing various assets.

An example is the WBTC market - we want to distribute COMP rewards for suppliers, but since this distribution rate applies at the same rate for both borrowers and suppliers, we end up with WBTC being borrowed at a negative interest rate. The same applies to most non-stablecoin markets.

### Solution

This proposal changes the Comptroller logic to have two different COMP distribution rates for each and every market - borrow-side (_compBorrowSpeeds_) rate and supply-side (_compSupplySpeeds_) rate.

The function `Comptroller._setCompSpeeds(CToken[],uint256[],uint256[])` is introduced to enable governance to set these differing rates.

Example usage: `Comptroller._setCompSpeeds([cUSDC],[0],[1e18])` - will set the COMP rewards for supplying USDC at 0 COMP per block, and for borrowing at 1 COMP per block.

## COMP rewards distribution bug fixes

This proposal fixes the following bugs:
- Market state indices were not being set when COMP rewards are added to already active markets. [[Bug 1](https://www.comp.xyz/t/comptroller-compspeed-bug/2111)]
- COMP rewards were distributed for periods preceding when the distribution rate is set. [[Bug 2](https://www.comp.xyz/t/comptroller-compspeed-bug/2111)]
- Borrowers were having to poke their borrow to accrue rewards if they borrowed before rewards rates were set. [[Bug 3](https://github.com/compound-finance/compound-protocol/pull/144/commits/f6d717bb78bef0c9851ad672f7b9aa1d90b0f00a)]

## Technical changes
- `Comptroller#compSpeeds` storage variable is no longer being used and has been effectively deleted. It's replaced by `Comptroller#compBorrowSpeeds` and `Comptroller#compSupplySpeeds`. This proposal copies the current rates into the new storage variables.
- `Comptroller#_setCompSpeed(CToken,uint256)` function has been removed and replaced by `Comptroller#_setCompSpeeds(CToken[],uint256[],uint256[])`. This new function allows COMP rewards rates for multiple markets to be set with a single call.
- An upgrade hook initializes all non-initialized market state indices (initial index is 1e36).
- When new markets are added, their state indices are now properly initialized (used to use lazy initialization which caused many problems).

## Other notable changes
- Depositing now uses slightly less gas after a user's initial deposit.
- Calling `Comptroller#claimComp` unfortunately uses a lot more gas to account for uninitialized borrow state indices. It's recommended to specify which markets (and which sides) to claim COMP in rather than claiming across all markets simultaneously.
- Flywheel tests have been updated and expanded upon to prevent the bugs fixed in this proposal from occurring again.
- These changes have been live on the Ropsten testnet for nearly a month and everything is working as expected.

## Credits
- Arr00: initial code supporting split COMP rewards; flywheel test re-writes
- Getty: bugs 1 and 2 diagnosis help and disclosure
- Elee: bugs 1 and 2 diagnosis help, fixing, and disclosure
- Coburn: bug 3 identification; test case
- Compound Labs (especially Jared): reviewing, guidance, general help, and coordination
- TylerEther (me): full implementation of split COMP rewards; testing infrastructure changes; bugs 1 and 2 identification, diagnosis, fixing, and disclosure; bug 3 fix; overall coordination; general testing; addition of many new test cases; proposal

## References
- [GitHub PR](https://github.com/compound-finance/compound-protocol/pull/144/)
- [Proposal simulation](https://github.com/TylerEther/compound-protocol/blob/f73b29373eb65cedf24896d7be46eed38435fc91/spec/sim/0011-split-comp-rewards/hypothetical_mainnet_upgrade.scen)
- [Comptroller compSpeed bug disclosure](https://www.comp.xyz/t/comptroller-compspeed-bug/2111)
- [Forums discussion](https://www.comp.xyz/t/rfp-16-dynamic-comp-reward-distribution/2016/11)
- [Etherscan - contract](https://etherscan.io/address/0x374abb8ce19a73f2c4efad642bda76c797f19233#code)

Split COMP rewards distribution and bug fixes

### Background

For almost two years now Gauntlet has formally and informally worked for Compound to perform [market risk assessments](https://gauntlet.network/reports/compound), contribute to [treasury management](https://compound.finance/governance/proposals/21), [optimize incentives](https://compound.finance/governance/proposals/35), calibrate [risk parameters](https://compound.finance/governance/proposals/39), and [upgrade](https://compound.finance/governance/proposals/30) the [protocol](https://compound.finance/governance/proposals/33). During that time Gauntlet has been able to refine our core models and agents specifically for autonomous interest rate protocol's like Compound.

As the protocol continues to decentralize to the community our position is that dynamic risk parameters are a vital component to growth.

[Full proposal and forum discussion](https://www.comp.xyz/t/dynamic-risk-parameters/2223)

### Contributor Grant 

Gauntlet is requesting a streaming grant for continuous market risk management to optimize yield, capital efficiency, and mitigate depositor losses.

Supported Risk Parameters include Collateral Factor, Close Factor, Borrow Cap, Reserve Factor, and Liquidation Incentive. Gauntlet will also develop a [Risk Dashboard](https://www.comp.xyz/t/dynamic-risk-parameters/2223#risk-dashboard-8) for the community. 

At the start of every quarter for one year Gauntlet will create a proposal to update the service fee payment (higher or lower) in accordance with the formula outlined in the full proposal.

Dynamic Risk Parameters

Right now, to make a proposal, a contributor must have (or have delegated to them) 65k COMP. This threshold is a good spam deflection mechanism, but creates a burdensome hurdle for some contributors.

In additional to keeping the 65k COMP threshold, we propose including a whitelist of contributor addresses, managed by the community multisig, who will always have the right to submit proposals, regardless of the # of COMP delegated to them, relieving a pain point in the current contributor experience.

Arr00 wrote the updated code, wrote tests/simulations, and did a bug bounty program. The overall code change is relatively small.

Changes: https://github.com/compound-finance/compound-protocol/pull/149/files

Forum discussion: https://www.comp.xyz/t/whitelist-of-addresses-that-can-create-proposals/1996

Address Whitelist for Submitting Proposals 

**Background**  
This proposal seeks to compensate users affected by the [unexpected increase](https://www.comp.xyz/t/dai-liquidation-event/642) in the DAI price to $1.30 on Coinbase Pro on November 26th, 2020. A total of 85,222,475 DAI was repaid on 11/26/20. Applying the 8% liquidation penalty, this proposal would pay out a total of 6,817,798 DAI from the 16.4 million DAI in the market [reserve](https://compound.finance/markets/DAI).

Thank you to the Compound community and investors for the weeks of feedback, iteration and discussions that have helped craft this proposal.

**Code Mechanics**  
This proposal utilizes a slightly modified version of the  [merkle distributor](https://github.com/arr00/compound-compensation-proposal)  used for the airdrop of Uniswap’s UNI token. The merkle tree contains the [addresses of those affected](https://github.com/arr00/compound-compensation-proposal/blob/master/scripts/generateAddressBalances.js) by the liquidation event, and was reconciled and analyzed against on-chain data from around the time of the liquidation event (block bounds 11332733 to 11335286).

A relayer will claim the merkle drop for each wallet according to the distributor and distribute the DAI to user’s wallets. Users do not need to interact with any contract to claim this DAI.

[@arr00](https://www.comp.xyz/u/arr00)/[arr00](https://github.com/arr00/)  is the core contributor to the code.

**Next steps:**  If you support this proposal, you can delegate COMP to this autonomous proposal.

To view the full forum post, [see here](https://www.comp.xyz/t/proposal-distribute-dai-to-users-affected-by-dai-liquidations/2110).

Distribute DAI to Users Affected in the DAI Liquidations

Previously we established a rule that every half year we send back funds that were accidentally sent to contracts managed by Compound governance ([proposal 37](https://compound.finance/governance/proposals/37)).

There was one request that meets the requirements: the [transaction](https://etherscan.io/tx/0xbfb32d43e5a4d9a5ebc18709697cbedb1c149b282e104ce2d38ded68a8d635c0) sent 5,000 USDT to the [cDAI](https://etherscan.io/address/0x5d3a536e4d6dbd6114cc1ead35777bab948e3643) contract, after the 10% penalty applied we are sending back 4,500 USDT


Requests can be posted on the forum link below.

[Discussion](https://www.comp.xyz/t/implement-ctoken-sweeptoken-and-return-accidentally-sent-funds/1147/34)

Return Accidentally Sent Funds

The [Pause Guardian](https://compound.finance/docs/governance#pause-guardian) is emergency functionality used to pause supply, borrowing, or liquidation in a market.

This proposal transfers guardianship from Compound Labs (which has always held this role) to Community Multi-Sig created by members of the community: [0xbbf3f1421D886E9b2c5D716B5192aC998af2012c](https://etherscan.io/address/0xbbf3f1421D886E9b2c5D716B5192aC998af2012c#code).

The Multi-Sig requires 4-of-6 signers to approve any transaction. The signer addresses can be seen [here on Gnosis Safe](https://gnosis-safe.io/app/#/safes/0xbbf3f1421D886E9b2c5D716B5192aC998af2012c/address-book), and currently include @TennisBowling, @arr00, @blck, Compound Labs, Dharma Labs (@0age), and @jared. For full context and history on the Multi-Sig, please see [this post](https://www.comp.xyz/t/community-multisig-4-of-6-deployment/134) on the Compound Community Forum.

Setting the Pause Guardian address to the Community Multi-Sig will further decentralize and ensure the security of the Compound Protocol.

Set Pause Guardian to Community Multi-Sig

Compound Proposal 53, 54, & 46 added MKR, SUSHI, AAVE, YFI, & LINK to the protocol with a collateral factor of 0. Now that each market has been safely added to the protocol, it is time to set initial collateral factors. Each of the collateral factors chosen is conservative and can likely be updated in 2-3 months once the markets stabilize.

[Forum thread](https://www.comp.xyz/t/add-markets-mkr-aave-sushi-yfi/1977/38?u=getty)

[LINK forum thread](https://www.comp.xyz/t/add-market-link/1516/65?u=getty)

MKR: 35%
SUSHI: 40%
AAVE: 50%
YFI: 35%
LINK: 50%

Add Collateral Factors for MKR, SUSHI, AAVE, YFI, & LINK

Compound Proposal 53 & 54 added MKR, SUSHI, AAVE, & YFI to the protocol with a collateral factor of 0. Now that each market has been safely added to the protocol, it is time to set initial collateral factors. Each of the collateral factors chosen is conservative and can likely be updated in 2-3 months once the markets stabilize.

[Forum thread](https://www.comp.xyz/t/add-markets-mkr-aave-sushi-yfi/1977?u=getty)

MKR: 35%
SUSHI: 40%
AAVE: 50%
YFI: 35%

Add Collateral Factors for MKR, SUSHI, AAVE, & YFI

On behalf of Getty Hill & Eddy Lee, Polychain is submitting their proposal to add AAVE, SUSHI, and YFI to Compound. Each of these coins are blue chip tokens and widely supported in the industry. 

[Forum thread](https://www.comp.xyz/t/add-markets-mkr-aave-sushi-yfi/)

[Simulation](https://github.com/gfx-labs/compound-protocol/tree/elee/spec/sim)

[cSUSHI](https://etherscan.io/address/0x4B0181102A0112A2ef11AbEE5563bb4a3176c9d7)
[cAAVE](https://etherscan.io/address/0xe65cdB6479BaC1e22340E4E755fAE7E509EcD06c)
[cYFI](https://etherscan.io/address/0x80a2AE356fc9ef4305676f7a3E2Ed04e12C33946)

Proposal calls:
- Add Comptroller support for cSUSHI
- Add Comptroller support for cAAVE
- Add Comptroller support for cYFI
- Set the reserve factor to 25% for each market (standard parameter)
- Add a borrow cap of 60k for AAVE (recommend by the AAVE team)
- Add a borrow cap of 1500 for YFI

Add AAVE, SUSHI, YFI

On behalf of Getty Hill & Eddy Lee, I am submitting their proposal to add MKR to Compound. MKR is the oldest running DeFi project and has been considered for addition since Compound V1. 

[Forum thread](https://www.comp.xyz/t/add-markets-mkr-aave-sushi-yfi/)

[Simulation](https://github.com/gfx-labs/compound-protocol/tree/elee/spec/sim)

[cMKR](https://etherscan.io/address/0x95b4eF2869eBD94BEb4eEE400a99824BF5DC325b)

[New oracle](https://etherscan.io/address/0x6D2299C48a8dD07a872FDd0F8233924872Ad1071) with MKR, AAVE, SUSHI, and YFI prices. 
Chainlink has initiated the ownership transfer of the UAV to the community multisig. 

This proposal initiates cMKR with a 25,000 MKR borrow cap, which reduces the risk of governance attacks and the systemic risk of DeFi.

Vote By Signature

62

Total Proposals

Recent Proposals