Summary
Introducing Aave v3.6, a new version of Aave v3 (currently v3.5) including the following changes and features:
- Liquid eMode exclusive collaterals.
- Liquid eMode exclusive borrowables.
- Liquid eMode exclusive LTV0 behaviour.
- Introducing renounce functionality on aToken allowance & credit-delegation.
- Liquidating aTokens no longer enables them as collateral.
- Receiving aTokens via transfer no longer enables them as collateral.
- Aligning tokens with OZ approval flow event emission.
- Removal of
ISOLATED_COLLATERAL_SUPPLIER_ROLErole.
Context
Historically, the major “sub-versions” of Aave v3 have targeted different parts of the protocol. Sometimes, adding new features, others making architectural changes, others focusing purely on security, and others improving user or developer experience.
The following is a quick recap of the past versions proposed and applied in production:
- Aave v3.1. Infrastructural, very oriented to security improvements, with the introduction of virtual accounting and the deprecation of stable rate borrowing.
- Aave v3.2. Feature-rich, focusing on the introduction of Liquid eModes, which radically changed the usage and configuration of assets listed on Aave pools.
- Aave v3.3. Again, infrastructural, but this time focused on optimising liquidations and starting to account for bad debt accrued on the protocol (deficit).
- Aave v3.4. A bit of an exception, as it has a pretty good balance between UX/DevEx-oriented changes and infrastructure. The rationale is that, given the criticality of the liquidations component touched on in v3.3, we decided not to include certain features and optimisations we had in a very advanced stage of development and pack them together in v3.4.
- Aave v3.5. Again, infrastructural, but this time focused exclusively on rounding & precision.
Aave v3.6 doesn’t really introduce completely new mechanisms, but improves those added in previous upgrades.
Specifically, doubles down on the learnings from Aave v3.2 and introduces some changes that were originally omitted to reduce scope, for example, improving how risk parameters can be configured on assets.
Aave v3.6 features
1. Liquid eModes improvements
The majority of changes introduced in v3.6 are focused on improving the configuration workflows of liquid eModes.
On prior versions of the Aave protocol, the default reserve configuration always supersedes the eMode configuration.
In practice, this meant:
- For an asset to be collateral inside an eMode, it must be collateral outside as well.
- For an asset to be borrowable inside an eMode, it must be borrowable outside as well.
- If an asset is set to
ltv = 0on the reserve configuration, it would be considered asltv = 0inside the eMode as well, and LTV0 rules* would apply.
(*) On Aave v3 ltv0 assets are on one hand, as expected ltv = 0, but in addition to that some ltv0-rules apply:
ltv0assets cannot be enabled as collateral.ltv0collateral has to be withdrawn first. This means that if the position consists ofltv0and nonltv0collaterals, trying to withdraw or transfer the nonltv0collateral will revert.
While this current approach was the natural evolution of the 3.0 behavior, it also made certain scenarios impossible to configure. Currently, it is impossible to list an asset and make it:
- exclusively borrowable in some eMode.
- exclusively collateral in some eMode.
- cap exposure via LTV0 rules exclusively for usage outside eMode, or exclusively inside a specific eMode.
This limitation is artificial, and only exists because upgrades have historically been applied gradually with as minimal but impactful changes as possible. Therefore, in Aave v3.6, the next minimal increment is to remove this limitation.
On Aave v3.6, the reserve configuration no longer overwrites the eMode configuration. In addition to that, the eMode configuration was extended by an ltvzerobitmap that allows enabling ltv0-rules for a specific asset on a specific eMode.
→ Motivation for the change
The motivation behind this feature is two-fold. Firstly, it allows for more granular control, making reasoning about risk easier.
Secondly, it resolves some actual issues risk teams currently face:
- If they want to make an asset collateral inside an eMode only, they still need to enable it as collateral outside of eMode. So they configure it with a very low
LTas a workaround, which is not ideal. - If they want to make an asset borrowable only inside of an eMode, they still need to enable it to be borrowable outside of eMode. There is currently no workaround, which is the reason why some assets are borrowable, although there is no clear general use-case for it.
- Being able to flag an asset as
LTV0only in a specific eMode, or more importantly, only outside of it, can give great benefits in risk control and would have been useful in the past. We think that given that possibility greatly improves risk control while also providing a way to off-board assets from an eMode.
2. Changes in automatic collateral behaviour
2.1. Liquidate aTokens
Liquidating aTokens will no longer automatically enable the received asset as collateral.
On-chain observations show that the current behaviour was never relied upon, but significantly increases gas cost for the liquidators. Therefore, we decided to drop it.
Users who would want to liquidate and enable as collateral could still do so in a single transaction via multicall if desired.
→ Motivation for the change
The current behavior was flagged by various auditors on multiple releases of the Aave protocol, as it creates strange situations on paper: when a user fully liquidates himself, their excess debt will be counted as a deficit, but they will be left with the bonus accounted as collateral.
After checking on-chain data, we found that:
- No one ever relied on this behaviour.
- Liquidations become around 25k gas cheaper when removing it.
Given the gas-sensitive nature of liquidations, we therefore decided that simply dropping the behavior is the best course of action.
2.2. Isolated collateral supplier
In Aave V3.2, we introduced an ISOLATED_COLLATERAL_SUPPLIER_ROLE role for certain permissioned entities to deposit an isolated collateral and automatically enable it as collateral.
This was done from a conservative point of view to still allow the flow, but the feature was never actively needed/used, and increases gas cost and code complexity.
Therefore, in v3.6, isolated collaterals are simply not automatically enabled as collateral.
→ Motivation for the change
We checked on-chain data for usage and realized that the role was only ever given twice to the MigrationHelperMainnet and Legacy ParaSwapLiquiditySwapAdapter. While the first one still has some transactions, migrating only isolated assets is not a common use case. The second one has not been used for over two years.
Again, on-chain data revealed that there was essentially no usage. On the flipside, the feature increased gas cost for every single transfer, so we think it’s a very reasonable thing to remove it.
2.3. Automatic enable as collateral on transfer
When receiving an aToken via transfer, the receiver will no longer be automatically enabled as collateral.
In previous versions of the Aave protocol, a transfer would enable a received asset as collateral automatically if possible. On-chain analysis shows that for the vast majority of transfers, the enabling as collateral is usually non-intentional: the vast majority of users never borrow any assets against assets received on transfer.
By removing this feature, aToken transfers become a lot more gas efficient, which in turn has effects on the whole ecosystem, improving user experience in e.g., boosted pools.
All major integrations that rely on aToken transfers already handle the case of an asset not being enabled as collateral, as there are already edge cases in which the automation will not work (isolation & ltv0).
While v3.6 changes the behavior on transfer, supply/ deposit flows remain untouched, as we evaluate that path as more sensitive integration-wise.
→ Motivation for the change
The automatic enabling as collateral on transfer feature was causing unnecessary gas costs and was not being used by the majority of users. By removing this feature, transfers are becoming much more gas efficient(~18% or ~25k) and improving user experience in integrations that heavily rely on transfers (e.g., boosted pools).
We’ve been checking with major integrations, and there should not be any impact on them. The only occasion found was in a Defisaver contract, which the team confirmed they can easily adapt to the new behavior.
Our rationale for changing vs not changing is the following:
- The feature is rarely relied upon by users. The majority of interfaces & integrations work with the underlying and then use
deposit. - If integrations want to rely on this feature, they still can by using the position manager or deposit on behalf.
- The gas saving is significant (~18% or ~25k), transfers being the backbone of some other contracts (stataTokens & weth gateway) means the gas saving will be perceivable there as well.
- The code simplification is very significant.
Finally, there should not be any type of scenario where integrations have any major problem, given that any contract handling aTokens directly will definitely have an outflow path defined.
3. Renounce allowance
We introduce a new function renounceDelegation(address delegator) on the VariableDebtToken, as well as renounceAllowance(address owner) on the AToken. This way, any given integration can call these functions to “burn” excess allowance by setting borrowAllowance and allowance back to zero.
→ Motivation for the change
In the current state of the Aave ecosystem, it is quite common to have pending dust allowance for aTokens and credit delegation. This stems from the fact that a/v tokens are rebasing, and usually, it is not known exactly how much allowance will be needed at the time of execution.
To mitigate that, integrations are over-approving, which in turn lets the unused “dust” allowance hanging, something not really optimal security-wise for those integrators.
4. OZ alignment
The transferFrom function on AToken no longer emits an Approval event. This is a gas optimization that aligns with OpenZeppelin’s ERC20 standard implementation, where transferFrom is not required to emit an Approval event. The allowance is still correctly updated.
The _decreaseBorrowAllowance function on the DebtTokenBase no longer emits a BorrowAllowanceDelegated event. This change was made to align with the logic of OpenZeppelin’s ERC20 implementation regarding allowance updates. This reduces gas costs for operations that decrease borrow allowance, such as borrowing on behalf of another user.
The BorrowAllowanceDelegated event is now only emitted on explicit approval via approveDelegation or delegationWithSig, which is analogous to how the Approval event is handled in OpenZeppelin’s ERC20 contract.
→ Motivation for the change
The current behaviour was highlighted by multiple auditors in the past as not being aligned with most of the other contracts out there (most notably modern OZ). By removing the event emission, the code is better aligned with the rest of the ecosystem, while at the same time saving some (~2k) gas for integrations that heavily rely on transferFrom (e.g., all Paraswap adapters).
5. EMode Category label
The v3.6 upgrade does NOT change anything on the label configuration, but simply includes a deprecation notice as a soft deprecation. We highly recommend to update UI code to handle the eMode selection based on a different logic than the on-chain label, but the on-chain label will remain for the foreseeable future.
→ Motivation for the change
The eMode category label was first introduced in Aave v3.0. Over time, eModes have been extended via liquid eModes in Aave v3.2 and further improved in this Aave v3.6.
Emodes are now much more dynamic than they originally were; thus, the fixed label that is set on creation is starting to fall out of date. In addition to that, there now exist multiple eModes for the same subset of assets, making naming via a fixed label far more complex, as can be seen by the existing, often clashing, labels, with differentiation suffixes.
While eMode labels made sense initially, they no longer do. With growing adoption of liquid eModes, we’d like to encourage integrations to generate reasonable labels based on the configuration instead of relying on the on-chain naming.
Next steps
- Create an ARFC Snapshot for the upgrade of all Aave v3 instances to Aave v3.6, after some days of discussion in this forum.
- Advance on security procedures for v3.6.
- On-chain AIP creation, for the Aave governance to upgrade all pool instances across all networks.
