1. Summary
Introducing Umbrella, a new version of the Aave Safety Module based on Aave v3 aTokens staking & slashing.
2. Context. The current Safety Module
In 2020, Aave introduced its Safety Module, a system for $AAVE (and $AAVE/WETH Balancer LP) holders to stake their tokens and gets rewards, but assuming slashing risk to cover any potential bad debt in Aave liquidity pools. This was a quite important innovation and movement to strengthen the resilience of the protocol with $AAVE tokenomics, adding more than $100m available to slash and cover bad debt if required.
However, like with almost any other system, the current Aave Safety Module has shortcomings and room to improvement. More precisely, the following limitations:
-
Bad debt on Aave will always manifest in borrowed assets. With AAVE being a pure collateral (governance token, not borrowable), if any stkAAVE slashing happens, the AAVE would need to be sold to the asset on which the debt is denominated; so capital is not efficient.
-
Consequence of the previous, slashing events could create bad dynamics on the coverage asset ($AAVE), as the sell pressure of the slashing itself will circularly reduce the coverage.
-
Slashing rules are very subjective. At the moment, any slashing is decided via a governance proposals. Even if this has some positive implication (e.g. governance can decide to slash or to use treasury funds), this create very important uncertainty about:
-
- in which situations slashing should happen.
-
- will $AAVE/stkAAVE holders vote for slashing.
-
- exactly which networks/pools are really covered by the Safety Module.
Some of the previous have been addressed via governance frameworks (e.g. which pools/networks are covered), but subjectivity in this context is not really positive.
-
-
Even if mandatory, auction mechanisms for slashed funds are not well defined, as the Safety Module doesn’t have a native auction module.
-
The system is relatively rigid on incentives, as each staked asset like stkAAVE can only have one type of rewards (currently AAVE), which is not really aligned with the community direction of for example having AAVE, GHO, or any other.
-
Staking and slashing is fully Ethereum based, which adds limitations on both capital acquisition for staking or even operational complexity to move slashed funds to any network to cover bad debt.
Umbrella, the new Safety Module, tries to address all the previous limitations of the system.
3. Umbrella, the new Safety Module
Umbrella’s goal is to address all the weakness of the current Safety Module, together with improving the architecture in a way that is future-proof.
This is achieved with the following design principles.
New staked assets: stk aTokens
As they are not effective for the task, stkAAVE and stkABPT will not be direct coverage assets anymore. Their replacement will be objectively the most effective assets to cover Aave debt: Aave aTokens.
All suppliers of aTokens on any Aave pool with no borrowings, will have the opportunity to enable the STK mode. By doing this this, 3 things happen:
- Their aToken balance (or any percentage of their balance they define) becomes slashable, to cover Shortfall Events in specifically the aToken they hold. E.g. if an user of aUSDC enables STK on their position and a loss happens affecting aUSDC suppliers, he will lose partially or totally his aUSDC balance.
- The user will start earning incentives, to compensate the utility they are bringing to the Aave protocol (risk of slashing). This could be in the same denomination of his aToken, $GHO, $AAVE or any other (or combination of them).
- In the meantime, the user will keep accruing yield on his aToken position, as factually he is just another supplier to Aave; just with extra risk, and of course extra reward.
To highlight why aTokens are the best possible staking/slashable asset, it is important to understand what bad debt technically is. Bad debt accrual in an Aave pool means that one or multiple positions have less collateral than liabilities, which leads to a situation on which the user has no incentive to repay and consequently, if all depositors of the borrowed asset would try to withdraw, there would be a deficit.
Whenever any amount of aTokens get slashed on Umbrella, no selling is needed to cover the deficit, only burning is required. For example:
- A total of 1’000 USDC is supplied to Aave v3 Ethereum, reflecting in 1’000 aUSDC total supply.
- Due to a collateral failure, 100 USDC bad debt is created. That means that only the ~900 USDC (interest aside) out of the 1’000 USDC supplied can be withdrawn.
- However, 200 aUSDC are staked in Umbrella. When the 100 USDC Shortfall Event happens, 100 aUSDC are slashed, and afterwards, burnt.
- After the aUSDC burn, aUSDC supply is 900, same as the 900 USDC liquidity withdrawable; so the system is whole.
Per-network aToken staking & slashing
On the previous Safety Module, using Ethereum as staking & slashing network had quite strong rationale: Ethereum was the most secure blockchain network; the Aave ecosystem was quite Ethereum-focused, with only a limited number of other instances appearing (e.g. Polygon and Avalanche on Aave v2); or the Safety Module infrastructure would be quite complex if having staking & slashing in non-Ethereum venues.
With Umbrella this approach changes radically: bad debt potentially accrues on each Aave instance in isolation, and having aTokens of an specific Aave v3 instance as staked assets only makes natural that users of Aave on network X will opt-in to stake for that Aave instance.
For example, it is very simple for a supplier of WETH on Aave v3 Arbitrum to decide if he wants to stake his aWETH for rewards and slashing risk, if bad debt accrues on his own supplied asset. However it becomes way more complicated for the same user to decide if he wants to stake for a different asset in a different network.
We see the system evolving with more heterogeneous assets and coverage strategies, but as basic building block we believe it is better to start simple: each Aave pool on each network will have its own Umbrella, where all aTokens users will be able to stake to cover the asset associated with their aTokens.
Automated (no governance) and precise slashing
Umbrella will not depend on Aave governance proposals for slashing, this will be done automatically and in a decentralised way, with rules clearly defined on the smart contracts. This is achieved with the following:
- The Aave pools will be updated to account for accrued bad debt on each asset. This will allow to precisely understand on-chain how much potentially needs to be covered by Umbrella.
- Once the bad debt in an asset crosses certain configurable minimum threshold (to protect for example against bad debt “dust” organically accruing), the system will allow anybody to initiate an slashing action. The Aave Robot automation system will be plugged to this.
- Each asset to cover will have associated its stk aToken to slash from. Once the slashing event happens, slash will be immediately processed, and funds sent externally to another contract controlled by the DAO.
- Once the aTokens are burnt, Umbrella will account for them, to discount the amount from any future slashing needs.
Introducing automatic and fast slashing has major implications simplifying the current Safety Module, more precisely:
- Cooldown technically can be slightly reduced.
- No mechanism to return funds post slashing is really needed, as the required amount will be exact. This is very important security-wise, reducing any vector of so-called donations.
- No post-slashing window is needed.
New incentives engine
With the Aave community lately doing an exceptional job on incentives management (e.g. Merit from ACI), we thought that Umbrella should have a powerful incentives management system, trying to cover as best as possible the needs of the Safety Module. The new system has the following characteristics:
-
Multi-rewards. Following the approach of Aave v3 pools, Umbrella allows for any staked asset to have one or multiple rewards at the same time. For example, stk aUSDT could be receiving simultaneously $AAVE and $USDT rewards, the first from the Ecosystem Reserve, and the second from the protocol revenue (e.g Reserve Factor).
-
Coverage target. When defining an amount of rewards for the Safety Module, implicitly the approach is doing it by asking the question “how many rewards should we configure in order to have X amount of assets available to slash and cover bad debt?”.
Umbrella will introduce a more dynamic rewards curve (stk Utilisation Curve), automatically optimising rewards to try to be close to the coverage amount targeted (stk Safety Target), but without over spending. This means that if the staked amount is lower than the target configured, rewards will be proportionally higher but without spiking to thousands of APR percent. If staked amount is too high, the system will adjust rewards proportionally lower.
stkGHO
Back in the days, we recommended other contributors to introduce stkGHO in the Safety Module. The rationale is that stkGHO is factually an aToken for all Safety Module purposes, and consequently, the best possible asset to cover GHO bad debt.
stkGHO will keep existing on Umbrella as main coverage asset of GHO, only adapting its smart contracts to be fully compatible with the new system.
More flexibility on staked assets
Even with aTokens being the corner stone of the system, we have taken into account the appetite of the community for other types of assets (like GHO LPs), and the system will enable each Aave asset covered by multiple stk.
In this case, whenever an slashing happens, all staked assets for the one to cover will be slashed proportionally (or following more complex strategies, like tranching), and those in different denomination (e.g. GHO/USDC to cover GHO) will need to be auctioned.
To start with though, we propose the following limitations, to not overcomplicate the system:
- Given its role in the Aave ecosystem, only GHO should have more than one staked asset associated.
- Only staked assets heavily correlated to the one to cover should be added to the coverage set to start. For example, a GHO/USDT LP token can be enabled to cover GHO, but to avoid complexity, better to avoid others like GHO/WETH.
- Incentives definition should be carefully evaluated when having multiple assets to stake for the same, as the management of them is substantially more complicated than with just aTokens.
Once again, in the future we envision a system with more complex coverage strategies, but we think it is more reasonable to start simpler on the first version of Umbrella.
Misc features of Umbrella
- Similar as with all other BGD projects on Aave, Umbrella has been designed to be flexible enough to adapt to future needs of the community. For that reason, the implementation should be compatible with new Aave sub-systems, including Aave v4, by doing only minor adjustments.
- Umbrella will have emergency mechanisms similar to EMERGENCY_ADMIN functions on Aave.
- During the design of Umbrella, we analysed the introduction of a mechanism like the Fast Pass proposed. However, the practical constraints that should include (e.g. it would only shorten the “standard” cooldown, but always leaving 7-10 days) led us to not propose it as part of Umbrella.
4. stkAAVE and stkABPT future
As previously mentioned, both stkAAVE and stkABPT are not good coverage assets on the Safety Module, due to their lack of correlation with the assets potentially accruing bad debt on the Aave pools. Consequently, Umbrella will not have them as stk Assets; they will be replaced by stk aTokens.
However, it is very clear that there is an appetite for usage of both stkAAVE and stkABPT into staking venues of the Aave tokenomics, with $400m supplied. For that reason, even if not including any strategy on this post to avoid confusion, we are collaborating with ACI for a new proposal to add extra AAVE utility, involving both stkAAVE and stkABPT, but in a different role compared with staked assets on Umbrella.
5. Glossary and FaQ
Glossary
→ Umbrella
Name of the system as a whole, but also the core smart contract of the system.
There will be one Umbrella connected to each Aave pool instance to be covered by the Safety Module
→ Safety Pool
Logical “vault” grouping one or more stk assets, and implementing all necessary logic to slash them.
Safety Pools could be the GHO v3 Ethereum Safety Pool, MATIC v3 Polygon Safety Pool or USDT v3 Base Safety Pool.
→ stk Asset
Each independent staked asset part of a stk Safety Pool:
- Underlying assets are deposited on each stk smart contract.
- Defines an exchange rate, depending on slashing.
- Contains all the cooldown related logic.
- Connects to a rewards smart contract.
stk assets could be stkGHO and stk-ECLP-GHO_USDC for the GHO v3 Ethereum Safety Pool, or simply stkAUSDC for the USDC v3 Arbitrum Safety Pool
→ stk Liquidation Mechanism
Each strategy implemented in the system to, from stk assets, get the underlying token to cover bad debt.
For example, aTokens will have a a very simply Liquidation Mechanism, only slashing the stk Asset and burning the underlying aToken. On the other hand, an LP token will require a Liquidation Mechanism slashing the stk and selling the LP to the required aToken underlying, to finally burn it.
→ stk Safety Target
Optimal coverage size for an stk Asset, working as main reference for automatic adjustment of the stk Utilisation Curve.
For example, a 50m USDC could be configured as stk Safety Target for stkUSDC, which would mean that rewards would be targeting a maximum of 50m aUSDC staked.
→ stk Utilisation Curve
Function automatically regulating rewards, by using the stk Safety Target as reference:
- Whenever the total staked assets are below the Safety Target, rewards are proportionally higher in a controlled manner, as the system needs to incentivise the entry of new capital.
- Whenever the total staked assets are above the Safety Target, rewards are proportionally lower in a controller manner, as the system needs to incentivise the exit of part of the capital.
The goal of the Utilisation Curve is to automate as much as possible the configuration of any rewards distribution, limiting external oracles to define the yield that stk participants will get at Safety Target size.
FAQ
→ Why having isolated instances of the Safety Module?
One core idea of this new Safety Module is for users to earn a yield premium on top of their aTokens in exchange for additional slashing risk. Given how this specifically targets users of an Aave instance/network, it is just natural and simpler that for example aUSDC v3 Arbitrum holders will have the possibility to cover bad debt of aUSDC v3 Arbitrum and not others, at least in the initial version of the system.
Additional arguments for this decision are:
- Having an aggregated layer of staked assets between networks would make very complicated to define incentives, and it is our duty on the development side to not off-board complexity to additional contributors (and cost for the DAO).
- Revenue for the DAO is accrued on each specific asset, on each specific pool, on each specific network. An organic and sustainable strategy would be using part of that revenue (e.g. a percentage of the Reserve Factor) to incentivise its associated stk Safety Pool.
→ Why aTokens as main underlying?
Bad debt accrual on a system like Aave means that part of the aToken holders will not be able to withdraw from Aave. By having aToken as underlying of the Safety Module, aToken holders participating factually opt-out to withdraw their funds if bad debt is realised.
In addition, they still keep earning yield plus rewards on top in compensation of the additional slashing risk.
→ Why non-aTokens as secondary underlying?
The Aave community has shown support to include on the previous Safety Module more heterogeneous assets, like LP tokens including GHO.
The new Safety Module will accommodate to those needs, allowing any type of underlying, with the only limitation of having a solid pricing mechanism associated (e.g. secure way of pricing a GHO/USDC LP token).
→ How many rewards an stk asset can have?
Similar as with the incentives system on Aave v3, an stk instance can have multiple rewards, mainly limited by the gas implications of it. Realistically, we don’t expect more than 3 rewards for a single stk simultaneously.
→ How rewards should be configured?
Rewards are configured based on having a competitive yield premium versus risk on the stk Safety Target. For example, if the Safety Target for USDC on v3 Ethereum is 50m USDC and the market seeks for an extra 3% to participate on the Safety Module, rewards would be in the order of $1’500’000 per year.
In practise, the entity controlling rewards configuration will configure a rewards per second at the Safety Target, and the Stk Utilisation Curve will provide to the protocol the exact rewards depending on how far the staked liquidity is from the Safety Target.
→ Apart from aTokens, which other assets can be part of the Safety Module?
The design of the Safety Module is pretty agnostic to the underlying: whenever bad debt needs to be covered, Umbrella will slash from the appropriate Safety Pool X amount of assets. How the Safety Pool sources the the funds can be as custom as necessary.
Example WETH:
- Umbrella asks for 10 WETH to cover bad debt to the WETH Ethereum Safety Pool.
- The WETH Ethereum Safety Pool has as underlying only stkAWETH (aToken of WETH v3 Ethereum), so will slash the full amount from it.
- Umbrella will burn the 10 aWETH and account for the bad debt cleanup.
Example GHO:
- Umbrella asks for 20’000 GHO to cover bad debt to the GHO Ethereum Safety Pool.
- The GHO Ethereum Safety Pool has 2 different underlyings: stkGHO and stkECLP-GHO-USDC (Gyroscope LP). Following the smart contract logic, the Safety Pool will slash partially from stkGHO and partially from stkECLP-GHO-USDC, sending directly GHO from the first to burn, and via the custom auction module, selling E-CLP GHO-USDC to GHO.
- Umbrella will burn the 20’000 GHO and account for the bad debt cleanup.
→ What Aave instances will be covered by the Safety Module?
The new Safety Module is prepared to cover any Aave instance on any network where Aave lives. In practise it is a matter of deploying the infrastructure, and activate it via a governance proposal that will define the covered assets, stk Safety Pools and rewards.
Our only recommendation is to not seek an activation of the Safety Module on new Aave pools until they reach certain size (in the order of millions), as the cost of activation could not be worth it.
→ Is not a problem the rebasing nature of aTokens for the stk Safety Pools?
aTokens listed on stk Safety Pools will use stataTokens, “wrapped” versions of Aave v3 aTokens we developed in the past, this way not rebasing in balance.
For the user, this process will be transparent, as we will build all the required smart contracts infrastructure to make the process very simple, allowing to participate in the Safety Module from underlying (e.g. USDC), aToken (e.g. aUSDC) or even stataToken (e.g. stataUSDC)
→ Why removing stkAAVE and stkABPT from the main Safety Module?
stkAAVE and stkABPT are not efficient coverage assets for Aave pools, as the price of their underlying is not correlated with the one of the asset where bad debt generally accrues (borrowed assets on Aave like WETH or stablecoins). So they should not be part of the main Safety Module dynamics.
→ Doesn’t this design resemble the existing stkGHO?
Yes, the usage of stkGHO as underlying of the existing Safety Module was our proposal to other service providers, as technically GHO is very similar to an Aave aToken, and the most effective coverage asset for GHO.
→ How is the theoretical sustainability of the system (e.g. incentives)?
With stk aTokens as underlying, Umbrella provides superior capital efficiency to cover potential bad debt. Consequently, the amount of rewards required to incentivise the system is substantially lower in value compared with the current Safety Module.
For example, with an Umbrella aggregated size of $100m for assets on Aave v3 Ethereum, $5m/year would provide 5% rewards, which would mean more than 10% yield on stablecoins aTokens (calculation based on 5-6% yearly average stablecoins aToken rates).
Moreover, the required coverage per asset per pool will be a percentage of the outstanding borrowings, which is same concept as the Reserve Factor. Part of the proceeds of the Reserve Factor could be allocated as rewards to stk Assets on Umbrella.
6. Next steps
Even if announcing the final design right now, we have been working on Umbrella since the beginning of our engagement, currently in good level of maturity of the implementation.
In the following weeks, we will be working on the following:
- Listen for feedback of the community.
- Finish the implementation of the whole system.
- Finish a more technical documentation of the system, complementary to the high-level one in this document.
- Communicate with all potentially involved service providers (e.g. risk, incentives management, growth) about Umbrella, and the role of everybody on it.
- Give our feedback/ideas to a new iteration of AAVE tokenomics, involving stkAAVE and stkABPT.