With the addition of WBTC collateral, many people have been talking about putting up more safeguards to avoid total loss in an infimint situation. While without migrating WBTC to a new cToken, I don’t think a supply cap is possible, but blck and I thought it’d be beneficial if we implement borrow limits for each cToken to reduce potential losses.
For example, ETH is rarely borrowed, so why should it be possible to borrow the whole supply when the only possible situation for that happening will be a compromised collateral infimint?
Borrow limits will be set by the admin or guardian and borrows will gracefully fail if the borrow amount brings total borrow above the set limit. The limits will be set high enough to enable normal usage but minimize loss of funds. I still believe that a supply cap is a much better solution and this restriction can be disabled if a supply cap is implemented in the future.
I have submitted a PR on GitHub with the code. A preliminary version is currently the Comptroller on Kovan. It has a borrow limit of 10,000 * 1e18 underlying for all assets. Currently, I am working on writing tests for the new patch.
This is a preliminary idea for starting borrow limits. These numbers are mostly random to help start discussion on what they should be. Setting the borrow limits will be successive calls in the same governance proposal after setting the new comptroller.
Things to discuss: what should the initial borrow limits be for each asset, does this comptroller patch need to be professionally audited, do we like this idea, should the guardian have full reign over the borrow limit?
It’s nice to see borrowing caps; these seem logical, and could help standardize assets as collateral (e.g. ETH, BAT, ZRX) with low borrowing caps, and stablecoins with very large borrowing caps.
A few questions:
Does this need a separate guardian? If it’s an “admin” function, it can be controlled through COMP Governance naturally. Would a 5 day proposal period be inadequate, or risky?
What is the impact on gas costs of each type of transaction, to add these checks?
Can you describe the logic, and how it works? Do transactions revert, if a transaction would exceed the cap?
On this thread, let’s focus on the development of the patch, and save the calibration of limits for future Proposals.
If this is implemented, it may also make sense to adjust the relevant interest rate models so rates are relatively high when borrowing value hits the cap.
Does this need a separate guardian? If it’s an “admin” function, it can be controlled through COMP Governance naturally. Would a 5 day proposal period be inadequate, or risky?
Yes, controlling the borrow limits will definitely need to be controller by the pause guardian or a different guardian. Without borrowing ability, many liquidators may have issues liquidating larger positions. Additionally, we don’t want to be getting in the way of normal usage or clogging up governance proposals with these minor changes.
We were thinking of a guardian with ability of changing borrow limits being a community multisig like you recommended for the pause guardian. It would make sense for this to be a different guardian, as it will be used in somewhat normal situations.
What is the impact on gas costs of each type of transaction, to add these checks?
Haven’t looked into this yet.
Can you describe the logic, and how it works? Do transactions revert, if a transaction would exceed the cap?
I tried to make the implementation for the new feature match existing compound code.
The additional logic is placed in the borrowAllowed function in the Comptroller. If the market has a borrowLimit set which is greater than 0, it does a safe addition of the new borrow amount with existing total borrows. If the result is greater than the borrow limit, the borrow function fails gracefully, returning an error code.
I return an error code because for almost all existing compound failures, error code are returned instead of reverting. The only time I see functions reverting in compound is authentication and when markets are paused. Additionally, returning an error code allows for the accureInterest to stay on chain.
I disagree. The idea of the new borrow limit is to restrict borrowing to expected amounts for normal usage. This is just extra security against an infimint situation and will potentially save hundreds of millions in funds.
If a market gets to the cap through normal usage, it should be raised to avoid obstructing normal usage of the protocol.
This makes sense. The governance overhead of updating debt ceilings is not insignificant, but probably simpler with Compound’s proposal flow vs Maker’s executive votes.
I think that having changes to borrow limits all go through governance would be very tedious and annoying. That’s why I propose having a community multisig borrow limit guardian.
What would be cool to see is a Compound community board that manages the pause guardian and borrow limits. Would need to create another contract to allow for elections though.
I think this is a very much needed aspect to the protocol. Pause guardian and borrow limits can’t wait for the normal process to finish.
I committed a new change to my patch which adds a separate Borrow Limit Guardian. It would be nice if you could have our community board setup in time for this proposal. I’d love to volunteer. Maybe that should be a separate posting?
Expansion allowance (when at cap, this amount can be added per 24 hrs)
I don’t think pause guardian fanciness is needed; you’ve got my vote for any meaningful risk reduction improvement that sets the borrow limits high on USDC, DAI, and ETH (perhaps 1B each is fine to start)
Personally, I would prefer a supply cap over all everything, but in the current state of Compound, I don’t believe it is not possible to add one for most assets. Any method of tracking supply can be undermined for v1 cTokens. We would need to migrate to new v2 cTokens which would be a big deal. I don’t think this will be happening soon.
Two main reasons not to do this from my point of view:
Increased gas costs
There are situations where the demand for assets in the market spikes overnight (ZRX price increase for example).
