[ARC] V3 Supply Cap Recommendations for Uncapped Assets
Vote Result: YES
Rationale
Although the decision logic remains to be further explained, an initial setting is acceptable and the community can always make amendments dynamically. It is important to set initial supply caps and the recommendations seem in line with the data in the tables, however the logic needs to be further expanded upon. Therefore, we are voting in favour of this proposal.
[ARC] Aave V3 Ethereum Deployment - Assets and Configurations Part 1
Vote Result: YES
Rationale
Since this proposal includes assets from Aave V2, and Gauntlet’s latest proposal takes into account community feedback and makes appropriate use of the isolation feature on V3 to include as many assets in as controlled a manner as possible, we are voting YES in favour of this proposal. A counterpoint is that some assets may be controversial, e.g., ENS and DPI as noted by Fig from Flipside Governance. However, if these assets are risky, and excessive risk is brought on to the system, the parameters can be changed later, and prior to adding these assets on V3, borrow and supply caps will, in all likelihood, be implemented.
[Temp Check] Add Support for cbETH for Aave V3
Vote Result: YES
Rationale
cbETH is liquid staked ETH maintained by Coinbase - this is a high quality asset that should be onboarded as collateral to Aave to diversify liquid staking exposure. Aave v3 will enable risk control features that should counteract concerns of (currently) low trading liquidity. The cap can be scaled up over time as liquidity conditions improve, and Coinbase is working with top external validators like Figment and Stake, among others, as can be seen in the whitepaper, reducing centralisation risks. Their liquid staking protocol (Alluvial) also offers an alternative form of staked ETH called lsETH which is decentralised. Moreover, cbETH is very likely to scale. Therefore, it may be beneficial to list the asset on Aave from the very beginning, help it scale, and benefit from the added volume and fees.
Therefore, we are voting YES in favour of this proposal.
Activation of a ParaSwap Fee Claimer Contract
Vote Result: YES
Rationale
This proposal is uncontroversial and seeks to claim ~$70k in unclaimed Paraswap fees from the Swap Collateral and Repay with Collateral features on the Aave IPFS interface. There is no negative side effect from the protocol. While there is a slight risk since the code has not been audited by an external provider, the code itself is simple and should not require such an audit. Therefore, we are voting in favour of this proposal.
Risk Parameter Updates for Aave v2 Ethereum Liquidity Pool
Vote Result: YES
Rationale
This proposal enables Aave to more granularly control the response to recent market events compared to freezing entire assets. While it was necessary to pass AIP-121, and V3 will allow for more granular control of risk for assets on Aave, the timeline for deployment is still relatively unclear and it may be months away. In the meantime, it benefits both users of Aave and brings revenue to the protocol by continuing to utilise v2 and unfreezing assets where it is safe to do so. Moreover, non-stable assets are only being listed as collateral and the proposal does not allow for these assets to be borrowed, limiting risk for Aave and mitigating the risk pointed out by @digi7287.
Therefore, we are voting in favour of this proposal.
Aave <> StarkNet Phase I. Release
Vote Result: YES
Rationale
This proposal is fairly uncontroversial, and seeks to deploy the Aave <> StarkNet bridge that has already been worked upon and created. The proposal has been tested using the available tools to be as close as possible to fork both Ethereum and StarkNet mainnets. Moreover, it has been tested by all security providers and all integration testing has been done. It would be important to pass this proposal to complete the goals of this experiment: increase Aave’s user base, test out new monetisation models for LPs, expand Aave to StarkNet, and understand how technically suitable it is to have Aave software on a non-EVM network.
Therefore, we are voting YES in favour of this proposal.
[ARFC] Aave DAO Policy Change: Halt Listings on all Aave v1 & v2 Non Permissioned Deployments
Vote Result: YES
Rationale
This proposal seeks a move away from Aave v2 and to Aave v3 which has better risk management parameters and controls. Given current market conditions, plus the imminent deployment of Aave v3 ETH, it makes sense to stop supporting deployments on v2 given the relatively higher risk compared to the reward it brings to the protocol. This decision would also encourage and incentivise the move to Aave v3, which is necessary for the continued growth of the protocol.
Therefore, we are voting YES in favour of this proposal.
V3 Borrow Cap Recommendations (Fast-track)
Vote Result: YES
Rationale
We understand that this is a fast-track proposal to add borrow caps to seven currently uncapped assets and amend the borrow caps of a further nine assets across various blockchains. The proposal follows on from several others submitted in response to the significant drop in market prices and liquidity over the past few months. This reduced liquidity introduces liquidity risk in the event loans become under-collateralised and underlying assets need to be liquidated.
Chaos Labs has analysed the target assets individually and considered their liquidity sources (which inform the cost of market manipulation) and oracle composition (which informs the cost of oracle manipulation). The target parameters are set to ensure that Aave can readily liquidate collateral assets in the market and that bad debt will be highly unlikely to accrue.
The caps are set well above current levels of borrowing so appear to support organic levels of borrowing activity, while defending against risks in extreme market conditions. The ceiling is lower for more illiquid assets, which is in line with what we would expect. While we have not seen Chaos Lab’s detailed analysis and so cannot comment on specific numbers, we understand the approach they have taken and consider it to be sound.
Risk Parameter Updates for Aave v2 Ethereum (DAI LT and LTV)
Vote Result: YES
Rationale
This is a proposal by Chaos Labs to update DAI’s risk parameters in Aave v2 Ethereum. Specifically, the proposal seeks to reduce the LTV and LT parameters to defend against potential attack vectors in light of the current market volatility, while also incentivising migration to Aave V3 with its E-mode and other enhanced mitigation tools.
We support the initiative to secure the system and ensure sufficient liquidity in the event of price manipulation, however the timing and process of implementation needs to be considered, even though the impact will be lower than for USDC. Overall, given the dollar value of liquidations and user losses is low and relatively insensitive between the two options, we propose going with the more aggressive plan of a 300bps LT decrease & LTV 75%.
Risk Parameter Updates for Aave v2 Ethereum (USDC LT and LTV)
Vote Result: YES
Rationale
This is a proposal by Chaos Labs to update USDC’s risk parameters in Aave v2 Ethereum. Specifically, the proposal seeks to reduce the LTV and LT parameters to defend against potential attack vectors in light of the current market volatility, while also incentivising migration to Aave V3 with its E-mode and other enhanced mitigation tools.
After analysing Chaos’ simulation for this proposed parameters, and considering we believe that the protocol’s security and risk mitigation are key to its long term sustainability, we will vote for the option 150bps LT decrease & LTV 80%, since it balances risk mitigation while also minimising the number of executed accounts and thus liquidation value. As suggested by Chaos, we support going forward with this parameter reduction in small steps, assessing their real impact, and providing this information to the community to decide the next steps.
Risk Parameter Updates for Aave v2 Ethereum - LTs and LTVs for Long Tail Assets
Vote Result: YES
Rationale
Given the current market conditions, with low liquidity conditions in the market and the potential for long-tail assets to be misused, especially on Aave v2 Ethereum given its less granular risk controls, this proposal seems to be prudent from a risk perspective as well as an effective incentivisation mechanism to move usage across to Aave v3. The move to v3 is necessary and if users do want to use these assets with better and more controlled risk parameters, then directing them to use the assets on v3 is the most prudent decision. The proposal follows the guidelines from the Risk Off Framework and reduces the LT and LTV by a max of 3%. A step-wise reduction in LT/LTV is sensible and prudent and reduces risk while simultaneously not deprecating the borrowing experience to a large degree.
Moreover, Chaos has indicated that they will communicate the changes to the accounts in risk of liquidation in advance, and more recent data says that the implications for the 300 bps decrease are identical to those of a 150 bps at the moment for SNX. The total amount liquidated with the change will only be ~$36 across 2 accounts.
Therefore, we are voting YES in favour of this proposal.
[ARFC] Repay Excess CRV Debt on Ethereum v2
Vote Result: Use USDC to Acquire CRV
Rationale
When choosing between the two payment options, we consider the opportunity cost of deploying the fund and the consequence after paying out the money. Given that aCRV can generate a considerable amount of return in the future to offset the incurrence of debt, we recommend saving aCRV for now and use USDC to repay the debt.
Secondly, USDC and aUSDC has a combined value that is 3.6 times of that of excess debt before taking other stable coin reserves into consideration. Therefore, paying out the money will not cause a significant change in Aave’s asset positions, so it is a safe way to do so.
Thirdly, aCRV will be needed on v3 and to realise the highest ROI and maximise revenue, it is advantageous for Aave to hold veCRV and aCRV. Moreover, CRV in Aave v3 will be one of the highest passive non-stablecoin income for the DAO. Therefore, veCRV and aCRV are both important to Aave. Given these points, it makes greater sense to use USDC (which there is an abundance of in the treasury) to purchase the aCRV and minimise the need to purchase it on the open market for v3 at a later date.
Therefore, we are voting for the option to use USDC to acquire CRV.
[ARFC] Ethereum v2 Collector Contract Consolidation
Vote Result: YES
Rationale
Llama proposes consolidating asset types from the Aave v2 Collector Contract to USDC, and redeeming ammTokens from the Aave AMM. The AMM market’s revenue accrues to the collector contract. Via governance the collector contract can withdraw the aTokens (aDAI) to the underlying (DAI). When v3 is deployed, Llama intends to submit a subsequent proposal to deposit the withdrawn tokens into the v3 market.
We believe this proposal will help optimise asset holdings by reducing their price volatility risk, and by consolidating them into an asset (USDC) that has a greater utility for the DAO’s operations, since most of its costs are denominated in it. In addition, given the small amounts, the premium strategy proposed to incentivise arbitrage and asset swapping, we believe is the correct one.
We support the implementation of this proposal.
[ARFC] Receipt of Gauntlet Insolvency Fund
Vote Result: YES
Rationale
We appreciate Gauntlet honouring its commitment and fund proceeds will help to pay down part of the accrued bad debt.
Aave v2 ETH Interest Rate Curve Update
Vote Result: YES
Rationale
This proposal is the on-chain implementation of this Snapshot vote, which we had previously voted in favour of, with the only changes being to amend the parameters for Stable Borrowing in line with the changes to the Variable Borrowing rates. Given our previous rationale in voting for this proposal, and given the risk analysis done by Gauntlet as detailed in the forum post, we are voting in favour of this proposal as well.
[ARFC] Aave DAO Policy Change: Halt Listings on all Aave v1 & v2 Non Permissioned Deployments
Vote Result: YES
Rationale
This proposal seeks a move away from Aave v2 and to Aave v3 which has better risk management parameters and controls. Given current market conditions, plus the imminent deployment of Aave v3 ETH, it makes sense to stop supporting deployments on v2 given the relatively higher risk compared to the reward it brings to the protocol. This decision would also encourage and incentivise the move to Aave v3, which is necessary for the continued growth of the protocol.
Therefore, we are voting YES in favour of this proposal.
[Temp Check] Deploy Aave on Metis
Vote Result: NO
Rationale
There are three key reasons as to why we are voting NO for this proposal:
Security Concerns
Metis has not yet implemented its technical roadmap - data is not posted on-chain, and Sequencer rotation is not yet supported which reduces the security of the system. As pointed out by L2 Beat, without running the verifier dtl, independent observers cannot verify if the posted state root is correct if the data is not posted on-chain. Therefore, if data is missing from the MEMO lab’s storage, then there is no clear plan of action for independent users. When compared to Optimism/Boba, which Metis can be closely compared to given that it is an Optimistic Rollup, users can prove that the state root is invalid and notify the community that fraud is happening, and the community can respond in 7 days using social means. In the case of Metis, all users can do is to complain that, according to them, data is missing in the MEMO lab’s storage without knowing if the posted state root is valid or not. This reduces overall security for the system.
TVL & Activity
TVL on Metis is $42.87 million according to DeFi Llama. This would make it the chain with the smallest TVL on Aave and would not bring any significant users or revenue to Aave compared to the risk. Given current market conditions and significant lack of liquidity in the market, there could be price manipulation attacks that could leave bad debt on Aave. The risk vs. reward of spinning up Aave v3 on Metis does not seem to match at the moment.
Metis’ Current State of Development
As explained by @Peter88, one of the co-founders of Metis, there is only a high-level roadmap that can be provided by Metis at the moment. This indicates that Metis is still very early on in its development. Aave is a flagship DeFi protocol and should only deploy on chains with the highest level of security and user activity. At the moment, it seems as if Metis is a level below this and it may be more prudent to wait for Metis to further fulfil its roadmap.
Set LDO, stMATIC, MaticX and SD Emission_Admin for Polygon v3 Liquidity Pool
Vote Result: YES
Rationale
We understand this is a re-vote of an earlier proposal by Llama that failed to reach quorum. We support this proposal as it should bring additional income and incentives for users of these pools on Polygon v3. The payload has been reviewed by BGD Labs and deemed not to introduce any meaningfully new risk to Aave, given their permissions are fairly limited. We would want to understand more about the multisig setup but this is a relatively minor detail that does not preclude the passage of the vote.
[ARC] Updated: Gauntlet <> Aave Renewal
Vote Result: YES
Rationale
In line with our past experience with Gauntlet, where they provide superior analytical services, it is our strong belief that Aave would greatly benefit from continuing the relationship with Gauntlet. They will be expanding their services to cover V3 Aave developments including all chains and features. The existing working relationship with Gauntlet is great and the new proposal only seeks to improve this. The renewal price is also lower than the initial price paid for this year, and highlights their commitment to working flexibly with Aave, as does the flexibility they have demonstrated around scope and pricing model after feedback was received for their initial proposal.
Freeze Aave V1
Vote Result: YES
Rationale
This is the on-chain vote for this Snapshot vote, in which we voted for Option 1 which passed. The proposal was non-contentious on Snapshot and there has been no negative discussion in the community forum. Therefore, we are voting YES in favour of this proposal.