The Aave v3 codebase is divided into 2 different parts, Aave v3 core, and Aave v3 periphery. While usually the concept of “protocol” is more related to the Aave v3 core, there are some complementary components of Aave v3 living on the periphery codebase, for example, the system managing external teams configuring rewards for Aave v3 activity (e.g. supply/borrow assets).
Similar to the majority of other Aave smart contracts, the ones on the periphery are upgradeable and controlled by the Aave governance, which means they are designed to be improved over time.
Given that the community has approved a new Aave v3 Ethereum, we have used the occasion to introduce light improvement/fixes on the periphery smart contracts and now will submit the upgrade to be approved via governance.
Changes included on Aave periphery v3.0.1
The changes on this upgrade of the periphery are really light, especially if we compare them with the ones on the upcoming core upgrade (to be deployed with Aave v3 Ethereum).
It is possible these changes here https://github.com/aave/aave-v3-periphery/pull/105 and they include the following :
- “Soften” Solidity versions of the contracts to ^0.8.0, not impacting the live smart contracts.
- Add a
getAssetIndex()function to the
RewardDistributor, alleviating a lot of gas consumption for systems built on top and requiring calculations on rewards.
- Fix a bug on the
setEmissionPerSecond(), as the total supply of a/v Tokens was not correctly considered.
- Fix a bug on the
getUserRewards()function, previously not returning what high-level should be the rewards accrued by the user.
- Removed unnecessary constructor, given the nature of the implementation always under a proxy.
These changes will be approved via cross-chain governance (or Guardian wherever not available) on all v3 instances: Polygon, Avalanche, Optimism, Arbitrum, Fantom, and Harmony (these last 2 for compatibility reasons, even if currently frozen).
The codebase of the proposal payload can be found at https://github.com/bgd-labs/rewards-controller-update
Security procedures applied
Given that the changes are on view functions or really small, we will ask Certora and SigmaPrime to review them, but we don’t think an audit report is required.
The whole upgrade has been tested and peer-reviewed by both BGD and Aave Companies.
Given that this is a purely technical/maintenance upgrade, we will be only submitting the on-chain proposal required in the following days, without a previous Snapshot, to not create unnecessary voting overhead.
Props for the general contributions and reviews of @miguelmtz and @kartojal from @AaveCompanies, and the participation of MerlinEgalite from MorphoLabs on one of the fixes.