KVORUM
compoundSource: Compound governor bravo · #112

Return Accidentally Sent Funds #3

executedJul 9, 2022, 02:27 AM UTCby2B0x2b38…bf33

01Summary

AISummary by Kvorumclaude-haiku-4-5

This proposal returns 90% of accidentally sent WBTC to the original sender by using a temporary Comptroller implementation to sweep WBTC, UNI, BAT, and SAI tokens to the Timelock, then disbursing them. Arr00 receives a 89k cUNI (~1790 UNI) bounty from protocol fees. The proposal has been audited by OpenZeppelin and uses a transient implementation to minimize risk.

Type
treasury allocation

Key changes

  • Deploy temporary Comptroller implementation with sweep function to extract WBTC, UNI, BAT, and SAI tokens(high)
  • Sweep WBTC (0x2260FAC5E5542a773Aa44fBCfeDf7C193bc2C599) from Comptroller to Timelock(high)
  • Sweep UNI (0x1f9840a85d5aF5bf1D1762F925BDADdC4201F984) from Comptroller to Timelock(medium)
  • Sweep BAT (0x0D8775F648430679A709E98d2b0Cb6250d2887EF) from Comptroller to Timelock(medium)
  • Sweep SAI (0x89d24A6b4CcB1B6fAA2625fE562bDD9a23260359) from Comptroller to Timelock(medium)
  • Restore original Comptroller implementation after sweeps complete(high)
  • Grant Arr00 bounty of 89k cUNI (~1790 UNI) for recovery efforts(medium)

Notable concerns

  • Temporary Comptroller implementation change introduces execution risk despite audit by OpenZeppelin
  • Multiple token sweeps from Comptroller could affect market state if implementation change is not properly reversed
Contracts0x3d9819210a31b4961b30ef54be2aed79b9c9cd3b0xff3C813559127d60Da732a0E8EC836f4C162dF820xbafe01ff935c7305907c33bf824352ee5979b526
Generated by Kvorum
model: claude-haiku-4-5
provider: anthropic
profile: anthropic-fast-v1
prompt: v1.0
generated: 2mo ago
Read the description ↗

02Description

194 words

Return Accidentally Sent Funds #3

Background

Following the two proposal which returned accidentally sent funds, this proposal will return 90% of the accidentally sent WBTC to a user that sent the WBTC to the Comptroller here.

Mechanics

In order to returns the accidentally sent funds, this proposal sets a transient Comptroller implementation which implements a sweep function. This proposal sweeps the desired tokens to the Timelock and then returns the Comptroller implementation to the current implementation. The Timelock then disburses the funds. On top of the WBTC, orphaned UNI, BAT, and SAI will be swept from the Comptroller to the Timelock. Arr00 will be granted a bounty of 89k cUNI (~1790 UNI), which is part of the fee collected by the protocol from returning accidentally sent funds in proposal 37.

Security

The execution of this proposal will not alter the Comptroller state at all—the method of a transient Comptroller implementation was chosen to reduce risk as much as possible. Additionally, there are proposal simulations which simulate proposal execution and normal market functionality afterword. Finally, the proposal was audited and signed off by Open Zeppelin as can be verified here.

Discussion

03Mismatch analysis

AIMismatch analysis by Kvorumclaude-sonnet-5
Consistent

The description's narrative maps cleanly onto the decoded calldata: a transient Comptroller implementation is set and activated (actions 0-1), the four tokens mentioned (WBTC, UNI, BAT, SAI) are swept to the Timelock (actions 2-5), the original implementation is restored (actions 6-7), and the Timelock then disburses WBTC to the affected user (action 8) and pays Arr00's bounty (action 9). The bounty amount checks out precisely: 8,900,000,000,000 units of cUNI (8 decimals) equals 89,000 cUNI, matching the '89k cUNI (~1790 UNI)' claim in the description. The WBTC transfer amount (0.30147937 WBTC) cannot be independently verified as exactly '90%' of the original accidental transfer without external data, but it is consistent with the described mechanism and no numeric inconsistency is apparent from the calldata alone. No unmentioned transfers, role grants, or target mismatches were found; the UNI/BAT/SAI sweeps are only described as moving to the Timelock (not further disbursed in this proposal), which matches the calldata exactly. Overall the proposal is a faithful, low-risk implementation of what is described in the prose.

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

04Actions

10 total
#0_setPendingImplementation(address)chain 0x1
Target
0x3d98…cd3b
Value
0 wei
Function
_setPendingImplementation(address)
Arguments
{
  "0": "0xff3C813559127d60Da732a0E8EC836f4C162dF82"
}
Calldata
#1_become(address)chain 0x1
Target
0xff3c…df82
Value
0 wei
Function
_become(address)
Arguments
{
  "0": "0x3d9819210A31b4961b30EF54bE2aeD79B9c9Cd3B"
}
Calldata
#2_sweep(address)chain 0x1
Target
0x3d98…cd3b
Value
0 wei
Function
_sweep(address)
Arguments
{
  "0": "0x2260FAC5E5542a773Aa44fBCfeDf7C193bc2C599"
}
Calldata
#3_sweep(address)chain 0x1
Target
0x3d98…cd3b
Value
0 wei
Function
_sweep(address)
Arguments
{
  "0": "0x1f9840a85d5aF5bf1D1762F925BDADdC4201F984"
}
Calldata
#4_sweep(address)chain 0x1
Target
0x3d98…cd3b
Value
0 wei
Function
_sweep(address)
Arguments
{
  "0": "0x0D8775F648430679A709E98d2b0Cb6250d2887EF"
}
Calldata
#5_sweep(address)chain 0x1
Target
0x3d98…cd3b
Value
0 wei
Function
_sweep(address)
Arguments
{
  "0": "0x89d24A6b4CcB1B6fAA2625fE562bDD9a23260359"
}
Calldata
#6_setPendingImplementation(address)chain 0x1
Target
0x3d98…cd3b
Value
0 wei
Function
_setPendingImplementation(address)
Arguments
{
  "0": "0xBafE01ff935C7305907c33BF824352eE5979B526"
}
Calldata
#7_become(address)chain 0x1
Target
0xbafe…b526
Value
0 wei
Function
_become(address)
Arguments
{
  "0": "0x3d9819210A31b4961b30EF54bE2aeD79B9c9Cd3B"
}
Calldata
#8transfer(address,uint256)chain 0x1
Target
0x2260…c599
Value
0 wei
Function
transfer(address,uint256)
Arguments
{
  "0": "0x6918fE32bB0CCfba961C554699c1B506eD0Bd458",
  "1": "30147937"
}
Calldata
#9transfer(address,uint256)chain 0x1
Target
0x35a1…d550
Value
0 wei
Function
transfer(address,uint256)
Arguments
{
  "0": "0x2B384212EDc04Ae8bB41738D05BA20E33277bf33",
  "1": "8900000000000"
}
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 · favorablethread · constructive

Arguments for

  • Establishing a clear, repeatable governance process for returning accidentally sent funds is a positive step for the community.— arr00, massnomis, cryptotyrel, Lavi
  • The new sweepToken function is well-engineered, tested via fork simulations and testnet, and verified against the deployed bytecode, making future recoveries simple.— arr00, rleshner, blck
  • Rewarding the developer with COMP rather than the recovered token aligns incentives and sets a sustainable precedent for future contributor compensation.— rleshner, arr00
  • Imposing a 10% penalty on returned funds fairly compensates the protocol/community for the error and discourages moral hazard.— arr00, johndoh

Arguments against

  • The 30 COMP reward for the developer should be decided separately by a grants/contributor committee rather than bundled into this specific proposal.— massnomis
  • Returning funds via a recurring proposal process could create unintended consequences or open the door to frequent claims, so the community should be cautious about scope.— massnomis

Unresolved concerns

  • The appropriate minimum value threshold ($1,000) for qualifying accidental transfers needs further discussion.— massnomis
  • Whether other cToken implementations (COMP, USDT, DAI) should also be upgraded now rather than waiting until funds are actually trapped in them.— rleshner, arr00
  • Clarity on how retroactive claims (accidents older than 6 months) would be handled and what the exact request process looks like.— cryptotyrel
  • Many token types (e.g., immutable cTokens, underlying-token deposits, phishing losses, slippage losses) are fundamentally unrecoverable under this mechanism, leaving affected users without recourse.— blck, arr00, boblogiii

Notable participants

  • arr00Proposer who designed the policy, wrote the sweepToken code, ran simulations, and has continued to administer fund-return requests for years after the original proposal.
  • rleshnerCore contributor who reviewed technical details, endorsed the COMP reward rationale, and later clarified governance policy on unrelated Uniswap airdrop claims.
  • massnomisEarly supporter who raised concerns about reward sourcing and precedent-setting implications of the policy.
  • johndohRaised the question of whether the sender should bear a penalty for causing the accidental transfer.
  • blckVerified the deployed contract bytecode and explained technical limitations on which tokens can and cannot be recovered.
  • cryptotyrelAsked about retroactive application of the policy and the request process, ultimately expressing support.
  • gettySuggested extending the sweep functionality to other cToken contracts and preventing further accidental transfers to cUNI.
  • LaviAsked where the 10% penalty funds would go, prompting clarification that they return to the Timelock/protocol.
Generated by Kvorum
model: claude-sonnet-5
provider: anthropic
profile: anthropic-strong-v1
prompt: v1.0
generated: 2mo ago
Open the thread ↗