Aave BGD Phase 5
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.
Onboard PT sUSDe July on Core Instance
Vote Result: YES
Rationale
This is a resubmission of this vote that we had voted in favour of according to our rationale here. Therefore, we will vote YES in favour of this proposal as well.
[ARFC] Aave V3 Deployment on Aptos Mainnet
Vote Result: YES
Rationale
The innovation from using the benefits of Aptos’ features and the Move language and adapting these to Aave v3 is great - it provides a great test case for Aave’s implementation across non-EVM networks. Acknowledging some of the “decentralisation” components brought up by BGD Labs, we think this is a fair trade-off given that Aave v3 has had to be reconstructed in spirit in the Move language.
From a security perspective, it is very interesting to see that Move was designed for formal verification and it’s great that Aave Labs has worked closely with Certora on the security aspect of this deployment. Lastly, both risk providers support the deployment and have recommended assets and parameters to be onboarded.
All in all, we will vote YES in favour of this proposal.
May Funding Update
Vote Result: YES
Rationale
This is an operational Aave Finance proposal that we will vote YES in favour of.
[ARFC] Horizon’s RWA Instance
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 as well.
[ARFC] Interest Rate Curve Risk Oracle
Vote Result: YES
Rationale
As with our feedback on the supply and borrow cap automation proposal, we’re in favour of enhancing the efficiency and responsiveness of critical parameters. The outlined effort to manually modify the IR curves across 60 stablecoin markets is not feasible even in the short-run, and if there is a solution available (with the appropriate checks and balances, as provided by LlamaRisk) then we should go ahead with it. The methodology developed by Chaos Labs is solid, especially using the aggregate protocol revenue as a measure of welfare and constraining it with utilisation.
All in all, we will vote YES in favour of this proposal.
[ARFC] Onboard tETH to Aave v3 Prime Instance
Vote Result: YES
Rationale
Chaos Labs’ explanation of why tETH is a good asset to list is extremely helpful. The opportunity to establish standardised benchmark rates in crypto for ETH and “unify” borrowing and lending rates across protocols is significant, especially when used as a benchmark in various financial products. Moreover, BGD Labs thinks there is no issue in integrating the asset and both risk providers support the proposal.
However, there is a key consideration that tETH does face some risks - Chaos Labs has outlined the mitigations but the main one would be the Insurance Fund, whose address and size have not been disclosed. We would like to see this disclosed.
We are in favour of this proposal and will vote YES.
[TEMP CHECK] Add PEPE as a Supported Asset on AAVE
Vote Result: ABSTAIN
Rationale
Given our feedback via our comment, we’re not convinced by the opportunity from listing PEPE on Aave. The risks of this asset also seem to be high to us at this stage. However, testing a liquid eMode pairing PEPE with GHO/wGHO at a higher borrow rate could be interesting and- it may be useful to see the risk provider’s perspective at the ARFC stage on both risk and revenue aspects, even though we still think it would still be very difficult to model the revenue from this listing.
Overall, we’re not really convinced by this proposal. Therefore, we will vote to ABSTAIN for now.
Onboard USDtb to Aave v3 Core Instance
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.
Remove USDe Debt Ceiling and Introduce USDe Stablecoins E-mode
Vote Result: YES
Rationale
As per our feedback via our comment, we think this proposal makes sense - the risk of applying maximal leverage does not seem to be very high, while the liquidity of the asset and demand for it seem very strong, and the revenue opportunity for Aave is strong. Therefore, we will vote YES in favour of this proposal.
stkGHO Emissions
Vote Result: YES
Rationale
Re-enabling emissions for stkGHO is sensible and we will vote YES in favour of this proposal.
[ARFC] Deploy Aave on Soneium
Vote Result: YES
Rationale
This is the ARFC for this Snapshot TEMP CHECK that we voted in favour of according to our rationale here. Furthermore, both risk providers support the proposal.
Soneium’s user activity and TVS has increased gradually since launch, and there is a clear focus on mainstream adoption via existing IP, reflected by the focus on IP protection in SBS Labs’ T&Cs, which could allow Aave to expand to more real-world use cases. A concern for us is that liquidity is still low on Soneium and revenue opportunity at the moment is limited; in terms of risk, however, the liquidity issue can be mitigated by listing only stablecoins and WETH for the moment. Therefore, we will vote YES in favour of this proposal.
Extend SVR V1 to More Reserves
Vote Result: YES
Rationale
As per our comment, we are in favour of this proposal; we need to expand the assets covered by SVR to maximise revenue for the DAO and a sufficient amount of time has passed in Phase 1 to assess any faults or issues. LlamaRisk’s analysis highlights that there is a clear need to scale SVR before its impact and be adequately judged. Expanding to Bitcoin and Ethereum-backed collateral including cbBTC and to mid-cap governance tokens will maximise the impact of SVR.
Therefore, we will vote YES in favour of this proposal.
[ARFC] Onboarding wETH to Aave V3 Celo Instance
Vote Result: YES
Rationale
Since the listing of WETH will help improve liquidity for the asset on Celo similar to the Wormhole bridge WETH, and because both risk providers support this proposal, we will vote YES in favour of this proposal.
[ARFC] Deploy 5M USDC for GHO Market Making on Gnosis Chain
Vote Result: YES
Rationale
As per our comment, this was not an easy proposal to vote in favour of. Upon discussion with the kpk team, our understanding was that these funds are simply to be allocated at this point and not deployed, and any deployment of the capital would occur alongside any other incentive programs. Moreover, voting yes at this stage would give kpk some certainty about the Gnosis Chain deployment and help them set the requisite infrastructure up to deploy the capital as required. Therefore, we will vote YES in favour of this proposal.
Add AAVE Token to Aave V3 Base Instance
Vote Result: YES
Rationale
Given the favourable liquidity conditions on Base for the AAVE token, the risk providers both supporting the proposal, and the continued growth of the Base market on Aave, we will vote YES in favour of this proposal.
LRT and wstETH Unification
Vote Result: YES
Rationale
The explanations from TokenLogic all make sense here. Implementing favourable eMode terms on Prime has a good chance of attracting further wstETH deposits, while increasing LTV and LT on Prime will increase capital efficiency of WETH and wstETH on Lido. Aligning LTV/LT of rsETH also makes sense, given that the 5% rsETH depeg will require a 35.7% ETHx drop, which is not likely to occur. Further, aligning parameters on Base with other instances also makes sense to ensure consistency across deployments. Lastly, the risk providers support the proposal as well. Therefore, we will vote YES in favour of this proposal.
Soneium aDI Path Activation
Vote Result: YES
Rationale
Given that we are in favour of deploying Aave on Soneium, it makes sense to vote YES in favour of this technical proposal.
[ARFC] Base Incentive Campaign Funding
Vote Result: YES
Rationale
As per our comment, there is clearly a lot to be gained from incentivising activity and capturing liquidity and users. Using revenue earned from the Base deployment to incentivise further activity is sustainable and fair. Lastly, the Aave-aligned actions have been carefully chosen and make a lot of sense to reward. Therefore, we will vote YES in favour of this proposal.
[ARFC] Supply and Borrow Cap Risk Oracle Constraint Specification
Vote Result: YES
Rationale
This proposal applies more guardrails on the use of the risk oracle; the constraints applied make sense and are prudent. Therefore, we will vote YES in favour of this proposal.