[TEMP CHECK] Introducing "FastPass" - A Safety Module Update

Governance
1

Title: [TEMP CHECK] Introducing “FastPass” - A Safety Module Update

Author: @marczeller - Aave-Chan Initiative (ACI)

Date: 2024-04-16

Summary

This proposal introduces the concept of “FastPass,” allowing a portion of safety module stakers to bypass cooldown periods in exchange for a fee.

Motivation

The Safety Module is the cornerstone of Aave protocol resilience, with users accepting the risk of being slashed during a shortfall event in exchange for safety incentives rewards and Merit airdrops. The Safety Module is crucial to Aave’s reputation as a trusted DeFi platform due to its extensive risk mitigation measures.

However, extended cooldown periods (20 days) impose additional friction, making the opportunity cost of remaining in the safety module a significant concern for some users. In current market conditions, the perceived cost of this opportunity may outweigh the reward compensation, resulting in subpar attractiveness. Moreover, the illiquid nature of staked AAVE assets restricts opportunities for composability and integrations on top of the Safety Module.

FastPass enables stakers to bypass mandatory cooldown windows, offering two exit options: the existing fee-free 20-day cooldown or FastPass. We anticipate that FastPass will cater to a specific user base while contributing to increased DAO revenue for an acceptable reduction in average Safety Module coverage.

To mitigate the risk of the entire Safety Module adopting FastPass and nullifying its coverage during a shortfall event, FastPass imposes a daily churn rate determined by Aave Risk Service Providers and enforced by Risk Stewards. Additionally, FastPass can be disabled entirely by Risk Stewards during a shortfall event.

We propose implementing FastPass on StkGHO first, evaluating its success before expanding it to other Safety Module components.

Specification

FastPass is an update to the Aave Safety Module, introducing a cooldown window bypass feature.

Scope StkGHO
FastPass Fee 100bps
FastPass Churn Rate 2.5M GHO/day
FastPass Fee Collector Aave DAO Collector

Detailed implementation discussions will take place during the ARFC stage of this proposal.

Next Steps

  1. Gather feedback from the community.
  2. If consensus is reached on this TEMP CHECK, escalate this proposal to the Snapshot stage.
  3. If Snapshot outcome is YAE, Escalate to ARFC stage.

Disclaimer

The Aave-Chan Initiative (ACI) is not acting on behalf of any third party and is not compensated for creating this TEMP CHECK proposal.

Copyright

Copyright and related rights waived via CC0

11 Likes
2

  1. Is fast pass intended to cover all Safety module assets? (stkAAVE, stkABPT, stkGHO)

    • If yes - is churn rate intended to be per asset or global value across the system?
    • If no and this intended only to be applied to stkGHO, why don’t we drop the whole “staking lockup” and just do a normal 4626 style sGHO vault (simmilar to sFRAX, sDAI, sDOLA etc) that will be easy to integrate across DeFi etc.

  2. FastPass Fee & Fee Collector

    • I would love to see design similar to many other “RageQuit” mechanisms where a portion of these exit fees went directly to those who remain in the system (stkAAVE, stkABPT, stkGHO) holders, instead of 100% to Treasury
    • Lastly, the 1% fee feels incredibly small given the rage quit designs of other systems which can be as high as 50%, linearly decaying for length of time left in the lock. If they intent is to make it easier for folks to exit, especially for stkGHO, I reiterate my suggestion earlier for moving to a sGHO model with immediate entry/exit and a fee can be applied on the yield rate directly.
3 Likes
3

Implementing FastPass for StkAAVE & StkBPT is much more complex, also considering their much larger size, this is out of scope for current proposal.

The safety Module is not a vault such as sDAI, it’s not meant to be liquid, it’s meant to protect the protocol in case of a shortfall event.

FastPass is a limited bypass feature effectively reducing the actual coverage of the Safety module to down to 85/90% of it’s nominal size in exchange for a stable flow of protocol revenue.

It’s an equilibrium between expected benefits of this new system with the cost of reduced effective coverage.

The Aave Ethos is never to punish users unnecessary there’s no justification or need for very high fee.

Governance can decide how FastPass revenue is attributed here’s some options:

  • Kept in treasury
  • Kept in safety module having a direct impact on StkGHO exchange rate (quitters boost stakers yields)
  • Re-distributed via merit
  • Used to buy AAVE on secondary markets and fund LM/Safety incentives

We’re in favor of both a merit redistribution & AAVE buybacks.

Keeping fee in safety module is exactly how the flashloan fee works currently in the protocol, this boosted revenue is unpredictable, the benefits are unclear and mainly invisible to users limiting the positive impact of the implementation

6 Likes
4

We are supportive of this idea and agree that it complements the Safety Module nicely and helps with GHO-sided demand.

We also think it would be good for risk providers to provide general guidance on how they would attempt to evaluate the decision to disable FastPass. Will it be at the moment bad debt has accrued or proactively disabled when Aave is entering into a state of potential bad debt due to market volatility?

Once disabled, will it require a governance vote to reenable FastPass?

2 Likes
5

Supportive of FastPass, another potential revenue source.
I have only one concern here, what if one big whale exits his position with FastPass and thus using the whole available churn rate?
This would leave other smaller uses stuck as they may not have enough money to pay for higher gas fees or get a prioritization in a block.

Would it make sense to cap it but offer the alternative that if one really wants to exit his whole position in a single day this individual would have to pay 250bps instead? Then use the accruing fees to buyback Aave from the market as already suggested.
This way, when FastPass will be extended to the stkAAVE pool user that are staying in the pool benefit from higher yield created by the one that exit. Which will cause some “gaming” effect. If you leave you may not be object to slashing, but otherwise you are losing some of your stack and boost the yield.

Just an idea to think about.

5 Likes
6

Fastpass would be a valuable feature for the Ave Safety Module. However, we would have to figure out the specifics of the proposed churn rate; we would propose having an individual cap based on a percentage of a user’s total stake. That way, anyone looking to withdraw would have a reasonable opportunity to do so.

5 Likes
7

We are supportive of the idea behind FastPass.

At the ARFC stage, it is recommended to write the following two point:

  • Risk analysis related to the proposed parameters
  • Limiting the range of Churn Rate that the Risk Steward can modify
8

The current proposal has been escalated to TEMP CHECK Snapshot.

Vote will start tomorrow, we encourage everyone to participate.

9

I am for this experimentation, but I would like to challenge a few points:

First, to explain where I am coming from, I think this proposal talks about two distinct features, very different in nature: FastPass dynamics for $stkGHO and $stkAAVE are totally different things in my opinion. The first (GHO) is about making liquidity available to repay a debt, buy a dip or execute an arbitrage opportunity while the second (AAVE) is about reducing exposure on AAVE token price.
→ From this perspective - and unless you think my interpretation is wrong - there is two distinct user stories here even though the technical aspect is the same.

  1. “I want to reduce exposure to AAVE the token”: In this case, I think FastPass could be replaced by “FastSwap”. This system would also take a fee (ex: 50bps ontop of any external fee) and allow users to swap from stkAave to stkGHO. This solves the main problem of the user - even though it doesn’t make the “sold AAVE liquidity” available - but still makes them contribute to the safety module. Then they can initiate their stkGHO withdrawal, starting the cooldown period on stkGHO instead of stkAave.

  2. “I want to unlock my stkGHO early to have liquidity available” (can even be just after 1): This is the topic of the present proposal from my interpretation. In this case, I agree with other comments that 100bps (1%) is too low as an initial fee. The stkGHO is part of the safety module, and is not meant to be liquid. A 100bps makes it quasi-liquid. For example is the GHO starts trading at 1.01 USD it becomes profitable to withdraw from the safety module for executing an arbitrage and wait for the price to repeg before rejoining the module. I don’t think this is how the safety module was imagined. The ideal approach in my opinion for choosing the fee is to start high, observe behavior (arbitrage, liquidity needs, etc…) and lower the fee until we observe the % of turnover we want. For example we could start with 5% (500bps) and go lower. Also, it should probably be function of the yield.
    → A more “free market approach” would be to let the market decide: Actor A wants to be the out early with 1000 stkGHO. Actor B is ready to pay 0.99 GHO on per stkGHO.You settle the trade. Actor B pays 990 GHO and receives 1000 stkGHO; Actor A receives 980 GHO, Aave DAO receives 10 GHO (if 100bps “base” fee).
    Maybe I am going too far, but my main concern is that a fee/cut that is (1) very low and (2) arbitrary at the same time doesn’t sound good to me. It should not be that easy to fly out of the safety module, unless somebody else wants in (and in an rational market, there will always be enough “wants in” if the situation is safe for Aave).

4 Likes
10

Hello, and thx for this reply:

  1. you’re correct, FastPass on StkAAVE & STkBPT are a different beast than on stkGHO, this is why this is out of scope of the current proposal.

  2. This is interesting feedback. At the ACI we have the ethos of not punishing users when not needed, I think the free market will indeed decide if the 100 bps fee is appropriate if the churn rate is maxed out every day, that might indicate the fee is being generous to users and will allow the DAO to consider higher fees. this should be deeply discussed at the ARFC stage of this proposal.

We personally side with being “too nice” to us users early and maybe ramp up fees to maximize DAO profits while staying in an acceptable range compared to being “too harsh” with our users and providing them with a bad experience.

2 Likes
11

After Snapshot monitoring, the current TEMP CHECK Snapshot has just ended, reaching both Quorum and YAE as winning option with 400K votes. Thank you everyone who participated in Forum.

Next step will be the publication of an ARFC to continue gathering community feedback and move forward with the proposal if applicable.

12

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.

14

Hello, After extensive discussions with service providers, this proposal won’t be escalated to ARFC due to technical limitations and safety module architecture pivot to “Umbrella” model.

Instead in discussion with Service providers such as @karpatkey_TokenLogic a 0.99:1 GHO/StkGHO “Buy wall” of up to 2.5M will be organized with Aave Finance service providers and included in Merit program to be treated as STKGHO deposits without AAVE rewards.

Allowing the same results as “FastPass” but in a more flexible & lighter setup.

A dedicated Merit round 7 ARFC-addendum will be escalated to snapshot to query governance approval on this.

5 Likes