What the rationale for not including GUSD? I don’t see any risks with GUSD being a stable. It cannot be used as collateral anyway, so what is the reason?
Gauntlet Recommendations
Following the Snapshot vote, Gauntlet’s initial recommendations for Aave V3 ETH deployment are below.
One challenge of parameterizing markets with no usage (new markets) is the lack of user data to train simulation models. At a high level, our research has shown that simulations using mock data are inaccurate (due to priors on the mocks not being representative of real-world usage in the protocol). As such, we are using the information and insights from simulations we have conducted on current Aave V2 ETH and Aave V3 AVAX to inform recommendations, but the risk analysis does not solely rely on those simulation results.
| Symbol | Isolation Mode | Borrowable | Collateral Enabled | LTV | LT | LB | RF | LPF | Debt Ceiling | Supply Cap | Borrow Cap | Supply Cap USD | Borrow Cap USD |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| USDC | NO | YES | YES | 8,650 | 8,850 | 10,480 | 1,000 | 0.20 | 0 | 2,000,000,000 | 591,700,000 | $1,918,303,914 | $591,631,355 |
| WETH | NO | YES | YES | 8,250 | 8,600 | 10,520 | 1,000 | 0.10 | 0 | 600,000 | 469,000 | $690,915,520 | $552,732,416 |
| WSTETH | NO | YES | YES | 7,200 | 8,300 | 10,720 | 1,000 | 0.10 | 0 | 600,000 | 94,000 | $682,967,764 | $106,998,283 |
| WBTC | NO | YES | YES | 7,200 | 8,200 | 10,520 | 2,000 | 0.10 | 0 | 40,000 | 4,600 | $594,982,530 | $75,440,126 |
| USDT | YES | YES | YES | 7,500 | 8,100 | 10,530 | 1,000 | 0.20 | 10,000,000 | 680,000,000 | 303,000,000 | $678,186,530 | $302,976,250 |
| DAI | NO | YES | YES | 7,650 | 8,900 | 10,430 | 1,000 | 0.20 | 0 | 320,000,000 | 114,400,000 | $316,922,850 | $114,357,765 |
| LINK | YES | YES | YES | 6,950 | 8,250 | 10,720 | 2,000 | 0.10 | 25,059,000 | 32,000,000 | 2,650,000 | $183,541,004 | $15,482,976 |
| CRV | YES | YES | YES | 5,500 | 6,100 | 10,830 | 2,000 | 0.10 | 20,929,000 | 140,000,000 | 25,000,000 | $67,634,449 | $12,986,109 |
| AAVE | NO | NO | YES | 6,600 | 7,300 | 10,770 | 0 | 0.10 | 0 | 3,000,000 | 0 | $155,435,804 | $0 |
| MKR | YES | YES | YES | 6,500 | 7,000 | 10,770 | 2,000 | 0.10 | 4,592,000 | 60,000 | 1,100 | $30,906,375 | $579,653 |
| TUSD | YES | YES | YES | 8,000 | 8,250 | 10,520 | 1,000 | 0.10 | 4,451,000 | 24,000,000 | 7,180,000 | $23,507,765 | $7,178,272 |
| FRAX | NO | YES | NO | 0 | 0 | 0 | 2,000 | 0.00 | 0 | 29,000,000 | 10,900,000 | $28,397,588 | $10,844,134 |
| BUSD | NO | YES | NO | 0 | 0 | 0 | 1,000 | 0.00 | 0 | 47,000,000 | 12,800,000 | $46,961,233 | $12,774,788 |
| YFI | YES | YES | YES | 5,000 | 6,500 | 10,770 | 2,000 | 0.10 | 16,187,000 | 10,000 | 200 | $24,279,888 | $1,082,947 |
| UNI | YES | YES | YES | 6,500 | 7,700 | 10,930 | 2,000 | 0.10 | 17,112,000 | 6,000,000 | 437,000 | $28,204,849 | $2,245,127 |
| ZRX | YES | YES | YES | 5,500 | 6,500 | 10,770 | 2,000 | 0.10 | 6,062,000 | 79,000,000 | 933,000 | $12,609,873 | $149,189 |
| MANA | YES | YES | YES | 6,150 | 7,500 | 10,770 | 3,500 | 0.10 | 6,869,000 | 34,000,000 | 1,980,000 | $10,302,960 | $612,605 |
| 1INCH | YES | YES | YES | 4,000 | 5,000 | 10,880 | 2,000 | 0.10 | 14,331,000 | 56,000,000 | 1,100,000 | $21,496,425 | $426,397 |
| DPI | YES | YES | YES | 6,500 | 7,000 | 10,770 | 2,000 | 0.10 | 118,000 | 50,000 | 4,500 | $2,350,324 | $257,971 |
| SNX | YES | YES | YES | 4,900 | 6,500 | 10,770 | 3,500 | 0.10 | 8,641,000 | 11,000,000 | 3,600,000 | $16,753,891 | $5,641,686 |
| CVX | YES | YES | YES | 3,500 | 4,500 | 10,880 | 2,000 | 0.10 | 3,367,000 | 2,000,000 | 257,000 | $5,049,037 | $868,088 |
| BAT | YES | YES | YES | 6,500 | 7,000 | 10,770 | 2,000 | 0.10 | 4,898,000 | 41,000,000 | 2,100,000 | $7,345,858 | $377,538 |
| SUSD | NO | YES | NO | 0 | 0 | 0 | 2,000 | 0.00 | 0 | 5,000,000 | 1,850,000 | $4,693,138 | $1,868,455 |
| BAL | YES | YES | YES | 6,500 | 7,000 | 10,830 | 2,000 | 0.10 | 3,390,000 | 1,000,000 | 185,000 | $5,084,701 | $980,370 |
| LUSD | NO | YES | NO | 0 | 0 | 0 | 1,000 | 0.00 | 0 | 3,000,000 | 1,210,000 | $2,355,611 | $1,229,852 |
| ENS | YES | YES | YES | 5,000 | 6,000 | 10,830 | 2,000 | 0.10 | 12,663,000 | 2,000,000 | 40,000 | $18,993,939 | $442,272 |
Supply Cap / Borrow Cap / Debt Ceiling
Caps and debt ceilings can be further fine-tuned as the protocol gathers more data on how usage grows. Setting robust, growth-oriented caps and debt ceilings both minimize the possibilities of insolvencies from price manipulation and liquidation cascades and enable further protocol growth. Gauntlet’s supply cap and debt ceiling methodology builds from the current v2 loanbook, taking into account for each analyzed asset how conducive this asset is to price manipulation and how that relates to potential attacker profitability given protocol parameters. The supply caps help ensure that attacker profitability is negative, given their capital firepower, in order to disincentivize such attacks so that the protocol does not incur bad debt while concurrently providing room for the protocol to grow.
Explicitly, Gauntlet recommends the proposed debt ceiling for each asset in isolation mode to be a small fraction of the capital needed to launch a price manipulation attack with >= 0 profitability. The amount of capital was derived via how much a potential attacker would need to manipulate the price of an asset, which would enable them to borrow positions that could lead to bad debt. This not only gives a considerable margin of safety that protects the protocol from potential attacks - since attackers seek to be profitable before launching an attack - but also provides ample room for the protocol to grow. Concurrently, because supply caps are intimately linked with the debt ceiling, Gauntlet recommends the supply cap to be a function of the v2 position book and the capital needed for a profitable attack.
Similarly, Gauntlet recommends the proposed borrow caps for each asset to allow for growth and minimize risk from potential market manipulations. Borrow caps were calculated based on v2 borrow balances and the recommended v3 supply caps above. We calculate the borrow caps as follows:
Utilizing current balances on v2 Aave and v3 supply caps allows the protocol to optimize for market precedence and market risk. We recommend these caps to allow for migration from the Aave v2 market.
Caps are something that may organically be tuned as the protocol acquires more TVL. Gauntlet will run regular analyses and make frequent updates to ensure the caps best balance insolvency minimizations with protocol growth.
Liquidation Threshold / Loan-to-Value
Gauntlet has previously provided parameter recommendations for LTV and LT for Aave v2 and Aave v3 Avalanche. We recommend initial Aave v3 Ethereum LT to be the average of the LT on Aave v2 and Aave v3 Avalanche, weighted by the total supply of the asset in v2 and v3 Avalanche. Similarly, we recommend initial Aave v3 Ethereum LTV to be the average of the LTV of v2 and v3 Avalanche, weighted by the total supply of the asset.
Initializing LTV and LT on v3 Ethereum with the weighted average of LTV and LT on v2 and v3 Avalanche will allow v3 Ethereum to both draw upon battle-tested precedent (v2 parameters) and also to take into account v3 dynamics (v3 Avalanche) while avoiding the potential inaccuracies of parameters derived from simulations run on spoofed and generated data.
Isolation Mode assets
Gauntlet recommends USDT, LINK, CRV, MKR, TUSD, YFI, UNI, ZRX, MANA, 1INCH, DPI, SNX, CVX, BAT, BAL, ENS to be listed in isolation mode. These assets either have exogenous risk factors that undermine their quality as collateral or have low float and could be subject to price manipulation, putting Aave at risk of bad debt.
Non borrowable assets
Like in v2, Gauntlet recommends AAVE to not be borrowable due to governance manipulation risk.
Non collateral assets
Gauntlet recommends BUSD, LUSD, SUSD, FRAX to not be enabled for collateral due to usage and exogenous risk factors that undermine their quality as collateral.
Reserve Factor
Gauntlet recommends asset reserve factors to be the reserve factors on v2, which will allow v3 Ethereum to draw upon battle-tested precedent.
Liquidation Bonus
Gauntlet has previously recommended Liquidation Bonuses for the Aave v2 market to account for the price slippage and volatility on Eth Mainnet. As such, we recommend implementing the liquidation bonuses from Aave v2 assets, adjusted upwards by a small amount due to the Liquidation Protocol Fee, such that 10000 + (1-LPF)*(LB - 10000) = v2 LB.
Liquidation Protocol Fee
Gauntlet recommends that stablecoins have 20% LPF and non stablecoins have 10% LPF. The LPF is a percentage of the LB that ultimately contributes to Aave reserves. Ultimately, more data is needed to conduct analysis on what optimal LPFs should be. LPFs, like LBs, are intimately linked to liquidation behavior, as they serve as the primary incentive for liquidators. LPF too high (and unadjusted LB) may deter liquidators from conducting liquidations due to fears of unprofitability. Likewise, a higher LPF, with an upwards adjusted LB to ensure liquidators have the same bonus as in v2, may cause too much of the collateral to be eaten up by liquidations, which also impacts liquidator behavior.
With regards to the breakdown between stablecoins and non stablecoins - while LPF is important to help build Aave v3 reserves over time to counter potential insolvencies, it is valuable to ensure liquidators are not disincentivized due to a high relative LPF. Non stablecoins are more volatile and may incur more slippage during liquidations, so in order to ensure liquidator incentives remain robust, we recommend a lower LPF for non stablecoins.
Gauntlet recommends 20% LPF for stablecoins and 10% LPF for non stablecoins to allow for protocol revenue from LPF while minimizing effects on liquidator behavior and user experience.
By approving this proposal, you agree that any services provided by Gauntlet shall be governed by the terms of service available at gauntlet.network/tos.
2 Likes
Thanks for sharing these, @Pauljlei; we wanted to point out a few questions and concerns around both process and risk appetite. We’ll start with the process, highlight some of our work in this area and raise some technical concerns.
Contributor Collaboration
Since the attempted exploit of Aave using CRV, Chaos has been working with several contributors to align on the v3 launch strategy and parameters, as was mentioned in BGD’s update post earlier this week:
This work has been shared privately for initial review and feedback and was sent to Gauntlet privately earlier this week. We’ve been iterating on this from the ground up with the hope of aligning on methodology (Supply Cap, Borrow Cap) and strategy/parameters (posted here) to minimize confusion for DAO stakeholders.
Since being onboarded to the DAO, we have attempted to build a professional working relationship with all community members, including delegates, technical contributors, and anyone interested in our work. We had hoped that sharing our methodology and working with Gauntlet before posting would be good-faith actions in this manner. Unfortunately, this post surprised us as the community has pushed all contributors towards collaboration to protect the protocol better and facilitate more efficient decision-making. For the betterment of the DAO, its service providers must be aligned on work and priorities.
This was a key tenant in recent discussions around both Choas’ onboarding and Gauntlet’s renewal, most specifically this response two weeks ago:
With the bustling innovation within the Aave community and challenging macro environment, there is a requirement for a lot of risk coverage. With two risk managers, we can drive tremendous impact to Aave, enabling the community to move fast without compromising quality or economic security. However, this requires a willingness to collaborate, coordinate, and communicate. Without that collaboration, multiple isolated proposals confuse all active community members and directly oppose the recent promise of working collaboratively.
We will continue sharing our methodologies and results for feedback with Gauntlet and other contributors before public release. We hope this allows for more communication between our teams before engaging the community to ensure the highest level of service to the DAO.
Ethereum v3 Work & Questions
As mentioned above, we’ve been working on the topic with other Aave contributors over the past few weeks. We want to share our work and research, culminating in a different set of initial v3 Risk Parameters recommendations, which has been posted here. We welcome the community’s feedback on our methodology and strategies to align on the best path forward.
For ease of reading for community members, we’ll list the guiding priorities that we considered for our recommendations and would like to raise several questions so that we can better understand the Gauntlet proposal.
Guiding principles:
- Optimizing for GHO: Prioritizing High-Quality Collateral
- Risk-Off, Guarded Launch
- Methodology Transparency
Optimizing for GHO: Prioritizing High-Quality Collateral
The main driver and urgency for the v3 launch, as communicated by key community members such as Aave Companies and BGD, was:
- Migrating existing and new users to a safer, improved version of the Aave protocol, post the CRV attack and as market liquidity has dried up
- Unblock the anticipated GHO stablecoin launch. GHO will initially be launched on Ethereum, leveraging v3 to enable $GHO minting and burning
Accordingly, the initial listing of v3 parameters is paramount. It is a significant milestone for the Aave community but also lays the infrastructure for a strategically essential and impactful stablecoin expansion for Aave. As such, we have been working on a two-phased approach to launch:
- Phase 1: Launch v3 with a subset of markets focused on high-quality, widely used assets which can serve as reliable, safe collateral for the initial GHO launch
- Phase 2: As market conditions allow (with a focus on liquidity & volatility), and with the successful scaling of GHO-specific liquidity and market cap, begin incrementally adding more markets
Risk-Off, Guarded Launch
One of the main takeaways in the aftermath of the CRV attack is that risk parameters across v2 do not reflect the current deteriorated market conditions,as was highlighted in the conversation in reaction to the attempted exploit (snippet below, but further color in that thread)
Chaos Labs has initiated a set of AIPs to reduce LTs across v2 to better protect against future bad debt and begin transitioning to v3 with reduced capital efficiency. The community firmly understands how tedious and time-consuming this process will be, as the continued decrease in risk parameters (namely liquidation thresholds) will likely trigger user liquidations. Since the CRV attack, we have seen firsthand the implications of high-risk parameters having real consequences for the protocol that creates “risk debt.” This impact, if not accurate, cannot easily be reversed and can take weeks to months to correct.
Chaos Labs believes that a more conservative, risk-off, and guarded launch is the more prudent path forward. With more user data and market stability, we can iteratively loosen risk controls instead of the other way around. We understand that increased capital efficiency in v3 will be an excellent motivator to accelerate adoption and migration. However, that shouldn’t justify adding excessive risk exposure at launch.
The migration will need to be an iterative process over the coming months where the community can:
- Responsibly decrement v2 risk via parameter updates
- Consider freezing v2 markets as they launch on v3, shifting net new usage to v3 while not hurting user optionality or experience.
- Consider alternative methodologies such as rewards programs to incentivize capital migration.
We can always increase LTs, LTVs, and other risk parameters as the market deems fit, but we recommend a more conservative launch in the current environment.
Methodology Transparency
The computed numbers between both proposals are encouraging. We’ve publicly posted our borrow and supply cap methodology - and shared it previously via other channels. Is Gauntlet willing to share more insights into calculating these numbers and how your methodology differs?
Generally speaking, we hope the community can converge on a single guideline to inform these processes. As the protocol scales and expands to new ecosystems and markets, we can have clear procedures that create a standard for projects as they look to understand what levers underly parameter decision-making. They can work towards building a stronger case for increased Aave usage & higher caps. We’re happy to collaborate on that as it will benefit the greater Aave community.
Specific metrics
An average of LTs of Ethereum V2 and Avalanche V3 by their current supply is leaning heavily towards V2 values, which are too high. For a bit of context, the v2 market size is ~4.5 Billion USD, while the Avalanche V3 deployment is ~425M USD. So v2’s weight is 10x more significant here and skews all the recommendations towards the v2 values, which, as discussed in previous threads, is quite risky with current market conditions. Moreover, if set too high, reducing the LTs at a later stage is problematic as it triggers users’ liquidations.
While reviewing the inclusion of stETH as a borrowable asset, we ran into concerns of liquidity concentration entirely on Curve. We are continuing to run more analyses to stress test the sensitivity. Still, we would appreciate more color on how you came to the conclusion of activating borrows and a $500m+ borrow cap.
Thank you, we look forward to getting your feedback and iterating on these parameters for a swift launch of v3 on Ethereum.
7 Likes
To respond quickly to the top of your post:
- First things first - we’re happy to work together. Feel free to start a thread on the forums and let us know what your expectations are here and we can discuss and land on what that looks like.
- No one I’ve talked to at Gauntlet is aware of being sent v3 recs to review. If so - we’re sorry we missed that message. I just DMed you my TG handle and we can set up a group for you to contact us in the future. In general, we try to go straight to the forums where possible, in order to keep the community in the loop the best we can.
- That being said - our risk product is a complete solution for Aave’s risk needs. The #1 piece of feedback we got from AAVE stakeholders was that they wanted us to support all markets and assets. This is exactly what we commit to in the renewal. We plan to produce recs for all AAVE markets and assets. We encourage you to do so as well - it will give the community more options for how they want to balance risk in the protocol. This won’t work all the time, as there are corner cases where if our recs conflict it could increase risk in AAVE. That’s something we’ll have to figure out together in the future.
Regarding your parameter suggestions, I’ll give the community a chance to weigh in before we respond in detail. I’d love to know what other people think:
- Do borrow and supply caps protect the protocol against low liquidity assets? Or should we keep LT low for the main assets as a further precaution?
- Should we phase the launch as Chaos suggested? Or go with the plan selected here ?
- How worried are we about stETH liquidity concentration? We are looking forward to Chaos’s aforementioned analysis here
We think our proposal is very low risk. We mean that. Without a ton of analysis, I’d say Chaos’s is even lower. If the community wants to go an even more conservative route here, we’d be happy to work with you all to do so and focus on increasing efficiency later. However if we felt that there was a more conservative path that wouldn’t needlessly punish users, we would have taken it.
1 Like
@jmo, thanks for the response. Happy to hear Gauntlet is open to collaborating on this front. We were able to set up a direct channel over Telegram and we are optimistic that this is the beginning of improved communications and coordination around recommendations, methodologies, and analyses both publicly in the forums and via private channels.
We look forward to hearing the community’s thoughts regarding the different approaches and recommendations for the initial parameters so we can move forward with a formal proposal toward a successful v3 launch.
6 Likes
@Pauljlei, what prompted you to include AMPL in the stable pool?
@RomanPope - we do not include AMPL in our recommendations above.
The Aave-chan Initiative (ACI) has reviewed the decision to onboard long-tail assets in Aave V3, and has determined that it is not economically viable to continue onboarding some of these assets on the protocol.
In the past, the Chainlink and Aave Companies have subsidized the price feeds for these assets, but these subsidies are now expected to end in 2023 with increased chatter of whitelist module chainlink activation, following the chainlink staking process. As a result, the ACI is in favor of not onboarding long tail assets in V3 and progressively offboarding them from V1 and V2 in order to cut losses on these assets.
This need to maintain only economically viable assets in V3 is more important in ethereum Mainnet than on L2s because the transaction fees of the L1 are much higher, and thus the cost of maintaining price-feeds on long tails assets.
the Aave protocol can afford to be more lenient on onboarding assets on L2s but the DAO need to prepare to support these costs in 2023 and can’t assume price feeds are “free” anymore (they never were, some third-parties were just picking the bill so far).
By implementing this policy and starting with a concentrated roster of assets, the Aave DAO will be in a stronger position to negotiate the re-onboarding of assets in the future, and will have the option to subsidize feeds for strategic assets or ask third-party teams to support the cost of price feeds for long tail assets that wish to be onboarded on Aave.
In terms of risk, a cleaned list of assets will decrease the workload of risk teams and potentially help mitigate risk for the protocol.
To this end, the ACI intends to publish a new ARC (Aave Improvement Proposal) to roll back the previous snapshot decision and offboard (more precisely not onboard) the following assets from V3:
| Asset | Initial list | Updated list | Comments |
|---|---|---|---|
| USDC | YES | YES | Strategic asset to keep in V3 (SA) |
| WETH | YES | YES | SA |
| WSTETH | YES | YES | SA |
| WBTC | YES | YES | SA |
| USDT | YES | YES | SA |
| DAI | YES | YES | SA |
| LINK | YES | YES | SA |
| CRV | YES | YES | SA |
| AAVE | YES | YES | SA |
| MKR | YES | YES | SA |
| FRAX | YES | YES | SA |
| LUSD | YES | YES | SA |
| TUSD | YES | NO | Non-economically viable asset to move over to V3 (NEV) |
| BUSD | YES | NO | NEV |
| YFI | YES | NO | NEV |
| UNI | YES | NO | NEV |
| ZRX | YES | NO | NEV |
| MANA | YES | NO | NEV |
| 1INCH | YES | NO | NEV |
| DPI | YES | NO | NEV |
| SNX | YES | NO | NEV |
| CVX | YES | NO | NEV |
| BAT | YES | NO | NEV |
| ENS | YES | NO | NEV |
update: being aware of @ChaosLabs proposal, we think it’s not relevant to propose a third option, The ACI will prepare an ARC to allows community to decide between Gauntlet & Chaos Lab phase I plans for V3 L1 launch.
2 Likes
To respond to a few questions above, at a high level, it is valuable for the community to consider how we should approach conducting a launch. Should supply/borrow caps be used as the primary method for a conservative launch, or should LT be the primary method? There are several downsides to relying on LT versus caps.
LTV and LT values for v2 and v3 should be similar, as market risks in both deployments are driven primarily by the liquidity of supported assets.
- Reducing LTV and LT will reduce the capital efficiency of v3 relative to v2, which is a disincentive for users to migrate to v3 without additional incentives.
- We agree that lowering LTs on v2 can encourage migration to v3, but this has meaningful user friction (risk-off liquidations), so it is up to the community to decide how much to rely on this lever. As for using incentives - this is again a strategic decision for the community (and potentially costly as well), in addition to having governance overhead + time, so it is again unclear how this will exactly look in practice.
- On the other hand, Aave v3 offers borrow and supply caps as additional risk parameters that can be used for a more conservative launch by capping potential risk in tail scenarios without compromising on capital efficiency.
Setting supply/borrow caps is not the same as setting LT and should not be treated identically. Whereas LT changes can cause meaningful user friction (e.g., liquidations), changing caps can be done more dynamically and thus can be a valuable lever for enabling a scaled roll-out of a new Aave v3 market.
As for the question on wstETH - our risk analysis for wstETH showed that there is more than sufficient liquidity for liquidators to acquire stETH to repay debts ($400mm swap incurs ~2% slippage, as well as natural ETH → stETH conversion via smart contract), and slippage from a large wstETH short is comparable to the slippage of shorts on WETH and other blue chip assets- Aave v3 Ethereum will be one of the first lending markets to support wstETH borrowing. Previously, stETH was not borrowable. Thus, it is important to note that there is no precedent for enabling stETH (or wstETH) borrowing on Aave. Predicting organic demand for borrowing wstETH has high variance. As a result, from a strategic perspective (not a market risk perspective), the community may wish to initialize the wstETH market with lower borrow caps while giving the market ample time to naturally evolve and grow. The wstETH market (supply side) can grow quickly due to its greater use cases as compared to stETH, however, lower borrow caps will strategically allow the protocol to observe how organic demand for borrowing grows. As such, we lowered the proposed wstETH borrow caps above from 479000 to 94000, which is reflective of strategic considerations rather than market risk analysis. We look forward to updating the caps depending on how the market evolves.
Also, to make sure the community is clear - the above recommendations are reflective of market risk, not smart contract risk (which is difficult to quantify). The DAO’s technical contributors (@bgdlabs and Certora @Shelly) may have additional feedback on the technical risk side. For example, the community may elect for much lower borrow and supply caps on initial launch, but that would be a strategic decision reflective of battle-testing the technical side and not of market risk. We would value any additional feedback from the DAO’s technical contributors.
1 Like
From the technical side, we are closely monitoring the risk recommendations and decisions of the community about them, as it impacts the activation process of Aave v3 Ethereum.
We want to point out different vital aspects related to the assets:
- All candidate assets are legitimate from the technical point of view, as they are factually a subset of those listed on Aave v2 Ethereum.
- In terms of pricing the assets, every asset is also ready to be listed and on the development side, we are just waiting for the risk suggestions and decision. 3 different pricing approaches will be applied:
- For all “standard” assets with / USD Chainlink feed, the feed will be directly connected to the v3 Pool, via the AaveOracle contract.
- For WETH and stETH, we will apply a special adapter contract we have designed, to avoid price desync updates, enabling maximum eMode efficiency. We will share more details in the following days, before the Aave v3 Ethereum activation.
- For WBTC, we are waiting for the resolution of https://snapshot.org/#/aave.eth/proposal/0x2b95df8c7b2141acdead83beb4cdede9624bb2a4c74f873a5727e2a54f322525. However, we are already finishing the preparation for the adapter if option 1 on Snapshot is chosen, given the timing criticality.
Regarding this, and other considerations, we would like to highlight that both @AaveLabs when they did the initial release of the first, and ourselves since the start of our engagement are doing a good effort on having all the v3 instances as homogeneous as possible, without changes between them.
This means that if smart contract risk on the assets themselves is controlled, the protocol should also inherit the security of other instances, as factually the software is exactly the same.
So we think parameters like borrow/supply caps should be defined based fully on market risk by general rule, and only being cautious in new cases, like for example if enabling wstETH for borrowing, but not so purely due to smart contracts risk.
1 Like
Are there any considerations, upgrades to be implemented to v3, to enable GHO to be launched in a safe and controlled manner ?
Some of the functionality, which I think is key, is the ability to control the following aspects:
Minting GHO
- Limit / Control which assets can be used as collateral to mint GHO
- Limit / Control the amount of GHO that can be minted against a specified asset type.
- Limit / Control the amount of GHO that can be minted per unit of collateral in each Reserve
This will give the community the ability to control the composition and risk profile of the assets backing GHO. Ideally, we launch GHO with the ability to mint GHO using only low volatile assets, like stable coins, and then over time introduce assets like ETH or BPTs. If a collateral type, ie: BPT or G-Uni token, actually contains GHO within it (bb-a-USD / GHO or ETH/GHO), then ideally we can control the amount of GHO which can be minted against each unit of collateral. This will enable greater capital efficiency whilst also avoiding minting GHO using GHO as collateral. ie: Collateral is 50% GHO, then users can mint GHO against the 50% that is not GHO and / or users can borrow GHO against the entire collateral holding as this does not affect/risk the over collateralization ratio of GHO.
Borrowing GHO
- Ability to create a GHO Reserve
- Ability to borrow GHO against certain collateral types
If we can control how GHO is minted against each type of asset to avoid GHO becoming under collateralized, then we can create a GHO Reserve within the same Aave deployment. If we can do this then we do not need to reply on separate v3 deployments that don’t have GHO mint functionality to enable GHO as Collateral or be borrowed.
My reasoning for asking, as the design of GHO is not known and it is even less clear if there are any limitations to GHO due to the v3 design, then now is the time to discuss when we upgrade v3. I would be particularly concerned, if we lack the functionality to introduce GHO in a controlled manner ie: control what is collateral for minting GHO, this to me would be a massive oversight and has the potential to mean GHO is back solely by long tailed assets which would give it a higher risk profile than proven stable coins like DAI and LUSD.
2 Likes