Areta Delegate Platform

v3 Periphery Maintenance

Vote Result: YES

Rationale

These two technical proposals are logical and straightforward to execute. Activating the Scroll L2 sequencer feed is sensible and fixes the issues with the static-a-token is also good practice. Therefore, we will vote YES in favour of this proposal.

2 Likes

Reserve Factor Updates (March 13, 2024)

Vote Result: YES

Rationale

This is another in a series of updates to the RF on Polygon v2 which we previously voted in favour of according to our rationale here. Therefore, we will vote YES in favour of this proposal as well.

2 Likes

Stablecoin Harmonization

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, notwithstanding ACIā€™s note about aspects of this proposal being removed from this payload, we will vote YES in favour of the remaining elements of the original proposal.

1 Like

Update a.DI Implementation and CCIP Adapters

Vote Result: YES

Rationale

This is a straightforward technical maintenance proposal that is obvious to vote in favour of to standardise off chain tracking of a.DI contracts and events and update the Chainlink CCIP Bridge Adapter to be compatible with the new CCIP version. Therefore, we will vote YES in favour of this proposal.

[ARFC] GHO Stewards + Borrow Rate Update

Vote Result: YES

Rationale

The treasury managers / GHO Stewards need more flexibility in managing GHO growth in these more volatile market conditions. The constraints of governance may hamper GHO growth and the treasury managers are more than capable of assessing the situation and taking appropriate action to ensure that GHO grows and is competitive.

We do believe that there should be a performance review for this specific topic - weā€™re all in favour of efficiency and expertise, but there should be a post-mortem once market conditions stabilise of how Aave has performed in comparison to other protocols regarding stablecoin performance (usage, revenues, borrows, generating organic GHO demand, etc.).

As such, we will vote YES in favour of this proposal.

1 Like

[ARFC] Reset Aave v3 Deployment Pipeline

Vote Result: YES

Rationale

Resetting the Aave v3 deployment timeline at the moment is sensible; we agree that the DAO can get better terms from deploying on these chains given the market conditions. Therefore, we will vote YES in favour of this proposal.

[TEMP CHECK] Onboard LlamaRisk as Aave Risk Service Provider

Vote Result: YES

Rationale

LlamaRiskā€™s credentials are impressive; their work with Curve and Prisma, the 70+ risk assessments they have published, the team composition, previous experience in collaboratively working with Chaos Labs, and expertise around regulation and policy, which is a skill-set the DAO does not currently have, position LlamaRisk well for the engagement. Their agent-based simulation model will complement that of Chaos Labs and provide a check and balance to their recommendations depending on the inputs to LlamaRiskā€™s models. The budget proposed is fair - $250k for the first 6 months is not excessive at all. The disclosures and reports provided on their spending are also good practice.

The scope adds further expertise in the areas of LSTs, LRTs, and GHO, all of which are becoming critical components of the protocol and could drive a lot of revenue for Aave. Providing further expertise on GHO is crucial for its wider adoption, so this is a welcome addition for the DAO. It is not immediately clear why the DAO would need any regulatory advice but since this is included within LlamaRiskā€™s broader scope and may become more important if Aave engages with RWAs in the near future, we are not opposed to it.

One concern is that other risk managers who potentially want to work with the DAO should also get a chance to put their proposals up. However, there is time before a potential on-chain vote, so if other risk managers put their hands up to work with Aave DAO, these can be considered as well.

All in all, we will vote YES in favour of this proposal.

1 Like

Remove ARB from Isolation Mode on Arbitrum

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.

Ethereum v2 Reserve Factor Adjustment

Vote Result: YES

Rationale

This is a continuation of this AIP that we voted in favour of according to our rationale here. Therefore, we will vote YES in favour of this proposal as well.

[ARFC] Avalanche v2 Reserve Factor Adjustment

Vote Result: YES

Rationale

Migrating users to Aave v3 is critical and it has been 1+ years since v3 has been implemented. This proposal gives sufficient notice to v2 depositors to migrate to v3 at this point. The same strategy has been employed on Polygon v2 and Ethereum v2 and does not affect usersā€™ HF. Therefore, we will vote YES in favour of this proposal.

Aave BGD Phase 3

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.

Contango FlashBorrower

Vote Result: YES

Rationale

This is an extension to the on-chain proposal for this AIP that we voted in favour of according to our rationale here. The additions proposed do not pose any issue. Therefore, we will vote YES in favour of this proposal as well.

1 Like

Activate Gho Stewards

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.

1 Like

[ARFC] aAMPL Interim Distribution

Vote Result: YES

Rationale

This initial partial distribution is a first step towards making aAMPL holders on Aave whole following the problem detected on the AMPL custom reserve on v2 Ethereum. There has been a lot of discussion on the original forum post and the risk service providers are coming up with the final distribution where all historic components are taken into account for the following distribution. Users will at least be able to withdraw some funds imminently, which they have been waiting for since December. Therefore, we will vote YES in favour of this proposal.

[ARFC] Onboard Catapulta as Aave V3 Deployment Service Provider

Vote Result: YES

Rationale

This is the ARFC 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.

[TEMP CHECK] Onboard ezETH to Aave V3 Ethereum

Vote Result: YES

Rationale

Similar to the proposal to onboard eETH, restaking has quickly become one of the hottest sectors in DeFi and Renzo, along with EtherFi, is one of the forerunners in the LRT space. Restaking is relatively risky, but the risk parameters can be set at the appropriate level and onboarding ezETH will bring further revenue to Aave. We would like to see Chaos Labs and the other prospective risk providersā€™ opinions on this listing. Therefore, we will vote YES in favour of this proposal.

GHO Stewards + Borrow Rate Update

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. Moreover, we activated the GHO Stewards in this AIP. Therefore, we will vote YES in favour of this proposal as well.

Funding Update (Part B)

Vote Result: YES

Rationale

This is the on-chain proposal for this Snapshot ARFC that we voted in favour of according to our rationale under the LBS Blockchain umbrella here. Performing Part B of the Funding Update is logical. Therefore, we will vote YES in favour of this AIP.

[TEMP CHECK] Allez Labs Risk Provider Proposal to Aave DAO

Vote Result: YES

Rationale

The Allez Labs team has a significant amount of experience on Aave that will be very beneficial for the protocol going forward. They have worked previously with Chaos Labs, with whom it is necessary for any risk provider to have a good working relationship. Moreover, the scope of work is broad and touches upon the right points, with the focus on GHO being absolutely critical as a potential money printer for the DAO over the mid term. Given the amount that was being paid to Gauntlet, the $400k budget over 6 months is not excessive at all, and if paid to the right contributors, is worth a lot to the DAO. Obviously, the scope and price must be considered in comparison with the other applicants, LlamaRisk and OpenBlock. The open sourcing of all data pipelines and models is a huge plus.

There is only one question to be answered before the risk providers are compared in the ARFC phase: Allez Labs has a good amount of stablecoin experience, but it must be said that the launch of GHO was not perfect, with the depegs, lack of organic usage and integrations across the ecosystem, and the lack of established liquidity pools prior to GHOā€™s launch. This is obviously not attributable solely to Allez Labs team, but given that they have mentioned their deep experience with GHO pre-launch, this is a question that needs to be asked.

Therefore, we will vote YES in favour of this proposal.

[TEMP CHECK] Onboard OpenBlock as Aave Risk Service Provider

Vote Result: NO

Rationale

OpenBlockā€™s expertise is definitely to be commended, especially considering their 40+ strong team with impressive professional backgrounds. Their LST and LRT expertise will be very valuable going forward. However, we have several concerns about their proposal and scope, especially in comparison with that of Allez Labs and LlamaRisk:

  • OpenBlock does not have a specific focus on GHO and this is one of the key aspects that the DAO needs to focus on now.
  • The budget is higher than the other risk providers (LlamaRisk and Allez Labs) but it is not especially clear as to why.
  • The scope does not see OpenBlock providing input into parameter recommendations for Aave v3.
  • OpenBlockā€™s LST and LRT expertise will be beneficial for Aave, but it is not clear why Chaos Labs cannot perform the same role.
  • In comparison with the other proposed solutions, OpenBlockā€™s scope seems the least comprehensive.

As such, we will vote NO on this TEMP CHECK to onboard OpenBlock and would like to further assess LlamaRisk and Allez Labs in the ARFC phase.