Safety Module

Aavenomics
Search…
Decentralizing Aave
Ecosystem Overview
Policies
Governance
Safety Module
Incentives Policy & AAVE Reserve
Flashpaper
Terminology
References
Governance (Developer Docs)
Safety Module
Summary
The primary mechanism for securing the Aave Protocol is the incentivization of AAVE holders to lock tokens into a Smart Contract-based component called the Safety Module (SM). The locked AAVE will be used as a mitigation tool in case of a Shortfall Event within the money markets that belong to the Aave ecosystem. A Shortfall Event occurs when there is a deficit. The interpretation for the occurrence of a Shortfall Event is subject to the Protocol Governance vote, detailed in Governance.
In the instance of a Shortfall Event, part of the locked AAVE are auctioned on the market to be sold against the assets needed to mitigate the occurred deficit. The SM includes a built-in backstop mechanism to prevent excess flow of AAVE into the open market that would further reduce the value of AAVE itself. Participants’ decision to lock AAVE into the SM assumes the acceptance of a potential Shortfall Event as they secure the protocol in return for receiving rewards, in the form of Safety Incentives (SI) and fee distributions.
To contribute to the safety of the protocol and receive incentives, AAVE holders will deposit their tokens into the SM. In return, they will receive a tokenized position that can be freely moved within the underlying network. The holder of the tokenized position can redeem their share from the SM at any time, triggering a cooldown period of one week (which can be further extended by the governance).
SI rewards are subject to a cooldown period where tokens are unclaimable. The cooldown period is set to seven days. However, fees generated by the protocol are continuously allocated to the users participating in the SM and can be withdrawn. Fees generated from the protocol are redistributed to the SI participants. The reward plan for the SI is designed to incentivize participants contributing to the safety of the protocol in its early stages. The SI emission will be controlled by the governance and adjusted to the protocol's needs. All fees distributions mechanisms are only potential until they go through AIP process and governance vote.
In case the SM is not able to cover all of the deficit incurred, the Protocol Governance can trigger an ad-hoc Recovery Issuance event. In such a scenario, new AAVE is issued and sold in an open auction for market price prioritizing the Backstop Module.
The issuance of AAVE in case of a Shortfall Event is mitigated by the existence of the SM. Prior to any issuance, the deficit of the protocol is first covered by the SM reserves.
Architecture
The Safety Module is defined by the following components:
Staking Module
The main component of the architecture, where users lock their AAVE tokens to protect the Aave Protocol in the instance of a Shortfall Event.
The Safety Module is built on top of existing AMM technologies. An 80% AAVE/20% ETH liquidity pool using Balancer will be used to provide benefits in terms of market depth for the AAVE token and earnings from locking AAVE. This also extends to BAL tokens and trading fees on top of the SI and protocol fees, while reducing the impact of a Shortfall Event on the AAVE token itself.
Auction Module
Auctioning system associated with the SM Module. Auctions are triggered upon the occurrence of a Shortfall Event.
Backstop Module
Part of the Auction module, contains the ETH and stablecoins pre-deposited that have a priority position on the auction in the case of a Shortfall Event occurrence. The backstop is explained more extensively in Safety Module.
Ecosystem Reserve
Component receiving and managing the distribution of fees from the different Aave Markets.
Oracles
The Aave Protocol Oracle System leverages oracles provided by Chainlink and backed by Aave, with an emergency backup oracle run by Aave. The decentralization process will consider providing adequate incentives for oracle providers.
Safety Module In Detail
Safety Module
Users interact with the Safety Module by locking AAVE and/or ETH into the Safety Module contract. The interaction with the SM is facilitated by a UI that clearly explains the SM dynamics, its purpose within the Aave ecosystem and the risks involved. Users will have the choice of locking AAVE directly or providing liquidity shares from the 80/20 AAVE/ETH Balancer Pool.
The Safety Module solves the issues with traditional staking systems and market liquidity: Tokens with locking/reward schemes tend to suffer from low market liquidity and extreme volatility when high percentages of the total supply are being locked. With the ability of contributing to the SM not only by locking AAVE, but also by contributing with liquidity into an AMM, stakers create a trustless and decentralized market with deep liquidity for trading AAVE against ETH.
The advantage of using Balancer against other AMM solutions is clear when we factor in the possibility of dynamically adjusting the weighting towards AAVE. This allows for the creation of a market and the provision of liquidity whilst maintaining exposure to AAVE. Holding AAVE/ETH liquidity with uneven weights is very close to simply holding AAVE, with the benefits of earning trading fees on top of it.
The Aave Governance will retain the ability to update the weights in the Balancer pool to better suit the protocol and stakers needs as the market evolves.
Since Balancer Labs is distributing BAL governance tokens to liquidity providers, having the SM liquidity in Balancer enables the users to receive BAL tokens on top of trading fees, protocol fees and SI rewards.
By also allowing users to simply lock AAVE, we free up less advanced users from the burden of providing two different assets to participate in staking. The SM will support weighted incentives to attract liquidity in case of AMM imbalance.
The primary (Safety Module) and secondary (Recovery Issuance) safety mechanisms are reinforced with a built-in Backstop Module. This module is a smart contract-based deposit pool to allow the Aave Community to deposit stablecoins and ETH acting as a buy order for the AAVE token at a price agreed-on by the protocol governance in the case of a Shortfall Event, to act as a buyer of last resort.
Back-stoppers are incentivized to have liquidity in the Backstop, as protocol fees are shared with them. In case of backstop buy back occurrence, the AAVE purchased by the backstop is distributed proportionally to backstop LPs, or they can directly deposit back their newly acquired AAVE in the staking module.
Shortfall Events
The main role of the Safety Module is to protect the protocol against unexpected loss of funds stemming from:
Smart contract risk: Risk of a bug, design flaw or potential attack surfaces on the smart contract layer.
Liquidation risk: Risk of failure of an asset that is being used as collateral on Aave; risk of liquidators not capturing liquidation opportunities in a timely manner, or low market liquidity of the principal asset to be repaid.
Oracle failure risk: Risk of the Oracle system not properly updating the prices in case of extreme market downturn and network congestion; risk of the Oracle system not properly submitting prices, causing improper liquidations.
In case of loss of capital, the SM uses up to 30% of the assets locked to cover the deficit. If the amount seized from the SM is not enough to cover the whole debt, an ad-hoc AAVE issuance event is triggered called Recovery Issuance. The issued AAVE are used, together with the amount drawn from the SM, to cover the deficit.
The auction module oversees the market emission of the seized funds. The Auction module follows a Dutch auction scheme, where the AAVE and the ETH collected from the SM are auctioned in lots, with their size depending on the deficit to be covered. The Backstop Module triggers whenever a lot is about to be sold at a price that is below the backstop price.
Shortfall Event and Governance
A Shortfall Event has certain governance implications. Users with locked liquidity in the Safety Module will still be able to vote on that matter using their tokenized version of their locked assets. Conceptually, AAVE holders participating in the SM will have to vote to safeguard the integrity of the protocol. Their choice to seize their own funds will need to take into account the long-term stability of the protocol and the future value of AAVE. 
This poses certain limitations on the amount of funds that can be seized in the case of a Shortfall Event. A percentage that is too high might bring conflicting sentiment in the AAVE holders participating in the SM, potentially compromising the long-term stability of the ecosystem. The protocol governance will always need to consider these implications whenever proposal discussing the SM funds management are submitted.
Governance
Incentives Policy & AAVE Reserve
Last modified 1yr ago
Export as PDF
Copy link
Contents
Summary
Architecture
Safety Module In Detail
Shortfall Events
Shortfall Event and Governance