Return Accidentally Sent Funds #3
01Summary
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
Generated by Kvorum
02Description
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.
03Mismatch analysis
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
04Actions
- Target
- 0x3d98…cd3b
- Value
- 0 wei
- Function
- _setPendingImplementation(address)
- Arguments
{ "0": "0xff3C813559127d60Da732a0E8EC836f4C162dF82" }- Calldata
- Target
- 0xff3c…df82
- Value
- 0 wei
- Function
- _become(address)
- Arguments
{ "0": "0x3d9819210A31b4961b30EF54bE2aeD79B9c9Cd3B" }- Calldata
- Target
- 0x3d98…cd3b
- Value
- 0 wei
- Function
- _sweep(address)
- Arguments
{ "0": "0x2260FAC5E5542a773Aa44fBCfeDf7C193bc2C599" }- Calldata
- Target
- 0x3d98…cd3b
- Value
- 0 wei
- Function
- _sweep(address)
- Arguments
{ "0": "0x1f9840a85d5aF5bf1D1762F925BDADdC4201F984" }- Calldata
- Target
- 0x3d98…cd3b
- Value
- 0 wei
- Function
- _sweep(address)
- Arguments
{ "0": "0x0D8775F648430679A709E98d2b0Cb6250d2887EF" }- Calldata
- Target
- 0x3d98…cd3b
- Value
- 0 wei
- Function
- _sweep(address)
- Arguments
{ "0": "0x89d24A6b4CcB1B6fAA2625fE562bDD9a23260359" }- Calldata
- Target
- 0x3d98…cd3b
- Value
- 0 wei
- Function
- _setPendingImplementation(address)
- Arguments
{ "0": "0xBafE01ff935C7305907c33BF824352eE5979B526" }- Calldata
- Target
- 0xbafe…b526
- Value
- 0 wei
- Function
- _become(address)
- Arguments
{ "0": "0x3d9819210A31b4961b30EF54bE2aeD79B9c9Cd3B" }- Calldata
- Target
- 0x2260…c599
- Value
- 0 wei
- Function
- transfer(address,uint256)
- Arguments
{ "0": "0x6918fE32bB0CCfba961C554699c1B506eD0Bd458", "1": "30147937" }- Calldata
- Target
- 0x35a1…d550
- Value
- 0 wei
- Function
- transfer(address,uint256)
- Arguments
{ "0": "0x2B384212EDc04Ae8bB41738D05BA20E33277bf33", "1": "8900000000000" }- Calldata
05Tally
Summed from votes
06Voters
No votes recorded yet.
07Forum
- Implement cToken sweepToken and return accidentally sent funds ↗discourse · high confidence
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
08Similar proposals
- compoundexecutedReturn Accidentally Sent Funds86%
- compoundexecutedReturn Accidentally Sent Funds73%
- compoundexecutedReturn accidentally send funds70%
- compoundexecutedUSDT Reserve Reallocation53%
- lidoexecutedEasy Track motion #98343%
- lidoexecutedEasy Track motion #86643%
- lidoexecutedEasy Track motion #79643%
- lidoexecutedEasy Track motion #69643%
- lidoexecutedEasy Track motion #36943%
- lidoexecutedEasy Track motion #83643%