Fix COMP Accrual Bug
01Summary
Fix COMP accrual bug from Proposal 62 by upgrading Comptroller implementation. Pessimistically re-enables COMP withdrawals for users who have not interacted with affected markets (cTUSD, cMKR, cSUSHI, cYFI, cAAVE, cSAI). Users must claim from unaffected markets only.
- Type
- contract upgrade
Key changes
- Fix COMP accrual calculations for affected markets (cTUSD, cMKR, cSUSHI, cYFI, cAAVE, cSAI)(high)
- Re-enable COMP distribution with pessimistic eligibility restrictions(high)
- Restrict COMP withdrawals to users who have not interacted with affected markets(high)
- Require users to claim COMP only from unaffected markets(medium)
Notable concerns
- Users with COMP accruals from affected markets cannot withdraw until a future proposal fixes their balances
- Protocols integrated with Compound that rely on COMP claim functionality may face temporary limitations
- Additional proposal required to compute and fix bad COMP accrual values for affected users
Generated by Kvorum
02Description
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 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 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
03Mismatch analysis
The proposal describes a bug fix to COMP accrual logic and a re-enabling of COMP distribution. The decoded calldata implements this via the standard Compound governance pattern for deploying logic changes: (1) set a new implementation address as pending on the Unitroller proxy, then (2) call _become on that new implementation to complete the upgrade. This two-step proxy upgrade is the conventional mechanism Compound uses to ship exactly this kind of fix — updating the Comptroller's internal accrual/claim logic — and is consistent with the description's stated goal of patching the bug and re-enabling withdrawals. The description does not go into low-level implementation details (i.e., it doesn't say 'upgrade the Comptroller proxy'), but this is reasonable summarization for a technical audience familiar with Compound's upgrade pattern, not an omission of a materially different action. I cannot independently verify that the bytecode at the new implementation address actually contains the described pessimistic-claim fix logic (no source given), which limits confidence to medium, but nothing in the calldata contradicts, redirects funds, or diverges from what is described. There are no numeric parameters, addresses to unaffiliated parties, or fee/recipient changes that could indicate a mismatch to flag as a discrepancy.
Generated by Kvorum
04Actions
- Target
- 0x3d98…cd3b
- Value
- 0 wei
- Function
- _setPendingImplementation(address)
- Arguments
{ "0": "0x234B619B4f4E405665F7d94F2CE60c24256032B5" }- Calldata
- Target
- 0x234b…32b5
- Value
- 0 wei
- Function
- _become(address)
- Arguments
{ "0": "0x3d9819210A31b4961b30EF54bE2aeD79B9c9Cd3B" }- Calldata
05Tally
Summed from votes
06Voters
No votes recorded yet.
07Forum
- Compound Proposal 63: Temporary Patch for COMP Distribution Bug (9/29/21) ↗discourse · high confidence
Arguments for
- Temporarily halting COMP claim distribution (while still accruing) is an acceptable safety measure to address the discovered bug.— jmo, Zarathustra
- Passing Prop 63 gives the community an additional tool to suspend COMP claims earlier than Prop 64 if the risk to the protocol outweighs the risk to integrations.— rleshner
- Given the scale of funds at risk, a temporary disruption is justified to protect the protocol from a larger exploit.— FoxRon
Arguments against
- The revert-based implementation would break external integrations that call claimComp, causing transactions to always fail.— banteg, bugduino
- Simulations show the proposal breaks OUSD's Compound-based investment strategy, including large deposits.— dvf
- A simple no-op return instead of a hard revert would achieve the same safety goal without breaking upstream integrations.— storming0x, allthecolors, dvf, bugduino
- The bug's blast radius extends beyond direct integrators like Idle Finance to downstream protocols (Yearn, Harvest, Enzyme, Gro) that rely on it, most of which cannot selectively skip COMP claims.— bugduino
- Setting COMP accrual speed to non-zero for all markets could avoid the bug without disabling claims entirely.— funky
Unresolved concerns
- Confusion and frustration from ordinary users about why their COMP balances and claim ability were hidden, and whether this compromised decentralization or their rightful earnings.— Theo, Andrew, newdude05
- Uncertainty over the exact severity and duration of impact on integrators if both Prop 63 and Prop 64 passed together (roughly 2 days of reverts).— jmo, bugduino
- Unclear process for how governance handles cancelling a proposal (63) once a substitute (64) is enacted, including the role of the multisig versus community vote removal.— ratankaliani
- Whether picking up/adjusting unclaimed rewards for affected users after the fix is fair or compatible with decentralization principles.— Andrew
Notable participants
- jmoStarted the discussion thread, linked the proposal, and later pressed for clarity on integration risk severity.
- dvfRepresented OUSD, ran simulations showing breakage, strongly opposed Prop 63, and later confirmed OUSD's mitigation.
- bantegIdentified the technical flaw (revert in grantCompInternal) that would break integrations like Yearn strategies.
- storming0xProposed a less intrusive no-op alternative to the revert-based fix.
- allthecolorsRelayed and championed an alternative filtering approach that mitigated integrator concerns.
- bugduinoRepresented Idle Finance, detailed downstream integration risks, and endorsed the alternative filter approach.
- TylerEtherProposer of Prop 64, explained the fix's mechanics and reassured users about COMP accrual and claims.
- rleshnerExplained the rationale behind supporting Prop 63 as a precautionary tool alongside Prop 64.
- arr00Clarified proposal cancellation mechanics as the whitelisted proposer who ultimately canceled Prop 63.
- TheoA confused and frustrated end user demanding clarity on his COMP balance during the disabled period.
Generated by Kvorum
08Similar proposals
- compoundexecutedCorrect Over-Accrued COMP85%
- compoundcanceledTemporarily Disable COMP Rewards80%
- compoundexecutedSplit COMP rewards distribution and bug fixes78%
- compoundexecutedCOMP Distribution Patch76%
- compoundexecutedDistribute COMP to Users72%
- compoundexecutedClose Deprecated Markets, Gas Savings72%
- compoundexecutedRemove automatic COMP claims and COMP speed refresh71%
- compounddefeated[Temp. Check] Should Compound retroactively distribute COMP tokens to early users?70%
- compoundexecutedInitialize Compound III COMP Distribution69%
- compoundexecutedAdd COMP Support68%