[ARC] Aave V3 Ethereum Deployment: Assets and Configurations

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

Gregory from Lido here :desert_island:
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.


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
stETH YES YES YES YES (wstETH) YES (wstETH, pending analysis) YES (wstETH) YES (wstETH)
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)

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.


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.


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.


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.


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.


To respond quickly to the top of your post:

  1. 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.
  2. 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.
  3. 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.


@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)
TUSD YES NO Non-economically viable asset to move over to V3 (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.


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:
    1. For all “standard” assets with / USD Chainlink feed, the feed will be directly connected to the v3 Pool, via the AaveOracle contract.
    2. 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.
    3. 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 @AaveCompanies 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

Hi @bgdlabs, @AaveCompanies,

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.