[ARFC] BGD. Aave v3.4

Development
21

Aave v3.4 split and activation


We would like to update the community regarding v3.4 and its activation, along with important changes related to this procedure.

During our internal analysis of the final upgrade codebase, we decided that, from all the changes, a subset would be better split off and audited separately as an independent upgrade on top of v3.4, which we call 3.5.

It is important to highlight that this doesn’t mean the set of included and pre-approved features disclosed in this forum has changed, but that we believed that both for our internal development procedures and third-party reviews, it would be cleaner and more secure.


To be more specific about it, the contents of the split original v3.4 into a reduced v3.4 and v3.5 are the following:


→ New reduced v3.4
It will include the majority of the features and changes presented in the original post and ARFC Snapshot, more precisely:

  • The “standardisation” of the custom a/v GHO on Ethereum Core, into the usual a/v Token model for any other asset, including all migration steps required on the protocol layer, not to affect users.
  • Multi-call support.
  • Introduction of the configurable Position Manager for users, to optionally allow switching emode or collateral enable/disable on behalf of the user.
  • Removal of the “unbacked” logic from the protocol.
  • Changes of different variables to immutables, given their constant nature.
  • Migration to Errors, instead of error codes.
  • Flash loan fee simplification.
  • The majority of the Misc changes are presented in the original post HERE.

A very exhaustive list of changes on the reduced v3.4 can be found HERE and on the upgrade v3.3 → v3.4 repository HERE.


→ v3.5
Will be focused on the math precision component presented originally HERE within v3.4, and some small improvements on logic libraries.

As aforementioned, this split makes things way simpler both for us on development and especially for security reviewers to analyse the changes.


For full transparency, the new reduced v3.4 and v3.5 have totally separate audit cycles, meaning that v3.4 has undergone 4 security audits (we commented later on those), while v3.5 will have an extra 4; totalling 8 audits if we consider the original v3.4 scope.



v3.4. Activation

On the new reduced v3.4, all procedures are finished for the creation of AIP, and we would like to share with the community the following:

  • The Aave Protocol v3.4 codebase can be found HERE. As always, this will be merged to main line if/when the Aave Governance approves and performs the upgrade on-chain from the current v3.3 to v3.4.
  • The codebase of the AIP itself, performing the upgrade, and everything surrounding it can be found HERE.
  • The security procedures performed in the codebase (both v3.4 and the AIP itself) have been the following:
    • All our (BGD) internal testing and evaluation, including making the Aave v3 fuzz suite compatible with v3.4.
    • Security review by StErMi. v3.4 & AIP.
    • Security review by Certora. v3.4 & AIP.
    • Security review by EnigmaDark. v3.4 & AIP.
    • Security review by Blackthorn (Sherlock), by senior researchers who also participated successfully in the Aave v3.3 Sherlock contest. v3.4 & AIP.
    • In addition, we have shared with Aave Labs the v3.4 codebase early on, for their optional review.
      The governance proposal will include a refund to BGD Labs of the audit costs incurred of $213’125.
  • We think the biggest change included in v3.4 is the standardisation of minted GHO on Core to a “normal” supplied asset. Everything is extensively explained in both the v3.4 codebase HERE and on the AIP HERE, but some very important aspects we would like to highlight:
    • Discount as working right now on variable debt GHO will not exist anymore after the upgrade, as that was precisely the main source of customisation on the smart contracts infrastructure for a/v GHO.
    • For all users with outstanding discount but not “settled” into their position accounting (every action on the vGHO/stkAAVE position updates it), we will coordinate with the Dolce Vita service by ACI to permissionlessly settle it in the period of 24-12h before the proposal activation, for any position with GHO debt size >10 GHO, as below there, the influence of discount since last action doesn’t even offset gas cost.
      For reference, a position of 1’000’000 borrowed GHO with maximum discount at the current GHO borrow rate would get ~25 GHO on a 12h period, meaning that with Dolce Vita targeting that timeline (and for big position will be less, targeting order of <6 hours), the impact will be minimal.


Next steps

  • After some days in this forum, we will create the on-chain AIP for the upgrade of Aave v3.3 to the new reduced Aave v3.4. A realistic target is middle next week, for execution to happen beginning of the 23rd June week.
  • In parallel, finish preparations of the split features into Aave v3.5. Currently, all security reviews are ongoing, so we expect this to be ready very soon after v3.4 for AIP too.
    However, we will still do more communications about v3.5 in this forum before AIP.
12 Likes