KVORUM
compoundSource: Compound governor bravo · #65

Correct Over-Accrued COMP

executedOct 17, 2021, 02:51 AM UTCbyC80xc8a6…dffc

01Summary

AISummary by Kvorumclaude-haiku-4-5

This proposal corrects over-accrued COMP tokens that resulted from a bug in Proposal 62. It deploys a new implementation of the Comptroller contract with a fixBadAccruals function that adjusts COMP accruals for 80 affected users by either reducing their accrued amounts or recording what they owe the protocol if they already claimed more than intended.

Type
contract upgrade

Key changes

  • Deploy new Comptroller implementation with fixBadAccruals function to correct over-accrued COMP amounts for 80 affected users across cSUSHI, cMKR, cYFI, cAAVE, cTUSD, and cSAI markets(high)
  • For users with accrued COMP greater than over-accrued amount, subtract the over-accrued portion from their accrued balance(high)
  • For users who claimed more COMP than entitled (compAccrued less than over-accrued amount), set accrued to 0 and record difference in new compReceivable storage variable for record-keeping(high)
  • Emit CompAccruedAdjusted event when updating compAccrued and CompReceivableUpdated event when updating compReceivable(medium)
  • Restore full functionality of claimComp for all users upon execution(high)

Notable concerns

  • Proposal only thoroughly reviewed by the proposer; community review encouraged before voting
  • Record-keeping for users who claimed excess COMP and subsequently returned funds will require a separate proposal
  • Implementation was simulated on a mainnet fork but not independently audited by multiple reviewers
Contracts0x3d9819210a31b4961b30ef54be2aed79b9c9cd3b0xbafe01ff935c7305907c33bf824352ee5979b526
Generated by Kvorum
model: claude-haiku-4-5
provider: anthropic
profile: anthropic-fast-v1
prompt: v1.0
generated: 2mo ago
Read the description ↗

02Description

431 words

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

03Mismatch analysis

AIMismatch analysis by Kvorumclaude-sonnet-5
Consistent

The description explains that a new one-off function, fixBadAccruals, needs to be introduced to the Comptroller and then called with a list of affected users and their over-accrued COMP amounts. The calldata shows exactly this pattern: action 0 sets a pending new implementation on the Unitroller proxy, action 1 has that new implementation call _become to complete the standard Compound proxy upgrade, and action 2 calls fixBadAccruals with a large array of addresses and corresponding uint256 amounts. This is the well-established Compound governance pattern for deploying new Comptroller logic and is implicitly required by the description's statement that fixBadAccruals is a 'newly introduced' function, even though the description doesn't explicitly spell out the _setPendingImplementation/_become upgrade mechanics — this omission is standard boilerplate for this contract type and not something a reviewer would flag. I cannot independently verify that every address/amount pair in the fixBadAccruals call matches the external verification script referenced in the proposal, but the structure, function name, and argument types (address[], uint256[]) precisely match what the description promises, and the number of addresses/amounts is consistent and paired correctly. No value, target, or omission discrepancies were found between the narrative and the decoded actions.

Generated by Kvorum
model: claude-sonnet-5
provider: anthropic
profile: anthropic-strong-v1
prompt: v1.0
generated: 2mo ago
Review the decoded actions ↗

04Actions

3 total
#0_setPendingImplementation(address)chain 0x1
Target
0x3d98…cd3b
Value
0 wei
Function
_setPendingImplementation(address)
Arguments
{
  "0": "0xBafE01ff935C7305907c33BF824352eE5979B526"
}
Calldata
#1_become(address)chain 0x1
Target
0xbafe…b526
Value
0 wei
Function
_become(address)
Arguments
{
  "0": "0x3d9819210A31b4961b30EF54bE2aeD79B9c9Cd3B"
}
Calldata
#2fixBadAccruals(address[],uint256[])chain 0x1
Target
0x3d98…cd3b
Value
0 wei
Function
fixBadAccruals(address[],uint256[])
Arguments
{
  "0": [
    "0xB3BD459e0598ddE1FE84B1d0a1430BE175B5D5be",
    "0xC5119DB28aDde44A8e1453E733381025a2910f7d",
    "0x309d413391e975B553B7B8D19bC11F8a6c2eB889",
    "0x261fe0Fc430c4Ce4158EBE9258e7F9c646fEA448",
    "0xdf6faDA48f5963a8977eC2BCD7b264434CE294f6",
    "0x2e4ae4d3bD0Af45040b4F17e0BB7E6dC548626B1",
    "0x3af015f6e3aC79D217198f00ef36AF099D223e29",
    "0xaB5a193A11f779fe105E8edf9815a0b514B013CA",
    "0xf3f5C252e8ACd60671f92c7F72cf33661221Ef42",
    "0x01B037084EbA7E4519dbFC9BA026ae696746E033",
    "0x9657BD100802434797d0fb21c356B0871C24485B",
    "0x712d0f306956a6A4b4F9319aD9B9de48c5345996",
    "0x98d105874052dDeF7150AFB661190df5f8c3a719",
    "0xf946CDAEcF5A15440e500E61A0c1d179A93652ad",
    "0x8E9c0eA7e72531BA2F7014f3b39783Ac4a26E34a",
    "0xA7B95D2a2D10028cC4450e453151181cBCAc74FC",
    "0x3b3f3EA865293f004E01c35B9e8BA80DAabc8a72",
    "0x0246C1e74EE54Af89c50BFEfFDDdbad0F0d63da2",
    "0xe68176A9D8A4323Ea3FaB649B30E00d0A6a87d15",
    "0xFa24DE5410581625Ca749D615191Bd33e0366a8f",
    "0x75E4c0FFb05c07798e22605b607e2c8717A1e885",
    "0x26A6dC267e276Fded7b40251C8fc08B1b40df367",
    "0x621Ec0b18317049583aC828461cdb4031AD2a76a",
    "0x8f4138b15A1Eb898380D29b677B417dCAfd2bBFE",
    "0x34BbC9a46B09283698ba7Aa1c273E8B4E9F7bcC3",
    "0x25B651A210f0Cd42D1540F885489caE8C9FF0FCC",
    "0xfF628B747C4E70825AF24e3d59748bac477dcbF6",
    "0x5d6DC617D38655254Ea718044D37451E75144357",
    "0x10bf1Dcb5ab7860baB1C3320163C6dddf8DCC0e4",
    "0x60A71287353f3ac632F3e75Fd1be532850aA5f4D",
    "0x53F79a391C638D03e9ED0823dF82e1E72E5F616a",
    "0x90F7Fe74192F18e0020EB04de550cb2BDBc7cd4f",
    "0x093599e111A14aaEFEf98573f26a7AA2Cc58eBff",
    "0xA5d223c176daAB154a3134369D1C0478c5e6FecF",
    "0x6c9eda0c8ce90CCaF6F88C0fB7511447FB92b3Fe",
    "0x7F9D39De53a3036463146e91E921cC9FbfCb2De4",
    "0x8FD2515a5B29E61220Ee080D484D1F2ea4C46E6B",
    "0xB35E71b6A5aebB07dFc3aA705968411ebdBC003f",
    "0x107e78d87005a76b1dc787C2e3DD7986bb47568B",
    "0x94AAF5Ceb457057AC4d1588257988D487272984F",
    "0x3DdfA8eC3052539b6C9549F12cEA2C295cfF5296",
    "0xe03fFE4cCe71b39Ae1A8580AA94AA40bA611c820",
    "0x11690B00Fef3091f37Dd0F88e36c838Cd344547f",
    "0x7d6149aD9A573A6E2Ca6eBf7D4897c1B766841B4",
    "0xF6c3c3621F42Ec1F1CD1207Bb1571d93646Ab29A",
    "0xd19B7946621FE75bA15Ce23ED90D0Af8C962e6d8",
    "0x8de962fDc6521A426389AAD89E1C067c8f816004",
    "0x212D3c9ad48926ED3e7ef538CAaDDb5D10E8Eb9e",
    "0xa92766340B0742d4AF8C065443640EFdfd18a9A3",
    "0x6DdCA709e0d29fdD03Be35553c77c08f81a3F9e1",
    "0x83B8987b2f48B6B7220fFC6E83fa0F129B9D5149",
    "0x9C84bE7Ba23a5034C56d0289EeFB6C083e96dD94",
    "0xD2E7d58850D058668Ee67fad262760E5b05Ed2a4",
    "0xb265aC5Bc12a97bC359b0Ca0870f8b1cEC6369E9",
    "0xba2ef5189B762bd4C9E7f0b50fBBaB65193935e8",
    "0xe095DE809090531D343D046B2Fd3Abf28419D3d0",
    "0x99265b66461539efD0334901DbB5a2d7f082687A",
    "0x86BBC49A00bDE4d64CdE650F6ca8CC0f138fD344",
    "0x87279585d52f534A2d2E453518cD7890c5762d19",
    "0x2eCdc1191514B7e1eD44587822DFfAF7C670D6aE",
    "0x138F85de34EC8057EC206788a064f842cd64Ce9E",
    "0xc63fc0aE83555e2553762EdD887433573F77CFc2",
    "0x2b3b15Cb2304223D1A8ca28c17258775Bd5B0826",
    "0x8c1A4C98C470900567FB9e764243c89cDa79400C",
    "0xF8d9EcFB5Ddd99A6E0ccABC54A440205Cd40e448",
    "0x728e7f512E01E7811037985dDFb15F9bFeF517a8",
    "0x6E13BE05021E83318Fae9f29F2f57CacAccB62A3",
    "0x124E1FafCadc2c017a17B4bBBBfFF3867b7dEE35",
    "0x0006e4548AED4502ec8c844567840Ce6eF1013f5",
    "0x82a726178Ab68d446e079901f2CA95f83DDe37d4",
    "0x339B00277F32265B5a46599Ad30495b0e921EB6f",
    "0xEbE5c14F6AC0ce53640CeBFe6D213674DC08D440",
    "0x0730fD7D15fA9a40a6C7B2bbb4B8CE9ee6E6d08B",
    "0xDe122ae193F46D67C239aE0c7DaE644f9931a772"
  ],
  "1": [
    "70024581827215461300286636",
    "99434542520051820798713",
    "91168628321892518528194",
    "65253893519524513427603",
    "37504914534703867310656",
    "29991222921414803034064",
    "29664092163099163866723",
    "22995425435193061317525",
    "18977306140567618322762",
    "16153770461869763337554",
    "14995552017332537907240",
    "11518530074563941561647",
    "9499196713099819935841",
    "7212224879583644596449",
    "7038803948830987770903",
    "4465995783400342603801",
    "3476860522368145404076",
    "2999525712631519714571",
    "2976977462986329769345",
    "1881718446191311189927",
    "1699235799386422007751",
    "1577018231157018115140",
    "1499788428567608763699",
    "1278642977639309919583",
    "1247907251007203364606",
    "998601466881096599093",
    "791579317801755286963",
    "773933487859775608904",
    "762430378814137892973",
    "505305506641181113258",
    "499866820508711159523",
    "491351929276724469475",
    "187011763377256292965",
    "95880194615183341505",
    "35906565779719826718",
    "34940732225857751281",
    "25099485956367649889",
    "19778101924102624863",
    "19505161319578397635",
    "2968804004067920724",
    "432423944715881797",
    "100905201500492779",
    "99856604811161355",
    "49962015092674176",
    "9951593329323840",
    "6757459496349902",
    "5597019815253533",
    "501759751685271",
    "200024507662316",
    "33277774577726",
    "14611468777911",
    "5014905724070",
    "4997677706137",
    "4989881308103",
    "2419923659650",
    "1486146270087",
    "496946680063",
    "349870854800",
    "152196995332",
    "147008249887",
    "104317366337",
    "99993707875",
    "47972588242",
    "44234730265",
    "12031544568",
    "10541282903",
    "8594826060",
    "5000000000",
    "1617031777",
    "1324963912",
    "751720862",
    "293454410",
    "171168761",
    "1549831"
  ]
}
Calldata

05Tally

Summed from votes

Voters0
VP participating0
Outcome (current)—
Current support—

06Voters

0 total

No votes recorded yet.

07Forum

AIForum synthesis by Kvorumclaude-haiku-4-5
sentiment · favorablethread · constructive

Arguments for

  • The patch correctly prevents the bug from affecting new users going forward by fixing the equality check in distribution logic.— hayesgm, TylerEther
  • The patch does not revert for any user and poses no worse outcome than current functionality if false negatives occur.— hayesgm
  • The patch should not negatively affect protocol integrations, unlike alternative proposals.— hayesgm
  • A follow-up proposal (65) will fully resolve the issue by correcting accruals and unblocking all users, with tools provided for community verification.— TylerEther
  • The temporary blocking mechanism is necessary to prevent further excess COMP withdrawals while a more complete fix is developed.— hayesgm

Arguments against

  • The patch is overly broad and will prevent some innocent users who interacted with affected markets (cREP, cWBTC, cSAI, cAAVE, cYFI, cTUSD, cMKR, cSUSHI) from claiming earned COMP rewards.— hayesgm
  • The temporary nature of the fix means users remain locked from withdrawals even after Proposal 64, requiring a follow-up proposal to unblock claiming.— hayesgm, newdude05

Unresolved concerns

  • The patch has not been officially audited and the community should thoroughly review the technical risks before voting.— hayesgm
  • Uncertainty remains about the timeline for when normal COMP distribution will fully resume and users can withdraw rewards without restrictions.— newdude05
  • It is unclear whether executing Proposal 63 before Proposal 64 would be preferable or if they should be executed in the stated order.— hayesgm

Notable participants

  • hayesgmProvided detailed technical analysis of Proposal 64, explaining its effects, limitations, and the need for a follow-up patch.
  • TylerEtherProposal author and core developer who clarified the approach for Proposal 65, published verification tools, and committed to minimizing additional risk.
  • newdude05Community member raising concerns about resolution timeline and broader governance process quality.
Generated by Kvorum
model: claude-haiku-4-5
provider: anthropic
profile: anthropic-fast-v1
prompt: v1.0
generated: 2mo ago
Open the thread ↗