Governance Proposal 22: Borrow Limits Comptroller Patch (Renamed to Borrow Caps)

[arr00]

I plan to deploy the current version of the new Comptroller with borrow limits implemented over the weekend. View the PR here. Assuming the deployment goes as planned and matches successfully, the proposal will be made sometime next week.

Update: Deployed here.

This was a somewhat long process with multiple postings about it:

Borrow Limits for each Market Comptroller patch

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 …

Borrow Limits Rules

With the Borrow Limits patch code completed, it is now time to decide on a set of rules that the community board will follow when setting the borrow limits. If approved by the governance process, this board will control a multisig that will act as the Borrow Limits Guardian. The community board will consist of 6 addresses with 4 required consensus: two controlled by members of the compound team and 4 by the community. This set of rules dictates how the community board sets market borrow limits.…

Community Multisig (4-of-6) Deployment

This post references this Discord message posted in the #governance channel of the Compound Protocol Discord, and refers to Discord usernames from that channel. In a community-driven effort with stewardship from @arr00, a Community Multisig has been deployed that can, through the governance process, be voted into usage by the protocol for a variety of purposes: for example, to act as Pause Guardian ; or in the future, to act as Borrow Limit Guardian . Six community members have been proposed …

Following the requests of the community, initially, the new code will be introduced without actually being utilized. The newly made community multisig will be set as the “Borrow Limit Guardian” but will not impose any limits. In future proposals, the limits will be set and the role of the community multisig will be further established.

I have written a test suite and a fork simulating the new proposal to test the new code, and it all checks out. Additionally, the new patch has been the comptroller on Koran for the past few weeks. Please proof read the code yourself before voting on the proposal. The code does not touch any core features of the protocol, so it not been audited professionally.

Another new idea I would like to introduce in this proposal is rewards to users who build on the protocol to encourage further development. In the future, this could be automated by the Governance Alpha contract, but for now, this must be added as additional actions to the proposal. Following recommendations, I propose withdrawing $5000 from the SAI reserves (equivalent to 2360 SAI) to my address as a reward for bringing this feature to reality. I don’t have any precedent to base this number on, so if you think it should be different, say so!

All in all, the planned actions of the proposal are as follows:

• Unitroller _setPendingImplementation(NewComptroller)
• NewComptroller _become(Unitroller)
• Unitroller _setBorrowLimitGuardian(community multisig)
• cSAI reduceReserves(2360 * 1e18)
• SAI transfer(Arr00, 2360*1e18)

[blck]

All good, matched the PR bytecode to the deployed Comptroller contract

Using network mainnet https://mainnet-eth.compound.finance
Matching contract at 0x707b501cbce95c5fdb25005a51f33c5b1aa30607 to Comptroller with args
Successfully matched Comptroller to 0x707b501cbce95c5fdb25005a51f33c5b1aa30607 with args

[rleshner]

Prior to creating the proposal, can you verify the steps taken to peer-review or audit the final contract, or get the PR into a “final” state?

This proposal would be include the first community-developed contracts with a self-issued reward (bounty) for the engineering effort – kudos on the creative approach to using protocol reserves.

If the community supports this approach, it could serve as a template for other community-developed protocol upgrades (without requiring a “development fund” or centralized approval).

[jared]

I’m going to attempt to simulate using the deployed contract, I’ll report back here with results.

[arr00]

We won’t be proposing this for the time being. Still working on further testing/auditing. Will be back soon with more updates.

[jayson]

I support this patch, but want to call out that we should not name the upgrade “Borrow Limit” as that term is already well known/used in the interface as an individual’s borrowing limit based on their supply (example - 1 example - 2).

“Borrow Cap” works great .

[arr00]

I was already questioning my word choice as I feel “cap” works better in the macro environment but was reluctant to change this far along. Combined with the chance of confusion, I agree with you. “Borrow Cap” it is.

[arr00]

I may have jumped the gun deploying before. I took some more input into account in recent commits from the community, Compound team, and Open Zeppelin audit. Again, please review the most recent commit. I’ll redeploy (hopefully for the last time) this weekend.

[arr00]

The PR is now in a final state with the comments in the audit taken into account. The contract has been redeployed here.

[jared]

I simulated what would happen on mainnet upgrading to 0x7b5e3521a049c8ff88e6349f33044c6cc33c113c, and found that the caps are working as expected, as far as I was able to check. There is a minor increase in gas costs for borrowing (looks about 4K or 1.66%). I checked setting up liquidations / borrows with and without the caps, before and after the upgrade. I also checked that borrows get rejected when they hit against the cap.

To run the simulation above, you will need to run your own ganache, or wait until the ganache on demand service is back up and running (temporarily down).

[blck]

checked the newly deployed contract it does matches with the github PR, all good again.

Using network mainnet https://mainnet-eth.compound.finance
Matching contract at 0x7b5e3521a049c8ff88e6349f33044c6cc33c113c to Comptroller with args
Successfully matched Comptroller to 0x7b5e3521a049c8ff88e6349f33044c6cc33c113c with args

[arr00]

The proposal is live here. I pushed a post proposal fork simulation to GitHub which shows that the execution will be successful and does some post execution sanity checks.

[mosayeri]

Wondering if there has been any further discussions since the original post around what the borrow limits should be. Seems like we should develop a framework around that.

[arr00]

Yes! Now that the framework to use them is in place we should discuss using it. Let’s take this to another thread.