Merit Approvals
01Summary
Merit is a merkle-tree-based periodic airdrop system to reward Aave-aligned user behaviors over a 90-day period. The proposal approves 2.9M GHO and 600 aEthWETH tokens to the Merit SAFE for distribution.
- Type
- treasury allocation
Key changes
- Approve 2.9M GHO for Merit airdrop distribution(high)
- Approve 600 aEthWETH for Merit airdrop distribution(high)
- Implement merkle-tree-based periodic airdrop system to reward Aave-aligned user behaviors(high)
Generated by Kvorum
02Description
Simple Summary
“Merit” proposes a merkle-tree-based periodic airdrop system, designed to reward Aave-aligned user behaviors and enhance protocol competitiveness, with a defined budget for the initial 90-day period.
Motivation
Addressing the competitive DeFi landscape, “Merit” seeks to elevate Aave’s appeal and efficiency through a rewarding mechanism that prioritizes DAO-beneficial actions, distinguishing Aave from competitors employing artificial incentive methods.
Specification
Merit SAFE: 0xdeadD8aB03075b7FBA81864202a2f59EE25B312b
- Approve 2.9M GHO
- Approve 600 aEthWETH
References
- Implementation: AaveV3Ethereum
- Tests: AaveV3Ethereum
- Snapshot
- Discussion
Copyright
Copyright and related rights waived via CC0.
03Mismatch analysis
The decoded action is a single opaque `execute()` call to what appears to be an Aave governance payload contract (0x9323...52b8). This matches the standard Aave V3 proposal pattern where the actual logic (e.g., ERC20 approvals) is implemented inside the payload contract's execute() function and delegatecalled by the governance executor, rather than being visible as discrete decoded arguments in the top-level proposal action. The description's claims — approving 2.9M GHO and 600 aEthWETH to the Merit Safe — align with the referenced implementation contract (AaveV3Ethereum_MeritApprovals) linked in the References section, which is consistent with this pattern. However, because the calldata for this single action does not expose any decoded arguments (target token, amount, spender), I cannot directly verify the specific figures or recipient address against on-chain data. This is a common and expected limitation for Aave payload-style proposals, not evidence of malicious intent, so I do not flag it as a discrepancy. Confidence is set to low because the calldata visibility is insufficient to confirm or deny the specific numeric/target claims in the description; a full verification would require decoding the bytecode or logs of the payload contract's execute() function.'
Generated by Kvorum
04Actions
- Target
- 0x9323…52b8
- 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.