This proposal aims to onboard and enable LBTC/WBTC (Lombard) liquid E-Mode for the Main Instance. By implementing this change, we seek to enhance capital efficiency for borrowers using LBTC/WBTC as collateral.
Motivation
The motivation behind this proposal stems from several key factors:
High Utilization: LBTC/WBTC has demonstrated significant usage as collateral for borrowing stablecoins on other platforms.
Capital Efficiency: Enabling liquid E-Mode for LBTC/WBTC will allow borrowers to substantially improve their capital efficiency when using this asset as collateral.
Controlled Growth: Liquid E-Mode provides a mechanism for more precise control over the growth and borrow demand in relation to the overall stablecoin liquidity within Aave v3 on Core Instance.
By implementing this proposal, we aim to optimize the use of LBTC/WBTC within the Aave ecosystem, attracting more liquidity for the protocol and increasing revenues.
Specification
This proposal will add LBTC/WBTC liquid E-Mode. Risk Parameters will be provided by Risk Service Providers and ARFC will be updated accordingly when ARFC is posted if it passes this TEMP CHECK.
Why does ACI support this proposal, versus tBTC/WBTC E-mode which already passed temp check?
Seems like a BTC-focused E-mode would be useful across all BTC-variant collateral. Both cbBTC and tBTC are live today — does it make more sense to start there while onboarding LBTC?
What about the risks involved with LBTC? The main question is where the yield comes from on all these BTC pairs? They are being hyper-intergrated across various ecosytems with inflated yields. I hope the risk committee assesses all possible points before integrating any BTC pair.
Could @ACI provide some information on what specifically they no longer support in the tBTC/WBTC liquid emode proposal? How is the tbtc/wbtc liquid e-mode proposal going to be reworked?
It would also be good to provide further information on how much of the original proposal is reasonable to be amended without requiring another vote altogether? What exactly is binding in an ARFC snapshot for the subsequent AIP vote given that it is possible to change things in an ARFC addendum.
The governance process is overdue for an update. At the moment it seems there is quite a lot of abuse in the manner in which certain proposals seem to be sped through the governance process, while others seem to be stuck in limbo despite passing the requisite snapshots and onchain votes.