## Simple Summary

A proposal to adjust three (3) total parameters across three (3) Compound assets.


## Background
This proposal is a batch update of risk parameters to align with the [Moderate risk level](https://www.comp.xyz/t/community-risk-level-consensus-check/2437) chosen by the Compound community. These parameter updates are the fourth of Gauntlet's regular parameter recommendations as part of [Dynamic Risk Parameters](https://www.comp.xyz/t/dynamic-risk-parameters/2223/16).


[Full proposal and forum discussion](https://www.comp.xyz/t/risk-parameter-updates-2021-11-30/2688)


## Motivation and Specification

This set of parameter updates seeks to level set assets to a Moderate risk level of the protocol while making risk trade-offs between specific assets. Note that some are different from the original [risk level consensus check](https://www.comp.xyz/t/community-risk-level-consensus-check/2437) as market conditions have changed.


![](https://i.imgur.com/8Fse7LI.png)



## Dashboard


Gauntlet has launched the [Compound Risk Dashboard](https://gov.gauntlet.network/compound). The community should use the Dashboard to better understand the updated parameter suggestions and general market risk in Compound.

As shown on our dashboard, these changes will slightly increase Value at Risk, but the corresponding increase in borrow usage is substantial.

![](https://i.imgur.com/lrdPBk4.png)

Risk Parameter Updates for WBTC, UNI, and COMP

## Simple Summary

A proposal to adjust four (4) total parameters across four (4) Compound assets.


## Background
This proposal is a batch update of risk parameters to align with the [Moderate risk level](https://www.comp.xyz/t/community-risk-level-consensus-check/2437) chosen by the Compound community. These parameter updates are the third of Gauntlet's regular parameter recommendations as part of [Dynamic Risk Parameters](https://www.comp.xyz/t/dynamic-risk-parameters/2223/16).


[Full proposal and forum discussion](https://www.comp.xyz/t/risk-parameter-updates-2021-11-17/2625)


## Motivation and Specification

This set of parameter updates seeks to level set assets to a Moderate risk level of the protocol while making risk trade-offs between specific assets. Note that some are different from the original [risk level consensus check](https://www.comp.xyz/t/community-risk-level-consensus-check/2437) as market conditions have changed.

In order to react to changing market conditions, our analysis recommends decreasing the collateral factors for BAT and ZRX while increasing collateral factors for ETH and DAI. Both BAT and ZRX have increased in volatility and decreased in volume since our last parameter changes. As shown on our dashboard, these changes will slightly increase VaR, but the corresponding increase in borrow usage is substantial. 


![](https://i.imgur.com/jXbgC5y.png)



## Dashboard


Gauntlet has launched the [Compound Risk Dashboard](https://gov.gauntlet.network/compound). The community should use the Dashboard to better understand the updated parameter suggestions and general market risk in Compound.

As shown below, this set of parameter updates will slightly increase VaR, but meaningfully increase borrow usage.

![](https://i.imgur.com/DeZz4Mj.png)

Risk Parameter Updates for DAI, BAT, ZRX, and ETH

# Summary: 


## Goal

Implement Security Solutions to prevent and mitigate loss of funds resulting from security risks introduced by community-proposed upgrades to the Compound protocol.


## Problem

As evidenced in recent market events and specifically Proposal 62, governance upgrades can introduce new security risk vectors which could result in reputational damage to the protocol and possible loss of user funds. Security is a continuous effort and should therefore be seen and addressed from a holistic, continuous perspective.


## Background

For the past two years, OpenZeppelin has worked formally and informally with Compound to perform [10+ security audits](https://blog.openzeppelin.com/?s=compound), develop a [standardized version of GovernorAlpha and GovernorBravo contracts](https://blog.openzeppelin.com/governor-smart-contract/), introduce security best practices for [safer governance systems](https://blog.openzeppelin.com/smart-contract-security-guidelines-4-strategies-for-safer-governance-systems/), and develop bespoke [threat detection agent scripts](https://github.com/forta-protocol/forta-agent-examples/tree/master/compound-ts) monitoring Compound.

As the community assumes greater responsibility for the protocol and the stakes become higher, Compound's decentralized phase of growth demands comprehensive and continuous security processes to thrive.


## Contributor grant

OpenZeppelin is requesting a streaming grant for the Security Solutions retainer fee to begin implementation of a comprehensive set of best-in-class Security Solutions throughout all stages of the Compound governance proposal lifecycle, the elements of which include:



* Protocol Security Officer to provide advisory services and recommendations on improvements to the governance process (specifically in the area of incident and emergency response)
* Security Training and tailored community support specifically designed to educate the community to security best practices and threats in the DeFi space related to the Compound protocol
* Continuous Audits of all new code introduced by governance proposals
* Continuous Threat Monitoring of the Compound Protocol

[See full proposal and forum discussion](https://www.comp.xyz/t/auditing-compound-protocol/2543)

Starting March 30, 2022,  and after further feedback from the Community, OpenZeppelin, will create an additional proposal to cover the performance fee payment in accordance with the formula outlined in the full proposal.


## References

- Forum Discussion on reviewing large code changes: [https://www.comp.xyz/t/more-rigorous-process-on-reviewing-large-code-changes-re-comp-bug-9-29-21/2326/2](https://www.comp.xyz/t/more-rigorous-process-on-reviewing-large-code-changes-re-comp-bug-9-29-21/2326/2)

- Patch for Proposal 63: https://www.comp.xyz/t/compound-proposal-63-temporary-patch-for-comp-distribution-bug-9-29-21/2327

Security Solutions For Compound Governance

### Simple Summary

A proposal to adjust four (4) total parameters across four (4) Compound assets.


### Background

This proposal is a batch update of risk parameters to align with the [Moderate risk level](https://www.comp.xyz/t/community-risk-level-consensus-check/2437) chosen by the Compound community. These parameter updates are the second of Gauntlet's regular parameter recommendations as part of [Dynamic Risk Parameters](https://www.comp.xyz/t/dynamic-risk-parameters/2223).

[Full proposal and forum discussion](https://www.comp.xyz/t/risk-parameter-updates-2021-11-04/2559)

### Motivation and Specification 

These recommendations build upon [Proposal 066](https://compound.finance/governance/proposals/66). In [Proposal 066](https://compound.finance/governance/proposals/66), recommendations included increasing Collateral Factors for LINK, MKR, SUSHI, and YFI and this set of parameter recommendations further increases Collateral Factors for these assets. With this set of updates, Compound's Collateral Factor settings would now reach the Moderate risk level as outlined originally in the [Consensus Check](https://www.comp.xyz/t/community-risk-level-consensus-check/2437). No further gradual increases of Collateral Factors for these assets are planned at this time. 


![](https://i.imgur.com/PdTt9ni.png)

Risk Parameter Updates for LINK, MKR, SUSHI, and YFI

This proposal stops COMP rewards for cCOMP borrowing using the new Comptroller function allowing for splitting COMP speeds. COMP rewards will remain the same for cCOMP suppliers.

Currently, there are COMP rewards given to cCOMP borrowers while the borrow cap is in use. This creates a situation where the net rate for borrowing COMP is negative.  As such, COMP borrowing is forced to the borrow CAP, and the market is unable to reach equilibrium. This proposal will cause the net rate of borrowing COMP to be positive and will result in the market reaching equilibrium.

End cCOMP Borrow Rewards

This question has been [debated and specifics have been worked on](https://www.comp.xyz/t/should-compound-retroactively-airdrop-tokens-to-early-users/595v) for about the past year by the community.

This proposal serves as a temperature check, ensuring that this initiative has sufficient support before making further proposals as to address how to distribute the token to early users.

The actions of this proposal are nil - the protocol does not change at all regardless of whether this proposal passes or fails. Rather, this proposal gauges consensus regarding the issue in the following way:
- FOR: You believe COMP tokens should be distributed to early users in at least some amount and/or way.
- AGAINST: You believe no amount of COMP tokens should be distributed to early users.

If this proposal...
- PASSES: The community will continue its efforts in distributing COMP tokens to early users. A series of follow-up proposals will guide the community in finalizing the total amount, the distribution model, and the way in which the tokens are distributed.
- FAILS: The community will abandon its efforts of this initiative.

A quick summary in support and opposition of this initiative:
- FOR: Early users were key in Compound's success. Their early use of the protocol shaped it to be what it is today, and those users should be given the power to continue shaping the protocol. Compound should continue to decentralize ownership of the protocol by distributing voting power amongst its early community members and users.
- AGAINST: Compound should use the tokens in the treasury as incentives for new work to continue growing the protocol.

Note: Since governance proposals require actions, a nil action has been provided.

## Credits

Allthecolors et al.

## References
- [Forums thread](https://www.comp.xyz/t/should-compound-retroactively-airdrop-tokens-to-early-users/595)

[Temp. Check] Should Compound retroactively distribute COMP tokens to early users?

### Simple Summary

A proposal to adjust six (6) total parameters across six (6) Compound assets.

### Background

This proposal is a batch update of risk parameters to align with the [Moderate risk level](https://www.comp.xyz/t/community-risk-level-consensus-check/2437) chosen by the Compound community. These parameter updates are the first of Gauntlet's regular parameter recommendations as part of [Dynamic Risk Parameters](https://www.comp.xyz/t/dynamic-risk-parameters/2223).

[Full proposal and forum discussion](https://www.comp.xyz/t/risk-parameter-updates-2021-10-25/2486)

### Motivation and Specification 

This set of parameter updates seeks to take the first step in level setting assets to a Moderate risk level of the protocol while making risk trade-offs between specific assets.


| Parameter | Current Value | Recommended Value |
| -------- | -------- | -------- |
| AAVE Collateral Factor    | 50%     | 60%     |
| LINK Collateral Factor    | 50%     | 60%     |
| MKR Collateral Factor  | 35%     | 45%     |
| SUSHI Collateral Factor    | 40%    | 45%     |
| USDC Collateral Factor    | 75%     | 80%     |
| YFI Collateral Factor    | 35%     | 55%     |

Risk Parameter Updates for AAVE, LINK, MKR, SUSHI, USDC, and YFI

## 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)

Vote By Signature

72

Total Proposals

Recent Proposals

Risk Parameter Updates for WBTC, UNI, and COMP

Risk Parameter Updates for DAI, BAT, ZRX, and ETH

Security Solutions For Compound Governance

Risk Parameter Updates for LINK, MKR, SUSHI, and YFI

End cCOMP Borrow Rewards

[Temp. Check] Should Compound retroactively distribute COMP tokens to early...

Risk Parameter Updates for AAVE, LINK, MKR, SUSHI, USDC, and...

Correct Over-Accrued COMP

Fix COMP Accrual Bug

Temporarily Disable COMP Rewards

Public API