The success of the Avalanche V3 market showed some protocol inertia inefficiency.
USDC deposit cap has been reached in less than 10 days and the regular framework to increase it would be to post a governance thread for 5 days, then start a snapshot vote that start 24h after posting for a vote that last at least 3 days, then gather proposition power of 80k Aave then post an AIP for a vote that last at least 5 days.
Even with perfect sync and full community support, the full process would take a couple of weeks. In reality a month is more likely as a timeframe.
This inertia is good for protocol safety but it hurts protocol growth and attractiveness. I would suggest the community to consider adopting a fast-tract process for V3 markets leveraging the current possible community enforcement capability on most V3 markets.
Suggested fast-track process :
Governance thread for 24h
Snapshot with immediate vote open for 48h
Community multisig enforcement
Suggested scope & limitations of the fast-track process :
-Fast-track can only act on Supply & Borrow caps with a 50% change
-Fast-track requires an 80k AAVE quorum
Hey Marc, I agree with the need for a fast-track process in order to prevent the halting of rapidly growing markets. The Avalanche markets do not currently require an AIP, though (Aave guardians act on snapshot results). That being said, would the same quorum need to be met in order to pass a fast-track proposal (320K Aave yes)?
(I have recently proposed that the Avalanche proposals not requiring an AIP reflect the quorum of AIP’s to be considered ‘passed’ here. I have been waiting for more interaction with this, but given the rapid growth of Avalanche on Aave v3, it appears that this document should be fleshed out ASAP. I will work on that and have it posted in the next few days!)
Supply and borrow caps are critical in my opinion in practice in 2 aspects:
On listing of a new asset. Depends a lot on the asset, but the caps are a perfect generalized constraint to cover almost any wide problem for the pool. This right now is totally controlled by the “normal” governance framework, as caps definition is part of the listing.
On first raise of cap. Here the rationale of the raise should be quite strict, as there should be a clear reason on why the caps should be different: maturity (assets with long history, where first cap was cautious protection) or technical changes on the asset (e.g. removal of minting capabilities).
After those, and exceptions apart, usually the process can be streamlined. The Avalanche scenario is completely clear:
Initial cap due to being a new pool deployed (v3), not even because of the nature of the assets themselves.
Pool with some maturity, known assets, raise of caps.
Current $2B supply cap on USDC, no difference in practice on having $4B.
So basically the governance framework is just a blocker at the moment in terms of growth for this specific case, without any need, and that should never happen. So fully agree on the proposal by @MarcZeller, but I would also propose the following changes:
This process can only be applied to assets listed for at least 2 weeks.
Supply & Borrow caps can be increased from 30% to 100%. There should be a proper reason to go to the highest tier.
The process should take maximum 4 days. Meaning that in networks currently with Guardian, the Guardian should prepare the signing in advance, to assure execution not more than 24h after Snapshot closes positively.