Proposal 65: Correct Over-Accrued COMP

1

This proposal follows up on my post regarding Proposal 64.

This script has been used to list all of the accounts that over-accrued COMP due to the Proposal 62 bug.

Account Address,Amount Over-Accrued,Current Amount Accrued
0xb3bd459e0598dde1fe84b1d0a1430be175b5d5be,70024581.827215461300286636,70026235.599882059838229769
0xc5119db28adde44a8e1453e733381025a2910f7d,99434.542520051820798713,99436.286923591330401865
0x309d413391e975b553b7b8d19bc11f8a6c2eb889,91168.628321892518528194,0.343336911491348169
0x261fe0fc430c4ce4158ebe9258e7f9c646fea448,65253.893519524513427603,0.0
0xdf6fada48f5963a8977ec2bcd7b264434ce294f6,37504.914534703867310656,0.000427352546333771
0x2e4ae4d3bd0af45040b4f17e0bb7e6dc548626b1,29991.222921414803034064,0.0
0x3af015f6e3ac79d217198f00ef36af099d223e29,29664.092163099163866723,0.000838253542351374
0xab5a193a11f779fe105e8edf9815a0b514b013ca,22995.425435193061317525,0.0
0xf3f5c252e8acd60671f92c7f72cf33661221ef42,18977.306140567618322762,0.01251652794850858
0x01b037084eba7e4519dbfc9ba026ae696746e033,16153.770461869763337554,16153.808145444719939078
0x9657bd100802434797d0fb21c356b0871c24485b,14995.55201733253790724,0.000103431906969403
0x712d0f306956a6a4b4f9319ad9b9de48c5345996,11518.530074563941561647,328.901642307158025404
0x98d105874052ddef7150afb661190df5f8c3a719,9499.196713099819935841,0.0
0xf946cdaecf5a15440e500e61a0c1d179a93652ad,7212.224879583644596449,7212.283480538767773356
0x8e9c0ea7e72531ba2f7014f3b39783ac4a26e34a,7038.803948830987770903,0.000032795086025069
0xa7b95d2a2d10028cc4450e453151181cbcac74fc,4465.995783400342603801,0.0
0x3b3f3ea865293f004e01c35b9e8ba80daabc8a72,3476.860522368145404076,3490.40445922678665738
0x0246c1e74ee54af89c50bfeffdddbad0f0d63da2,2999.525712631519714571,0.0
0xe68176a9d8a4323ea3fab649b30e00d0a6a87d15,2976.977462986329769345,2977.061180768804901484
0xfa24de5410581625ca749d615191bd33e0366a8f,1881.718446191311189927,0.0
0x75e4c0ffb05c07798e22605b607e2c8717a1e885,1699.235799386422007751,0.000461043674977252
0x26a6dc267e276fded7b40251c8fc08b1b40df367,1577.01823115701811514,0.02081734390136282
0x621ec0b18317049583ac828461cdb4031ad2a76a,1499.788428567608763699,0.0
0x8f4138b15a1eb898380d29b677b417dcafd2bbfe,1278.642977639309919583,0.0
0x34bbc9a46b09283698ba7aa1c273e8b4e9f7bcc3,1247.907251007203364606,0.00165454068581036
0x25b651a210f0cd42d1540f885489cae8c9ff0fcc,998.601466881096599093,1.505296151428545413
0xff628b747c4e70825af24e3d59748bac477dcbf6,791.579317801755286963,0.0
0x5d6dc617d38655254ea718044d37451e75144357,773.933487859775608904,0.248376883324206702
0x10bf1dcb5ab7860bab1c3320163c6dddf8dcc0e4,762.430378814137892973,0.000116427785168512
0x60a71287353f3ac632f3e75fd1be532850aa5f4d,505.305506641181113258,0.000483092598975978
0x53f79a391c638d03e9ed0823df82e1e72e5f616a,499.866820508711159523,0.0
0x90f7fe74192f18e0020eb04de550cb2bdbc7cd4f,491.351929276724469475,0.0
0x093599e111a14aaefef98573f26a7aa2cc58ebff,187.011763377256292965,0.0
0xa5d223c176daab154a3134369d1c0478c5e6fecf,95.880194615183341505,4.398925514276196038
0x6c9eda0c8ce90ccaf6f88c0fb7511447fb92b3fe,35.906565779719826718,0.003381559620539385
0x7f9d39de53a3036463146e91e921cc9fbfcb2de4,34.940732225857751281,0.0
0x8fd2515a5b29e61220ee080d484d1f2ea4c46e6b,25.099485956367649889,0.0
0xb35e71b6a5aebb07dfc3aa705968411ebdbc003f,19.778101924102624863,0.0
0x107e78d87005a76b1dc787c2e3dd7986bb47568b,19.505161319578397635,0.000000787409783801
0x94aaf5ceb457057ac4d1588257988d487272984f,2.968804004067920724,2.968805604364673206
0x3ddfa8ec3052539b6c9549f12cea2c295cff5296,0.432423944715881797,0.0
0xe03ffe4cce71b39ae1a8580aa94aa40ba611c820,0.100905201500492779,0.0
0x11690b00fef3091f37dd0f88e36c838cd344547f,0.099856604811161355,0.101025277738879831
0x7d6149ad9a573a6e2ca6ebf7d4897c1b766841b4,0.049962015092674176,120.551253553868518242
0xf6c3c3621f42ec1f1cd1207bb1571d93646ab29a,0.00995159332932384,0.010451141982817861
0xd19b7946621fe75ba15ce23ed90d0af8c962e6d8,0.006757459496349902,0.782910668575382704
0x8de962fdc6521a426389aad89e1c067c8f816004,0.005597019815253533,0.109147386565220699
0x212d3c9ad48926ed3e7ef538caaddb5d10e8eb9e,0.000501759751685271,0.778778835751644402
0xa92766340b0742d4af8c065443640efdfd18a9a3,0.000200024507662316,0.000202688876003611
0x6ddca709e0d29fdd03be35553c77c08f81a3f9e1,0.000033277774577726,112.286558630800153647
0x83b8987b2f48b6b7220ffc6e83fa0f129b9d5149,0.000014611468777911,1.40572082158446895
0x9c84be7ba23a5034c56d0289eefb6c083e96dd94,0.00000501490572407,0.211635090467960075
0xd2e7d58850d058668ee67fad262760e5b05ed2a4,0.000004997677706137,0.0
0xb265ac5bc12a97bc359b0ca0870f8b1cec6369e9,0.000004989881308103,0.000004989881308103
0xba2ef5189b762bd4c9e7f0b50fbbab65193935e8,0.00000241992365965,0.0
0xe095de809090531d343d046b2fd3abf28419d3d0,0.000001486146270087,0.000001486146270087
0x99265b66461539efd0334901dbb5a2d7f082687a,0.000000496946680063,0.000233247219600195
0x86bbc49a00bde4d64cde650f6ca8cc0f138fd344,0.0000003498708548,0.000846145490121417
0x87279585d52f534a2d2e453518cd7890c5762d19,0.000000152196995332,0.441051013964912238
0x2ecdc1191514b7e1ed44587822dffaf7c670d6ae,0.000000147008249887,0.000000147008249887
0x138f85de34ec8057ec206788a064f842cd64ce9e,0.000000104317366337,0.123242782911884664
0xc63fc0ae83555e2553762edd887433573f77cfc2,0.000000099993707875,0.659320233643772688
0x2b3b15cb2304223d1a8ca28c17258775bd5b0826,0.000000047972588242,0.000000047972588242
0x8c1a4c98c470900567fb9e764243c89cda79400c,0.000000044234730265,3.680560411138504644
0xf8d9ecfb5ddd99a6e0ccabc54a440205cd40e448,0.000000012031544568,2.74044837345881888
0x728e7f512e01e7811037985ddfb15f9bfef517a8,0.000000010541282903,0.000093450955160815
0x6e13be05021e83318fae9f29f2f57cacaccb62a3,0.00000000859482606,0.000000014984902173
0x124e1fafcadc2c017a17b4bbbbfff3867b7dee35,0.000000005,0.0
0x0006e4548aed4502ec8c844567840ce6ef1013f5,0.000000001617031777,0.0
0x82a726178ab68d446e079901f2ca95f83dde37d4,0.000000001324963912,0.191268026306613049
0x339b00277f32265b5a46599ad30495b0e921eb6f,0.000000000751720862,0.020494098260190955
0xebe5c14f6ac0ce53640cebfe6d213674dc08d440,0.00000000029345441,0.0
0x0730fd7d15fa9a40a6c7b2bbb4b8ce9ee6e6d08b,0.000000000171168761,0.0
0xde122ae193f46d67c239ae0c7dae644f9931a772,0.000000000001549831,0.934955697489397386

Proposal 65 uses this list to correct the over-accrued COMP for all of the users who have over-accrued COMP due to the bug.

I’ve run all of Compound’s tests on the latest Comptroller which includes the new tests to identify the proposal 62 bug, and they all pass.

More details to come once I submit the formal proposal.

5 Likes
2

The script has been updated to match its data against the proposal data. It’s an exact match! I encourage others to also verify it.

4 Likes
3

Mainnet upgrade simulation which executes proposal 65 and verifies that it works as expected: Proposal 65: Correct bad COMP accruals by TylerEther · Pull Request #166 · compound-finance/compound-protocol · GitHub

6 Likes
4

Screen Shot 2021-10-13 at 12.30.54 PM
Screen Shot 2021-10-13 at 12.30.54 PM1338Ă—62 71.4 KB

I was able to match the contract to the code in the PR successfully. Additionally, the fork simulations execute as expected.

3 Likes
5

Thanks to @TylerEther for putting this proposal together.

a16z plans to vote yes on this proposal, as the changes being made here ensure that all users will be able to claim all correctly accrued COMP and that users who accrued excess COMP as a result of the 62 bug cannot claim that excess COMP. It fixes the root cause of the issues caused by Proposal 62 and gets Compound back to its fully functioning state and allows the protocol to move forward. We are fully supportive of this effort. Additionally, @alex_kroeger from our team put together a dune dashboard to review the data inputs being provided by Tyler’s script. You can find that dashboard here.

While we plan to vote yes, there are a few points about the proposal process that we would like to highlight. After Proposal 62 passed and the exploit was identified, we as a community had to move fast in order to stop the bleeding – it is completely reasonable to prioritize speed when funds are actively at risk, as they were in the case of proposals 63 and 64. However, after Proposal 64 was executed successfully, we had reached a point where funds in the Comptroller were no longer at risk of being drained.

Going forward, the community should aim to be more deliberate and systematic in our approach to reviewing code that affects contracts that hold a significant amount of funds. For example, for this current proposal, the community would have benefitted from having more time for review before the on-chain proposal was created. This would ensure sufficient time was given for audit/review, feedback, questions, and collaboration.

In the future, one way to implement this would be for the community to create and enforce a standard process for any new proposals that are introduced. It could look something like this:

  • Post in forums with links to the technical implementation for the community to review
  • Wait a minimum of a week from forum posting to pushing the proposal to an on-chain vote
  • During that week, the OP should:
    • Actively seek feedback from community members and adjust the proposal as needed
    • Join community calls to answer any questions on the proposal
    • Proactively seek other community members to review, audit, and test the implementation

Only after there has been sufficient time for people to review and feedback has been gathered, then it makes sense to move forward with the on-chain governance vote. There are likely other ways to implement this sort of thing, but in general a more rigorous process along these lines makes sense going forward. We encourage and welcome additional ideas from the community as we continue to iterate here.

8 Likes
6

Gauntlet will ABSTAIN from Proposal 65.

Our first concern is that very few people seem to have reviewed it (at this point). The other concern is that the proposal is using an extra state variable to prevent it from being called twice. Given that only admin (governance) can call this function and it will be removed in the next proposal, it doesn’t seem like it is worth protecting. However, I do think this patch misses an obvious step to extract a bit more accrued COMP from each of the violating users. Basically, it looks at the compAccrued variable for each user and tries to extract as much as possible. If some of these users only claimed COMP say 2 weeks ago, we are missing all the COMP they have accrued since then.

Instead, I think we could call distributeSupplierComp and distributeBorrowerComp in this function to make sure compAccrued reflects an up-to-date calculation of accrued COMP. Alternatively, this could be done in a separate proposal but then I feel the use of the state variable for proposal65 is tricky as it claims to be “final”.

P.S. It’s worth mentioning that much more aggressive steps could be taken to seize the COMP from violating users, in particular, their collateral could be frozen or liquidating or their cTokens could be seized (not sure if this is possible). This would be much more complex and trust-breaking so not necessarily recommending but good to keep in mind.

7

Thanks for the feedback, a16z and Gauntlet.

These changes were put together and proposed much quicker than most other proposals. While Compound is no longer at risk of losing additional COMP, the protocol is still not fully functional - users active in the affected markets are not able to withdraw their accrued COMP. If the protocol were fully functional, these changes certainly would have had a lot more public discussion before being submitted for a vote.

Getting Compound protocol to a fully functioning state with minimal downtime is my #1 priority. This partial downtime of COMP rewards can have negative effects on both users, other protocols, and developers. What if a user’s/protocol’s business logic relies on receiving the accrued COMP tokens and they’re unable to claim them?

We all know Compound’s governance is disorganized, and there are only a few busy individuals who are capable of seeing changes through all the way to proposal execution. It’d be terrible for this partial downtime to drag on for months due to this.

1 Like
8

Instead, I think we could call distributeSupplierComp and distributeBorrowerComp in this function to make sure compAccrued reflects an up-to-date calculation of accrued COMP.

This sounds very expensive gas-wise.

9

It only needs to be done for addresses that are in debt where it will lead to more COMP being extracted. And the gas cost is therefore not crazy at all, individual users pay for these functions any time they claim COMP.