hello boys and girls
just like to point out that the list you’re operating with is missing ENS token for some reason - even though less utilized tokens (cough, renFIL, cough) are on it
1 Like
weren’t those v2-specific features? are those present in v3 (or others that rely on exact precision)?
Not v2 specific, the same issue is present on v3 as well.
I would advocate for omitting DPI due to a low market cap (~$32mm.)
We are supportive of the third version of this proposed list, a combined iteration of Gauntlets’, Emilio, and Oneski22. @sakulstra thanks for the technical clarity here - wstETH seems best.
While DPI had demand and fit well into the meta-governance play, it feels best to not include it in V3 due to the recent mango hack and threats circulating social media.
If this perspective changes, we welcome a proposal to re-list and enable borrowing.
The list IMO which should be regarded this way is:
DeFiPulse Index ($32m)
Ren ($111m)
xSUSHI ($100m)
This is being discussed in parallel at: [ARC] Price Manipulation Implications on Aave: October 2022
Hey,
Gregory from Lido here 
Thank you for taking a close look at wstETH, we are also thinking of price manipulation potential around its mechanism. The Lido team is in touch with Gauntlet, we will be back with more details if we find anything unexpected on our side.
1 Like
The DeFi Pulse Index, operated by Index Coop, has been available as collateral on Aave v2 markets for over a year. Snapshot vote for reference.
When referencing the recent Mango Markets incident, I assume this means oracle manipulation. TVL should not be the sole parameter for determining the risk of price manipulation. For DPI, in particular, the permissionless mint/redeem capabilities (as mentioned by Llama) allow for arbitrage opportunities when any of the underlying assets see significant price deviation.
Index Coop previously dealt with an attack similar to the recent Mango incident. At the start of the year, an attacker attempted to manipulate an oracle for the BED Index through Rari markets. This attack was unsuccessful because all Index Coop products can be freely minted making it easy for arbers to act quickly. This thread gives a detailed account of this failed attack. Moreover, our Flashmint functionality makes this arbitrage opportunity even easier, using Aave to instantly create a flashloan into the position. We’ve seen significant volume in our Flashminting contracts up until now and expect any significant deviation to see an immediate arb.
As Aave and the defi ecosystem matures, Index Coop believes structured products with inherent risk management are critical. We’ve seen larger DPI holders use DPI as collateral on Aave and expect this to continue as we strive to get DPI into the hands of more traditional investors. We hope to see DPI listed amongst this first batch of assets and bring increased buy pressure for the largest tokens in DeFi including AAVE. While DPI is one of the lower market cap assets, it is far less risky for Aave than most assets being proposed. As one of the largest voters in AAVE governance we looks forward to voting on these new assets in V3 and are happy to answer any questions.
3 Likes
Thank you, everyone, for your thoughts. We propose Gauntlet 4 below. To keep the discussion moving forward, we are targeting a Snapshot vote next week for Gauntlet 4 with the options YAE, NAY, and ABSTAIN.
Following this Snapshot vote, we look forward to providing parameter recommendations for the standard V3 market.
We’d note that we include USDT in isolation mode, similar to V3 Avalanche and V3 Polygon.
| Asset | Gauntlet 1 | Gauntlet 2 | oneski22 Proposal | Emilio Proposal | Gauntlet 3 | Llama Proposal | Gauntlet 4 |
|---|---|---|---|---|---|---|---|
| USDC | YES | YES | YES | YES | YES | YES | YES |
| ETH | YES | YES | YES | YES | YES | YES | YES |
| stETH | YES | YES | YES | YES (wstETH) | YES (wstETH, pending analysis) | YES (wstETH) | YES (wstETH) |
| WBTC | YES | YES | YES | YES | YES | YES | YES |
| USDT | YES | YES | YES | YES | YES | YES | YES (Isolated) |
| DAI | YES | YES | YES | YES | YES | YES | YES |
| LINK | YES | YES | YES | YES | YES | YES | YES |
| CRV | - | YES | YES | YES | YES | YES | YES |
| AAVE | YES | YES | YES | YES | YES | YES | YES |
| MKR | - | YES | YES | YES | YES | YES | YES |
| TUSD | - | YES | YES | YES (Isolated) | YES (Isolated) | YES (Isolated) | YES (Isolated) |
| FRAX | - | - | YES | YES (isolated or no collateral) | YES (no collateral) | YES (no collateral) | YES (no collateral) |
| BUSD | - | YES | YES | YES (no collateral) | YES (no collateral) | YES (no collateral) | YES (no collateral) |
| YFI | - | - | YES | YES (isolated?) | YES (isolated) | YES | YES (isolated) |
| UNI | - | YES | YES | YES (isolated?) | YES (isolated) | YES | YES (isolated) |
| ZRX | - | - | - | YES (isolated) | YES (isolated), but TBD | YES (isolated) | YES (isolated) |
| MANA | YES | YES | YES | YES (isolated) | YES (isolated), but TBD | YES (isolated) | YES (isolated) |
| xSUSHI | - | - | - | - | - | - | - |
| 1INCH | - | YES | YES | YES (isolated) | YES (isolated) | YES | YES (isolated) |
| DPI | - | - | - | - | - | YES | YES (isolated) |
| GUSD | - | - | YES | - | - | - | - |
| SNX | - | YES | YES | YES(isolated) | YES(isolated) | YES | YES(isolated) |
| CVX | - | - | YES | YES(isolated) | YES(isolated) | YES | YES(isolated) |
| BAT | - | - | - | YES(isolated) | YES(isolated), but TBD | YES(isolated) | YES(isolated) |
| REN | - | - | - | YES(isolated) | YES(isolated), but TBD | YES(isolated) | - |
| sUSD | - | YES | YES | YES(isolated or no collateral) | YES(no collateral) | YES | YES(no collateral) |
| ENJ | - | - | - | - | - | - | - |
| BAL | - | - | YES | YES(isolated) | YES(isolated), but TBD | YES | YES(isolated) |
| AMPL | - | - | - | - | - | - | - |
| RAI | - | - | - | - | - | - | - |
| USDP | - | - | - | - | - | - | - |
| UST | - | - | - | - | - | - | - |
| LUSD | - | - | YES | YES (no collateral) | YES (no collateral) | YES | YES (no collateral) |
| FEI | - | - | - | - | - | - | - |
| renFIL | - | - | - | - | - | - | - |
| KNC | - | - | - | (there is a proposal to list the new KNC token, so we should evaluate how that goes) | - | - | - |
| ENS | - | - | - | - | - | YES | Yes (isolated) |
2 Likes
Regarding some technical aspects affecting the listing of assets in the future Aave v3 Ethereum:
- In order to have unified behavior across all Aave v3 instances, we recommend using USD as the reference currency of the Aave oracle, changing this way from the ETH reference on Aave v2 Ethereum.
Given the presence on the Ethereum v2 pool (and plans for the upcoming v3) of stETH, we will be introducing an oracle adapter to be used by wstETH as a price feed, to avoid any problem with async updates from Chainlink price feeds. - We recommend using the BTC/USD feed for WBTC, as we consider it more representative than an alternative WBTC/USD, based exclusively on the secondary market value of WBTC.
- For the listing of wstETH, it will be necessary to evaluate the availability of a conversion feed between stETH and wstETH, as the pricing should be through the chain ETH/USD → stETH/ETH → wstETH/stETH.
- For if not taken into consideration, it is essential to highlight that DPI is a Chainlink calculated price feed, meaning that its value derives from the aggregated value of its underlying assets.
We will be synchronizing with Chainlink to verify that all the requirements in terms of feeds are met before any deployment of Aave v3 Ethereum by the community.
3 Likes
We have published the Snapshot vote below and encourage all in the community to participate.
1 Like
Hi @Pauljlei - we have expressed this privately but feel concerned about the inclusion of DPI / ENS.
Both seem to be proposed as a result of external partnerships, which are now no longer relevant.
Happy to be more explicit if needed.
Looking at these assets, on V2 - only 43 addresses borrowed DPI at a total of $1,971,056.
ENS had 77 unique addresses for a total of $8,732,512.
xSUSHI, omitted from the list, was borrowed by 167 users for a total of $186,286,217…
Or look at ENJ, 292 unique addresses for a total $24,448,819.
I understand there are important risk metrics involved as well, but at face value, some of the other assets would be a better fit - looking at demand and users.
This deliberate choice of long-tail assets feels a divergence of two different strategies. This is a critical time for the DAO to choose: either we list a bunch of assets, boosting a UX and freedom.
Or - we focus on the ones with verifiable, proven demand.
This analysis needs to include the recency of demand but it is important question to consider for developing a new market - which type of assets do we focus on?
We say this as ENS delegates too.
2 Likes
Chaos Labs would like to express our support of this proposal. As we commented before, Aave v3 offers improved risk mitigation mechanisms (such as Isolation Mode, Supply/Borrow Caps) and we believe it is of the community’s best interest for users to migrate from v2 to v3. We believe this initial list of assets is a significant first step that can help achieve this goal. In that spirit, we also recommend adding ENJ as an isolated asset, as it is currently the only asset available to be used as collateral on v2 that is not on the proposed list.
We look forward to the deployment of Ethereum V3 and partnering with other contributors to enhance the ongoing safety and growth of the protocol via parameter recommendations and new asset listings.
2 Likes
Why enabling stETH/wsthETH as collateral at deployment? I understand that’s the current situation with Aave V2, but I wonder if it was the right choice at that time.
Allowing borrowing any asset against stETH in Aave, it’s a significant risk to the protocol solvency which Aave cannot control.
Firstly, although there is a tentative timeline for withdrawals enabled on main-net, Aave cannot know how long it will take and what will be impact of it on stETH/ETH liquid markets.
Secondly, the Lido withdrawal contract is not even deployed yet. Before allowing stETH as non-isolated collateral, I think Aave should wait for multiple audits/formal verification on the final implementation and that the contract is deployed and immutable.
I propose stETH/wsETH to be enabled in isolated mode in Aave V3, pending Lido full withdrawal contract implementation and withdrawals enabled on main-net.
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
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