BGD. Full deprecation of stable rate

Development
1

Simple summary

Proposal for the full deprecation of stable rate mode from Aave v2 and v3, with all user positions being swapped to variable.

Including also a parallel proposal for the bug bounty payment of the report received on 4th November 2023 in relation to the stable rate.



Motivation

On the 4th of November 2023, a report was received via the Aave <> Immunefi bug bounty program about a critical bug related to the stable borrow rate.

Only certain assets were affected due to their configuration, but given the nature of the bug, together with the progressive deprecation of stable rate that started before (not enabled in Aave v3 Ethereum, the main instance of Aave at the moment, or any other afterwards), the fix involved a full deprecation of minting mechanisms of stable debt: halting new borrowings in that mode and also halting rebalancing and swapping from variable to stable.


Even if with the halting of minting of stable rate we are fully confident that there is no further vector, the current situation is extremely asymmetric, and creating really important technical overhead, for example when doing security evaluations/reviews of the protocol: there are user positions at stable, which factually have fixed rate until they decide to close it, without any kind of rebalancing applicable.

Additionally, and even if we know with full certainty that it is not applicable anymore, we are not comfortable disclosing how was the attack vector reported in November until all user stable debt positions are closed.

Therefore, after evaluating the scenario for some time, we think the better solution is to progress on the deprecation of stable rate, by having all user positions at stable moved to variable.



Specification

The Pool smart contract on both Aave v2 and v3 has a function swapBorrowRateMode(), originally allowing for an user to swap his own borrow mode from stable to variable and vice versa, and after the bug report, only allowing the user to swap from stable to variable.

With one of the swap directions not available anymore, this function becomes factually a mechanism of off-boarding from stable rate to variable. However, in some cases, for lack of monitoring of the positions, and in others, because it is not profitable, multiple users have stayed in stable rate mode, not swapping to variable.


The proposal consists in an update to the Aave Pool and its affected libraries to make the swapBorrowRateMode() permission-less in order to allow any address to trigger a swap of rate from variable to stable.

This will allow, for example, an Aave DAO automation to swap all current stable debt positions to variable, without any type of penalty to the users, apart from losing their stable exposure (sometimes positive for them, sometimes negative, if compared with the current variable rate).

As no new positions with stable rate can be created, this will allow for the final off-boarding of the mode, once all positions are at variable.


The bounty

As the problem with stable rate was detected via a bug report within the Aave <> Immunefi program, a bounty needs to be released to the white-hat, together with the Immunefi fee.

This bug had clear Critical severity, eligible for the maximum bounty on the program, amounting to $1’000’000 value. The Immunefi fee is 10% on all payouts, so $100’000 in this case.

As defined in the program description (”Program Overview” section), the Aave DAO has the possibility of doing the payments in a mix of AAVE and stablecoins. So open for feedback, our proposal is to do the payment half in stable-coins and half in AAVE token, to not de-capitalize the stable-coins reserves of the DAO, together with also giving governance power to an actor that made a really important contribution to Aave; the white-hat. The Immunefi fee needs to be paid in stablecoins.

In terms of disclosure, even if all parties aware of the vector (including us and the white-hat) are fully confident that the whole Aave system is safe, as we mentioned before, we see no value in disclosing the details of the vector yet. However, for full transparency with the community, we will also request contributors of the community (Avara as reviewers on Immunefi and Certora as security service providers to the DAO) to confirm in this thread that the maximum payout is required.



Next steps

The next steps will be the following:

  • Receive feedback and answer questions from the community regarding this proposal. This also includes risk providers of the community (props to Chaos Labs for sharing high-level data about current stable rate positions).
  • Create an ARFC Snapshot, for pre-approval of the community on the deprecation of stable rate mode. This will be done only after a minimum of 5 days of this proposal being in the forum, to give enough time for discussion.
  • If the ARFC is approved, and after passing the appropriate security procedures, proceed with an on-chain AIP, upgrading the v2/v3 pools and potentially enabling some type of Aave Robot automation to permission-less doing user migrations.
  • In parallel, and also after feedback from the community (especially contributors to the financial area), create an on-chain AIP for the bounty payment, following the 50%/50% split proposed.
5 Likes
2

I have actively participated to the assessment and resolution of the stable rate issue and i 100% confirm its severity and eligibility for the 1M bounty. I want to personally thank the hacker who reported the issue and the Immunefi team for contributing to the safety of the Aave protocol. This shows how much the Aave DAO cares about security and is ready to properly compensate security researchers when unknown issues are discovered.

2 Likes
3

At the ACI, we want to thank the whitehat that protected the protocol, ImmuneFi, @bgdlabs and everyone involved in this process, resulting in Aave users being protected.

The Bounty is deserved, and we show full support for its payout.

In terms of payment, the DAO treasury can afford stablecoins, AAVE payment, or a mix, so we will defer to Aave Finance to pick the most efficient path forward @TokenLogic @Karpatkey.

We think a mix would be a suitable solution, but we are not ready to die on any hill for these details.

3 Likes
4

Thanks @bgdlabs for opening it up to discussion. We appreciate BGD’s leadership and the whitehacker’s contributions to make Aave safer.

This bounty’s payment can be executed in a 50/50 split between AAVE and stablecoins.

  • We propose that stablecoin half is carried out in 500k aUSDT tokens (Aave v2).
  • For the second half to be paid in $AAVE, we propose a 30-day price average is used to calculate the final amount. We will gladly supply this value at the time of posting the AIP.
  • The Immunefi fee ($100k) is also to be carried out in aUSDT: 100k aUSDT tokens (Aave v2).
5

Certora was fully involved in the evaluation and mitigation of the aforementioned bug.
Our assessment fully agrees with @bgdlabs and @Emilio on the eligibility of the report to a maximum bounty stated in the program.

As DAO members, we deeply thank the whitehat who reported the bug for their contribution to Aave’s security and congratulate them for the highly deserved reward.

1 Like
6

While it is unfortunate that stable borrowing has been disabled, I highly appreciate and want to thank the white-hat for reporting that error. Security is important and needs to be rewarded. I do trust the statements provided by BGD, Emilio and Certora and therefore support the max bounty.

Again thank you for making Aave a little bit safer again.

2 Likes
7

Being an important topic, after leaving some extra days for the community to participate in the discussion, we have created an ARFC Snapshot for pre-approval proceeding with the technical deprecation of stable rate mode.

Participate :ghost:
https://snapshot.org/#/aave.eth/proposal/0xb58ef33b4b7f4c35b7a6834b24f11b282d713b5e9f527f29d782aef04886c189

1 Like
8

We confirm aUSDT as the currency for the part of the bounty to be paid out in stablecoins.
Additionally, the suggested AAVE TAP price for the last 30 days is $89.56.

9

In parallel with the ARFC for the final stable rate mode deprecation, we have also created an on-chain AIP for the bug bounty payment for the white-hat.

Voting starts in approximately 24 hours. Participate :ghost:
https://vote.onaave.com/proposal/?proposalId=36

4 Likes
10

i am against this.

this topic came out previously and i asked questions directly to @bgdlabs bgdlabs and got no response. so pls i would prefer if @bgdlabs responds and i don’t get attacked/sidetracked by others

below is the question i asked:

Continuing the discussion from Aave v2/v3 security incident 04/11/2023:

you have now upgraded to “extremely asymmetric”? please explain what you mean by this? with respect you throw in a technical word with no explanation. sounds like baloney to me.

you mention that the attack vector is closed and pools with stable rates are NOT at risk of exploit or putting protocol at risk:

Even if with the halting of minting of stable rate we are fully confident that there is no further vector

or what are you saying? the use of “if” makes it a bit ambiguous. is it or is it not still a risk vector?

In terms of disclosure, even if all parties aware of the vector (including us and the white-hat) are fully confident that the whole Aave system is safe, as we mentioned before, we see no value in disclosing the details of the vector yet

so is the following your case for moving ppl from stable to variable:

  1. you can release the reason for exploit
  2. the stable rate pools make your risk models more difficult
  3. asymmetry (pls explain this)

also what is meant by this:

there are user positions at stable, which factually have fixed rate until they decide to close it, without any kind of rebalancing applicable

“the users positions at stable, which factually have fixed rate until the decide to close”. again with respect this sounds like gobbledygook. stable and fixed rate are the same thing. always have been.

full disclosure:

i opened stable rate in bear. have had that open for a long time. the stable rate during bear was higher than variable, so i was paying more to aave and one could say subsidizing the variable rate ppl to give them cheaper debt.

i did this because i thought when bull market comes the variable rate will increase as ppl seek leverage. this has finally started happening and now you want to force me to close this position.

i think this is unfair and i don’t think @bgdlabs reasoning justifies forcing ppl to close their positions.

i.e.
there is no exploit risk.
i don’t believe that the stable pools would complicating their models as much as they are purporting.
there are a lot more complex variables that they need to model.

1 Like
11

Full disclosure: I am a trader who opened a stable position in the bear market, whose stable position is currently very good compared to current rates, and I concur with the above that I feel like (unsubstantiated) what’s happening is that I have paid an additional premium for something back during the bear market, something that this change would unjustly take away from me if my position were switched, against my will, to variable. My address is kuilin.eth, feel free to take a look at my positions.

If possible, I would like someone with an archival node and scripting ability (or similarly good data) to quantitatively collect the following information:

  • Since inception, in total, how much have stable positions paid more or less compared to the same positions if they were variable instead?
  • The above, broken down by the asset being borrowed.
  • The above, also broken down by account, as a graph of the distribution.

This wouldn’t say much about whether stable traders, going forward, deserve to keep the stability they purchased (more than the costs mentioned above, such as technical overhead). But it would at least say whether they, looking backwards, have already profited off of it if they called the bear market successfully, or if most stable traders are yet to see any return from their decision to purchase a stable rate guarantee.

I would try to collect this data myself if I had the bandwidth to look into how the contracts work and whatnot, but I do not, and I think there are others here who can do this without as much startup time as me, so I humbly request someone else to do this please :) I hope to either substantiate or refute the feelings I mentioned earlier with this data, and believe people in a similar situation would feel similarly.

1 Like
12

Hello @chippervan , glad to answer your questions, and apologies if we missed them before.

With “asymmetric” we refer to what we mentioned in the initial rationale: at the moment, it is not possible to create new stable debt, or rebalance the current positions. That means that the user stables rates are fixed; any user rate will stay like that forever, until the user decides to close it or gets liquidated.
That is not how the system worked before: stable rate was never same as fixed, under certain conditions defined in the logic, an user having for example a 4% rate could be rebalanced by anybody to a higher rate. This is because a pool system like Aave simply can’t work with fixed rates, as borrowings don’t have time duration, and utilisation dynamics would break.


Regarding the exploit, the halting of minting of stable rate done back in the days stops both the reported vector and additional others we noticed during the evaluation back in the days. Now, the root of the problem is based on certain logic that we simply think is not solvable in any reasonable manner, and related with mathematic imprecision.
There have been multiple attack vectors based on imprecision on DeFi protocols, and same as it is our duty to propose new technical features, it is also our duty to propose deprecating mechanisms that we simply consider dangerous, no matter if we don’t see any specific vector at the moment.


We understand that economically is not good for borrowers with stable rate below the current variable to be swapped to variable. At the same time, on the medium term is not realistic to have completely fixed positions underpaying compared with variable, and with simply no mechanism to change that.
Therefore, we think it is reasonable to, even if the proposal passes, leave some additional time without proceeding with the execution of the deprecation. But after approximately 4 months since the disabling of the minting direction, we also think it is reasonable to proceed, given that as borrow positions with rate over market are closed, only those below will remain and then utilisation dynamics could be quite skewed.

2 Likes
13

Hello @kuilin .

Data extraction is not our field of contribution, but we will request the risk service provider of the community @ChaosLabs to share with the community some extra visibility about stable rate mode positions.

2 Likes
14

@bgdlabs appreciate the response.

i don’t understand this. how can anybody rebalance “stable rate user” to a higher rate when the “stable rate user” locked in a stable rate? my understanding was that if you locked in a stable rate it was locked for that user until you as “stable rate users” made changes to that loan, i.e. if current rate market stable rate is higher and you increase your loan then the rate will change proportionally?

is this not resolved by stopping minting of new stable rate positions?

i disagree with this and don’t think it is valid. this was the whole premise of locking in a stable rate to begin with. you locked in a stable rate as you think rates at that time are decent and you take that position, i.e. you think rates will be higher in the future so you are happy to pay premium in short term to lock this in. that is what i did. at the time of locking i was above the variable rate and subsidizing. so i think it is unfair to deprecate when this position is finally working out for me.

15

Not exactly, stable rate could change due to rebalance conditions (see HERE) and also due to Aave governance changes on the interest rate strategy itself (how the logic works).


Yes, the attack vector doesn’t exist, but that doesn’t mean that it is possible to enable minting again. And without minting, the protocol ends in the aforementioned asymmetric situation.


To insist on this, even with no change due to the bug-fix, a position with lower stable rate could have been naturally rebalanced if the rebalance conditions would have applied organically.

16

ok thanks. do you when the rebalance condition defined? i see documents were updated 5 months ago. was this when this condition defined or was this defined before that?

do you know if rebalance was applied in the past?

17

https://etherscan.io/advanced-filter?mtd=0xcd112382~Rebalance+Stable+Borrow+Rate

The first 4 bytes of keccak("rebalanceStableBorrowRate(address,address)") is 0xcd112382.

You can also search by emitted event RebalanceStableBorrowRate(address,address) whose topic0 is 0x9f439ae0c81e41a04d3fdfe07aed54e6a179fb0db15be7702eb66fa8ef6f5300 if you’re looking at a specific stable token.

18

Yes, the rebalance mechanism was live since the inception of Aave v2.

19

Following the supportive outcome on the ARFC stage, we have created an on-chain AIP to upgrade Aave v2 to enable permissionless migration of stable debt position to variable debt.

This means that after approval and proposal execution, any address will be able to call a swapToVariable(address asset, address user) function on the Aave v2 pool contract, to swap the debt mode of any user with stable to variable.


Voting will start in approximately 24 hours, participate :ghost:
https://vote.onaave.com/proposal/?proposalId=86

1 Like