Temporarily Disable COMP Rewards
01Summary
Proposal to temporarily disable COMP rewards distribution due to a bug introduced in Proposal 62 that allowed users to claim more COMP than intended, putting COMP tokens in the Comptroller contract at risk.
- Type
- contract upgrade
Key changes
- Disable distribution of accrued COMP rewards until a long-term fix is tested and implemented(high)
- Set new pending implementation for Comptroller contract at address 0x7102A09B55A6e39B75DEd6073a2e0337255abf02(high)
- Activate the new implementation by calling _become() to restore correct COMP distribution logic(high)
Notable concerns
- A bug in Proposal 62's COMP distribution logic allows users borrowing certain assets to claim more than their intended share of COMP
- All COMP tokens in the Comptroller contract are at risk from continued distribution with the buggy logic
- This is a temporary patch pushed out quickly with additional details to follow in the forum thread
Generated by Kvorum
02Description
Temporarily Disable COMP Rewards
Objective
Disable the distribution of COMP rewards, temporarily
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. 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. 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
03Mismatch analysis
The proposal describes a temporary disabling of COMP reward distribution due to a bug introduced in Proposal 62. The decoded calldata shows the standard two-step Compound proxy upgrade pattern: (1) _setPendingImplementation on the Unitroller proxy pointing to a new Comptroller implementation, and (2) _become called on that new implementation to activate it. This is exactly how Compound protocol upgrades are performed to change Comptroller logic — in this case, presumably to implement logic that halts COMP distribution. The description does not spell out the technical upgrade mechanism (contract addresses, _setPendingImplementation/_become calls), but this is a routine, expected way to deliver the described change and falls under legitimate summarization of mechanical steps rather than an omission of a materially different action. There is no value mismatch, target mismatch, or unexplained transfer of funds/control to an unrelated party — the new implementation is the direct counterpart contract to the existing Unitroller, consistent with a code-logic patch. No numeric parameters are claimed in the description that could be checked against calldata since this is purely a contract logic swap. Overall, the actions align well with the stated objective and no red flags emerge from the calldata that contradict the description's intent to halt COMP distribution.
Generated by Kvorum
04Actions
- Target
- 0x3d98…cd3b
- Value
- 0 wei
- Function
- _setPendingImplementation(address)
- Arguments
{ "0": "0x7102A09B55A6e39B75DEd6073a2e0337255abf02" }- Calldata
- Target
- 0x7102…bf02
- 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
- compoundexecutedFix COMP Accrual Bug80%
- compoundexecutedCOMP Distribution Patch73%
- compoundexecutedSplit COMP rewards distribution and bug fixes73%
- compoundexecutedCOMP Rewards Adjustments - Kickstart Rewards: Step One72%
- compounddefeatedCOMP Rewards Adjustments - Kickstart Rewards: Step Two72%
- compounddefeated[Temp. Check] Should Compound retroactively distribute COMP tokens to early users?71%
- compoundexecutedDistribute COMP to Users71%
- compoundexecutedEnd cCOMP Borrow Rewards70%
- compoundexecutedRemove automatic COMP claims and COMP speed refresh69%
- compoundexecutedCorrect Over-Accrued COMP69%