## Objective

Correct the amounts of over-accrued COMP due to the bug in Proposal 62 and fully restore the functionality of COMP rewards.

## Justification

[Proposal 62](https://compound.finance/governance/proposals/62) introduced a bug in the COMP distribution logic that allowed users borrowing certain assets to claim more than their intended share of COMP. 
[Proposal 64](https://compound.finance/governance/proposals/64) patched the bug introduced in Proposal 62 and disabled COMP claiming for users active in the affected markets (cSUSHI, cMKR, cYFI, cAAVE, cTUSD, and cSAI).

## Details

Now that proposal 64 has been executed, we're able to compile a definite list of users who have over-accrued COMP along with the exact amounts they over-accrued.

This proposal contains that exact list and calls a newly introduced one-off function - fixBadAccruals - to correct the over-accrued COMP. This function behaves the following way:
- If the user's amount of accrued COMP is greater than the amount they over-accrued, the amount over-accrued is subtracted from their accrued amount (compAccrued).
- If the user's amount of accrued COMP is less than the amount they over-accrued (i.e. they successfully claimed more COMP than they should have), their accrued amount (compAccrued) is set to 0 and the difference (i.e. what they owe the protocol) is saved to compReceivable. This new storage variable is only used for record-keeping at the moment.
- An event - CompReceivableUpdated - is emitted when compReceivable is updated.
- An event - CompAccruedAdjusted - is emitted when this function updates compAccrued.

Note: Record-keeping for the users who _successfully claimed more COMP than they should have and then subsequently returned the funds_ will have to be updated in a different proposal.

Since this proposal corrects all of the amounts of over-accrued COMP, the functionality of claimComp has been restored for all users.

Upon execution of this proposal, Compound protocol will return to its fully functioning state.

## Verification

Everyone is encouraged to verify that the list of users along with their over-accrued amounts exactly matches the output of [the script](https://github.com/TylerEther/compound-tools/blob/main/scripts/proposal-62-bug/find-affected-accounts.js) used to create this list.

## Review

This proposal has only been thoroughly reviewed by myself, so I urge everyone to also thoroughly review this proposal before voting on it.

The proposal has been simulated from a fork of mainnet at block #13380217. The simulation passes with the proposal behaving exactly as expected.

## Credits

TylerEther (me)

## References
- [Forums - Proposal 65 discussion](https://www.comp.xyz/t/proposal-65-correct-over-accrued-comp/2428)
- [Forums - Proposal 64 analysis](https://www.comp.xyz/t/analysis-of-proposal-64/2384/2?u=tylerether)
- [Proposal simulation](https://github.com/TylerEther/compound-protocol/blob/fix-bad-comp-accruals/spec/sim/0065-correct-bad-comp-accruals/hypothetical_mainnet_upgrade.scen)
- [Compound tools repository](https://github.com/TylerEther/compound-tools) hosting the [script used to create the list of affected users and their over-accrued amounts](https://github.com/TylerEther/compound-tools/blob/main/scripts/proposal-62-bug/find-affected-accounts.js)
- [Comptroller - Etherscan code](https://etherscan.io/address/0xBafE01ff935C7305907c33BF824352eE5979B526#code)

Correct Over-Accrued COMP

## Objective

Patch the bug introduced in Proposal 62 and pessimistically allow COMP reward withdrawals until the bad COMP accruals can be fixed.

## Justification

[Proposal 62](https://compound.finance/governance/proposals/62) introduced a bug in the COMP distribution logic that allowed users borrowing certain assets to claim more than their intended share of COMP. 
[Proposal 63](https://compound.finance/governance/proposals/63) prevents further COMP from being distributed until the correct logic is restored but causes issues for protocols that integrated with Compound and required the claim functionality.

## Details 

These changes fix accurals for the affected markets (cTUSD, cMKR, cSUSHI, cYFI, cAAVE, and cSAI) and pessimistically [1] enbles COMP distribution again.

[1] Only users who have not interacted with the affected markets will be able to withdraw their accrued COMP.

Note: To claim COMP successfully, not only must you not have interacted with the affected markets, you must also not try claiming COMP for the affected markets.

Please use either `Comptroller#claimComp(address holder, CToken[] markets)` or `Comptroller#claimComp(address holder, CToken[] markets, bool borrowers, bool suppliers)` with **only** the unaffected markets.

After this proposal passes, we'll have a state where we'll be able to compute an exhaustive list of users with bad COMP accrual values. From there, we'll submit another proposal to fix the bad COMP accrual values and return everything to normal.

## Review
While this has been tested, we will do further testing during the review period, and we implore the community to check the proposal.

## References
- [Forum Thread](https://www.comp.xyz/t/compound-proposal-63-temporary-patch-for-comp-distribution-bug-9-29-21/2327)

Fix COMP Accrual Bug

## Objective

Disable the distribution of COMP rewards, temporarily 

## Justification

[Proposal 62](https://compound.finance/governance/proposals/62) introduced a bug in the COMP distribution logic that allowed users borrowing certain assets to claim more than their intended share of COMP. This puts all of the COMP tokens in the Comptroller contract at risk, but not those in the Reservoir contract. For more details, [see Leshner's tweets here](https://twitter.com/rleshner/status/1443380518498848768). This change will prevent further COMP from being distributed until the correct logic is restored. 

## Details 

This change disables distributing accrued COMP until a long-term fix is tested and implemented. As this change was pushed out as quickly as possible, please follow along in the forum thread where we will provide more information during the review period

### [Forum Thread](https://www.comp.xyz/t/compound-proposal-63-temporary-patch-for-comp-distribution-bug-9-29-21/2327)

Temporarily Disable COMP Rewards

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%

Vote By Signature

65

Total Proposals

Recent Proposals