Risk Parameter Updates for Aave v2 Ethereum Liquidty Pool
01Summary
Llama and Chaos Labs propose disabling borrowing on 21 volatile assets in Aave v2 Ethereum while allowing deposits, as an alternative to AIP-121's more conservative freeze approach. This is a risk mitigation response to recent market events and liquidity contraction.
- Type
- parameter change
Key changes
- Disable borrowing on 21 reserve assets including YFI, CRV, ZRX, MANA, 1INCH, BAT, sUSD, ENJ, GUSD, AMPL, RAI, USDP, LUSD, xSUSHI, DPI, renFIL, MKR, ENS, LINK, UNI, and SNX(high)
- Retain ability for deposits on majority of reserves while restricting new borrowing(high)
- Unfreeze reserves if AIP-121 was previously executed, ensuring predictable final state(medium)
- Risk parameter adjustments for higher volatile assets in response to market contraction(high)
Notable concerns
- This is presented as less conservative than AIP-121's freeze approach
- LTV and LT thresholds for highly liquid assets will likely require amendment in near future via separate submission
- Proposal is contingent on handling potential conflicts with AIP-121 execution
Generated by Kvorum
02Description
Simple Summary
In response to recent market events and resulting discussion on the governance forum, Llama and Chaos Labs propose to make a series of parameter changes to the Ethereum Aave v2 Liquidity Pool.
Abstract
This proposal presents an alternative pathway forward to AIP-121. The community can elect to Disable Borrowing whilst retaining the ability to Deposits assets across the majority of Reserves rather than Freezing as outlined in AIP-121.
This proposal is a collaborative effort between Llama and Chaos Labs and reflects the communities governance forum discussion.
Motivation
In response to recent market events and the continued contraction of liquidity across markets, this proposal seeks to reduce the risk profile across many higher volatile assets. AIP-121 presents an opportunity to Freeze many Reserves, whereas this proposal intends to Disable Borrowing whilst retaining the ability to deposit assets.
AIP-121 is a more conservative response relative to this proposal. It is likely, LTV and LT thresholds for highly liqudity assets will also require amending in the near future. This will be managed via a separate submission.
Specification
The following risk parameter proposal are presented below:
Implementation
This proposal will reconfigure the following asset Reserves:
- YFI
- CRV
- ZRX
- MANA
- 1INCH
- BAT
- sUSD
- ENJ
- GUSD
- AMPL
- RAI
- USDP
- LUSD
- xSUSHI
- DPI
- renFIL
- MKR
- ENS
- LINK
- UNI
- SNX
This proposal is written in an atomic manner that will unfreeze reserves in case AIP-121 gets executed before.
To achieve this, freezeReserve(address asset), unfreezeReserve(address asset) and disableBorrowingOnReserve(address asset) will be performed via the PoolConfigurator for each asset respectively to ensure a predictable final state.
POOL_CONFIGURATOR.freezeReserve(address asset)
POOL_CONFIGURATOR.unfreezeReserve(address asset)
POOL_CONFIGURATOR.disableBorrowingOnReserve(address asset)
Implementation can be found here
Copyright
Copyright and related rights waived via CC0.
03Mismatch analysis
The proposal follows the standard Aave v2 governance pattern: the on-chain proposal contains a single action that calls execute() on a dedicated payload/executor contract, which internally performs the granular reserve-level configuration changes (freezeReserve, unfreezeReserve, disableBorrowingOnReserve for each of the 21 listed assets) described in the prose. Because the decoded calldata only exposes this outer execute() call and not the internal bytecode logic of the payload contract, it is not possible to independently verify each individual freeze/unfreeze/disableBorrowing call against the description from the data provided. However, nothing in the available decoded data contradicts the description, the target is a single well-formed payload contract with zero ETH value (consistent with a parameter-change proposal, not a fund transfer), and this pattern is routine for Aave v2 risk parameter proposals implemented via separate payload contracts. Given the lack of visibility into the payload's internal calls, confidence is low, but there is no evidence of a mismatch, so the proposal is treated as consistent rather than flagged for a discrepancy that cannot be substantiated from the given calldata.
Generated by Kvorum
04Actions
- Target
- 0x53d3…570e
- Value
- 0 wei
- Function
- fallback()
- Arguments
{}- Calldata
05Tally
Summed from votes
06Voters
| Voter | Choice | % of total | Rationale | ||
|---|---|---|---|---|---|
| AF0xafda…3a6e | For | 97K | 14.95% | — | 4y ago |
| 070x0703…961b | For | 90.1K | 13.87% | — | 4y ago |
| DC0xdc1f…e432 | For | 90K | 13.87% | — | 4y ago |
| 620x62a4…816a | For | 81K | 12.48% | — | 4y ago |
| B80xb83b…cf5c | For | 80K | 12.33% | — | 4y ago |
| 550x55b1…f262 | For | 63.2K | 9.74% | — | 4y ago |
| DD0xdd45…4cc5 | For | 59.4K | 9.16% | — | 4y ago |
| B90xb933…8dd1 | For | 41.9K | 6.46% | — | 4y ago |
| B80xb8c2…4f87 | For | 19.2K | 2.96% | — | 4y ago |
| 160x1664…36d9 | For | 16.9K | 2.60% | — | 4y ago |
| 860x86c3…ff36 | For | 3.2K | 0.50% | — | 4y ago |
| 510x510b…9938 | For | 3K | 0.46% | — | 4y ago |
| 570x572b…3ea5 | For | 1.6K | 0.25% | — | 4y ago |
| 8D0x8dd6…f976 | For | 1K | 0.16% | — | 4y ago |
| B80xb82e…35ab | Against | 826.6 | 0.13% | — | 4y ago |
| FE0xfe99…b14d | Against | 171.2 | 0.03% | — | 4y ago |
| B60xb6d8…8f54 | For | 140.3 | 0.02% | — | 4y ago |
| 580x58d0…5798 | Against | 116.2 | 0.02% | — | 4y ago |
| EA0xea17…6676 | For | 36.8 | 0.01% | — | 4y ago |
| A30xa3e2…d200 | Against | 36.7 | 0.01% | — | 4y ago |
| A00xa0ef…2d56 | For | 8.3 | 0.00% | — | 4y ago |
| 2F0x2fe1…975e | For | 4 | 0.00% | — | 4y ago |
| C50xc5ab…44de | For | 3.7 | 0.00% | — | 4y ago |
| FB0xfb43…8554 | For | 2.2 | 0.00% | — | 4y ago |
| AD0xad7a…f871 | For | 1.5 | 0.00% | — | 4y ago |
| 770x77ce…f42a | For | 1.4 | 0.00% | — | 4y ago |
| 380x382c…be0c | For | 1.1 | 0.00% | — | 4y ago |
| 320x3270…77fa | For | 1 | 0.00% | — | 4y ago |
| E50xe539…5708 | For | 1 | 0.00% | — | 4y ago |
| 9A0x9a37…ea65 | For | 1 | 0.00% | — | 4y ago |
| 060x064f…f2fb | For | 0.8 | 0.00% | — | 4y ago |
| 0D0x0d9d…9ff1 | For | 0.6 | 0.00% | — | 4y ago |
| 2C0x2cd3…5133 | For | 0.6 | 0.00% | — | 4y ago |
| 8F0x8fc6…3246 | For | 0.6 | 0.00% | — | 4y ago |
| 460x4606…5a6f | For | 0.5 | 0.00% | — | 4y ago |
| 8E0x8ee3…3148 | For | 0.5 | 0.00% | — | 4y ago |
| C00xc04a…9a11 | Against | 0.5 | 0.00% | — | 4y ago |
| 890x89d9…8978 | For | 0.4 | 0.00% | — | 4y ago |
| 400x40f4…85f7 | For | 0.4 | 0.00% | — | 4y ago |
| 4E0x4ee8…9a26 | For | 0.3 | 0.00% | — | 4y ago |
| 910x9188…c834 | For | 0.3 | 0.00% | — | 4y ago |
| E20xe225…b754 | For | 0.3 | 0.00% | — | 4y ago |
| D40xd41c…6666 | For | 0.3 | 0.00% | — | 4y ago |
| 470x4712…ac60 | For | 0.3 | 0.00% | — | 4y ago |
| 0D0x0d95…2392 | For | 0.2 | 0.00% | — | 4y ago |
| D20xd260…b1b6 | For | 0.2 | 0.00% | — | 4y ago |
| 610x615b…be40 | Against | 0.2 | 0.00% | — | 4y ago |
| 980x98be…d2c5 | For | 0.2 | 0.00% | — | 4y ago |
| 7D0x7d2e…6f47 | For | 0.2 | 0.00% | — | 4y ago |
| 3F0x3f8e…34be | For | 0.2 | 0.00% | — | 4y ago |
07Forum
- [ARC] Risk Parameter Recommendations for Aave V2 ETH (2022-11-22) ↗discourse · high confidence
Arguments for
- Freezing long-tail assets provides immediate risk mitigation across multiple attack vectors without triggering liquidations of existing healthy user positions.— Pauljlei, MarcZeller, kakagri, lbsblockchain
- The CRV attack demonstrated that traders are willing to risk substantial capital unprofitably, fundamentally changing the security threshold and justifying a more conservative approach.— Pauljlei, tarun, Alex_BertoG, lbsblockchain
- Freezing tail assets that represent only ~5% of V2 TVL but pose disproportionate risk is a reasonable tradeoff to de-risk the protocol ahead of V3 migration.— Pauljlei, fig, lbsblockchain, kakagri
- V3's risk controls (supply caps, borrow caps, isolation mode) will enable more granular and safer management of these assets once deployed.— Pauljlei, MarcZeller, fig, lbsblockchain
- Freezing avoids the need for broad reductions in liquidation thresholds on major assets like USDC/DAI, which would trigger liquidations and harm healthy users.— Pauljlei, omergoldberg, tarun, lbsblockchain
Arguments against
- A blanket freeze is overly conservative and lacks surgical precision; disabling borrowing on volatile assets while keeping supply side intact is more proportionate.— eboado, Llamaxyz, TokenBrice, Figue
- The root cause of the CRV attack was excessive USDC liquidation threshold (89%), not the presence of CRV itself; lowering major asset LTs is the more targeted fix.— eboado, TokenBrice, tarun
- Freezing assets like stablecoins (GUSD, LUSD, USDP) and assets without borrowing enabled is unnecessary given their lower inherent risk and peg mechanisms.— eboado, monet-supply, TokenBrice, michwill
- Freezing may harm Aave's perception and competitiveness in DeFi by signaling weakness compared to competitors and reducing protocol adoption.— Figue, DTBAEE
- Freezing tail assets without addressing the underlying risk parameter issues on major collateral is incomplete and doesn't solve the systemic problem.— eboado, stani, michwill
Unresolved concerns
- Whether reducing liquidation thresholds on USDC and DAI is necessary and, if so, what magnitude of reduction balances risk mitigation against user liquidations.— eboado, omergoldberg, yaron
- Unclear what the community's actual risk tolerance and security budget should be for tail assets going forward, which should guide parameter decisions.— tarun, Alex_BertoG
- Whether disabling borrowing (less conservative) versus freezing (more conservative) is the appropriate response, given disagreement among risk providers and the DAO.— eboado, Llamaxyz, Callen_Wintermute
- Lack of clear timeline for V3 Ethereum deployment, making it uncertain how long V2 assets will remain frozen and whether migration incentives will work.— fig
Notable participants
- PauljleiGauntlet risk analyst who proposed the initial freeze of 17 long-tail assets and provided detailed risk rationale throughout discussion.
- eboadoBGD contributor who provided detailed asset-by-asset risk analysis and pushed back against the blanket freeze, advocating for more granular parameter adjustments.
- tarunGauntlet principal who clarified the security budget framework and justified the freeze as preferable to across-the-board LT reductions on major assets.
- LlamaxyzRisk provider who acknowledged over-conservatism in the initial proposal and led effort to develop an alternative 'disable borrowing' proposal as middle ground.
- omergoldbergChaos Labs analyst who quantified liquidation impacts of LT reductions and proposed consensus parameters to disable borrowing instead of freezing.
- MarcZellerAave core contributor who supported the proposal as conservative risk mitigation and opportunity to encourage V3 adoption.
- monet-supplyCommunity risk analyst who identified specific stablecoins (GUSD, USDP, LUSD) with strong peg mechanisms that may not warrant freezing.
- AaveLabsCore team that signaled support for community-led risk response following the CRV incident.
- staniAave co-founder who ultimately voted for the freeze proposals while acknowledging merit in a more granular alternative approach.
- bgdlabsBGD team that provided technical clarity on V3 deployment timeline and governance proposal execution mechanics.
Generated by Kvorum
08Similar proposals
- aavedefeatedRisk Parameter Updates for Aave v2 Polygon90%
- aaveexecutedRisk Parameter Updates for Aave V2 ETH Market (2022-11-22)81%
- aaveexecutedChaos Labs V2 to V3 Migration Next Steps80%
- aaveexecutedRisk Parameter Updates for Aave V2 AMM Market (2023-03-31)80%
- aavedefeatedRisk Parameter Updates for Aave V2 AMM Market (2023-03-29)80%
- aaveexecutedRisk Parameter Updates for Aave V2 ETH Market (2022-11-12)78%
- aavedefeatedFreeze Aave V177%
- aaveexecutedFreeze Aave V177%
- aaveexecutedAllow Emergency Admin to freeze on Aave V277%
- aavedefeatedFreeze stETH, Increase stETH Liq. Threshold to 90%, Pause ETH Borrowing76%