Consolidate Reserve Factors and Enable Borrowing DPI
01Summary
Consolidate Aave mainnet V1 and V2 Reserve Factors to increase treasury from ~$27.32M by redirecting V1 revenue to V2, and re-enable DPI borrowing on Aave markets with specified interest rate parameters (Base 0%, Slope1 7%, Slope2 300%, 45% utilization rate).
- Type
- protocol addition
Key changes
- Redirect all V1 Reserve Factor revenue to V2 Reserve Factor, consolidating ~$435K in V1 assets with $26.88M in V2+AMM assets for total of ~$27.32M(high)
- Upgrade token distributor to send all future protocol revenue from V1 deployment to V2 Reserve Factor(high)
- Re-enable borrowing of DPI token on Aave markets with interest rate parameters: Base 0%, Slope1 7%, Slope2 300%, and 45% utilization rate(medium)
- Disable future revenue accrual in V1 Reserve Factor post-implementation(medium)
Notable concerns
- DPI borrowing was previously disabled via AIP-44 but was found to be safe for re-enablement
- V1 market TVL is declining (~$102.7M) with slowing revenue generation
- No ask for Stable Interest Rate borrowing of DPI at this time
Generated by Kvorum
02Description
Simple Summary
This AIP is the combination of two ARCs presented on the Aave Governance Forum. This proposal performs the initial step of the Llama treasury management strategy and also includes Index Coop’s enable borrowing of DPI proposal.
The Llama proposal entails re-routing the current and future revenue from the mainnet V1 Reserve Factor to the mainnet V2 Reserve Factor. The Index Coop proposal re-enables users to borrow DPI after it was disable by AIP-44.
Abstract
The Llama Community recommends consolidating revenue earned on all Aave markets on mainnet into a single Reserve Factor (RF). This proposal consolidates past and future Aave mainnet V1 market revenue into the mainnet V2 RF. In the future, other aspects of the Llama treasury management proposal will be implemented through separate AIPs.
This proposal is broken into two parts, the second part is to enable borrowing of DPI. The borrowing of DPI was disabled via AIP-44 along with xSUSHI. Shortly after enacting AIP-44, DPI was found to be safe. This proposal is to reinstate DPI as an asset that can be borrowed on the Aave markets.
Motivation
Part A - Consolidate Aave Mainnet V1and V2 Reserve Factors
The legacy V1 market continues to generate mostly flash loan fee revenue and this has slowed down in recent times. There is only ~$102.7M of TVL remaining in the V1 market, and at the rate of which revenue is generated is expected to continue declining as more and more users move to V2 or V3 over time.
This proposal recommends consolidating the Aave V1, V2, and AMM market revenue into a single location before deploying the capital to earn additional yield. The V1 RF holds around ~$435K of assets at the time of writing, whereas the Ethereum V2 + AMM market holds $26.88M of assets. Consolidating the RF balance would increase the mainnet treasury to around $27.32M.
Specification
Part A - Consolidate Aave Mainnet V1 and V2 Reserve Factors
Within this proposal, the assets held with the Aave mainnet V1 RF are to be transferred to the Aave mainnet V2 RF. All future revenue from the V1 deployment will now automatically accrue in the V2 RF upon implementation of this proposal. Post implementation of this proposal, the V1 RF is not expected to accrue any future revenue.
A detailed breakdown of the consolidated constituents can be found on the Aave Treasury Finances by Llama Dune Dashboard.
Part B - Enable Borrowing DPI
The recommendation is to enable borrowing and although there are a number of extrinsic use cases for DPI emerging, starting with a utilisation rate of 45%. For Variable Interest Rate parameters, a Base of 0, Slope 1 of 7% and Slope 2 of 300% was selected which is similar to the constituents within DPI. At this point in time, there is no ask for Stable Interest Rate borrowing.
The details outlining the original specification for listing DPI can be found here, AIP-31. For any additional information see Index Coop’s website: https://www.indexcoop.com/dpi.
Test Cases
The full test of this proposal can be found here: https://github.com/llama-community/refactor-aave-rf/
Implementation
Aave mainnet V1 Reserve Factor: 0xE3d9988F676457123C5fD01297605efdD0Cba1ae
Aave mainnet V2 Reserve Factor: 0x464C71f6c2F760DdA6093dCB91C24c39e5d6e18c
By calling function execute() and function distributeTokens() on the ProposalPayload contract, the token distributor will be upgraded to send all funds to the Aave mainnet V2 Reserve Factor, the AAVE protocol v1's token distributor will be set to Aave mainnet V2 Reserve Factor, DPI borrowing will be enabled and all large balances from the Aave mainnet V1 Reserve Factor will be distributed to Aave mainnet V2 Reserve Factor. The new token distributor implementation was deployed to 0x55c559730cbCA5deB0bf9B85961957FfDf502603.
Target Contracts
ProposalPayload = 0x43D2A74c55eE4DB917251eC934b2fD03E3069bd6
Copyright
Copyright and related rights waived via CC0.
03Mismatch analysis
The proposal description explicitly states the mechanism of execution: calling execute() and then distributeTokens() on the ProposalPayload contract at 0x43d2a74c55ee4db917251ec934b2fd03e3069bd6, and describes that these two calls will (a) upgrade the token distributor to route V1 revenue to the V2 Reserve Factor, (b) enable DPI borrowing, and (c) sweep existing V1 RF balances to the V2 RF. The decoded on-chain actions are exactly two calls — execute() and distributeTokens() — on that same target contract, matching both the target address and the two-step call sequence described in the Implementation section. Because Aave AIP payload contracts typically bundle multiple sub-actions (reserve factor changes, distributor upgrades, risk parameter updates) inside a single execute() function, the decoded calldata naturally shows only the outer function calls rather than the internal state changes (e.g., DPI interest rate parameters, distributor address changes). This is standard for this proposal pattern and is fully disclosed in the description, so it does not constitute an omission needing a flag — the description accurately previews what the two calls will do. Confidence is medium rather than high because the internal bytecode/state changes of execute() (e.g., exact DPI utilization/slope parameters, exact addresses set) cannot be independently verified from the flat decoded calldata provided, only inferred from the description's own account of the payload's design. No numeric values, target mismatches, or extra/omitted top-level actions were found between the two data sources at the level of granularity available in the calldata dump.
Generated by Kvorum
04Actions
- Target
- 0x43d2…9bd6
- Value
- 0 wei
- Function
- fallback()
- Arguments
{}- Calldata
- Target
- 0x43d2…9bd6
- Value
- 0 wei
- Function
- fallback()
- Arguments
{}- Calldata
05Tally
Summed from votes
06Voters
No votes recorded yet.
07Forum
- ARC - Consolidate Aave V1, V2 & AMM Reserve Factors, Purchase CVX and Deploy to Earn Yield ↗discourse · high confidence
Arguments for
- The Aave treasury's reserve factor holdings are largely unproductive and should be consolidated and deployed to earn yield beyond simple aToken returns.— MatthewGraham, Dydymoon
- Acquiring CVX and veCRV gives Aave metagovernance influence over Curve gauge weights, which can boost CRV incentives on Aave-related pools and create a virtuous flywheel for aToken liquidity and TVL.— MatthewGraham, Dydymoon, 0x7751, JeanBrasse
- The initial $2M CVX allocation is too conservative; Aave should buy at least $5M worth of CVX upfront to clear voting hurdles immediately and gain broader governance influence (including over other protocols like Frax).— JeanBrasse, Dydymoon
- An Enzyme vault could solve execution, delegation, and operational concerns by letting Llama manage the portfolio under pre-defined risk controls without telegraphing every move or requiring a governance vote per transaction.— 0x7751
- General enthusiasm for finally putting the treasury to work and expanding this approach to other markets like Polygon and Avalanche.— capncook, oneski22, Donzo
Arguments against
None surfaced.
Unresolved concerns
- Allocating 94.4% of the treasury with over two-thirds concentrated in Convex creates significant smart contract and counter-party risk, and insurance options (e.g., Nexus Mutual) cannot cover deployment at this scale.— fig, eboado, oneski22
- There is no clear governance framework for day-to-day metagovernance voting decisions—whether via full DAO votes, an internal committee, or a delegate like Llama—and what accountability structures (term limits, reporting, compensation) should apply.— fig, 0x7751, oneski22
- Long-term dependency on Convex is risky: as CVX/Convex yields potentially erode over time, unwinding a large, publicly visible position would be slow and market-disruptive, and the treasury could end up holding a large CVX position with only speculative value.— eboado, 0x7751
- The operational implementation plan is complex and lacks detail on which transactions require governance votes, who will execute them, and what security review process will be used for the underlying contracts.— eboado, 0x7751
- Fundamental skepticism about normalizing systematic governance bribing dynamics (à la Convex/Curve wars) as an appropriate strategy for Aave, versus simpler alternatives.— eboado
Notable participants
- MatthewGrahamCo-author of the proposal (Llama Community), laid out the full strategy and responded to technical questions.
- DydymoonCo-author of the proposal who engaged with feedback and agreed to increase the CVX allocation.
- JeanBrasseProposed increasing the CVX purchase to $5M and outlined the strategic rationale for larger governance influence.
- figRaised early concerns about concentration risk, insurance, and governance/voting process for metagovernance assets.
- oneski22Responded to insurance feasibility concerns and suggested a committee-based voting model similar to BadgerDAO/IndexCoop.
- eboadoRaised deeper concerns about long-term Convex dependency, market risk of CVX, and requested implementation/security details.
- 0x7751Representing Avantgarde/Enzyme, proposed a vault-based solution to address delegation, operational, and rebalancing concerns; followed up later without response.
- capncookSuggested extending similar treasury strategies to the Polygon market given multi-chain expansion of Curve/Convex.
- DonzoBrief supportive comment with no substantive argument.
Generated by Kvorum
08Similar proposals
- aaveexecutedConsolidate Reserve Factors and Enable Borrowing DPI100%
- aaveexecutedAave v2 ETH Interest Rate Curve Update74%
- aaveexecutedCRV Interest Rate Curve Upgrade74%
- aaveexecutedLower Reserve Factor for AMPL73%
- aaveexecutedAdding AMPL on AAVE71%
- aaveexecutedBUSD Offboarding Plan71%
- aaveexecutedUpgrade AMPL implementation71%
- aaveexecutedBUSD Offboarding Plan Part II70%
- aaveexecutedFix rate strategies issue on Aave v2 Polygon70%
- aaveexecutedBAL Interest Rate Upgrade69%