Rewards controller update across V3 pools
This proposal updates the rewardsController to it's newest version improving the DX by adding new getters and resolving some minor issues:
- soften solidity versions to
- adding a getter to fetch the current index here
- replacing totalSupply with totalScaledSupply on
- pumping revision from
getUserRewardto return correct rewards for users with 0 balance here
- remove unnecessary
constructorthat sets state on a contract always used behind a proxy here
- consistently uppercase license pragma
- improving documentation on various structs here
- removing constructor of RewardsDistributor and RewardsController here
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 and it only makes sense to apply them to already existing v3 pools.
This proposal executes
PoolAddressesProvider.setAddressAsProxy(keccak256("INCENTIVES_CONTROLLER"), rewardsControllerImpl) on
Polygon V3 pool.
If this proposal succeeds, this will be seen as positive signaling to upgrade implementations for v3 pools on networks controlled by guardians as well.
RewardsController contracts are deployed and initialized already:
- Fantom:RewardsController verification does not work properly
- Harmony:RewardsController verification does not work properly
Verification on harmony & fantom does not work due to bugs in the respective explorers.
You can verify though that bytecode &
initialize calls are 100% the same between the different networks.
For guardian controlled pools the transactions are executed via gnosis, so instead of deploying a payload the guardians will just sign the
setAddressAsProxy(keccak256("INCENTIVES_CONTROLLER"), rewardsControllerImpl) transactions.
The pre-encoded calldata to be executed by guardians on the respective
- Test suite
- Original discussion
- Updated RewardsController contract
- Update diffs
Copyright and related rights waived via CC0.
Your voting info
20 Dec 2022, 17:43 UTC +00:00
21 Dec 2022, 17:50 UTC +00:00
24 Dec 2022, 09:50 UTC +00:00
25 Dec 2022, 12:52 UTC +00:00
BGD Labs (@bgdlabs)