cWBTC still holds over $100m in WBTC deposits, as it seems mostly by uninformed users.
The token bares 0 interest, and thus users do not gain anything by holding it.
Moreover, Compound as a protocol suffer because of it. First because of liquidity fragmentation, and second because it is not presented at the Compound website interface.
I also have a personal agenda, as the founder of B.Protocol, we have a user with over $10m in legacy WBTC deposits, who seems to be uninformed of the new cWBTC, and we do not have any way to notify him.
The proposed solution is to upgrade the comptroller such that seizeAllowed will allow a dedicate new smart contract to seize any legacy cWBTC collateral, and also to call enterMarket to cWBTC2, on behalf of the seized account.
The dedicated smart contract will withdraw the WBTC and deposit them in cWBTC2, and will transfer the cWBTC2 back to the seized account.
There could be an issue if a smart contract is the collateral owner, and does not have a functionality to handle cWBTC2, and I am willing to investigate it further, if there is a positive vibe from the community towards implementing such change.
If the Comptroller is being modified, what about a Migrate function, which seizes the legacy cToken, mints the new WBTC, enters market for the user – internal to the Comptroller? Is an external smart contract necessary?
I think it’s definitely a good idea to explore, I imagine at some point we want to make all the markets upgradeable, and making the migrations easy / automatic would be a huge win in making that happen
Not necessary at all, I was under the impression that you might want to minimize changes at the comptroller code itself.
It will also cause a re-entry call to the comptroller (comptroller.migrate=>cWBTC.seize=>comptroller.seizeAllowed) but nonReentrant modifier is not used at the comptroller, so it should be ok.
An even more comprehensive (but more complicated) solution is to also tweak redeemAllowed so if user tries to redeem old cWBTC token (after it was seized and converted to cWBTC2), then the comptroller will automatically convert the cWBTC2 back to cWBTC and allow withdrawal.
This part is pretty ugly, and I wonder if there is any way around it that will allow smart contract accounts to someday withdraw their cWBTC2 even if they didn’t had cWBTC2 programmed in their code.
That’s just seems to you. For somebody else it might look as the opposite, like informed concious choice by users, to hold their assets in non-upgradeble contract, rather than in upgradeble. You do check code once, and stay well, rather then checking it all the time for it to not be “upgraded” to some noncense like seizures.
I strongly believe that absolutely zero functionality making possible to seize anything for any sort of “upgrade” or “benefit to user” should even exist in codebase.
Every action should be only be possible to be initiated exclusevely by user, and not by contract and/or governance.
Apps, build OVER Compound could have such functionality, where user is well aware beforehand and specifically delegate that rights to smart contract.
This is a legit opinion, however compound protocol seems to transition to mostly upgradable contracts.
Again legit opinion, but this already exist in cWBTC, and it is non upgradable so cannot be changed…
I can say for myself, that for B.Protocol, which is building on top of Compound, we cannot do any operations on behalf of the users.
But compound has a strong and more importantly very decentralized dao, so I can see why they might choose a different path.
BTW I was asked to present this idea on the next development call, this Wednesday, it I guess it would be a good place to discuss both sides of the equation.