Simple summary
Presenting to the community the implementation of Aave Umbrella, a system for users to stake their Aave aTokens covering potentially arising deficit (bad debt) on Aave systems, and earning rewards for it.
This post covers all aspects of Umbrella:
- Smart contracts.
- Security procedures.
- Aave DAO’s user interface.
- Branding guidelines.
- Activation recommendations.
The codebases of all Aave Umbrella components are on:
- Umbrella smart contracts: https://github.com/aave-dao/aave-umbrella
- Umbrella UI (Aave DAO):https://github.com/aave-dao/aave-umbrella-ui
Umbrella is now fully ready for activation in production, with all development and security procedures finished.
Context
In THIS POST, we introduced the early design of the Aave Umbrella system, but the following is a summarised recap.
What is Aave Umbrella?
One of the main project/product lines of the DAO is the Aave Safety Module: a system by which users can currently stake their AAVE, stkABPT (Balancer AAVE/wstETH LP token), and GHO to earn rewards, but by potentially getting slashed to cover any arising bad debt on the Aave liquidity pools.
Aave Umbrella is a radical evolution of that system, by which, instead of staking AAVE and stkABPT, users will stake Aave v3 aTokens like aUSDC or aUSDT for rewards and risk of slashing. Aave aTokens are the best possible asset to cover bad debt arising on the Aave pools, as they only need to be burnt in that scenario, compared with currently AAVE/stkABPT that currently would need to be sold.
Additionally, Umbrella is an objective system, depending on the existence of bad debt (called deficit) on the smart contracts data of the Aave pools to trigger a slashing, instead of depending on governance decisions or other subjective mechanics.
Finally, Umbrella’s on-chain rewards management is designed to be, even if still pretty flexible and fair for stakers, oriented to capital efficiency on the budget management of the DAO.
Why improving the current Safety Module?
The current Safety Module, even if functional and pretty innovative when it was introduced years ago, has some shortcomings:
-
Aside from GHO, the other assets staked (AAVE, stkABPT) are loosely correlated in price with the assets that generally would need to be covered in the Aave pools if bad debt arises: highly borrowed tokens like stablecoins or ETH. That means that in the majority of scenarios, the slashed AAVE tokens would need to be sold in the market to acquire e.g. USDT, and then repay the bad debt.
This is not capital efficient, and also creates bad economic dynamics on the AAVE token, for example in anticipation of major slashes and the consequent sell pressure. -
In the current Safety Module, slashing rules are very subjective: any slashing is decided via governance proposals. Even if this has some positive implications (e.g. governance can decide to slash or to use treasury funds), it also creates very important uncertainty around:
- In which situations slashing should happen?
- Will $AAVE/stkAAVE holders vote for slashing?
- Exactly which networks/pools are 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 positive, as generally bad debt is measurable.
-
The system is relatively rigid on incentives, as each staked asset like stkAAVE can only have one type of reward (currently AAVE) on-chain, which is not aligned with the community direction of for example having AAVE, GHO, or any other.
-
Staking and slashing are 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.
Specification
Umbrella smart contracts
The high-level design of Umbrella has not changed radically since the initial post, and instead, the focus has been on polishing the different components, simplifying them, and making them as useful as possible for the expected usage of the Aave DAO.
On the smart contracts side, there are the following three major smart contract components.
1. The Umbrella StakeToken/s (stk)
Umbrella’s StakeToken is a staking smart contract for users for Umbrella: one StakeToken instance for each wrapped aToken of an Aave pool.
Extensive high-level and technical documentation of the StakeTokens can be found HERE.
They have the following characteristics:
- Technically, they are generic ERC4626 vaults supporting non-rebasing underlying tokens.
- They are oriented though to be used initially with 2 specific underlying tokens: wrapped Aave v3 aTokens (previously known as stataTokens), and GHO.
- Fully liquid on the supply side, without any cap.
- Withdrawal of funds from the StakeToken can be done only after activation of the cooldown period, during a follow-up withdrawal window. This is the same as with the existing stkAAVE/stkABPT/stkGHO, with a 20-day cooldown period and 2 days withdrawal window.
- When staking, there is risk of slashing (more on this in the Umbrella core description), based on the deficit (bad debt) accumulated on the associated Aave borrowed asset.
- As counterpart of the slashing risk, stakers earn rewards.
- Compatible with permit()-like operations, for example for staking and withdrawal, but also for activation of cooldown by a third-party (cooldown operator) chosen by the staker.
- Upgradeable, with upgradeability controlled by the Aave governance.
- The Aave governance will be in full control of which StakeToken/s to create: for which assets are listed in an Aave pool (or GHO), and on which network.
- Each StakeToken protects one and only one borrowed asset listed on the associated Aave pool in a network. For example, staked waUSDC core would protect deficit on borrowed USDC on Aave v3 Core Ethereum, staked waUSDS core would protect borrowed USDS on Aave v3 Core Ethereum; or staked waWETH Arbitrum would protect borrowed WETH on Aave v3 Arbitrum.
Permissioned actions & roles
All admin-like actions on StakeTokens happen via the Umbrella core smart contract. However, the final recipients of permissions over those actions are granular, as follows:
- Change cooldown to withdraw: Aave governance.
- Change unstake window: Aave governance.
- Emergency pause and unpause: Aave Protocol Guardian.
- Slash: automated, and regulated by the logic of the Umbrella core smart contract.
- Upgradeability: Aave governance.
In summary, users stake their wrapped aTokens into a StakeToken in a network to earn rewards, but with risk of slashing if there is any deficit (bad debt) arising in the connected Aave pool.
2. The Umbrella Rewards Controller
When users stake their wrapped aTokens into Umbrella StakeTokens, they immediately start accruing rewards. The accounting, management, and distribution of these rewards is managed fully on-chain by the Rewards Controller smart contract.
An extensive high-level and technical documentation of the RewardsController can be found HERE.
Umbrella’s rewards management sub-system has the following characteristics:
- Designed to have one RewardsController per network where the Aave governance wants to activate Umbrella: all StakeTokens on the same network “hook” into the Rewards controller.
- Users can claim rewards from the Rewards controller, accrued by staking.
- Each StakeToken can have up to 8 different reward tokens associated. For example, Staked wrapped aUSDC can have simultaneously USDC, GHO, and AAVE rewards.
- Per each reward token, each staked asset defines an emission of token rewards per second: e.g. per second, for Staked wrapped aUSDC the RewardsController could configure rewards of 0.1 GHO (8’640 GHO per day), which would be the total getting distributed amongst all stakers.
- More on the Emission Curve section, but for each asset, rewards levels depend mainly on two parameters:
- Target liquidity: the amount of staked assets the system optimizes rewards towards; at target liquidity of total assets staked, the system is distributing maximum aggregated rewards.
- Maximum emission per second: rate of token rewards per second at target liquidity of staked assets. Both when total staked assets are lower or higher than target liquidity, the emission per second of rewards is lower.
For example, for Staked wrapped aUSDC, the RewardsController could configure a maximum emission per second of 0.1 GHO (8’640 GHO per day), which would be the total getting distributed amongst all stakers at exactly Target Liquidity staked tokens.
- Allows for claims of rewards in batch.
- Supporting claiming rewards via permit()-like logic.
- Each staker can configure zero or multiple addresses to claim rewards on their behalf.
- Upgradeable, with upgradeability controlled by the Aave governance.
The Emission Curve
As previously described, the Rewards Controller manages rewards distribution for stakers fully on-chain, with a more dynamic system compared to that of the current Safety Module.
The reward rate for total assets is static on incentive systems like the one for stkAAVE, or the one used to reward supplies and/or borrowers on Aave v3. This means that for example, the Aave governance can configure an emission of rewards of 820 AAVE tokens per day, and, if the total staked assets is 1 AAVE, the user staking 1 AAVE will receive 820 AAVE per day, a massive amount of incentives. On the other hand, if there were 10’000’000 AAVE staked and the same reward rate of 820 AAVE per day, each staked unit of AAVE would receive 820 divided by 10’000’000, very small incentives.
If the Aave governance would want to give good incentives when the total staked amount is very small, but not massive with a hundred thousand of APY, in the existing “legacy” systems like stkAAVE’s a rewards admin would need to manually adjust the rewards rate, by monitoring how much assets are at stake each moment. This is not scalable, or optimal operational-wise, and so the Umbrella Rewards Controller works quite differently.
Goal-wise, staking tokens like the ones of Umbrella are oriented to optimize for X total staked amount. For example, after modelling coverage potential on deficit of an Aave pool, the Aave governance may want to have 50 million total staked wrapped aUSDC, and allocate 2.5m USDC rewards per year for it.
The on-chain smart contracts should optimize for that, and that is precisely what the Umbrella Emission Curve does.
Umbrella’s Emission Curve is a mathematical model optimizing the distribution of rewards for the following:
- The system defines a maximum we want to trend to: the Target Liquidity. Target liquidity is for example a configuration saying: “We want to trend the total staked assets to be 10’000’000 assets”.
- Whenever liquidity is bootstrapping and total staked is far below the Target Liquidity, the rate of rewards should be proportionally higher than when being close to the Target Liquidity, as we want to attract people to stake.
- Whenever total staked assets are above the Target Liquidity, rewards should be (slightly) proportionally lower, as we don’t want to attract more people to stake.
- The maximum reward rate of the system happens when the total staked assets are exactly Target Liquidity.
- We believe that systems showing or advertising hundreds or thousands of APY are misleading, as they are showing a temporary scenario that will disappear as soon as any minimal liquidity enters.
Umbrella’s Emission Curve has a high-level effect of “softening” the rewards APY: even when assets staked are very low, this doesn’t reflect in massive APY, only proportionally higher than when more assets are staked, but within “sane” limits. - The system is easy to understand and relatively predictable for treasury contributors. As the maximum expenses of the system happen at exactly Target Liquidity, that is the upper limit that will be spent for each reward of an asset on Umbrella. On all other levels of staked assets (above and below), expenses in rewards are lower.
On the following simulation tool, anybody can “play” with different configurations of the Emission Curve Umbrella-APY | Desmos, but a numeric example would be the following (simplifying with USDC as the staked asset, instead of how it will be in Umbrella with wrapped aUSDC):
- Target liquidity configured at 10m USDC.
- Rewards of 3’300 $AAVE tokens per year.
- Average price of $250 for $AAVE.
- At target liquidity, the APY is ~8.3%.
- The maximum APY (when a minimal amount of USDC is staked) goes to ~16%, but never above, decreasing in a “softened” manner to ~8% at Target.
As a general rule, the maximum APY is double the APY at Target. - When liquidity staked surpasses the Target, the APY decreases, but very slowly. For example going down to 4% when liquidity staked is 25m USDC, 2.5x the intended target.
Permissioned actions & roles
- Configuring new rewards for assets rewarded (StakedTokens): Aave governance.
- Configuring major parameters for asset rewarded (e.g. Target Liquidity): Aave governance.
- Set an address to claim on behalf of a staker: Aave governance.
- Modify rewards parameters of already-configured rewards: address with REWARDS_ADMIN role (e.g. Aave Finance Committee).
In summary, Umbrella Stake Tokens plug into the Rewards Controller smart contract, which regulates rewards for them, via a dynamic system implemented on the aforementioned Emission Curve.
3. The Umbrella core
Umbrella core is the smart contract acting as high-level orchestrator/controller/configurator of all the StakeTokens associated with an Aave pool, and handling slashing and deficit coverage logic.
An extensive high-level and technical documentation of the Umbrella smart contract can be found HERE.
It has the following characteristics:
- One Aave v3 Pool, one Umbrella core smart contract associated with it.
- It acts as the main hub to create instances of StakeTokens, and configure them.
- Contains the logic of deficit levels that cause an immediate slash on any of the StakeTokens controlled by the Umbrella contract.
- Manages deficit coverage on the connected Aave v3 pool, by “pulling” tokens from an external entity and using them to cover the deficit.
- Defines pairs of assets to cover on Aave and StakeToken associated with them, in this first version a 1:1 relation. For example, to cover USDC on Aave, you have wrapped aUSDC as the associated StakedToken.
- Contemplates 2 types of internal deficit:
- Pending deficit: funds already slashed, that will be used to cover the deficit on the Aave pool.
- Deficit offset: a variable representing a lower threshold to not slash funds under it. E.g. (with some extra logic aside), high-level a 1’000 offset means that while the deficit accrued on the Pool is below 1’000, no slashing will affect stakers.
This is to be used for the DAO to high-level defined something like “while the deficit of USDC on v3 Ethereum is below 100’000 USDC, no slashing on Umbrella waUSDC will happen, as the Aave Collector will cover said deficit”.
A realistic slashing flow on the Umbrella core contracts is as follows:
- Some deficit is accrued on USDC of Aave v3 core Ethereum, e.g. 1’000 USDC.
- An automation calls the
slash(USDC)on the Umbrella core. As the deficit offset was configured to 500 USDC, the 500 USDC value of the staked wrapped aUSDC gets slashed. - The slashed funds (waUSDC) are sent to the Aave Collector. As of now, those slashed funds are not withdrawable anymore by stakers, which means the 500 deficit on the pool is technically “hedged”: the Aave DAO will cover that deficit, as it has funds for it.
- An address with a required role and permission to pull 500 waUSDC from the Aave Collector, will call
coverPendingDeficit(USDC, 500). The Umbrella contract will pull funds from that address holding the waUSDC and will use them to call theeliminateReserveDeficit(USDC, 500)on the Aave v3 pool.
Permissioned actions & roles
As previously mentioned, aside from its configurations, Umbrella core also acts as an entry gateway for granular entities to configure Stake Tokens. As those have been already explained in the Stake Token section, here we will only outline the configurations available for the Umbrella core system itself, which are the following:
- Enable new pairs of assets to cover on Aave v3 ↔ Staked Token: Aave governance
- Change any slashing configuration (e.g. deficit offset, pricing for underlying of the Stake Token: Aave governance.
- Upgradeability: Aave governance.
- Initiate slash: permissionless, regulated by the logic of the smart contract.
- Cover deficit (both pending and offset): an entity with COVERAGE_MANAGER_ROLE, initially probably the Aave governance, but designed to have some constraint smart contract with that task.
- Rescue funds sent by mistake: Aave Protocol Guardian.
The Umbrella UI
We believe scopes like the Umbrella project should cover all the vertical, from smart contracts to user interaction venues. Because of that, and to complement any other access point to Umbrella, we have created a UI application that allows users to interact with the Umbrella smart contracts, allowing for:
- Staking.
- Activating cooldown.
- Unstaking.
- Claim rewards.
- Visualise aggregated data of the staking positions.
Similar to for example the Aave Governance V3 interface, the Umbrella interface follows the following principles:
- Owned and BUSL-licensed to the Aave DAO, but friendly to integrations. In this case, naturally allowing anybody to host it, use it, and modify it if the smart contracts interacted with are the official Umbrella addresses approved by the DAO.
- Oriented to easy hosting (e.g. via Vercel), or even self-hosting. Ideally, anybody who wants to give access to the Umbrella smart contracts can host an instance of the interface, adapting it or extending it as wished, for example, to build better UX or additional products on top of Umbrella.
For example, BGD will host an instance of the interface, but anybody else can. - Fully decentralized, only depending on RPC endpoints that anybody can configure on their own.
The Aave Umbrella UI codebase can be found on the aave-dao Github org, on https://github.com/aave-dao/aave-umbrella-ui. It will be production-ready only at the activation time of the Umbrella smart contracts by the Aave governance.
Umbrella batch helper
As a peripheral smart contract, we have created a smart contract to simplify interactions with Umbrella, the UmbrellaBatchHelper.
The contract has been audited and in this case is fully MIT-licensed, for anybody who wants to interact with Umbrella to be able to use it on their UX flows.
All details about the batch helper can be found HERE.
Security
Aside from the usual unit/end-to-end testing of the smart contracts, and all BGD’s internal quality assurance, we have engaged and already completed all external security reviews planned, including the following:
- Security review by @StErMi (https://x.com/StErMi) here.
- Security review by MixBytes (https://x.com/MixBytes) here.
- Security review by Ackee (https://x.com/AckeeBlockchain) here.
- Security review by @Certora (https://x.com/CertoraInc) here.
The total cost of the security reviews has been $249’000, paid to the security firms by BGD Labs and to be refunded from the Aave DAO on the activation proposal of Umbrella.
Umbrella branding
As part of their scope for services to the DAO, @AaveLabs produced an official brand book with visual components to use and guidelines to follow when referencing high-level Aave projects or the Aave DAO and community.
Given that Umbrella will be one of the major product lines of the Aave DAO, we believe it should be aligned branding-wise with the approved Aave brand kit and styling. So we have created an Umbrella “add-on” for it, that we will contribute via PR on the aave-brand-kit repository.
The following is a summary of Umbrella’s visual identity we propose:
Logotype
Aave Umbrella’s logo combines the global Aave logo, with a similarly styled umbrella, representing the ghost (Aave and all its users) being protected by the new system (the umbrella).
Colors
Currently, the yellow color on Aave’s brand guidelines is already used to represent for example stkAAVE or stkGHO on the legacy Safety Module.
We think it was a good decision, and we expanded on it assuming the same color as the official of the Umbrella product line, with an accent of Aave’s purple in components like the asset frame.
Staked tokens’ asset frame
The conceptual reference used for Umbrella’s Stake tokens’ asset frame is a zenith plane of an umbrella.
That concept materializes in a frame surrounding the Umbrella Stake Tokens, with colors used the following way:
- If the frame is exclusively yellow, it means the staked asset is not an Aave aToken, for example, GHO.
- For staked Aave aTokens, the frame is a combination of yellow and purple, representing both Umbrella and Aave.
Examples of illustrations
Umbrella activation guidelines
Activating the Umbrella system into Aave comprises different decisions that the DAO should approve.
In the following points, we try to summarise those, and welcome service providers from other involved “departments” of the DAO to give their feedback. Important to highlight that these are guidelines for the initial activation of the system, which naturally will evolve.
-
Networks/pools to activate Umbrella on. Umbrella can technically be enabled on all networks hosting Aave pool/s, as it only depends on Aave v3.3 being enabled, which is the case for all networks where Aave lives.
In practice, we recommend starting with a selective subset of networks during the first 2-3 months, as service providers need to get familiar with the non-technical flows of Umbrella in production, like Target Liquidity modeling or rewards management.For example, based on market size and user count metrics, one realistic option is enabling Umbrella on Ethereum, Arbitrum, Avalanche, and Base; but not problematic to add one or 2 more if strategic anyhow for the DAO.
-
Assets to enable on each network. On the assets side, we recommend initially focusing on a small subset of assets on each of the selected pools, with the following characteristics:
-
Highly borrowed, as deficit will only materialize in borrowable assets.
-
Associated with positions with the hypothetical potential to create deficit: e.g. a WETH collateral USDC borrowing position can create deficit, or even a USDC collateral and USDT debt. But wstETH collateral WETH debt positions are less likely, given the pricing model of wstETH.
Generally, it is a safe choice to enable only the major stablecoins of a pool (e.g. USDC, USDT, or maybe USDS), WETH, and potentially WBTC.
-
-
Cooldown period and unstake window configuration. To not overcomplicate the activation procedure, we recommend the same parameters as on the current Safety Module with a 20-day cooldown period and a 2-day unstaking window.
-
Rewards management. Similar to other Aave on-chain systems, Umbrella has been designed with a governance-first approach to start with. It means that for example, initializing new Umbrella StakeTokens must be done via on-chain governance proposals, or configure very high-level parameters like the Target Liquidity of each StakeToken.
On the other hand, “maintenance” tasks of rewards are to be managed by a
Rewards Adminrole, given/revoked by governance, but in charge of, when a StakeToken and reward is enabled on Umbrella, modifying parameters like the maximum of rewards per second at Target Liquidity, the duration of the rewards distribution, or even disabling rewards completely.As the initial entity to manage rewards, we agree with what was proposed in the Aavenomics ARFC: the Aave Finance Committee.
-
Funds management for rewards. Aside from the configuration of rewards, for obvious reasons, the tokens being rewarded should be available to the Aave Umbrella to pull and send to stakers claiming them.
On Umbrella, each configured reward has arewardPayeraddress configured from where funds will be pulled from.Keeping that in mind, we recommend the following:
- On networks where the DAO holds already enough funds in its Collector or Ecosystem Reserve to cover any potential rewards configured on Umbrella, make them available to the Umbrella contracts or directly, or even better, isolate them to a separate Collector instance with limited funds than can be periodically topped up.
- On networks where Collector funds are not enough, or the assets bridging infrastructure of the DAO is not solid enough, use the same isolated Collector instance, but be topped up by the Aave Finance Committee.
For example, a monthly governance proposal will transfer from the Ethereum Collector to the Aave Finance Commitee Safe enough funds to cover rewards for 1-2 months on let’s say Base, the Commitee will bridge them to Base and top up the isolated Collector there.
The idea with this is being operational effective, but reducing still to the minimum the delegation on funds management.
-
Transition period from stkAAVE/stkABPT/stkGHO. As Umbrella requires a certain time for minimal bootstrapping, we recommend keeping slashing active on stkAAVE and stkABPT until Umbrella liquidity reaches Target Liquidity or even if less, acceptable levels.
The case of stkGHO is different, as Umbrella should have a StakeToken instance for GHO staking from day 0. So for GHO, we recommend removing slashing and cooldown from the current stkGHO, and moving rewards to the new Umbrella staked GHO, for all stkGHO holders to migrate without any barrier.
FAQ
How frequently a slashing is expected to happen?
In a protocol like Aave, a small deficit on highly borrowed assets is expected to happen, but in a very low order of magnitude.
As an example, during the month Aave v3.3 (accounting for deficit) has been enabled in production, approximately $400 deficit has been accrued across all Aave v3 Pool.
If we compare with the close to $9.5 billion outstanding borrows, that is approximately 0.000004% of the outstanding borrowings in a month.
Umbrella is designed to do relatively frequent slashings, but in very low order of magnitude, with rewards plus supply APY of aToken almost always being way higher than the loss from slashing.
Considering the DAO fairly certainly defines an offset to not slash funds under, and that historically the Safety Module has never been slashed, slashing events in size should not be too frequent.
However, Umbrella is a fair and rational system: you earn rewards as a staker, you have risk and accept it.
While staking aTokens, does my balance grow? Meaning, is the staked token rebasing?
No, the system always wraps your rebasing aTokens before staking them on Umbrella. However, if using the Umbrella UI, the wrapping/unwrapping happens transparently for you in one transaction.
When unstaking from Umbrella, you can choose if you want to withdraw from a rebasing aToken to a non-rebasing (wrapped) one, or even if completely out of Aave.
What happened with the yield I accrued on my aTokens when staking?
You keep accruing that yield while staking, as the aToken itself is staked. For example, if aUSDC is yielding on Aave 6% and staking rewards are 4%, when staking you will receive a total of 6% + 4% = 10%.
If I stake my aUSDC on let’s say Arbitrum, do I have slashing risk only from Arbitrum or from all Aave pools?
If you stake aUSDC on Arbitrum, you are only accepting slashing risk for borrowed USDC on that pool in Arbitrum, nothing else.
If I’m using the current Safety Module (stkAAVE, stkABPT, stkGHO), do I need to do something?
Due to the Aavenomics proposal, stkAAVE and stkABPT will suffer some changes, with the major being that slashing will be at some point after Umbrella activation is disabled.
However, Umbrella is a separate system, as the assets to stake are aTokens (e.g. aUSDC, aUSDT), not $AAVE or LP tokens like Balancer ABPT. So if you are holding stkAAVE, stkABPT, nothing needs to be done on the Umbrella side.
For stkGHO, there will be a migration required, but as slashing and cooldown will be disabled, will be as simple as withdrawing from the legacy stkGHO and staking in the Staked GHO of Umbrella.
This FAQ will be updated as questions on the community arise.
Disclosure
The contents of the Umbrella project have been produced by BGD Labs to the Aave DAO in the scope of the engagement for services described HERE.
The system has been designed exclusively for the benefit of the customer (Aave DAO), all intellectual property and licensing rights of the different components of Umbrella presented belong exclusively to the Aave DAO, represented by its governance smart contracts on the Ethereum blockchain.
Next steps
- Wait for feedback from the community and/or other service providers, to model a final set of recommendations for the initial activation of Umbrella.
- Create an ARFC Snapshot outlining the final activation parameters of Umbrella.
- If the ARFC Snapshot is approved, proceed with the activation of Umbrella in production, via Aave governance AIP.
