Gas Rebate for Recognized Delegates
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, as the original authors of this proposal, we will vote YES in favour of this AIP as well.
[ARFC] Add rETH Aave v3 Optimism
Vote Result: YES
Rationale
Adding rETH would drive material borrowing revenue to Aave and diversifying LSTs on Aave and allows Aave to position itself as a neutral platform, driving volume and engagement. rETH is already listed on other deployments and should be listed on Optimism as well. This proposal is supported by Chaos Labs and their suggested change to the borrow cap has been implemented by Llama. Therefore, we will vote YES in favour of this proposal as well.
[TEMP CHECK] Aave V3 Deployment on Linea Testnet
Vote Result: YES
Rationale
As Linea is seeking to be an EVM equivalent utilising zk technology but still works on the Ethereum L1 solidity code it would be worthwhile to join as a launch partner with their firm commitment towards decentralisation and innovation.
[ARFC] Set Metis Foundation Wallet as Emission Manager for METIS Token on Aave V3 Metis Pool
Vote Result: YES
Rationale
As delegates we believe this proposal aligns with the goals of expanding the Aave ecosystem and building its user base.
[ARFC] Aave Governance v3 (Governance, a.DI, Robot v3)
Vote Result: YES
Rationale
This proposal enhances Aave governance and allows for it to be leading the space in terms of governance. While there could be potential security concerns with the upgrade, the benefits far outweigh them and as delegates we are in favour of this proposal.
[ARFC] Gauntlet Risk Parameter Updates for Ethereum v3, Arbitrum v3, Ethereum v2
Vote Result: YES
Rationale
As delegates we support the constant updates to risk parameters to keep Aave secured.
GHO Mainnet Launch
Vote Result: YES
Rationale
As delegates we seek to boost the Aave ecosystem and believe this proposal aligns with this goal. In line with how we have voted previously, we will vote YES in favour of this AIP to bring GHO to mainnet.
Gauntlet Cap Updates for Ethereum, Optimism Aave v3
Vote Result: YES
Rationale
Since supply cap utilisation has been 20%, 5%, and 1% respectively for BAL and LINK on Ethereum v3 and OP on Optimism v3 over the last 3 months, lowering the caps when utilisation is low is sensible and can be adjusted back up when demand is higher. Therefore, we will vote YES in favour of this proposal.
Add RPL to Aave V3 Ethereum Pool
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 as well.
Make USDT a Collateral for Aave V3 ETH Pool
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 as well.
Chaos Labs Risk Parameter Updates - Aave V2 Ethereum
Vote Result: YES
Rationale
This is the on-chain vote for this Snapshot proposal. While we voted for the MODERATE option, the community has decided to go with the AGGRESSIVE option. We will respect their decision and vote YES in favour of this AIP to implement the AGGRESSIVE option.
[TEMP CHECK] Treasury Management - Introducing StrategicAssetManager
Vote Result: YES
Rationale
The intention here to reduce governance redundancy is appreciated, so we vote YES here. However, the key issue that we have concerned is how much constraint should be put around the AssetManager role. We are looking forward to more specifications on what the role can do in future [ARFC] publications and make our final decision.
[ARFC] Aave V3 Deployment on BNB Chain
Vote Result: YES
Rationale
Deployment of Aave on the BNB chain will increase its exposure to new users and opportunities brought by the BNB ecosystem. With appropriate parameters settings, we will not hesitate to vote for YES.
[ARFC] GHO Steward - Agile Parameter Changes
Vote Result: YES
Rationale
Most of the general functions of the Steward align with the Risk Steward that is already implemented and this role is necessary to enable GHOâs safety upon launch. It is more important to vote to enable these functions now and then iterate upon the features of the GHO Steward - while we agree with ACI on their suggested changes to the Steward, these can be made in another proposal and it is better to enable the role as quickly as possible.
A counterpoint is that the configurations of the Steward are too conservative and need to be more agile, and Chaos and Gauntlet provide a good level of checks and balances with the feature of a Snapshot available if they disagree. While we generally agree with this, we believe it is better to improve upon the Stewardâs feature set than wait for another proposal to be passed to enable the Steward itself.
Therefore, we will vote YES in favour of this proposal.
Bug Bounty May 2023
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 as well.
Add rETH Aave v3 Optimism
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 as well.
MaticX Polygon Supply Cap Update
Vote Result: YES
Rationale
While Gauntletâs rationale for waiting is not wrong, waiting for community alignment on the killswitch options may take time and would inhibit Aave from earning revenues from the demand to supply MaticX on Polygon. Since one risk provider agrees with the changes, we are comfortable voting in favour of the increase. Therefore, we will vote YES in favour of this proposal.
[ARFC] - Chaos Labs Risk Parameter Updates - CRV Aave V2 Ethereum - 2023.07.10
Vote Result: YES
Rationale
The suggested risk parameter adjustments are necessary given the large CRV position on Aave in an illiquid market. The Aggressive option would reduce governance bloat and de-risk CRV quicker while the liquidation value for this option is still very low. Moreover, the proposers, Chaos Labs, recommend the Aggressive option. Therefore, we will vote YES in favour of the Aggressive option here.
[TEMP CHECK] GHO Stability Module
Vote Result: YES
Rationale
There is a need for the GSM to protect GHO and all of the features suggested are appropriate. A lot of features improve upon current PSM designs, so this must be commended. Since this is just a TEMP CHECK, we are comfortable with this proposal, but we encourage incorporation of Chaos Labsâ feedback at the ARFC stage, as well as that of Angle Protocol and @sogipec. Moreover, a discussion is necessary around adopting the Transmuter so it would be good if there was some feedback on that by @AaveLabs and the rest of the community. If it reduces development effort and the code is robust, it could be extremely useful and quicker to roll out.
In light of all the above, we will vote YES in favour of this proposal.
[ARFC] TUSD Offboarding Plan
Vote Result: YES - LOWER LT TO 75%
Rationale
With the recent proposals to de-risk TUSD that we have voted in favour of, this one makes sense as well. Weâre also in favour of Option 1 since it does not trigger any forced liquidations. Therefore, we will vote YES in favour of this proposal.