Add claimRewardsToSelf() to incentives for Ethereum V2 Aave Market
01Summary
Add a claimRewardsToSelf() function to Aave's liquidity mining incentives contract that allows callers to claim their own rewards using msg.sender instead of specifying a recipient address. This enables integration with Enzyme vaults and similarly-architected protocols that cannot trust transaction originators.
- Type
- contract upgrade
Key changes
- Add claimRewardsToSelf(address[] calldata assets, uint256 amount) function to incentives controller that claims rewards to msg.sender instead of a specified recipient(high)
- Reuses existing claiming logic with no changes to storage layout or core functionality(medium)
- Enables Enzyme vaults and similarly architected smart contract protocols to claim rewards without requiring trusted transaction originators(high)
Notable concerns
- None explicitly stated - proposal has been audited and test cases reviewed by Aave team; Enzyme contracts have been audited by PWC, Chain Security and leading auditors on the Enzyme Council
Generated by Kvorum
02Description
Summary
Add a claimRewardsToSelf() function to the liquidity mining incentives contract, so a caller can claim their own rewards without specifying the to recipient.
Abstract
Aave incentive contracts currently only contain claiming functions in which the caller specifies the recipient to address, who will receive the claimed rewards. Unfortunately, this poses a security problem for abstractly-designed smart contract claimants that do not have fully-trusted originators of claiming txs. This is the case for Enzyme vaults. By adding an additional claiming function to the incentive contract that uses msg.sender instead of to, the tx originator no longer needs to be trusted.
This simple addition - that reuses the exact same claiming logic as the current claiming functions with no changes to storage layout - will increase composability opportunities with Enzyme and similarly architected protocols.
Motivation
Enzyme is a decentralised asset management infrastructure built on Ethereum. It allows asset managers to build on-chain investment Vaults that utilise and allocate to the newest innovations in DeFi. Because all transactions occur on the Ethereum blockchain, compliance, accounting, and investor management services are rendered programatically and at a dramatically-reduced cost to their traditional finance counterparts.
Amongst other things, Enzyme Vaults can interact with AAVE by lending. We are currently also working on accommodating the borrowing functionality to enable leveraged strategies.
In order to keep providing our users with superior asset management tools in DeFi, we want to open up the liquidity mining option for them as soon as possible. Our users rely on having the latest DeFi functionality in Enzyme to reach their full potential.
Benefits for AAVE:
- Increased AAVE adoption by the Enzyme user base and other similarly architected protocols
- Tapping into a new and fast-growing community
- A closer collaboration between our two projects & communities
- Enzyme contracts have been audited by PWC, Chain Security and some of the leading auditors in the space who sit on the Enzyme Council
- Opening up the possibility for new and novel use-cases to be built around AAVE
Specification
Adds function claimRewardsToSelf(address[] calldata assets, uint256 amount) to the liquidity mining incentives contract, which reuses the logic of claimRewards() but uses msg.sender instead of to.
Rationale
This is the simplest, least intrusive way to support claimants who might not be trusted to send claimed rewards to a third party.
Test Cases
Test suites (local, mainnet fork, and proposal flow on mainnet fork) have been included at https://github.com/aave/incentives-controller/pull/4 and have been reviewed by Aave team.
Implementation
Full PR: https://github.com/aave/incentives-controller/pull/4
New incentives implementation contract on Ethereum mainnet: 0xD9ED413bCF58c266F95fE6BA63B13cf79299CE31
Upgrade to be executed via deployment of ProposalIncentivesV2Executor.sol: https://github.com/aave/incentives-controller/blob/e5e8b2c994ee29b0af883db7c94add372b4423b2/contracts/proposals/ProposalIncentivesV2Executor.sol
Deployed proposal payload (ProposalIncentivesV2Executor.sol) on Ethereum mainnet: 0xb8fA635fEC4E6BDb05e7937cBeF01214991e9D5a
Audit
Snapshot vote
https://snapshot.org/#/aave.eth/proposal/QmcgTovk982fcUTN17qtDyZ4oCoVGnKZJGuwMVtqspfphk
Copyright
Copyright and related rights waived via CC0.
03Mismatch analysis
The proposal's single decoded action is a call to execute() on the address 0xb8fa635fec4e6bdb05e7937cbef01214991e9d5a, which exactly matches (case-insensitive) the 'Deployed proposal payload' address stated in the description's Implementation section. This is the standard Aave governance pattern: the short executor contract's execute() function performs the actual state changes (here, upgrading the incentives controller implementation to add claimRewardsToSelf()) internally, and those internal calls are not separately decoded in the provided calldata. Because the on-chain target matches the address the description explicitly names as the payload responsible for this upgrade, and the description's technical specification (new function reusing claimRewards logic with msg.sender) is consistent with the stated purpose of that payload, there is no target mismatch, value mismatch, or omitted/extra action visible at the level of detail decoded. Confidence is medium rather than high because the calldata only shows the outer execute() call and not the internal upgrade logic, so the precise internal effects (e.g., the exact bytecode change) cannot be independently verified from this data alone, though the address match and consistent narrative provide reasonable assurance. No numeric parameters, recipients, or contract targets in the description appear altered or contradicted by the decoded action. This matches the common Aave 'short executor' proposal structure where the description's implementation details are trusted to correspond to the deployed and audited payload referenced by address. Given the strong address match and lack of any contradicting decoded detail, this proposal is assessed as consistent with medium confidence due to the opacity of the single execute() call.
Generated by Kvorum
04Actions
- Target
- 0xb8fa…9d5a
- Value
- 0 wei
- Function
- fallback()
- Arguments
{}- Calldata
05Tally
Summed from votes
06Voters
No votes recorded yet.
07Forum
No forum thread is confidently linked to this proposal.
08Similar proposals
- aaveexecutedClaim Aave v2 stkAAVE rewards76%
- aaveexecutedClaiming AAVE Rewards for the Sablier Legacy v1.1 Contract76%
- aaveexecutedWhitelist Balancer’s Liquidity Mining Claim73%
- aaveexecutedAllow Balancer To Claim Mining Rewards72%
- aaveexecutedWhitelist Curve Liquidity Mining Claim70%
- aaveexecutedintroduce Liquidity Incentives for Aave v269%
- aavecanceledAllow Balancer DAO to Claim Liquidity Mining Rewards (Arbitrum & Base)69%
- aaveexecutedAllow Balancer DAO to Claim Liquidity Mining Rewards (Arbitrum & Base)69%
- aaveexecutedAave V2 - Liquidity Mining Program (90 days at 30% reduced rate)66%
- aaveexecutedAave V2 - Liquidity Mining Update (90 days at 30% reduced rate)64%