LBS Blockchain Society Delegate Platform

Delegate Platforms
229

[ARFC] - Chaos Labs Risk Parameter Updates - Aave V3 Polygon - 2023.04.23

Vote Result: YES

Rationale

The adjustment makes those asset classes to be utilised in a more efficient way. The procedure that Chaos Labs follows to generate the parameters is well defined and widely agreed, so we will vote YES in favour of it, especially since there is no effect on project VaR and EVaR.

230

[ARFC] MaticX Supply Cap Increase Polygon v3

Vote Result: Option 2 - 29.3M supply cap

Rationale

The recent spike of MaticX in Polygon signals an urgent demand for Aave to increase the supply cap for it, as Aave is an important component in this LST loop strategy. Based on Chaos Lab’s estimation in terms of liquidation penalty and price slippage, doubling the current supply to 29.3M is acceptable with sufficient growing space. Therefore, we will vote YES in favour of Option 2.

231

[TEMP CHECK] Aave V3 GHO Genesis Parameters

Vote Result: ABSTAIN

Rationale

Both Options A and B have their pros and cons. We have summarised these below:

Option A

Pros

  • The initial launch phase of a stablecoin requires the build-up of deep secondary liquidity and needs to be able to scale. Option A has a higher Facilitator Bucket and lower borrow rate which will incentivise GHO to be borrowed and build up demand.
  • If the parameters end up being riskier, they can be modified later, and it may be better to tend towards scalability initially to increase adoption.
  • Given the status of Aave and hence GHO in the ecosystem, initial adoption and liquidity should be relatively high. Supply should be above natural demand plus a buffer margin. Looking at comparable liquidity of stablecoins, it seems as if $100M could be an appropriate Facilitator Bucket.

Cons

  • There is no liquidity and slippage analysis for Option A and it would be better to judge when it is completed.
  • Since the parameters can be adjusted quickly, it may be better to start off conservative.

Option B

Pros

  • Given the liquidity and slippage analysis from Gauntlet, a $50M bucket limit could initially be appropriate and could be scaled up quickly if need be.
  • There needs to be a comparable analysis done with Option A, and the level of organic demand can only be judged with time, so it may be better to be more conservative initially and a more bespoke bucket limit can be set when demand is more certain.

Cons

  • It is important to make GHO attractive to mint and generate organic demand and adoption. A lower bucket limit and higher borrow rate could disincentivise this.
  • Comparable demand for stablecoins combined with Aave’s market position make it relatively likely that GHO attains organic demand.

While we are leaning towards Option A, since this is a TEMP CHECK, it would be better to do a similar liquidity and slippage analysis for Option A as has been done for Option B. Therefore, we will await this analysis before the next vote and will vote ABSTAIN for this Snapshot vote.

232

[ARFC] Aave V2 Interest Rate Curve Changes (2023-04-21)

Vote Result: YES

Rationale

With reasonable elasticity estimation for Aave users, we believe that the model will work efficiently in explaining the short-term and long-term effects after the IR rate changes. The proposed IR curves are well-balanced between risk and revenue, incorporating the recent utilization rate accordingly. Therefore, we will vote YES in favour of this proposal.

233

[ARFC] Polygon v2 - Parameter Update

Vote Result: YES

Rationale

Given that the current utilisation for certain assets is 100% (CRV, GHST, LINK), we should raise the borrowing cost. We suggest going with option 2 because it results in a higher borrowing cost, which will discourage users from borrowing on V2 and allows more space for the migration to V3. Moreover, since Option 2 (as with the other options) generates no significant additional risk according to Gauntlet, we are in favour of Option 2.

234

Aave Bug Bounty Program on Immunefi

Vote Result: YES

Rationale

Aave is a complex protocol with an ever-evolving codebase and there are vulnerabilities that could emerge often from new (or even existing) code. A bug bounty program would incentivise security researchers to continuously assess Aave’s codebase and provide incentives for hackers to disclose bugs as well. The Immunefi team has taken feedback on board and agreed to create a more granular reward system and adapt their methodology to align with that of Aave. Therefore, we will vote YES in favour of this proposal.

235

Aave Metis V3

Vote Result: YES

Rationale

Given that the suggested parameters for deployment on Metis have been presented jointly by Chaos and Gauntlet, and that all testing and preparation has been completed, we will vote YES in favour of this proposal.

236

Upgrade Aave V3 pools to Aave V3.0.2

Vote Result: YES

Rationale

Given that the unification of codebases across deployments reduces maintenance costs and increases the efficiency of Aave, and that the codebase has been checked and certified by Certora and Sigma Prime, we are aligned with this proposal and will vote YES in favour.

237

Upgrade the safety module to v1.5 PART 1

Vote Result: YES

Rationale

This is the on-chain vote for this Snapshot proposal that we voted in favour of according to our rationale posted here. Therefore, we will vote YES in favour of this proposal as well.

238

[TEMP CHECK] Allocation of 300k OP Received by Aave Grants DAO

Vote Result: YES

Rationale

The allocation of funds, with the 100k and 200k split and the subsequent allocation of the 100k towards Optimism-based projects seems fair. Moreover, the split between grants and bounties, with more funds being allocated towards grants, is also sensible. The OP tokens have been received by AGD and should be used to further Aave’s growth on Optimism, which is what the proposal seeks to do. Therefore, we will vote YES in favour of this proposal.

239

[ARFC] Modify Snapshot Proposal Threshold

Vote Result: YES

Rationale

Increasing the threshold will make the community operate in a more efficient way by reducing junk proposals, and 250 AAVE is a reasonable amount, so we are in favor of the proposal.

240

Gauntlet Recommendations for Polygon V3 and Arbitrum V3

Vote Result: YES

Rationale

Given that EURS’ borrow and supply caps have surpassed the 75% threshold, Gauntlet’s recommendations are sensible and we are in agreement, especially given that the conservative methodology has been applied in this case, leaving room for further expansion if required. Therefore, we will vote YES in favour of this proposal.

241

Risk Parameter Updates Aave V3 Polygon

Vote Result: YES

Rationale

This is the on-chain vote for this Snapshot proposal that we voted in favour of according to our rationale posted here. Therefore, we will vote YES in favour of this proposal as well.

242

Supply and Borrow Cap Updates Aave V3

Vote Result: YES

Rationale

The supply or borrow caps for these assets have reached the 75% utilisation threshold and need to be increased. Given that the increases are in line with the Supply and Borrow Cap Methodology and the Aave v3 Caps Framework, and stick to increasing either cap by a max of 100%, we are in favour of this proposal and will vote YES.

243

[ARFC] - GHO Facilitator Onboarding Process and Application

Vote Result: YES

Rationale

The process is simple and straightforward and makes sense. The sample applications are detailed and provide a lot of information to the community about the applicant and their rationales for wanting to be facilitators. Therefore, we will vote YES in favour of this proposal.

244

[ARFC] Aave V3 Interest Rate Curve Changes (2023-04-27)

Vote Result: YES

Rationale

Making these interest rate curve changes would enable an increase in revenue for the protocol, and Gauntlet’s methodology is well-explained in the post. Making these changes would allow for more information to be gathered about user behaviour in response to interest rate changes, informing more pinpointed interest rate parameters going forward. Moreover, the changes can be rolled back in case of unexpected user behaviour, and there does not seem to be too much additional risk from these changes at the moment. Therefore, we will vote YES in favour of this proposal.

245

[ARFC] E-Mode Specific Supply and Borrow Caps

Vote Result: Option 1: Add EM Specific Caps

Rationale

E-mode specific caps for every LST-base asset pair maximises capital efficiency and siloes the risk due to the differences in characteristics between different LSTs. Gauntlet’s methodology is sensible and this vote is not on how aggressive the caps are - since it is only implementing e-mode specific caps. However, we would be in favour of e-mode specific pools as well, without having an opinion yet on an aggressive or conservative cap option. Therefore, we will vote YES in favour of this proposal.

246

Add MAI to Aave Optimism V3 Pool

Vote Result: YES

Rationale

This is the on-chain vote for this Snapshot proposal that we voted in favour of according to our rationale posted here. Therefore, we will vote YES in favour of this AIP as well, especially given the consensus on risk parameters between Gauntlet and Chaos Labs.

247

Add MAI to Aave Arbitrum V3 Pool

Vote Result: YES

Rationale

This is the on-chain vote for this Snapshot proposal that we voted in favour of according to our rationale posted here. Therefore, we will vote YES in favour of this AIP as well, especially given the consensus on risk parameters between Gauntlet and Chaos Labs.

248

MaticX Supply Cap Increase Polygon v3 and AGD Approval

Vote Result: ABSTAIN

Rationale

There was no mention of the AGD-related implementation on the forum and we are in agreement with @MarcZeller. We will also abstain on this AIP to make sure this does not happen again - Llama mentioned the AGD component last in January and there needs to be better signposting on what delegates need to vote on and provide the requisite information.

1 Like