BGD. Aave Safety Module v1.5


We present to the community a technical upgrade of the Safety Module (SM) smart contracts (stkAAVE/stkABPT), facilitating slashing management and improving other aspects like cooldown mechanics.


On September 2020, the Aave Safety Module was introduced into the ecosystem, to improve the protection of the liquidity protocol, adding an extra utility for the AAVE token: AAVE or AAVE/WETH BPT holders stake their assets to act as a defensive layer in front of any shortfall event.

Since then, apart from really minor upgrades, the contracts have remained the same and in parallel, the system has been adopted by other communities.

As part of our engagement with Aave, we identified that the Safety Module is a clear area of improvement in the ecosystem, from 2 different standpoints:

  1. Technical. Improving the basic existing mechanisms of the contracts, but without disrupting radically the current design of the SM.
  2. Conceptual. Making more efficient the SM dynamics (e.g. slashing, rewards distribution rules, etc), by modifying the whole design.

The conceptual improvements should be discussed separately by the community, as they belong more to the field of AAVE token dynamics. In this document, we outline the Technical upgrade.

Safety Module 1.5

Considering the currently deployed version of the Safety Module as v1, the one we present to the community can be addressed as v1.5, being more of a technical improvement, and not a complete revamp of the system that would qualify as v2.

In this document, we will be referring to stkAAVE, but everything described will also apply to stkABPT.

1. New slashing mechanism

On the running SM v1, in order to slash, an ad-hoc governance proposal is required, involving important development overhead, which is not ideal.

The new SM v1.5 adds an enhanced mechanism to facilitate slashing of the underlying by tracking an exchange rate between the staked AAVE and the stkAAVE received by stakers. The mechanism is simple: when somebody stakes AAVE, they receive a certain amount of stkAAVE, which no longer is 1:1 equivalent, as it keeps track of slashing (meaning with the same stkAAVE, stakers are able to claim less AAVE).

Given that in a slashing scenario is highly probable that the slashed amount with not be fully used to cover a shortfall event, the exchange rate introduced also supports any entity to “return” or “donate” funds to stakers, necessary in the case of over-slashing to account for price volatility on a potential shortfall event.

A full slashing flow could be as follow:

  1. The protocol suffers a shortfall of 100’000 DAI, which should be covered by slashing AAVE from the SM.
  2. The slashing admin (explained later) slashes 2000 AAVE, equivalent to ~160’000 DAI, to account for a potential price depreciation of AAVE during the time to cover the shortfall. The exchange rate gets updated, as now stkAAVE has fewer claims over staked AAVE.
  3. By some auction mechanism (out of the scope of the SM at the moment), finally only 1500 AAVE are required to cover the 100’000 DAI shortfall, so 500 AAVE can be returned back to stkAAVE stakers.
  4. The system holding the 500 AAVE (e.g. the Aave Collector, or any escrow contract of an auction) interacts with the SM to return the funds to stakers. The exchange rate is updated, as now stkAAVE has recovered some extra claims over staked AAVE.
  5. The slashing admin marks the slashing action as settled, and the Safety Module returns to its normal functioning.

From the previous flow, it is important to highlight certain new dynamics and roles:

  • Slashing admin. The only entity with permission to trigger the slash() function on the Safety Module contract. Taking into account the time constraints required for an efficient slashing (should be fast enough), and also considering that governance is not fundamentally affected by the action, initially to be assigned to the Level 1 (Short) Executor.

    Additionally, the slashing admin is in charge of defining the maximum slashing percentage that can be slashed at once, currently determined by the community as 30%.

  • Running vs Post-Slashing states. Whenever a slashing happens, by definition the Safety Module enters a slightly unbalanced state, as potentially some (or even all) funds could be returned.

    In order to not allow any kind of arbitrage, after slash and until the slashing admin decides to settleSlashing(), the system enters a Post-Slashing state, during which:

    • Staking is disabled. Given that is unpredictable if funds are gonna be returned or not from slashing “leftovers” no extra staking is allowed.
    • Cooldown is disabled. If anybody wants to redeem their assets, no cooldown needs to be respected, as it is reasonable to give a choice to stakers to evaluate if the risk/reward of staying is worth it. Important to clarify that staking rewards keep accruing, so the “pressure” of stakers redeeming will accentuate the rewards of those staying.
    • No extra slashing can be done. In order to respect the maximum slash percentage, it is not possible to slash without settling first the current slashing.

    The Running state is the non-Post-Slashing, so just the “normal” situation of the SM.

2. New cooldown mechanics

The current cooldown on SM v1 consists of a time delay of 10 days to be respected whenever anybody wants to redeem the staked AAVE. At the moment, this cooldown is affected by in/outflows of stkAAVE, both via transfer() and stake()/redeem(), in order to protect the system from being gamed.

This mechanism is not really optimal and adds important complexity, so on v1.5 has been changed to the following: after activation of cooldown, a staker will be able to redeem the minimum balance he will hold between cooldown activation and redeem window.


  • Staker A has 100 stkAAVE, and activates cooldown.
  • After 2 days (so with the current 10 days of cooldown, 8 days left) Staker B sends 200 stkAAVE to Staker A, making his balance 300 stkAAVE.
  • The cooldown period of Staker A remains unaffected (8 days), but he will only be able to redeem the initial 100 stkAAVE he has.
  • In order to redeem the full current 300 stkAAVE balance, Staker A can activate again the cooldown, but this will reset the delay to the initial 10 days.

To avoid complexity, if the staker activates the cooldown and decides to transfer out part of his stkAAVE, that outflow amount will be discounted from what he will be able to redeem once the delay finishes.

Apart from the user-level cooldown new mechanics, we also propose to increase the cooldown period from 10 days to 20 days.

The rationale is that the Level 1 (Short) governance procedure has a duration of approximately 5 days, so having a 4x longer cooldown period will act as an important deterrent for anybody trying to game the system by continuously activating cooldown.

3. Aave Governance Implications

Even if stkAAVE has voting power on the Aave governance, technically that power belongs to the AAVE claims by stkAAVE holders, which at the moment are 1:1 equivalent.

As with v1.5 the 1:1 equivalence will potentially not be respected anymore, this upgrade will also adapt the Aave governance strategy to take into account the exchange of stkAAVE with AAVE, in order to not under/overcount the stkAAVE influence.

4. GHO

The Aave community has already approved the deployment and activation of the GHO stablecoin and the first facilitator will be the Aave v3 Ethereum pool.

In order to enable the discount mechanism by holding stkAAVE described on the GHO proposal, the design of Aave Companies requires to introduce of a piece of logic on the stkAAVE transfer(), in order to “notify” the GHO facilitator system of stakers’ balances.

We have evaluated this and we think it is acceptable, so it will be included in this upgrade. From a technical perspective, stkAAVE includes logic protections to remain unaffected if anything would go wrong with the GHO facilitator, which at the same time should be considered a trustable entity, as it will be controlled by the Aave governance.

5. Misc

  • The new version contains a stakeWithPermit() function to facilitate staking via signature by relayers or intermediate contracts, possible on stkAAVE given the underlying permit() of the AAVE token.
  • The contract includes new “convenience” functions like claimRewardsOnBehalf(), claimRewardsAndRedeem(), or claimRewardsAndRedeemOnBehalf(), permissioned to an entity “claim helper”, not included in this scope but that can be done in the future.
  • On a technical note, the new implementation follows a preview*() approach for stake and redeem actions, following similar standards as 4626, even if it is not the current objective to be fully compliant.
  • The contracts can potentially be used by other communities/projects looking for the same functionality, but it is important to keep in mind that the current implementation is designed taking into account the existing production deployment, so customization (e.g. using completely different tokens to AAVE) should be done carefully.


Security procedures by both providers of the Aave DAO (SigmaPrime and Certora) are getting finished at the moment, with an important emphasis on formal verification via Certora properties.

Additionally, we have followed our standard internal practices, including testing, code, and storage layout comparison with the previous implementation.

Finally, we appreciate the peer review done by @miguelmtz and @Zer0dot from Aave Companies.

All the information can be found in the Security section of the repository.

Next steps

Given this is an important development, we will be creating a Snapshot vote in the following days, and if approved by the community, once the security procedures are completely finished, we will submit the Aave governance proposal to execute the upgrade of the system on Ethereum.


This seems to be a pivotal upgrade.

Reading through the proposal as is, these two sections stick out to me the most:

At a high level, it seems to implement the following:

  • increases the duration of the redemption of stkAave by 2x (10 → 20 days)

  • eliminates the voting power parity of Aave and stkAave

Am I right in this understanding?


Great proposal and we are very much in favour!

Both the slashing and cooldown mechanisms provide simple and robust improvements to the current Safety Module.

Running vs Post-Slashing states . Whenever a slashing happens, by definition the Safety Module enters a slightly unbalanced state, as potentially some (or even all) funds could be returned.

What would the actual state flow look like? Would it be:

Vote to slash → unbalanced state → vote to enter post-slashing state → vote to enter running state.

So all up, 3 votes will be needed to rectify a shortfall event (if passed by governance)?

1 Like

This is correct, but from a technical perspective, a relatively minor change in the system. The rationale of it is purely high-level, as the current 10 days cooldown is not so aligned (too short) with the governance timing of 5 days.

Would not say that reduces the parity, just it adapts to the underlying new slashing logic.
stkAAVE’s voting power is exactly the same as AAVE at the moment because no slashing has happened, so whenever somebody holds stkAAVE, for the governance system it is as holding the same amount in underlying AAVE.
If a slashing happens, the claim over underlying AAVE will be lower, and so the voting power should be proportional to it.

Thanks, @WintermuteGovernance .

Slightly different:

  1. Vote to slash()
  2. Once the proposal gets executed, the underlying slashed AAVE gets sent to the recipient of the Aave DAO and the system enters automatically in Post-Slashing state.
  3. Whenever the DAO decides that the situation is resolved and all the “leftover” funds from slashing have been returned (one or multiple times), the DAO can settle the post-slashing state, going back to Running.
1 Like

Glad to see this finally happening!
The Safety Module is an instrumental piece of the Aave protocol, and the technical revamp of stkAave and stkAbpt is a real need. It also paves the way for GHO with the logic on stkAave transfers.
A pleasure to review such an important code of the protocol :handshake:


With the security procedures almost finished, we have created a Snapshot vote for the community to signal the upgrade of the Safety Module.

The vote will start in approximately 24h and extend for 5 days on
We think a minimum of 200’000 YES votes and 80’000 differential is reasonable to consider it successful and proceed with the on-chain proposal.


Awsome technical upgrades and thanks BGD for the thoughtful proposal. It’s great to see innovation in a key element of Aavenomics. These expansions of the governance toolbox will enable a quicker and more effective response in the event of a shortfall scenario - and increase the confidence of AAVE/stkAAVE holders.

As for the auction mechanism, while not covered in this proposal’s scope, it would be interesting to hear if BGD Labs has any plans to introduce such a feature into the Safety Module in the future. Integrating an auction mechanism could further streamline the process of covering shortfalls and ensure a more optimized use of slashed assets.

1 Like

Following the timeline, with all the security procedures finished now, we want to inform the community that the proposal to upgrade the Aave Safety Module to the 1.5 version will be submitted in the following days.
The repository with all the information of the project can be found on

This proposal, as it involves the upgrade of stkAAVE and stkABPT, will run on the Level 2 Executor (Long Executor), with a quorum requirement of 1’040’000 AAVE on YES, so we encourage everybody in the community to participate.


Following the creation of proposal 214 to upgrade stkAAVE to v1.5 we have created the second proposal (221) of the 1.5 upgrade, in this case affecting stkABPT.

Different to stkAAVE, the upgrade of stkABPT will be done via the Level 1 Executor, so the quorum requirements are lower, of 320’000 AAVE on YES, and voting/timelock period is shorter (3 and 1 days respectively).

Voting will start in approximately 24h, participate on

As an update, proposal 221 has been approved by governance and executed, which means that stkABPT is running on version 1.5 now.

This impacts stkABPT holders by increasing the required cooldown period before withdrawal from 10 to 20 days.
Additionally, after the activation of the cooldown, a staker will be able to redeem the minimum balance he will hold between the cooldown activation and redeem window.

Proposal 214 has been approved by governance and executed, which means that stkAAVE is running on version 1.5 now.

This marks the completion of the Safety Module upgrade to v1.5.

The same new cooldown dynamics commented on the previous post to stkABPT apply to stkAAVE.