Rewards controller update across V3 pools
Simple Summary
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
^0.8.0here - adding a getter to fetch the current index here
- replacing totalSupply with totalScaledSupply on
setEmissionPerSecondhere - pumping revision from
1to2here - fixing
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
agpl->AGPLhere - improving documentation on various structs here
- removing constructor of RewardsDistributor and RewardsController here
Motivation
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.
Specification
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.
The RewardsController contracts are deployed and initialized already:
- Polygon:RewardsController
- Avalanche:RewardsController
- Optimism:RewardsController
- Arbitrum:RewardsController
- 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 PoolAddressesProvider:
0x5dcc528c0000000000000000000000005f4d15d761528c57a5c30c43c1dab26fc5452731
References
- Polygon:UpgradeRewardsControllerPayload
- Test suite
- UpgradeRewardsControllerPayload
- Original discussion
- Updated RewardsController contract
- Update diffs
Copyright
Copyright and related rights waived via CC0.
| Voter | Cast Power | Vote & Rationale |
|---|---|---|
0xc17c...C264E1 | 166,683 | YAE |
FranklinDAO (Prev. Penn Blockchain) | 90,067 | YAE |
0x62a4...96816a | 81,016 | YAE |
0xB83b...Fbcf5C | 80,000 | YAE |
0x329c...543eD4 | 78,542 | YAE |
VOTE POWER
Proposal Status
- Published Onchain
0xf71f...c61E02
- Wed December 21 2022, 05:50 pmVoting Period Starts
- Sat December 24 2022, 10:04 amEnd Voting Period
- Sat December 24 2022, 12:52 pmQueue Proposal
- Sun December 25 2022, 02:57 pmExecute Proposal
Current Results
1-YAE
566,382.1
2-NAY
0.1
