KVORUM
compoundSource: Compound governor bravo · #64

Fix COMP Accrual Bug

executedOct 7, 2021, 06:10 AM UTCbyC80xc8a6…dffc

01Summary

AISummary by Kvorumclaude-haiku-4-5

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

02Description

246 words

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

AIMismatch analysis by Kvorummedium confidenceclaude-sonnet-5
Consistent

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
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": "0x234B619B4f4E405665F7d94F2CE60c24256032B5"
}
Calldata
#1_become(address)chain 0x1
Target
0x234b…32b5
Value
0 wei
Function
_become(address)
Arguments
{
  "0": "0x3d9819210A31b4961b30EF54bE2aeD79B9c9Cd3B"
}
Calldata

05Tally

Summed from votes

Voters0
VP participating0
Outcome (current)—
Current support—

06Voters

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