[TEMP CHECK] Onboard BNBx on Aave V3 BNB Chain
Vote Result: YES
Rationale
Adding a BNB LST onto the BNB chain, especially the most used BNB LST, is logical. We welcome Chaos Labs’ opinion on the appropriate parameters with which to list BNBx. Therefore, we will vote YES in favour of this proposal.
[TEMP CHECK] Onboard sUSDe to Aave V3 on Ethereum
Vote Result: YES
Rationale
Given that this is a TEMP CHECK, it makes sense to explore the addition of sUSDe to Aave. It could be a lucrative asset for Aave given the interest in Ethena currently, and the fact that there is a $100M Curve pool is an indicator of this. Moreover, the synergies with GHO are appealing, but should be made clearer. A concern is that the sUSD APY is extremely high - where this emanates from is not clear and may bring undue risk to the Aave protocol.
We await a detailed analysis of sUSDe from Chaos Labs - the stablecoin is relatively new and untested and may bring quite a lot of risk to Aave, and we would want much more assurance in the ARFC stage that this is a risk/reward balanced asset to onboard onto Aave.
[ARFC] Set Aave Chan Initiative as Emission Manager for PYUSD on Aave V3 Ethereum Market
Vote Result: YES
Rationale
Setting the ACI as Emissions Manager for PYUSD on Aave v3 Ethereum makes sense. Therefore, we will vote YES in favour of this proposal.
[ARFC] Set Aave Chan Initiative as Emission Manager for sUSD on Aave V3 Optimism
Vote Result: YES
Rationale
Setting the ACI as Emissions Manager for sUSD on Aave v3 Optimism makes sense. Therefore, we will vote YES in favour of this proposal.
Ethereum v2 Reserve Factor Adjustment
Vote Result: YES
Rationale
This is the on-chain vote for this ARFC that we voted in favour of according to our rationale here. Therefore, we will vote YES in favour of this proposal as well.
addFlashborrowers
Vote Result: YES
Rationale
This proposal makes sense and we agree with ACI’s logic of making Aave more competitive for these strategic protocols who use flash loans. The lost revenue can be mitigated by increased borrow volume - this should be tracked, however, and if over time this is not the case then the relevant protocol should be removed as flashborrowers on Aave v3. We will vote YES in favour of this proposal.
Activation of A-C Prime Foundation
Vote Result: YES
Rationale
This is the on-chain vote for this series of proposals (TEMP CHECK, ARFC, AIP) that we voted in favour of under the LBS umbrella (for the ARFC and AIP, after abstaining for the TEMP CHECK) according to our rationales here, here, and here. Activating the A-C Prime Foundation and investing the $1m in the Anemoy Liquid Treasury Fund 1 via this off-chain Cayman Island foundation company aligns with the previous discussion. Therefore, we will vote YES in favour of this proposal.
GHO Borrow Rate Increase
Vote Result: YES
Rationale
Increasing the GHO borrow rate in this context makes sense - AIP-381 allows for 100bps increases every 7 days up to 9.5% if the monthly average price of GHO is outside the 0.995 to 1.005 price range, which it is currently. This AIP will align the GHO borrow rate with market rates which will maintain its attractiveness while helping the peg. Therefore, we will vote YES in favour of this proposal.
Set Price Cap Adapters (CAPO)
Vote Result: YES
Rationale
The correlated asset price oracle is a great addition to Aave’s armour of reducing risk across its most used assets. It is important to protect against ‘black swan’ type events like unexpected inflation of the underlying asset or the underlying rate oracle is manipulated to the downside, which leads to unfair liquidations. Chaos Labs and Gauntlet are both in favour, and this proposal in combination with the upcoming killswitch mechanism will go a long way in maturing how Aave handles risk of LSTs. Therefore, we will vote YES in favour of this proposal.
[ARFC] Emission Manager Framework Update
Vote Result: YES
Rationale
This is a non-controversial proposal that streamlines the Emission Manager onboarding process and allows incentives to be distributed more efficiently. There is little to no risk emanating from this proposal and therefore we will vote YES in favour of it.
[ARFC] - Remove ARB from Isolation Mode on Arbitrum Market
Vote Result: YES
Rationale
This move is a no-brainer given the improvement in ARB liquidity and the clear demand to use it as collateral given the 96% debt ceiling it has already reached on v3 Arbitrum. Moreover, ARB liquidity has improved significantly and Chaos Labs supports this proposal. Therefore, we will vote YES in favour of this proposal.
[TEMP CHECK] Onboard sUSDe to Aave V3 on Ethereum
Vote Result: YES
Rationale
This is a repeat of this TEMP CHECK that we voted in favour of according to our rationale here. Therefore, we will vote YES in favour of this proposal as well.
[ARFC] TUSD and BUSD Aave V2 Rate Amendments
Vote Result: YES
Rationale
This proposal ensures that the bad debt build-up on Aave v2 does not get excessive, especially given that the incentives to repay debt may not be realised. Chaos Labs’ solution is logical, and we will vote YES in favour of this proposal.
[ARFC] Stablecoin IR Curve Amendment on Aave V2 and V3
Vote Result: YES - AGGRESSIVE
Rationale
This proposal will align rates with market demand and brings Aave in line with other protocols, enabling Aave to be competitive in this market. The recommendation to increase rates to 14% makes sense, since this will mitigate short-term rate volatility (of which there is a lot at the moment) and will discourage deviations above uOptimal, which has been happening quite a lot recently. Slope1 can be reduced as and when sDAI rates revert or decrease over time, but it is more important to mitigate volatility at the moment and ensure Aave’s competitiveness with the DSR, Spark, and other protocols. Increasing the borrow rate will also increase revenue for the protocol, which is key to capture in this market. Increasing uOptimal to 92% also makes sense given that the utilisation rate is above the current uOptimal and has remained so over the last few months.
Therefore, we will vote YES in favour of the AGGRESSIVE option.
Aave Liquidity Committee Funding
Vote Result: YES
Rationale
This is the on-chain proposal for this Snapshot ARFC that we voted in favour of according to our rationale here. Therefore, we will vote YES in favour of this proposal as well.
[ARFC] BGD <> Aave Phase 3 (2 Scopes)
Vote Result: YES
Rationale
BGD Labs has been invaluable to Aave and this proposal is a no-brainer. We are especially excited about Code A - improving the SM is critical for Aave and especially improving AAVE tokenomics to acquire more value and distribute it to holders is key. We are supportive of the budget being denominated in GHO since this aligns service providers even more with the Aave DAO and increases usage of GHO. Therefore, we will vote YES in favour of this proposal.
[TEMP CHECK] Onboard Catapulta as Aave V3 Deployment Service Provider
Vote Result: YES
Rationale
Streamlining the deployment of Aave v3 on other networks is key and using Catapulta’s services would make deployment more straightforward while ostensibly reducing costs. David’s experience at Aave Companies / Avara is crucial and the fee of $15k per deployment seems reasonable, especially with the current status quo where BGD has to do a lot of work to deploy on another chain. Given that deploying across chains is critical for Aave, having a dedicated team working on this in a streamlined manner is logical.
[ARFC] Chaos Labs - Borrow Cap Reductions on Aave Ethereum - 03.11.24
Vote Result: YES
Rationale
Mitigating the volatility of long-tailed assets by reducing borrow caps for these assets, especially in such a high-volatility environment as the one we are in currently, will reduce risk for the protocol. Chaos Labs’ formula makes sense, especially given that it accounts for the max amount that can be safely liquidated in an extreme scenario.
One concern for us is that there should be a balance between having conservative borrow caps for these long-tail assets and the fees they generate. For example, if an asset generates fees above a certain threshold, then its borrow cap can be set on a case-by-case basis rather than reducing the cap to an amount which will significantly reduce the amount it is borrowed and in turn reduce revenue for the DAO in this lucrative market environment.
Given the above, we suggest a more granular approach towards these long-tail assets but do acknowledge the need to de-risk Aave v3 in this environment. Therefore, we will vote YES in favour of this proposal and hope that there is a framework created on the lines of what @EzR3aL has mentioned.
Generalized LT/LTV Reduction on Aave
Vote Result: YES
Rationale
Reducing debt asset volatility is important but only if it is balanced with incremental reductions in LT combined with sufficient notice to users, which will mitigate the amount of liquidations while reducing the potential of bad debt on Aave. Implementing this LT/LTV reduction in incremental steps while constantly giving the community enough time to react and de-risk their positions is important. The first increment of 1% leading to a liquidation of only $9k in the first step is acceptable and the community has had enough notice to de-risk since this proposal was published on 28th Feb. Therefore, we will vote YES in favour of this proposal.
[ARFC] Onboard osETH to Aave V3 on Ethereum
Vote Result: YES
Rationale
Listing osETH is important since StakeWise is built to encourage solo staking, which is important in decentralising Ethereum. The token is over-collateralised by design, which limits risk. Increasing osETH demand and usage is mutually beneficial for Aave and StakeWise, while Chaos Labs is in favour of this proposal, which is why we will vote YES in favour of this proposal.