New Feature: Borrow Caps
01Summary
Proposal to upgrade the Comptroller contract with a new 'borrow caps' feature that enforces maximum borrow limits per asset. The upgrade has been reviewed by OpenZeppelin and tested on Kovan testnet. Includes a ~$5000 SAI bounty payment to Arr00 for organizing the implementation. Actual borrow cap parameters and the Borrow Cap Guardian role will be determined in future governance votes.
- Type
- contract upgrade
- Funding
- $~5000
Key changes
- Implement new Comptroller with borrow caps feature that checks total borrows against a cap on each borrow transaction(high)
- Deploy new implementation contract at 0x7b5e3521a049c8ff88e6349f33044c6cc33c113c(high)
- Withdraw approximately $5000 worth of SAI from cSAI reserves as bounty payment(low)
Notable concerns
- Actual borrow cap usage and parameters will be determined in future governance votes
- Borrow Cap Guardian role and responsibilities to be established later
- Feature is being deployed before active usage parameters are set by community
Generated by Kvorum
02Description
New Feature: Borrow Caps
This proposal implements a new comptroller with the “borrow caps” feature requested by the community. On each borrow, the new total borrows is checked against the borrow cap and reverts if the new total borrows is too large.
The actual usage of borrow caps will come at a later date once the community understands the new feature fully. Then, it will be how to use the borrow caps and what the role of the Borrow Cap Guardian will be.
This patch has been discussed and developed in the open, reviewed by members of the community, and tested on the Kovan testnet. New scenario tests and fork simulations for the new contract were written. The new contract has been reviewed by Open Zeppelin and no major issues were found. Their recommendations were taken into account for the new comptroller deployment.
The last two calls withdraw from the cSAI reserves about $5000 worth of SAI and sends it to Arr00 as a bounty for organizing and implementing this proposal.
Discussion GitHub pull request
Proposal by Arr00
03Mismatch analysis
The proposal's core claim — deploying a new Comptroller implementation with borrow caps — matches actions 0 and 1 (_setPendingImplementation followed by _become), which is the standard Compound upgrade pattern. The description's mention of the 'last two calls' withdrawing cSAI reserves and paying Arr00 a bounty also matches actions 2 and 3 (_reduceReserves on the cSAI market followed by a SAI transfer to a specific address). The mechanics align well and no unmentioned significant actions or a wrong target were found. The only discrepancy is a numerical mismatch: the description estimates the bounty at 'about $5000 worth of SAI' while the calldata moves exactly 2800 SAI, which (given SAI's near-$1 peg) is roughly $2800 — noticeably less than the stated $5000. This is a soft, non-critical estimate in prose rather than a hard on-chain parameter, so it doesn't redirect funds or misrepresent recipients, but a careful reviewer should note the sizing discrepancy. Given the low materiality (a rough dollar estimate error, not a wrong recipient or hidden action), the overall assessment is a minor discrepancy with high confidence, since amounts are clearly decodable and comparable.
Discrepancies
- lowvalue mismatch
The description states the bounty transfer is 'about $5000 worth of SAI', but the calldata reduces reserves and transfers exactly 2800 SAI. Since SAI is a stablecoin pegged near $1, 2800 SAI is closer to $2800, not $5000. This is a notable overstatement of the bounty size relative to the actual on-chain amount.
“withdraw from the cSAI reserves about $5000 worth of SAI and sends it to Arr00 as a bounty”
Generated by Kvorum
04Actions
- Target
- 0x3d98…cd3b
- Value
- 0 wei
- Function
- _setPendingImplementation(address)
- Arguments
{ "0": "0x7b5e3521a049C8fF88e6349f33044c6Cc33c113c" }- Calldata
- Target
- 0x7b5e…113c
- Value
- 0 wei
- Function
- _become(address)
- Arguments
{ "0": "0x3d9819210A31b4961b30EF54bE2aeD79B9c9Cd3B" }- Calldata
- Target
- 0xf5dc…44dc
- Value
- 0 wei
- Function
- _reduceReserves(uint256)
- Arguments
{ "0": "2800000000000000000000" }- Calldata
- Target
- 0x89d2…0359
- Value
- 0 wei
- Function
- transfer(address,uint256)
- Arguments
{ "0": "0x2B384212EDc04Ae8bB41738D05BA20E33277bf33", "1": "2800000000000000000000" }- Calldata
05Tally
Summed from votes
06Voters
| Voter | Choice | % of total | Rationale | ||
|---|---|---|---|---|---|
| ED0xed40…08ff | For | 325.8K | 39.69% | — | 6y ago |
| AC0xac57…faf6 | For | 105K | 12.79% | — | 6y ago |
| 540x54a3…e189 | For | 100K | 12.18% | — | 6y ago |
| 7E0x7e4a…19fa | For | 100K | 12.18% | — | 6y ago |
| 5D0x5d89…9e68 | For | 75K | 9.14% | — | 6y ago |
| 870x879d…0f11 | For | 25.2K | 3.06% | — | 6y ago |
| DAdakeshi.eth0xe3c9…6b21 | For | 20K | 2.44% | — | 6y ago |
| E50xe5b5…4b03 | Against | 15K | 1.83% | — | 6y ago |
| 0A0x0a09…b92e | For | 15K | 1.83% | — | 6y ago |
| 7F0x7f89…58c4 | For | 13K | 1.59% | — | 6y ago |
| A80xa8c6…3985 | For | 10K | 1.22% | — | 6y ago |
| B00xb032…449b | For | 9K | 1.10% | — | 6y ago |
| B80xb8a6…6406 | For | 5K | 0.61% | — | 6y ago |
| FC0xfc04…5ac2 | For | 2.3K | 0.28% | — | 6y ago |
| 4C0x4c1b…b8f7 | For | 300 | 0.04% | — | 6y ago |
| 850x8553…0136 | For | 57.5 | 0.01% | — | 6y ago |
| 2B0x2b38…bf33 | For | 54.7 | 0.01% | — | 6y ago |
| F80xf853…e619 | For | 27.4 | 0.00% | — | 6y ago |
| 8D0x8d07…a265 | For | 10.1 | 0.00% | — | 6y ago |
| D70xd76a…3834 | For | 8.3 | 0.00% | — | 6y ago |
| 990x994e…bfd9 | For | 5.8 | 0.00% | — | 6y ago |
| 350x3588…21dd | For | 2 | 0.00% | — | 6y ago |
| 2B0x2b61…2c69 | For | 1.4 | 0.00% | — | 6y ago |
| 220x2212…c93e | For | 1.2 | 0.00% | — | 6y ago |
| A60xa657…3a61 | For | 1 | 0.00% | — | 6y ago |
| 2A0x2a4e…f008 | For | 0.8 | 0.00% | — | 6y ago |
| TOtoño.eth0x01a4…8ead | For | 0.3 | 0.00% | — | 6y ago |
| 790x79fa…03a6 | For | 0.3 | 0.00% | — | 6y ago |
| ED0xed8c…af6f | For | 0.3 | 0.00% | — | 6y ago |
| JTjthrack.eth0x44c6…aabd | For | 0.3 | 0.00% | — | 6y ago |
| 940x9429…6f47 | For | 0.1 | 0.00% | — | 6y ago |
| 7D0x7de0…a044 | For | 0.1 | 0.00% | — | 6y ago |
| 9F0x9fc3…2ebc | For | 0.1 | 0.00% | — | 6y ago |
| 840x84e3…5a95 | For | 0.1 | 0.00% | — | 6y ago |
| 3A0x3a74…1379 | For | 0.1 | 0.00% | — | 6y ago |
| E30xe3e1…54be | Against | 0.1 | 0.00% | — | 6y ago |
| 740x74aa…017a | For | 0.1 | 0.00% | — | 6y ago |
| E20xe248…ee9f | For | 0 | 0.00% | — | 6y ago |
| 750x75f3…3281 | For | 0 | 0.00% | — | 6y ago |
| D20xd26a…45b9 | For | 0 | 0.00% | — | 6y ago |
| 7B0x7bcb…b476 | For | 0 | 0.00% | — | 6y ago |
| 8A0x8a5e…85a4 | For | 0 | 0.00% | — | 6y ago |
| 7E0x7e11…c1de | For | 0 | 0.00% | — | 6y ago |
| 160x16a6…38c4 | For | 0 | 0.00% | — | 6y ago |
| DC0xdcc9…0ff1 | Against | 0 | 0.00% | — | 6y ago |
| E80xe838…b11d | For | 0 | 0.00% | — | 6y ago |
| BE0xbe40…a9d5 | For | 0 | 0.00% | — | 6y ago |
| 970x9752…ea32 | For | 0 | 0.00% | — | 6y ago |
07Forum
- Governance Proposal 22: Borrow Limits Comptroller Patch (Renamed to Borrow Caps) ↗discourse · high confidence
Arguments for
- Implementing borrow caps per market reduces the risk of catastrophic protocol loss (e.g., from an infinite-mint style exploit) by limiting how much of a market can be borrowed.— arr00, blck
- A community-developed feature with a self-issued bounty from protocol reserves sets a positive precedent/template for future community-driven protocol upgrades without needing a centralized development fund.— rleshner
- Rewarding the community developer for building the feature helps incentivize further community contributions to the protocol.— arr00
Arguments against
None surfaced.
Unresolved concerns
- No concrete framework or values had been established for what the actual borrow cap limits should be once the guardian mechanism goes live.— mosayeri, arr00
- The $5000 (2360 SAI) bounty amount arr00 proposed for himself had no precedent and was left open for community input, but no one weighed in on whether the amount was appropriate.— arr00
- Concern about verifying the audit/peer-review steps and finalizing the contract before submitting the on-chain proposal was raised, requiring extra rounds of redeployment and testing.— rleshner, arr00
Notable participants
- arr00Proposer and lead developer who built the Borrow Cap feature, iterated on the code based on feedback and audit, and ultimately submitted the governance proposal.
- rleshnerRaised the need for audit/peer review verification and highlighted the governance significance of the community bounty approach.
- jaredIndependently simulated the deployed contract on a mainnet fork to verify borrow cap functionality and gas cost impact.
- blckVerified on two occasions that the deployed contract bytecode matched the GitHub PR code.
- jaysonSuggested renaming the feature from 'Borrow Limit' to 'Borrow Cap' to avoid confusion with existing UI terminology, which was adopted.
- mosayeriRaised a follow-up question about developing a framework for setting actual borrow cap values.
Generated by Kvorum
08Similar proposals
- aaveexecutedBorrow Cap Reductions on Aave V3 Ethereum75%
- aaveexecutedSupply and Borrow Caps Update - LUSD - v3 Ethereum69%
- aaveexecutedChaos Labs Risk Parameter Updates - Decrease Supply and Borrow Caps on Aave V365%
- compoundexecutedcETH Risk Mitigation65%
- aaveexecutedUpdate MAI Caps Aave Polygon V3 pool64%
- aaveexecutedAave V3 Ethereum MKR Debt Ceiling Update63%
- aaveexecutedReinstate Supply and Borrow Caps on Aave V3 Gnosis Instance63%
- aaveexecutedChaos Labs Risk Parameter Update - MAI Aave V363%
- aaveexecutedIncrease cbBTC Supply Caps62%
- aaveexecutedIncrease weETH Caps on Base62%