KVORUM
compoundSource: Compound governor bravo · #63

Temporarily Disable COMP Rewards

canceledOct 5, 2021, 08:27 AM UTCby2B0x2b38…bf33

01Summary

AISummary by Kvorumclaude-haiku-4-5

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
Contracts0x3d9819210a31b4961b30ef54be2aed79b9c9cd3b0x7102A09B55A6e39B75DEd6073a2e0337255abf02
Generated by Kvorum
model: claude-haiku-4-5
provider: anthropic
profile: anthropic-fast-v1
prompt: v1.0
generated: 2mo ago
Read the description ↗

02Description

129 words

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

AIMismatch analysis by Kvorumclaude-sonnet-5
Consistent

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
model: claude-sonnet-5
provider: anthropic
profile: anthropic-strong-v1
prompt: v1.0
generated: 2mo ago
Review the decoded actions ↗

04Actions

2 total
#0_setPendingImplementation(address)chain 0x1
Target
0x3d98…cd3b
Value
0 wei
Function
_setPendingImplementation(address)
Arguments
{
  "0": "0x7102A09B55A6e39B75DEd6073a2e0337255abf02"
}
Calldata
#1_become(address)chain 0x1
Target
0x7102…bf02
Value
0 wei
Function
_become(address)
Arguments
{
  "0": "0x3d9819210A31b4961b30EF54bE2aeD79B9c9Cd3B"
}
Calldata

05Tally

Summed from votes

Voters29
VP participating1.2M
Outcome (current)For
Current support86.6%

06Voters

29 total

No votes recorded yet.

07Forum

AIForum synthesis by Kvorumclaude-sonnet-5
sentiment · mixedthread · constructive

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
model: claude-sonnet-5
provider: anthropic
profile: anthropic-strong-v1
prompt: v1.0
generated: 2mo ago
Open the thread ↗