[Discussion] Safety Module

Hi Aave :wave:

Llama has conducted an analysis on the performance of the Safety Module and we would like to share our findings with the broader community. We mentioned a few considerations for the community to discuss which can then be incorporated into a future proposal.


To start, as a refresher on the Safety Module (SM).

Two tokens can be deposited and staked in the SM. These are AAVE and the Balancer v1 80AAVE20wETH (ABPT) liquidity token. By depositing AAVE and ABPT in the SM, depositors receive stkAAVE and stkBPT respectively, along with yield nominated in AAVE. 550 AAVE are distributed daily to users who stake AAVE and another 550 AAVE is distributed daily to depositors who stake ABPT. In return for the AAVE yield, depositors are risking up to 30% of their capital by providing a backstop for the Aave markets.

Aave governance can in the event of a shortfall, auction off up to 30% of the assets held in the SM. A cool down period exists to prevent depositors from withdrawing their capital from the SM before the governance process auctions AAVE and ABPT to replace the funds lost by Aave users. If greater than 30% of the SM is needed, the Aave community has the ability to mint and auction new AAVE tokens on market.

For more details on the SM, please check out this Aavenomics link.


The image below shows the composition of the SM and indicates most of the Shortfall Coverage is provided by AAVE depositors. Do note that the ABPT is utilising Balancer v1 and Balancer v2 was launched early in Q2 2021.


The SM provides around a 6.13% APY on stkAAVE deposits and 13.3% APY on stkABPT deposits. During June 2022, the AAVE emissions to stkABPT and AAVE deposits was renewed.

The annual spend, 398,200 AAVE, is worth $32.12M at $80/AAVE and is heavily dependent upon the price of the AAVE token. The chart below shows the daily expense being accrued by Depositors, ie: 1,100 AAVE/day x Spot Price, to be around $88,000 per day from mid May 2022 to mid August 2022.

Daily SM spend is $88,000 at $80/AAVE

Annual SM spend is $32,120,000 at $80/AAVE

In return for 1,100 AAVE/day in SM emissions, the community receives $126.1M of shortfall coverage, defined as 30% of the funds deposited in the SM. The value of the Protocol Coverage is volatile, fluctuating from about $340M to $52M during 2022.

The combined TVL across these markets is $3.73B. Do note, this only includes the following deployments and does not reflect the recent Ethereum v3 deployment inclusion.

  • Ethereum v1 market
  • Ethereum v2 market
  • Ethereum ARC market
  • Avalanche v2 market
  • Polygon v2 market

The “Percent of Aave’s TVL Covered by the Safety Module” chart shows below. It ranges from 1.0% to 3.0% of total TVL for the covered Aave deployments.

The chart below shows the value of the AAVE emissions divided by 30% of the value staked in the SM. ie: the cost per $ of actual coverage. The yield ranges between 27.8% and 44.8%.

Annual $32.12M in AAVE emissions at $80/AAVE whilst receiving $126.1M of actual Short Fall coverage.

Diving a little deeper, the below chart shows the amount of AAVE being claimed each month varies greatly and that most of the AAVE is either transferred to another wallet, swapped for another asset or compounded by staking to earn more AAVE yield.

The charts below show the next action taken by depositors who receive AAVE from the SM. 37.3% of AAVE claimed by stkAAVE depositors is staked and compounded. 53.9% of AAVE emission received by stkABPT holders is transferred to another address. 31.4% and 38.4% of AAVE received by stkAAVE and stkABPT holders is swapped, sold, on market.


(LST = Liquid Staking Token)

The below summarises well known topics relating to the SM within the community:

  • SM is over exposed to a single asset, AAVE
  • Auctioning AAVE in the event of a Shortfall can lead to front running, which can have an adverse effect price, causing a greater amount to be auctioned
  • Introducing additional, or alternative assets, into the SM will reduce the dependence on a single asset
  • Increasing the amount (30%) auctioned off in a shortfall event will increase Protocol Coverage, but may require a higher yield to compensate for risk
  • Introduction of Snapshot has increased the overall governance process duration
    • Extend the Cool Down period to be realigned with Governance process duration

The below summaries the notable findings from this analysis:

  • Assets held within the SM are volatile and broadly aligned with TVL
    • Dollar value of Protocol Coverage fluctuates with the broader market
  • 30% shortfall coverage is not scalable and greater capital efficiency is needed
  • Overall spend on SM is high relative to DAO’s revenue
    • Annualised SM spend - $32,120,000 at $80/AAVE
    • Annualised Revenue - $16.3M
  • Notable portion of SM emissions are being sold on market indicating users prefer yield in an alternative asset
  • Balancer v1 is obsolete and the ABPT pool requires migration to Balancer v2
    • Opportunity to revisit the 80AAVE20WETH composition of the pool
    • Balancer’s tokenomics has changed, Aave SM incentives should be additional to Balancer / Aura gauge yield.

The following bullet points introduce concepts for discussion in the comments section below:

  • Include non AAVE emissions - Eg: GHO, to reduce sell pressure on AAVE

    • A portion of the GHO revenue can replace or complement AAVE emissions
    • Potential to reduce AAVE sell pressure, especially if depositors can choose what token is to be received. This is similar to cvxCRV staking.
  • Shortfall coverage tiers - Auction off varying portions of deposits in the event of a Shortfall. Examples: 30%, 45% and 60%. Aave can elect to offer higher yield for higher Shortfall coverage. The type of assets included, amount (ceiling) and composition can all be controlled by Aave governance.

  • Reduce AAVE weighting when migrating from Balancer v1 ABPT to v2 and introduce additional pools which could lead to price arbitrage triangles like shown below. (This is an idea, for discussion, not a recommendation). More importantly introduce GHO pools to the SM and reduce the composition of AAVE in each pool.
  • Realise synergies with bootstrapping adoption of GHO whilst encouraging greater GHO liquidity. Ie: GHO/LST

  • Develop an equivalent contract which enables deposits into the SM to earn rewards from Curve, Convex, Balancer, Aura and others. This is to showcase something that could be done but would introduce a lot of risk surface area. The community does need to consider the holistic Aave exposure to one protocol from a risk perspective.

  • Introduce a Bad Debt budget backed by assets held in the Collector Contract that acts as the first source of liquidity for excessive debt repayments.

Next Steps

Depending upon feedback in the comments, the two topics that can be progressed via their own ARFC proposal in the near future:

  • AAVE liquidity pools

    • Pivot away from AAVE/wETH (80/20)
    • Migrate to Balancer v2
    • Consider core pool status on Balancer (>50% pool is productive, ie: LST)
    • Create an AAVE pool on another DEX
    • Future AAVE/GHO or GHO pools considerations
  • Introduce a Bad Debt budget

    • Nominal amount of annual budget allocated to paying down excessive debt
    • Guidelines for how /when this would be called upon, ie: avoid SM Auction as excessive debt is less than Bad Debt budget
    • CRV bad debt was $1.7M, initial budget of $2M could be considered

Thank you for taking the time to read this discussion post and learning more about the Aave SM. We look forward to reading your comments below and welcome your feedback.

This post was prepared by Llama contributors: DeFi_Consulting (@MatthewGraham), @Dydymoon, @scottincrypto and @schlabach.


Thanks for getting the ball rolling on this. Focusing on the points (that I’ve also discussed here) that:

  • the SM is overexposed to AAVE

  • Auctioning AAVE in the event of a Shortfall can lead to front running, which can have an adverse effect price, causing a greater amount to be auctioned

  • 30% shortfall coverage is not scalable and greater capital efficiency is needed

I believe that the SM should remove AAVE altogether, as there is seemingly no situation in which a large deficit could be covered by the fund without sending the token to 0 and creating a minting death spiral. LP tokens are a bit better, and I agree that they should be diversified. Including GHO makes sense, as long as the amount that is allowed to be deposited into the SM scales with GHO liquidity on DEXs so as to not risk depegging in the case of an Auction.


Thanks for the analysis @Llamaxyz !

Some aspects to take into account and guide the discussion of the community:

  • The “tranches” model is something that has been discussed in the past, and definitely has potential. From the technical side, important to clarify that the current system is not really adapted to define a specific % of “APR”, as it is based on the concept of “emission per second”, the equivalent to what @Llamaxyz points out of 550 AAVE per day currently.
    So a model like this, would be more about defining a total of emissions per second (one/multiple reward tokens, e.g. AAVE, GHO, etc) and then static percentages for different tranches: for example, the 60% slash tranche would get 60% of rewards, 45% the 30% of rewards and 30% would get 10% of rewards.
    This model is more optimal because the market itself will define the appetite of risk profiles and self-arbitrate. Additionally, almost no extra development would be needed.
  • Depending on the underlying facility (Curve, Convex, Aura, etc), potentially is possible to not do any extra development for re-usage of capital on the SM, it mainly depends if those platforms allow tokenization & transferability (that SM can just use them without any problem as it is), or not.
    Generally, we encourage to focus on platforms with tokenization, as it makes things simpler development/security-wise.
  • Given the first GHO facilitator was chosen to be Aave v3 Ethereum by the community, having GHO as a reward type for the Safety Module seems natural from a high-level perspective. That being said, we recommend being cautious with ideas of using GHO or LPs including it as asset to deposit into the SM. If properly defined could potentially work, but initially it creates some type of circular dependency that should be studied in depth for the following reasons:
    • GHO is minted exclusively from Aave v3 Ethereum to start with, and on that model, used to backstop precisely the debt of that pool, including GHO debt.
    • The Aave v3 Ethereum GHO facilitator has at its core a discount mechanism based on the SM holdings. Most probably this is not an issue, but definitely, the impact should be considered.
    • GHO is exposed to all assets listed and to-be-listed in non-isolation in the Aave v3 Ethereum pool. It means the risk profile changes with every new asset listed (not straightforward to state if its risk profile gets better or worse, depends on multiple factors), so again, having it backing the same pool and acting as a reward is somehow interdependent == should be really studied.
  • As announced in our engagement, we have been working on an update of the Safety Module smart contracts, purely improving the technical aspects of it. We will be publishing all the details of this new version (addressed as SM v1.5) in the following days, but we can already confirm that the extension of the cooldown period is part of the development, initially proposing 20 days cooldown.
  • We have this pending in our pipeline for this upgrade to migrate to Balancer v2, and will be finished just after the SM v1.5 update. All the Aave smart contract components are quite interdependent, and liquidity on the existing AAVE/WETH is quite important for the ecosystem, which is why it made more sense to first “settle” aspects like first the Level 2 voting thresholds or the aforementioned SM v1.5.
  • It is important to not forget that the SM has a core role in the Aave governance, and the numbers provided seem to support that, with an important percentage of the current AAVE rewards coming back to the ecosystem in one way or another.
    We suggest analyzing from the governance point of view too because one of AAVE’s main utilities is its governance power.

Needless to say, not in the conceptual field (as @Llamaxyz is diligently leading the conversation), but we will tackle any extra development if required, once the final model is defined


Hi jbeezy from Lido DAO.

Of course I have bias but agree with making the SM more productive and having less direct risk being exposed to AAVE risk. I think adding an LST such as wstETH is a great idea. It could help the pools and assets be more productive in the underlying AMMs / Safety Module compared to standard WETH/ETH.

I would be happy to discuss additional considerations such as wstETH/bb-a-WETH support. This could have second order effects by increasing TVL on Aave markets both through direct deposits from Bal as well as the folded leverage loops that are popular with the kids.

GHO adoption will be a risk initially but I think Lido can help with bootstrapping efforts replacing as @Llamaxyz mentioned WETH, with a more productive asset. Which of course is not without its own risk.

We are already deeply integrated in the Curve ecosystem as well so would be happy to explore and facilitate new pools and the reWARDS committee could probably assist in the bootstrapping efforts. Lots to discuss here.


Hey @Llamaxyz, thank you for posting this! Very exciting to see the conversation move forward after our initial inquiry on the topic!

Doing some analysis on our end, our primary concern is sustainability of the strategy. So far in 2023, emissions to incentivize staking in the Safety Module are 4.8x revenue earned from the covered instances (not including flash loan revs). SM AAVE incentives are funded by the Ecosystem Reserve. So that gives this strategy roughly a 4.5-year runway.

Notes: run-rate doesn’t account for third-party payments out of the ecosystem reserve.

Regarding design considerations:

  1. Treasury/Currency Alignment
    a. SM incentives come from the treasury, which is recouped with revenues from borrowing, flashloans, and liquidation fees. So in a sense, this insurance cost should take into consideration the DAO revenues that are funding it.
    b. The DAO earns revs in the tokens that are borrowed and then pays for insurance in AAVE. There is an obvious mismatch here between revenues, the asset being used to insure, and the asset used to pay for it. Diversification is a reasonable goal (transition DAO’s treasury from a large AAVE allocation), but this should be explicit rather than simply convenient. Especially since the treasury gets more diverse each day, since aToken revenue is never AAVE.

  2. Risk Budget.
    a. The risk budget can be defined as any spending that goes toward preventing lending losses. This includes paying Gauntlet and Chaos Labs to set params that will protect depositors as well as expenses allocated for an “insurance” or safety module. Importantly, part of the payment for Gauntlet’s services includes deposits into an insolvency fund.

  1. Effectiveness
    a. As we stated in our post a few weeks ago, using AAVE or BPTs as collateral for your insurance pool is heinously ineffective. Only ⅓ of staked assets can be used and likely only ⅔ or less of that can actually be recouped from the market in a firesale. There are alternative ways that achieve the desired outcome, or at least present less risk, which we should (in theory) be optimizing for (have an insurance fund to repay depositors in the case of bad debt).
    b. The name of the game here is liquidity. Stablecoins and ETH are by far the most liquid assets and should be prioritized in any insurance fund research/allocation.

  2. Tokenomics
    a. Currently, the Safety Module functions to serve AAVE tokenomics at the expense of practicality. The tension between AAVE utility and the SM’s purpose as insurance is the main source of the issue, and it’s worth exploring the (at least partial) separation of these two functions).

  3. BizDev and Diversification
    a. The desire to make assets in the SM productive holds weight, if they are not productive then this increases the cost the DAO would need to pay to attract depositors. That is the tradeoff. This also provides an opportunity to diversify risks away from the Aave protocol. This might be heresy, but to put SM assets on Aave to be there in case something goes wrong on Aave sounds ill-advised. Further, it is an opportunity to support partners. Whether that is Lido, Balancer, Curve, Yearn, or others. The risk team will of course be tasked with thorough analysis but there might be an opportunity here.

h/t Kentrell Key on the data/viz


Hey everyone, thanks for the interesting feedback !

While this post is focusing on analysis and a high level vision of the potential improvements to evaluate the community interest; the issues outlined above led us to work on a strategy improving the SM mechanisms & efficiency, as well as GHO & AAVE liquidity, which will be posted in detail on the forum in the coming days.

However to give some context, this proposal will considers to:

  • Implement several “modules” for each asset category & Update the slashing parameters
  • Diversify assets supported in the SM, initially focusing on Aave related tokens and liquidity
  • Improve the rewards management with gauges on smBPT assets to avoid incentives dilution
  • Optimize strategic voting power by moving the distribution for part of the current SM reward budget to vote incentives, leveraging the premium compared to liquidity mining.
  • Implement Aura contracts to the SM

Overview of the proposal design:


As mentioned in the analysis, the main goals are increasing the asset diversity and capital efficiency of the funds deposited in the SM, reducing the insurance cost and the AAVE dependence in case of shortfall event, and increasing the cover value as well as the yield for depositors.

The SM currently has 2 categories (Single Asset & Variable LP). There are several considerations for the slashing categories: The one described above is assuming the same assets in the 45% & 60% slashing categories.

Another one, which is considered in the strategy, would be to have 3 categories with different assets: Single assets, Volatile LPs and Stable LPs, with different slashing and yield ranges for each category.

The assets considered in the strategy are the following:

Single assets: 30% Slashing (Rewards in AAVE & potentially GHO)

  • AAVE > StkAave
  • wETH (and/or wstETH) > StkwETH (and/or StkwstETH)

Volatile LPs: 45% Slashing (Rewards in BAL + AURA)
The weights are to be discussed in the Aave liquidity pools proposal:

  • BPT-AAVE-WETH (or LST) > Stk-aurasmB-AAVE-WETH-gauge
  • BPT-AAVE-GHO > Stk-aurasmB-AAVE-GHO-gauge
  • BPT-GHO-WETH (or LST) > Stk-aurasmB-GHO-WETH-gauge

Stable LPs: 60% Slashing (Rewards in BAL + AURA)
There are several stables that could be considered for pairing GHO, the community should discuss the assets to consider for this pool. (Note: There will be several GHO pools created.)

  • BPT-GHO-Stable: > Stk-aurasmB-GHO-Stable-gauge

In both volatile and stable categories, the SM would receive BPT, then mint “smBPT” (which is the asset eligible for the gauge), then deposit smBPT on Aura which stake on Balancer & boost, the SM receive aurasmBPT-gauge & mint Stk-aurasmBPT-gauge to depositors.

Considering that CRV & CVX holdings are relatively small, that most of GHO liquidity will most likely be on Balancer and to reduce the scope and associated risks, the strategy proposal is focusing on the Balancer ecosystem.

However, as the veBoost power would be too low to max boost positions on Balancer at first, the idea would be to start by implementing Aura only on the SM contracts.

As the Aave DAO veBAL boost power will grow over time, Balancer can be implemented later to optimize the veBoost by migrating part of the funds deployed on Aura to Balancer.

Curve, Convex and any other protocol where Aave would accumulate strategic voting power can also be considered later.

Thanks for the detailed feedback !

To clarify, there is a typo on the risk tranche 2 & 3, tokens emissions rewards considered are BAL & AURA not AAVE & GHO. Also, the range APR shown on the table above are taken from the proposal, based on TVL & yield estimations as well as current market metrics. (The strategy calculations are based on the current SM reward budget to remain below 1100 AAVE/day).

According to estimated TVLs, targeting these APR ranges would result in an increasing reward budget if distributed in AAVE liquidity mining, which is not the idea.

While it’s better to keep this liquidity mining method for single assets because there are no gauges on it, it’s possible to have some for Balancer liquidity pools, it’s even more interesting if these are core pools.

If smBPT are eligible for gauges rewards, part of the current AAVE reward budget should be used for vote incentives, driving more BAL emission to Aave related pools, bringing more Aura rewards as AURA emission is related to BAL captured by the protocol. Later on, migration from AAVE to GHO rewards could be considered.
This would be the case in both volatile & stable LP categories, which would create too much complexity to use the same distribution model as single assets liquidity mining.

I guess AURA + BAL rewards claimable weekly/bi-weekly and distributed in proportion to the deposits in the SM could be more gas efficient and easier to implement for LP categories ?

Despite strategic voting power positions like veBAL holdings which might be locked on Balancer from the collector contract, all liquidity positions on the quoted protocols allows tokenization & transferability.

It can make sense to add new protocols progressively, starting by the Balancer & Aura (Most interesting for the strategy considering Aave’s veBAL share.)

While all pools proposed with stables are including GHO, I totally agree with this point and I remind that these are only examples, the assets in the pools are to be discussed by the community.

I initially considered core pools everywhere but renounced them as the obvious choice to pair would be bb-a-USD, which creates an even bigger circular dependancy, so it’s very risky to have aTokens in the SM.

Of course there are other possibilities for core pools such as generalized boosted pools recently released by Balancer which could be discussed later if the community is interested in focusing on this point.

One potential solution to limitate GHO inclusion risks could be to cap the deposits on each asset, with a limited amount compared to the total GHO circulating. This would also help define and maintain the range APR expected depending on TVL & voting power on the smBPT gauges. Other stablecoins than GHO could also be considered.

Thanks for the feedback !

While adding LST to the SM can bring additional risks that need to be properly considered, wstETH could be added either on single assets, volatile LPs or in both categories.

As mentioned above, it’s very risky to add aTokens in the SM as it’s here to cover the funds deposited on the Aave protocol, so if something happens on Aave and aTokens are in the SM, the same happens to the cover. However, the wstETH/bb-a-ETH pool seems a very good addition as collateral for the StakedATokens proposal.

Hey John, thanks a lot for this detailed feedback !

I agree that the liquidity mining in Aave from the ecosystem reserve is not sustainable, and Llama’s work on some previous and upcoming proposals aims to change that in several ways:

Strategic voting power accumulation:

  • Proposals to buy BAL, convert in B-80BAL-20WETH and to lock BPT & CRV holdings bought and from the Collector contract to receive veBAL & veCRV, allowing to redirect emission on the Aave related pools
  • Collector contracts treasury strategies: In work proposals to deploy part of the funds held in the collectors to accumulate more strategic voting power.
  • Protocol Owned Liquidity & Insurance : If the SM update is voted, considerations to deposit part of the collector contract in the Safety module to partially self insure the protocol and accumulate more BAL & AURA, increasing the voting power of the DAO over time, which reduces the reward budget needed. (This would also re-accumulate AAVE as the DAO would receive some as vote incentives).

Safety Module updates (upcoming proposals):

  • Optimization of the rewards distribution by creating vote incentives to attract more strategic voting power on Aave pools
  • Safety module Insurance cost important reduction
  • Boost of the yield by Aura’s veBAL holdings + AURA & BAL rewards for depositors
  • Core pools considerations (receives vote incentives directly from Balancer, in exchange for part of the yield generated by IBTs in the pool)
  • Slashing parameters increase leading to a higher cover value
  • Avoid incentives dilution by creating gauges on smBPT assets
  • Earn AAVE back by voting with the DAO on Aave pools & receiving vote incentives.
  • Implement a bad debt budget to reduce the risks & associated yield on the SM

Further Considerations:

Use part of the revenues generated by GHO for several uses cases such as:

  • Progressively replace the current SM budget, reducing AAVE selling pressure & spending (~10 to 20% of GHO earnings)
  • Consider using a portion TBD to build POL positions over time, generating more strategic assets, leading to a better liquidity as well as a reduction of incentives needed.

As for the treasury diversification, I’d say it’s already happening but it takes time. AAVE holdings represent 75.6% of a 143M treasury, while 19.3% are stables. It’s true that the collector contracts earn revenues from many different assets, which is why we proposed consolidation proposals, but it was for USDC. The DAO could consider doing the next consolidation for AAVE indeed.

I believe this covers the points 1-Treasury Currently Alignment & 2-Risk Budget.

About point 3-Effectiveness, I fully agree with you on the lack of efficiency and I believe you’ll like the upcoming proposal as it’s about fixing all these points.

Agree about point 4-Tokenomics, but I guess things will change with the GHO release, as the tokenomics are improved by the reduced interest rate if holding StkAAVE. Migrating the rewards to GHO over time and consider a long term accumulation by the protocol could also help.

Again, I agree on point 5, the goal is definitely to benefit from considerable partnerships with influential protocols in the ecosystem and create synergies.

Looking forward to discuss and receive more valuable feedback on these topics !


Super thorough response, really appreciated. Lot of good thinking here.

On Proposed Changes:

Is it fair to characterize the proposed changes into two groups?

  1. Add ETH and wstETH to the existing SM.

  2. add new BPTs and use Aave’s BAL and AURA rewards to drive rewards to smstkBPTs, thereby decreasing the cost to the DAO of those assets?

Re 1) big fan. Adding ETH and wstETH, which are super liquid, to the SM makes a ton of sense.

Goal 2 is interesting but I think the juice won’t be worth the squeeze. Using end-of-year numbers, the sim below shows at different BAL prices and SM staker yields how much value would be added to the SM. Even at the most optimistic assumptions, it is an additional $6.5mm deposited in the SM. Note that this doesn’t include AURA rewards and would acquire the necessary ETH for a veBAL position.

  • Proposals to buy BAL, convert in B-80BAL-20WETH and to lock BPT & CRV holdings bought and from the Collector contract to receive veBAL & veCRV, allowing to redirect emission on the Aave related pools

Perhaps we could solve for how much value should be locked in the SM and can back out how much initial investment that would cost.

On Design Principles:

“the main goals are increasing the asset diversity and capital efficiency of the funds deposited in the SM”

What is the justification for the first goal: increasing the asset diversity?

Just a first go at this, but I would think the primary goal of the Safety Module would be to be an effective insurance fund for depositors. Aave collects reserves in various tokens from fees, which is a nice, natural diversifier. Instead of targeting diversification, I still find myself in the “increase liquidity” camp for SM assets.

  • This is where the desire for liquidity comes from and the support/alignment on your proposal to add ETH and wsETH assets to the SM.

The secondary goal would be ensuring the insurance funds are paid for sustainably and in a cost-effective manner. I think this is aligned with your “increase capital efficiency” goal.

The tertiary goal would be creating additional utility for the AAVE token and aligning stakers with protocol governance.

Excited to see the other proposals and thinking here! Beyond recommending adding ETH/wstETH/stables to the SM, will think on ways to reduce the cost of insuring the protocol as well.


You could actually define 3 groups:

  • Single assets (AAVE & ETH/LST)
  • Volatile LPs (Pools Including AAVE or ETH)
  • Stable LPs (Pools including GHO and/or other stables)

However the Aave voting power is not sufficient to drive enough incentives to the sm gauges so the goal would be to create vote incentives, but since the DAO will probably still vote with part of its voting power it will receive AAVE rewards for it, reducing the DAO costs.

As mentioned earlier, I agree that the veBAL voting power and boost are not sufficient to support this kind of initiative at the moment, especially considering all the potential other initiatives concerned by this voting power (StakedATokens, Treasury Management, GHO Liquidity and potentially the SM)

As the strategic voting power of the DAO will grow, its emission capacity will also increase over time, allowing to partially sustain these goals. Until then, other solutions can be considered to attract more votes:

One part of the strategy proposes to use part of the current SM budget (1100 AAVE/Day) to create vote incentives for veBAL/vlAURA and potentially any other wrapper that can vote.
This would considerably increase the capacity emission on the SM gauges by leveraging the premium on votes incentives vs liquidity mining without raising the DAO expenses.
(This also allow to considerably increase its strategic voting power and partially self insure in case of POL strategy)

Agree on this point, even a bigger reward budget this does not create endless incentives, so adding a TVL cap for each assets in the SM would help to attract enough votes for the right estimated yield, as well as adding flexibility for incentives management.

The justification is to progressively reduce the AAVE dependency by increasing the assets receiving rewards (ETH & Stables) and creating a stable category with the highest slashing and yield, which should reduce the total amount of AAVE in the SM.
The Aave governance could also discuss about a framework and requirements to add new assets as well as managing the assets cap.

Thanks again for all the suggestions & feedback !


Hi everyone :wave:

Thanks to everyone giving feedback on this post, it was very helpful :slight_smile:

Llama will now publish the full proposal, but split in six parts to facilitate the discussions.

Summary of the topics discussed:

  1. [TEMP CHECK] Safety Module Update Part I - Migrate AAVE/wETH Balancer v1 Pool to Balancer v2
  2. [TEMP CHECK] Safety Module Upgrade Part II - Asset Diversity, SM Categories & Slashing Updates
  3. [TEMP CHECK] Safety Module Upgrade Part III - Enable gauges on BPT in Safety Module (smBPT)
  4. [TEMP CHECK] Safety Module Upgrade Part IV - Incentives Management Upgrade
  5. [TEMP CHECK] Safety Module Upgrade Part V - veToken Holding Management Framework
  6. [TEMP CHECK] Safety Module Upgrade Part VI - Future considerations

This series of publications presents the community with an opportunity to reshape how AAVE incentives are distributed to significantly improve Aave’s economics and enhance the capital efficiency of the SM.

  • Increased Backstop Value
  • Decreased AAVE Spending
  • Increased Yield for depositors
  • Improved Profitability and Financial Sustainability

Upgrading the SM represents one of the highest impact challenges the community can address which will significantly improve Aave’s overall financial outlook.

Looking forward to presenting the full proposal and thank you in advance for taking the time to read all six publications.


Gauntlet supports many of the points made in the initial post, specifically the need for an explicit Bad Debt budget, and the point that the SM is overexposed to AAVE which could cause structural problems when actually using the SM to cover insolvencies.

This post is timely as we have seen multiple shortfall events over the past year, and any lending protocol should not only be prepared for such shortfall events but should be comfortable with them as the reason that a lending protocol can generate revenue is due to taking on risk.

A Bad Debt budget (we have in the past called this a Security Budget), is an important concept for risk providers in order to better calibrate models and ensure Risk Managers are matching the preferred risk level of community.

We are strongly in favor of establishing this budget and making it explicit for the community. Some additional thoughts on the budget:

  • Ideally, this could be defined in terms of a % of the safety module or whatever source of funds is being used rather than an absolute number. This will give flexibility for more dynamic risk management and will scale better with the protocol as funds in the safety module/reserves change over time. This will be easier than needing to decide a budget on a cadence (yearly), and also ensures that risk managers are always calibrating risk parameters for the currently available budget.
  • In terms of the actual amount, we believe defining it as X% of the slashable value of the safety module would be an easy starting point for the community to align on and makes it easy to calculate/monitor
  • We should clarify the time horizon on which the budget can be used. We think it would make sense for the bad debt budget to represent the single event coverage the protocol has i.e. the USDC decorrelation, or CRV insolvency, rather than a yearly budget. This further makes it easier for risk managers to look holistically at all the risk vectors in the protocol

Excited to see this conversation progress further!

1 Like

Is there an off chain conclusion about the SM’s proposal? What’s the current status of this idea? Who is taking the lead?