[ARFC] Proposal to Allocate AGD Treasury to Aave DAO
Vote Result: YES
Rationale
Given that the AGD has wound down and the current state of the Aave ecosystem, we are in favour of allocating the leftover funds to the treasury. Therefore, we will vote YES in favour of this proposal.
[TEMP CHECK] Deploy Aave v3 on Ink
Vote Result: YES
Rationale
Given Kraken’s user base and the potential to expose these users to Aave, it makes sense to further judge the benefit of deploying on Ink at the ARFC stage. However, given the low onchain metrics currently, we’d also like to see a revenue analysis on whether it makes sense to deploy at this stage for Aave. Therefore, we will vote YES in favour of this proposal.
[TEMP CHECK] Recognize HyperLend as a Friendly Fork
Vote Result: YES
Rationale
Hyperlend’s proposal to be recognised as a friendly fork is in alignment with Aave’s Fork Framework. We’re generally in favour of forks and increasing proliferation of Aave’s tech, so we will therefore vote YES in favour of this proposal.
stkBPT Incentives
Vote Result: YES
Rationale
Given the impending Umbrella upgrade, we think it makes sense to re-enable stkBPT incentives emission for now given its role as a supply sink for AAVE. Therefore, we will vote YES in favour of this proposal.
[ARFC] Core & Base - BTC Correlated Asset Update
Vote Result: YES
Rationale
Increasing the growth of LBTC across Aave Core and Base v3 aligns with the growth it has shown as the leading BTC LST in the market. Creating all of these eModes on Core will allow for increased leveraged looping with all of the other BTC wrappers and therefore will add to Aave’s revenue. Both risk providers are in favour of this proposal and their recommendations have been implemented in the version up for vote. Therefore, we will vote YES in favour of this proposal.
[ARFC] Update AAVE LTV and Liquidation Threshold Percentages
Vote Result: YES
Rationale
Given that both risk providers think that increasing the AAVE token’s LTV and LT parameters is acceptable from a risk perspective, albeit with different parameters to the initial proposal, we are fairly comfortable with this change. Only $2.5M would be liquidated if AAVE price drops by 25%, which is much higher than the 17.25% largest daily drop over the last year. AAVE users are generally conservative, have high collateralisation, and high health scores, which reduces risk as well. However, it is important to note that there is a clear risk of bad debt generation, especially with AAVE being a native token that could lead to a loop of token price declines in a very heated market.
Therefore, we will vote YES in favour of this proposal.
[TEMP CHECK] Deploy Aave v3 on Bitkub Chain
Vote Result: YES
Rationale
Bitkub is the largest CEX in Thailand and exposing its users to Aave through this deployment seems like a good idea. The POL commitments also seem acceptable on the face of it. We’d like to see this proposal further analysed at the ARFC stage, not only from a risk angle but also from a revenue generation perspective, i.e., the onchain metrics of Bitkub Chain and the revenue Aave could generate by deploying on it.
We’d also like to see the proposal author’s plans on how they plan on integrating Aave into their applications and marketing it to users - the opportunity of gaining access to Thai users is strong, but we’d like to see more details provided on how this will be executed in practice.
Therefore, we will vote YES in favour of this proposal.
Edit: This vote was cancelled after we posted our rationale.
[ARFC] Add sUSDE to Aave V3 Base Instance
Vote Result: YES
Rationale
Adding sUSDe to Base will allow Aave to support Ethena’s growth on Base, and allow for utilisation of the borrow stables / swap for sUSDe strategy. We are wary of the low supply and liquidity of sUSDe on Base and the risks emanating from that. Therefore, conservative parameters at first, observing performance, and then improving parameters makes sense to us.
Therefore, we will vote YES in favour of this proposal.
[TEMP CHECK] Add Support for Wrapped Origin Sonic (wOS) to Aave v3
Vote Result: YES
Rationale
Preparing the Aave v3 Sonic deployment by seeding it with in-demand assets is a good strategy. We’d like to see this proposal explored further from a risk (especially from the OS/S price feed angle) and revenue perspective at the ARFC stage, and would appreciate more numeric detail from the proposal authors about the level of TVL/revenue expected from this onboarding. Therefore, we will vote YES in favour of this proposal.
Prime Instance - Restore ETH LTV
Vote Result: YES
Rationale
This is the onchain vote 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.
Upgrade Aave Instances to v3.3
Vote Result: YES
Rationale
As per our feedback in the original Umbrella discussion, we’re very excited to see this system implemented and v3.3 lays the foundation for it. The improvements to the liquidation engine are great; allowing more flexibility to the CloseFactor and reducing even dust bad debt is a natural improvement.
Therefore, we will vote YES in favour of this proposal.
Caps Risk Oracle Activation on Arbitrum
Vote Result: YES
Rationale
As per our feedback on the forum, we’re excited to see Edge AGRS go live for caps to streamline risk management and meet user needs around borrow/supply caps more efficiently is very high. We’re glad to see Chaos Labs incorporate a more conservative method and activate Edge AGRS only for the appropriate markets while acknowledging the difficulties of doing so for growth assets.
Therefore, we will vote YES in favour of this proposal.
Adjust Risk Parameters for Aave V2 and V3 on Polygon
Vote Result: NO
Rationale
This is the onchain vote for this Snapshot ARFC that we voted against according to our rationale here. Therefore, we will vote NO against this proposal as well.
[ARFC] Onboard rsETH to Arbitrum and Base V3 Instances
Vote Result: YES
Rationale
rsETH has seen a lot of growth on Aave driven by the wstETH e-mode; presenting it as an option on Arbitrum would therefore be value additive. Both risk providers and BGD Labs support the proposal. Therefore, we will vote YES in favour of this proposal as well.
[TEMP CHECK] Deploy Aave on Soneium
Vote Result: YES
Rationale
As we mentioned in our forum comment, the opportunity of onboarding the Sony user base onto Aave is lucrative and we should aim to deploy Aave in time with the ACS campaign. It is clear from the forum responses that Soneium has a clear plan to increase adoption and potentially bring in a net new user base. The liquidity commitment on Aave is significant as well.
Therefore, we will vote YES in favour of this proposal.
Update AAVE Token LTV/Liquidation Percentages
Vote Result: YES
Rationale
This is the onchain vote 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 today.
sUSD Risk Parameter Adjustment
Vote Result: YES
Rationale
Given the secondary market price of sUSD remains below peg and liquidity concentration is out of bounds, combined with demand for sUSD being incentive-driven rather than organic, we think it is sensible to prevent further borrowing by lowering LTV to 0 and reducing the LT is the first step towards deprecating the e-mode. Therefore, we will vote YES in favour of this proposal.
Aave V3.3 Sonic Activation
Vote Result: YES
Rationale
This is the onchain vote for this Snapshot TEMP CHECK that we voted in favour of according to our rationale here. Therefore, we will vote YES in favour of this proposal today.
Extend GHO Steward on Aave Prime Instance
Vote Result: YES
Rationale
Given the growth of GHO, it makes sense to extend the Steward role to the Reserve on Aave v3 Prime to allow for quicker, more efficient parameter updates. Therefore, we will vote YES in favour of this proposal.
[TEMP CHECK] Deploy Aave v3 on megaETH
Vote Result: YES
Rationale
As per our comment, given the potential of megaETH, we are in support of this deployment at this stage, prior to the risk providers’ opinions. Therefore, we will vote YES in favour of this proposal.