memoscan

0xc8a6…dffc

All memos sent from and to 0xc8a6…dffc.
0xc8a69971…dffcsent to0x7a6bbe7f…71e8·#16,636,371·0xbe8aed5a…b755ca
This changes the delay to about 22 hours, allowing for people to get their votes and delegations in order. This delay is especially useful when fighting governance attacks, should they ever occur.
0xc8a69971…dffcsent to0xc0da0293…6529·#14,592,603·0xc0109067…18738b
# COMP Rewards Adjustments - Kickstart Rewards: Step Two The initial objective of the COMP rewards program was to distribute the token to our users. While this was an effective way to kickstart Compound and reward early users, the practice of COMP farming for profit has become very problematic. Since most COMP being distributed by the current rewards program is instantly sold off, existing users and token holders are at a great disservice. Their share of the protocol is being diluted for nothing other than farming COMP for profit. This COMP farming behavior is not the kind of activity that will bring value to the protocol, or for the existing users and token holders. Incentives need to be used to grow the protocol to the benefit of the protocol itself and its users and token holders. Going forward, I believe it’s best to end the current COMP rewards program and to start a new one with the sole purpose of kickstarting new markets: kickstart rewards. This proposal is the second step towards launching the new rewards program - **existing rewards are being slashed to 0**. For more information and discussion, please visit the [discussion thread on the forums](https://www.comp.xyz/t/comp-reward-adjustments-v2/3074/).
0xc8a69971…dffcsent to0xc0da0293…6529·#14,412,632·0x01f6eeb5…61a7e2
# COMP Rewards Adjustments - Kickstart Rewards: Step One The initial objective of the COMP rewards program was to distribute the token to our users. While this was an effective way to kickstart Compound and reward early users, the practice of COMP farming for profit has become very problematic. Since most COMP being distributed by the current rewards program is instantly sold off, existing users and token holders are at a great disservice. Their share of the protocol is being diluted for nothing other than farming COMP for profit. This COMP farming behavior is not the kind of activity that will bring value to the protocol, or for the existing users and token holders. Incentives need to be used to grow the protocol to the benefit of the protocol itself and its users and token holders. Going forward, I believe it’s best to end the current COMP rewards program and to start a new one with the sole purpose of kickstarting new markets: kickstart rewards. This proposal is the first step towards launching the new rewards program - **existing rewards are being cut by 50%**. For more information and discussion, please visit the [discussion thread on the forums](https://www.comp.xyz/t/comp-reward-adjustments-v2/3074/).
0xc8a69971…dffcsent to0xc0da0293…6529·#14,098,002·0x46fb3ad1…292d4b
# Add Market: FEI Fei USD (FEI) is a highly scalable and decentralized algorithmic stablecoin that utilizes protocol controlled value (PCV) for peg stabilization, while maintaining highly liquid secondary markets. Users can mint FEI from ETH and other bonding curves, while FEI is redeemable at $1 USD (with a 1% fee) for ETH at the peg price. FEI is governed by TRIBE holders who manage the PCV, backing FEI with a community-owned reserve. This proposal serves to add a market for Fei USD (FEI) with the following parameters: - Interest rate model: same as cDAI, cUSDT, and cTUSD (stablecoin standard) - Collateral factor: 0% (standard to start) - Reserve factor: 25% (standard) - Borrow limit: none - COMP rewards: none (for now, pending a broader discussion) - Price source: Chainlink reporter anchored to [Uniswap V2 FEI/ETH](https://etherscan.io/address/0x94b0a3d511b6ecdb17ebf877278ab030acb0a878) References: - [Fei Protocol](https://fei.money/) - [Etherscan - cFEI](https://etherscan.io/address/0x7713DD9Ca933848F6819F38B8352D9A15EA73F67) - [Forums discussion](https://www.comp.xyz/t/add-market-fei/2241/) - [Proposal simulation](https://github.com/TylerEther/compound-protocol/blob/add-market-fei/spec/sim/1001-add-market-fei/hypothetical_proposal.sim) Proposer disclaimers, affiliations, and transparency: - FEI and TRIBE held over the past 90 days: none - Compensation for this proposal: none - Affiliation to FEI/TRIBE: none
0xc8a69971…dffcsent to0xc0da0293…6529·#13,781,437·0xd2826263…885136
# Add Market: USDP Pax Dollar (USDP) is one of the most regulated stablecoin around being regulated by the New York State Department of Financial Services (“NYDFS”). This has the following benefits ([taken from here](https://www.paxos.com/a-regulated-stablecoin-means-having-a-regulator/)): - The value of each stablecoin token is tied directly to the value of the US dollar, and the amount of “reserve” dollars equal or exceed the number of stablecoins outstanding. - Regulators are overseeing the establishment and maintenance of reserves backing the stablecoins. - Reserves may only be held in the safest forms, such as FDIC-insured bank accounts and in short-term maturity US Treasury instruments. - Reserves are fully segregated from corporate assets, specifically for the benefit of token holders, and are held bankruptcy remote pursuant to the New York Banking Law. This proposal serves to add a market for Pax Dollar (USDP) with the following parameters: - Interest rate model: same as cDAI, cUSDT, and cTUSD (stablecoin standard) - Collateral factor: 0% (standard to start) - Reserve factor: 25% (standard) - Borrow limit: none - COMP rewards: none (for now, pending a broader discussion) This proposal also updates the Uniswap-anchored ChainLink oracle with support for USDP (pegged to 1 USD). References: - [Etherscan - UAV price oracle](https://etherscan.io/address/0x046728da7cb8272284238bd3e47909823d63a58d) - [Etherscan - cUSDP](https://etherscan.io/token/0x8e870d67f660d95d5be530380d0ec0bd388289e1) - [Forums discussion](https://www.comp.xyz/t/new-listing-proposal-paxos-stablecoin-pax/1894/) - [Proposal simulation](https://github.com/TylerEther/compound-protocol/blob/add-market-usdp/spec/sim/1000-add-market-usdp/hypothetical_proposal.sim) Proposer disclaimers, affiliations, and transparency: - USDP held over the past 90 days: none - Compensation for this proposal: none - Affiliation to USDP/Paxos: none
0xc8a69971…dffcsent to0xc0da0293…6529·#13,699,757·0xe89ed547…35c607
# Add Market: USDP Pax Dollar (USDP) is one of the most regulated stablecoin around being regulated by the New York State Department of Financial Services (“NYDFS”). This has the following benefits ([taken from here](https://www.paxos.com/a-regulated-stablecoin-means-having-a-regulator/)): - The value of each stablecoin token is tied directly to the value of the US dollar, and the amount of “reserve” dollars equal or exceed the number of stablecoins outstanding. - Regulators are overseeing the establishment and maintenance of reserves backing the stablecoins. - Reserves may only be held in the safest forms, such as FDIC-insured bank accounts and in short-term maturity US Treasury instruments. - Reserves are fully segregated from corporate assets, specifically for the benefit of token holders, and are held bankruptcy remote pursuant to the New York Banking Law. This proposal serves to add a market for Pax Dollar (USDP) with the following parameters: - Interest rate model: same as cDAI, cUSDT, and cTUSD (stablecoin standard) - Collateral factor: 0% (standard to start) - Reserve factor: 25% (standard) - Borrow limit: none - COMP rewards: none (for now, pending a broader discussion) This proposal also updates the Uniswap-anchored ChainLink oracle with support for USDP (pegged to 1 USD). References: - [Etherscan - UAV price oracle](https://etherscan.io/address/0x046728da7cb8272284238bd3e47909823d63a58d) - [Etherscan - cUSDP](https://etherscan.io/token/0x8e870d67f660d95d5be530380d0ec0bd388289e1) - [Forums discussion](https://www.comp.xyz/t/new-listing-proposal-paxos-stablecoin-pax/1894/) - [Proposal simulation](https://github.com/TylerEther/compound-protocol/blob/add-market-usdp/spec/sim/1000-add-market-usdp/hypothetical_proposal.sim)
0xc8a69971…dffcsent to0xc0da0293…6529·#13,541,005·0xbb0f58cf…723194
# [Temp. Check] Should Compound retroactively distribute COMP tokens to early users? 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)
0xc8a69971…dffcsent to0xc0da0293…6529·#13,400,029·0x90b8e1bf…00b8ee
# Correct Over-Accrued COMP ## 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)
0xc8a69971…dffcsent to0xc0da0293…6529·#13,337,292·0xee3e768e…e04bf7
# Fix COMP Accrual Bug ## 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)
0xc8a69971…dffcsent to0xc0da0293…6529·#13,272,478·0xd58dc430…d43890
# Split COMP rewards distribution and bug fixes 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)