LBS Blockchain Society Delegate Platform

Update AAVE V3 ETH Risk Parameters

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.

Risk Parameter Updates Aave V3 Optimism

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.

[Temp Check] - Community Preference for Supply Cap Limits for LSTs

Vote Result: YES

Rationale

Given MaticX’s current utilization of 98.31%, the 50% supply cap limit is relatively conservative and hinders the growth of the protocol to a certain extent. 75% supply cap limit is a more balanced target and allows room for further growth and profitability. Moreover, setting the 75% supply cap limit does not necessarily mean that the supply cap must reach 75%. Instead, like Llama suggests in the discussion, a smaller increase in the supply cap can be implemented depending on the risk profile of the specific asset. On the risk side, although it is true that the 50% supply cap limit provides an additional safety cushion for Aave, when it comes to extreme cases, such as the breakdown of Lido or Stader, the loss under the 50% supply cap limit is still not negligible. Therefore, there is actually not as much difference to set the supply cap limit to be higher.

[ARFC] Add MAI to Arbitrum Aave V3 Pool

Vote Result: YES

Rationale

It is important to increase Aave’s stablecoin diversity and increase Aave’s offering to support more volatile assets and increase revenue, backed by appropriate debt ceilings and borrow and supply caps enabled by v3. Moreover, Chaos Labs supports the proposal and initial parameters are relatively conservative. A potential point of concern is that MAI is a low market cap asset that could prove to be volatile and subject to price manipulation and attacks. This, however, is mitigated by the relatively conservative risk parameters set.

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

[ARFC] Add MAI to Optimism Aave V3 Pool

Vote Result: YES

Rationale

It is important to increase Aave’s stablecoin diversity and increase Aave’s offering to support more volatile assets and increase revenue, backed by appropriate debt ceilings and borrow and supply caps enabled by v3. Moreover, Chaos Labs supports the proposal and initial parameters are appropriate for the liquidity for Optimism and are also relatively conservative. A potential point of concern is that MAI is a low market cap asset that could prove to be volatile and subject to price manipulation and attacks. This, however, is mitigated by the relatively conservative risk parameters set.

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

[ARFC] Deprecate Aave V2 AMM Market

Vote Result: YES

Rationale

There is low usage of the V2 AMM market and deprecating it would not harm user experience since the only available assets in the market are available on both V2 and V3 ETH, providing ample user optionality. Moreso, this is only a Snapshot vote that is only indicative, and gives affected users with $150k of LP tokens to adjust their positions in order to not get liquidated. Given the risk/return profile of V2 AMM is low, we are in favour of this proposal and will vote YES.

[ARFC] Private Voting for Aave Governance [2-month Trial]

Vote Result: YES

Rationale

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

[TEMP CHECK] Gas Fee Rebate for On-Chain Votes

Vote Result: YES

Rationale

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

Risk Parameter Updates for Aave V3 Polygon (2023-04-21)

Vote Result: YES

Rationale

Given that utilisation of EURS is at 89% and the supply cap increase meets the conditions outlined in the v3 Cap Updates Framework that the community has agreed with, this proposal is sensible and we are in agreement with it. Therefore, we will vote YES in favour of it.

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.

Increase SupplyCap stMATIC Polygon & wETH Arbitrum

Vote Result: YES

Rationale

The proposal aims to increase the supply cap of stMATIC on Polygon from 21M units to 25M units. Given that the utilisation of stMATIC has reached 75%, the cap increase matches Chaos Labs’ Updated Supply and Borrow Cap Methodology, and Chaos is also in favour, we think this proposal is logical and are in favour of it. We are not in favour of increasing the supply cap to 37.5M units as proposed by Llama, given Chaos’ analysis that bridged liquidity is not used to liquidate positions often, and that stMATIC is used to borrow stablecoins which may lead to liquidity and price volatility risk. Lastly, we are also in favour of the wETH supply cap increase that we already voted in favour of here. Therefore, we will vote YES In favour of this proposal as well.

Add wstETH to Polygon Aave v3

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.

BAL Interest Rate Upgrade

Vote Result: YES

Rationale

We support the increase in BAL interest rates to move it in line with comparable liquidity pools deployed on other protocols, and improve utilisation and revenue from BAL vaults to capture the strong demand.

WAVAX Borrow Cap Update - V3 Avalanche - 04.21.2023

Vote Result: YES

Rationale

The above adjustment follows the borrow cap methodology published by Chaos Labs before, so we don’t have any objection. Therefore, we will vote YES in favour of this proposal.

[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.

[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.

[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.

[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.

[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.

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.