[ARFC] Optimism Create ETH E-Mode
Vote Result: YES
Rationale
On-chain data shows that there is a clear demand for yield generation by borrowing wETH and acquiring more wstETH to loop, which will lead to increased revenue generation for Aave as users will be able to enter yield maximising strategies with greater capital efficiency. Moreso, Gauntlet and Chaos Labs are both in support. Therefore, we will vote YES in favour of this proposal.
[ARFC] Optimism v3 Supply Cap Update
Vote Result: YES
Rationale
There is a clear need to increase the supply cap for wstETH on Optimism v3, given the current utilisation of >90%. We are in agreement with Gauntlet to threshold the supply cap to 50% of the local supply which in this case is 18,000. This will also allow for the change to be implemented via the Risk Council as per the AIP-234 vote, and even if this supply cap is reached, the Risk Steward can modify caps every 5 days. This scenario is more efficient for the Aave DAO, given the delays to go through Snapshot and AIP votes. Therefore, we will vote YES in favour of increasing the supply cap to 18,000 units.
[ARFC] Polygon Supply Cap Update 23.05.2023
Vote Result: YES
Rationale
The previous vote shows that there is a consensus on the maximum potential supply cap, which is 75%, in case of MaticX deposits increasing significantly. With that in mind and in respect of the fact that the previous supply cap filled up rapidly, we support Chaos Labs’s conclusion to raise the supply cap to 38M.
Price Feeds Operational Update
Vote Result: YES
Rationale
The update creates more consistency in pricing methods of LSTs on Aave, which will allow the growth of strategic assets for the Aave DAO while maintaining the highest safety standards. Therefore, we will vote YES in favour of this proposal.
[TEMP CHECK] Safety Module Upgrade Part II - Asset Diversity, SM Categories & Slashing Updates
Vote Result: YES
Rationale
This proposal allows for the Aave DAO to accumulate strategic assets in its treasury. Adding stable LP tokens as a category generates a significant amount of the coverage as 60% of the TVL can be slashed with very low price impact across the broader ecosystem. The SM can be diversified to include Curve and Convex Finance risks and not only cover Balancer risks, reducing the risk of the SM. Moreover, adding wstETH as a single asset improves capital efficiency and allows users to earn a higher overall APY. Adding new assets also reduces the amount of liquidity mining done by Aave and reduces sell pressure on the AAVE token. The Volatile LP tokens will generate higher yield for LPs, making it an interesting category to add to the SM, and for the Stable LP tokens, by integrating a GHO pair to the SM, Aave will help bootstrap GHO adoption through incentivised liquidity and will also earn revenue from the GHO borrowing rate.
While there is risk from the potential price divergence of LSTs in the Safety Module, this is mitigated by the divergence having significantly reduced recently and the liquidity for stETH being very deep, as mentioned in the post.
Therefore, we will vote YES in favour of this proposal.
[TEMP CHECK] Safety Module Upgrade Part III - Enable Gauges on BPT in Safety Module (smBPT)
Vote Result: YES
Rationale
It is important for Aave to have strategic assets in the treasury, which AURA is; this is not a consequence of the SM upgrade, but implementing the smBPT gauge would allow for more of these assets to be collected. Moreso, this strategy is shorter-term and flexible, and can be changed as per the community’s decision when needed. As shown in Part IV here, implementing the smBPT gauges and utilising the AURA strategy has the potential to increase cover from $119M to $175M and reduce the cost of insurance from 30.02% down to 17.23%. If users receive BAL and AURA, the selling pressure is externalised only from AAVE, and reducing the liquidity mining budget helps reduce AAVE token inflation and selling pressure on the token. This strategy also incentivises users to deposit into the SM with multiple assets, increasing cover for Aave.
A few negatives are the risks from Balancer gauge and Aura smart contract risk exposure, and from the upgraded SM contracts having greater smart contract risk than in the current implementation. This can be mitigated with comprehensive smart contract audits, which the DAO will have to bear the cost for. However, these costs can also be mitigated if Aave receives AURA in exchange for the audit costs being borne by Aave, which will increase yield and allow higher voting power. As discussed earlier, accumulating strategic assets like AURA and BAL would be beneficial for Aave in the longer term.
Therefore, we will vote YES in favour of this TEMP CHECK and look forward to hearing the community’s opinions on these proposals from Llama as well.
[ARFC] Add fUSDC to Ethereum v3
Vote Result: YES
Rationale
This proposal has been implemented with the conservative parameters outlined by Chaos Labs which we are in agreement with. Listing fUSDC in isolation mode will reduce the risk of unhealthy liquidations by only allowing stablecoin borrowing, and allows for more data to be gathered about fUSDC before setting more aggressive parameters. The supply cap of $4.5M is sensible since it allows for half of the total supply to be liquidated at once. Setting conservative initial parameters somewhat mitigates the ‘unknown’ risks of fUSDC, i.e., Flux Finance and OUSG being nascent, and the protocol and its governance being untested. It allows Aave to gather data about fUSDC and allows for OUSG and Flux to grow further before being listed outside of isolation mode on Aave v3. Therefore, we will vote YES in favour of this proposal.
[ARFC] Add RPL to Ethereum v3
Vote Result: YES
Rationale
RPL is the native governance and utility tokens of the one the largest decentralised liquid staking protocols (and one of the largest liquid staking protocols). Adding it to Ethereum v3 will allow it to be borrowed for voting purposes (governance) and to deploy staking pools (utility). The suggested conservative risk parameters appear sensible in light of the market cap and trading volume of the token, and moreover, are supported by both Chaos Labs and Gauntlet. A couple of risks are that adding RPL in borrow mode may leave it vulnerable to attack vectors given the relatively low trading volume, particularly in light of the low on-chain 24H trading volume of around $720K. Moreover, there is a risk that the Slope2 figure is potentially not high enough to consistently deter borrowing beyond the UOptimal point. However, this is mitigated by Gauntlet and Chaos Labs monitoring the RPL borrow usage and potentially recommending a steeper Slope2 parameter if users borrow close to 100% of total supply.
Therefore, we will vote YES in favour of this proposal.
[ARFC] Polygon v3 Supply Cap Update 2023.05.21
Vote Result: 40M UNITS - CHAOS LABS
Rationale
Small, incremental increases in supply caps for stMATIC and other assets have clearly been filled up quickly, leading to governance overhead and a significantly worse user experience for depositors, limiting the growth of Aave and of revenue sources to the protocol. We have already implemented conservative approaches in the past that have shown to be too conservative, and it is necessary to be more risk-on to meet the demand for depositing stMATIC. Increasing the supply cap to only 32M is too low and will not fulfil demand - there is a need to balance risk with user experience and demand, and increasing the cap to only 32M will lead to imbalance. Lastly, while Gauntlet is not in favour of the increases, Chaos Labs is, which gives us confidence especially given the stress tests conducted simulating depeg scenarios.
Therefore, we will vote YES in favour of the 40M units option presented by Chaos Labs.
BUSD Offboarding Plan Part II
Vote Result: YES
Rationale
This is the on-chain vote for this Snapshot proposal that we voted in favour of according to our rationale here. Therefore, we will vote in favour of this AIP as well.
[TEMP CHECK] Aave V3 Deployment on Base
Vote Result: YES
Rationale
As a new Layer 2 solution built on the OP Stack and incubated by Coinbase, thus potentially providing access to its huge user base (110M+) and asset base ($80B+), it makes sense for Aave to deploy on Base. This captures the growth and interest of Coinbase users and opens up numerous revenue opportunities for Aave. Right after the announcement of Base, there has been a lot of user activity on the chain which has the potential to introduce new, valuable users to DeFi and Aave. Base has also shown impressive retention for a blockchain, with ~70,000 unique wallets returning to Base for subsequent transactions within one day. Deployment on Base enables also DeFi rails for Coinbase. Therefore, we will vote YES in favour of this proposal.
[ARFC] Add ARB to Arbitrum Aave v3
Vote Result: YES
Rationale
Given that the TEMP CHECK successfully passed, the proposed risk parameters by both Gauntlet and Chaos Labs seems reasonable in line with prior data to assure a stable ARB pool. Therefore, we will vote YES in favour of this proposal.
Update Mai Token Implementations, Unpause & Enable Flashloanable
Vote Result: YES
Rationale
This is a simple fix to resolve issues with repayments of MAI on Aave v3 Arbitrum and Optimism. Given that the proposal does not create a meaningful risk to the Arbitrum and Optimism instances and is straightforward, we will vote YES in favour of this proposal.
Deprecate Aave V2 AMM Market
Vote Result: YES
Rationale
This is the on-chain vote for this Snapshot proposal that we voted YES in favour of according to our rationale here. Further, given that no user liquidations will occur only due to the assets being frozen, we will vote YES in favour of this AIP.
Add LUSD to Arbitrum Aave V3
Vote Result: YES
Rationale
This is the on-chain vote for this Snapshot proposal that we voted YES in favour of according to our rationale here. Therefore, we will vote YES in favour of this AIP.
[ARFC] Add USDP to Aave V3 Ethereum
Vote Result: YES
Rationale
Given that the TEMP CHECK successfully passed, the proposed risk parameters by Chaos Labs seems reasonable in line with prior data. Therefore, we will vote YES in favour of this proposal.
[ARFC] Add GUSD to Aave V3 Ethereum
Vote Result: YES
Rationale
This proposal is in alignment with the multi-phased plan proposed by Chaos Labs previously to facilitate a seamless and successful migration from Aave V2 to V3 on Ethereum. We believe that the listing of GUSD in isolation mode will be a necessary step in the process of the migration and should be considered.
Polygon Supply Cap Update
Vote Result: YES
Rationale
This is the on-chain vote for this Snapshot proposal we voted in favour of according to our rationale here. Therefore, we will vote YES in favour of this proposal as well.
[TEMP CHECK] Pyth to Support AAVE on Optimism as a Secondary Oracle
Vote Result: YES
Rationale
Having looked over this proposal, we are in alignment on incorporating Pyth as a secondary oracle on Optimism. Resiliency, especially for key infrastructure like oracles, is critical. Pyth as a backup to be used only if Chainlink goes down or faces issues makes sense to us, as does this deployment as a secondary oracle on Optimism as a trial for Pyth to be used more broadly across the Aave ecosystem.
Including Pyth as a secondary oracle on Optimism increases Aave’s resilience and adds much-needed competition to the oracle space. Pyth is a robust, proven oracle with its data sourced from multiple reputable providers and has already proven itself on Optimism with its function as the principal oracle on Synthetix. Moreover, the integration work will be minimal since Aave already has the notion of a backup oracle provider that Pyth can cleanly fit into. The forum discussion shows wider alignment across the community about incorporating Pyth as a secondary oracle, and as described by @Marin, Pyth has taken a conservative and mature approach by aiming for the secondary oracle position and one chain before moving toward a higher position, which demonstrates their deep understanding of the risks associated with oracles.
Given the above, we will vote YES in favour of this proposal.
[TEMP CHECK] Aave v3 MVP Deployment on Scroll Mainnet
Vote Result: YES
Rationale
Expanding Aave’s presence across the L2 ecosystem is necessary. Firstly, this proposal is only for an MVP with conservative parameters, and has been verified by Gauntlet and Chaos Labs. It will add minimal risk to Aave. Secondly, the commitment to the Safety Module is well-noted and further minimises risk for Aave. Thirdly, Scroll’s EVM-equivalence and bytecode equivalency means that it should be minimal effort to deploy Aave on the chain. Lastly, Scroll being made up of builders and users across every continent will help Aave expand and bring in new users and liquidity to the Aave ecosystem. Therefore, we will vote YES in favour of this proposal.