KVORUM
aaveSource: Aave governor v2 · #77

Add claimRewardsToSelf() to incentives for Ethereum V2 Aave Market

executedMay 27, 2022, 05:17 PM UTCby770x7751…035b

01Summary

AISummary by Kvorumclaude-haiku-4-5

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
Contracts0xD9ED413bCF58c266F95fE6BA63B13cf79299CE310xb8fA635fEC4E6BDb05e7937cBeF01214991e9D5a
Generated by Kvorum
model: claude-haiku-4-5
provider: anthropic
profile: anthropic-fast-v1
prompt: v1.0
generated: 2mo ago
Read the description ↗

02Description

462 words

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

https://github.com/aave/incentives-proposal/blob/1ef7705546dc7970795003e435f76b73efebbb1d/audits/Enzyme_Aave_IncentivesController_Improvement.pdf

Snapshot vote

https://snapshot.org/#/aave.eth/proposal/QmcgTovk982fcUTN17qtDyZ4oCoVGnKZJGuwMVtqspfphk

Copyright

Copyright and related rights waived via CC0.

03Mismatch analysis

AIMismatch analysis by Kvorummedium confidenceclaude-sonnet-5
Consistent

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
model: claude-sonnet-5
provider: anthropic
profile: anthropic-strong-v1
prompt: v1.0
generated: 2mo ago
Review the decoded actions ↗

04Actions

1 total
#0fallback()chain 0x1
Target
0xb8fa…9d5a
Value
0 wei
Function
fallback()
Arguments
{}
Calldata

05Tally

Summed from votes

Voters159
VP participating352.6K
Outcome (current)For
Current support100%

06Voters

159 total

No votes recorded yet.

07Forum

No forum thread is confidently linked to this proposal.