# \[ARFC\] BGD. Aave v3.7 **URL:** \ **Category:** Development\ **Created:** [February 16, 2026, 10:52am UTC](https://governance.aave.com/t/arfc-bgd-aave-v3-7/24075 "2026-02-16T10:52:22Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![bgdlabs](https://dub1.discourse-cdn.com/flex013/user_avatar/governance.aave.com/bgdlabs/32/1829_2.png) [@bgdlabs](https://governance.aave.com/u/bgdlabs)\ **Post date:** [February 16, 2026, 10:52am UTC](https://governance.aave.com/t/arfc-bgd-aave-v3-7/24075/1 "2026-02-16T10:52:22Z")
![Aave v3.7](https://europe1.discourse-cdn.com/flex013/uploads/aave/original/2X/6/6f7bf35d5ebdd88ca7c48b3f0f5a962cb4419d44.jpeg) # Summary Introducing Aave v3.7, a new version of Aave v3 (currently v3.6) focused on non-invasive simplification of the protocol. It includes the following changes and features: - Simplification of eModes’ configuration, adding an `isolated` flag. - Removal of isolated collaterals and borrowable in isolation, features not useful anymore. - Removal of the L2 sequencer oracle. - Explicit removal of the flow to drop reserves, making the reserves list append-only. - Small improvements on liquidation calculations. - Multiple improvements/simplifications (not on-chain) of the codebase peripheral infrastructure. # Context On previous upgrades (v3.4/5, v3.6), we have commented with the community that, while future upgrades should not be categorically discarded, they will naturally be much smaller than previous ones, focusing on surgical changes and simplification oriented toward maintainability. v3.7 follows exactly that approach, being a smaller upgrade from code size and invasiveness perspective, and focusing on simplifying the protocol to its current and envisioned usage. We believe this is an important upgrade to reduce unnecessary maintenance overhead and modelling work. Especially considering that Aave will have three production protocols running in parallel very soon, with the upcoming v4. # Aave v3.7 changes ## 1. eMode `isolated` configuration Adding a new `bool isolated` flag on eMode categories, that when `isolated = true`: - Only assets explicitly listed in the eMode’s `collateralBitmap` contribute LTV. All other assets the user has supplied are treated as LTV-zero (they still contribute to the liquidation threshold and health factor, but cannot back new borrows). - Users with non-eMode collateral enabled cannot enter the isolated eMode — entry is blocked because those assets would become LTV-zero. - Users already inside an isolated eMode cannot enable non-eMode assets as collateral. ### → Motivation for the change In the current version of Aave (v3.6), eMode categories define a `collateralBitmap` that determines which assets receive the eMode’s enhanced LTV/LT parameters. However, assets outside the bitmap still contribute their regular (non-eMode) LTV. This means a user in an “ETH-correlated” eMode could still borrow against non-ETH collateral at the asset’s base LTV, defeating the purpose of the eMode’s risk isolation. The workaround in v3.6 is for governance to manually set `ltvzeroBitmap` bits for every non-eMode asset. Even if very explicit and functional, this is operationally burdensome: it requires an LTV0 of multiple assets on listing. The `isolated` flag solves this by automatically treating all assets outside the `collateralBitmap` as LTV-zero, removing the need for per-asset manual maintenance (but still allowing granularity via LTV0 on eMode). * * * ## 2. Removal of isolated collateral/borrowable in isolation configurations Aave v3.7 removes two configuration features introduced on v3.0: 1. **Isolation Mode** - Restricts users to a single collateral asset with a debt ceiling and limited borrowable assets 2. **Siloed Borrowing** - Prevents users from borrowing multiple assets if one was marked as siloed ### → Motivation for the change - No current need for those modes. - Siloed borrowing: never actively used in production. - Isolated collateral: very few assets configured with debt ceilings (across all networks, the majority of assets in isolation are LTV0), and no real need to do so by risk teams going forward, versus other mechanisms. - v3.6 (and v3.7 isolated eMode) introduces simpler mechanisms to achieve similar control. E.g., siloed borrowing can be achieved reproduced using borrowing enabled/disabled on eModes, while collateral isolation can be achieved in a similar way with eModes. - v3 codebase complexity reduction. Simplifies in a very non-invasive way multiple components of the protocol, using the validation logic where the main change resides. This translates into simpler auditability/maintainability and reduces the overall attack surface. - Simplifies the reasoning model and configuration levers for risk and growth providers. * * * ## 3. Removal of L2 sequencer uptime oracle This feature was used on some of the L2 deployments to check whether the L2 sequencer was online, and enforce a grace period to users after recovery, with the following: - Borrowing was blocked while the sequencer was down or the grace period had not elapsed (`isBorrowAllowed()`). - Liquidations were blocked under the same conditions (`isLiquidationAllowed()`), with a special exception: liquidations were always permitted when a position’s health factor fell below `MINIMUM_HEALTH_FACTOR_LIQUIDATION_THRESHOLD` (0.95), regardless of sentinel status. Both checks are removed. Borrows and liquidations now proceed without sequencer uptime gating. ### → Motivation for the change Historically, sequencer uptime detection on L2s has been very ad-hoc, with each network having different mechanisms and reliability characteristics for reporting sequencer status. This lack of standardisation led to infrastructure differences across deployments/chains, hence to high-maintenance overhead both on the Aave side and middleware like Chainlink, and to false positives. That is very problematic to the system because false positives can, in the worst case: - Block liquidations: allowed unhealthy positions to deteriorate further, increasing protocol risk during the exact moments when liquidations were most needed. - Block borrows: prevent normal user activity during periods where there was not really any issue on the network. In summary, our evaluation of risk versus value tells us that the right decision is to remove the mechanism, which, similar to other changes included in this v3.7, improves simplicity and auditability, while reducing the attack surface. * * * ## 4. Removal of drop reserve flow This includes the `dropReserve()` methods from both PoolConfigurator and Pool contracts, and logic _directly_ related to those. However, we keep untouched some (now redundant) validations across the codebase, as they really have no impact, but reduce the changes surface. ### → Motivation for the change The functionality to drop reserves has never been used, and there is no plan to do so. Also, we know it should enforce extra validations that are not currently in the code, and that we will not approve a governance proposal to use it without a deep review of the flow and security procedures. So factually, it is a non-active/deprecated part of the code, which we are making more explicit. This also adds value from the same angle as other features in this v3.7: simplification, as now the list of reserves will be append-only. * * * ## 5. Small precision improvements on liquidation Post v3.5 (adding directional rounding to the protocol), we detected some minor part of the protocol logic on liquidation that could be improved even further in terms of rounding, without being too invasive. These are included in this v3.7 proposal, with details to be disclosed once we finish our internal development/security evaluations. ### → Motivation for the change Improving the precision of the math in the protocol. * * * ## 6. Misc simplifications In parallel with (and outside of) numbered releases of Aave (but async to them), we do different maintenance tasks on non-core protocol components in the Aave v3 Origin repository. Aside from other minor changes, we have been doing the following high-level changes since the v3.6 release. - Some non-invasive [dependencies cleanup](https://github.com/aave-dao/aave-v3-origin/pull/169). - Archival from v[3 Origin of the Paraswap adapters](https://github.com/aave-dao/aave-v3-origin/pull/166), not used anymore in production. - Archival of the [RevenueSplitter contract](https://github.com/aave-dao/aave-v3-origin/pull/164), not currently used. - Simplification of the V3 ConfigEngine. ### → Motivation for the change General simplification of the Aave v3 Origin repository, to reduce global compilation time or reduce inconsistency on dependencies. Basically, a continuous improvement of maintainability. # Next steps 1. Create an ARFC Snapshot for the upgrade of all Aave v3 instances to Aave v3.7, after some days of discussion in this forum. 2. Advance on security procedures for v3.7. 3. On-chain AIP creation, for the Aave governance to upgrade all pool instances across all networks. ---
**Author:** ![bgdlabs](https://dub1.discourse-cdn.com/flex013/user_avatar/governance.aave.com/bgdlabs/32/1829_2.png) [@bgdlabs](https://governance.aave.com/u/bgdlabs)\ **Post date:** [February 24, 2026, 10:57am UTC](https://governance.aave.com/t/arfc-bgd-aave-v3-7/24075/2 "2026-02-24T10:57:59Z")
We have created the ARFC Snapshot for the approval of v3.7 in order to start external security procedures. Voting will start in approximately 24 hours, participate 👻 [https://snapshot.org/#/s:aavedao.eth/proposal/0x2cdd27eda22b36ddde2303c3d69859f74b330eb93661e632700d18c6095335a8](https://snapshot.org/#/s:aavedao.eth/proposal/0x2cdd27eda22b36ddde2303c3d69859f74b330eb93661e632700d18c6095335a8) ---
**Author:** ![bgdlabs](https://dub1.discourse-cdn.com/flex013/user_avatar/governance.aave.com/bgdlabs/32/1829_2.png) [@bgdlabs](https://governance.aave.com/u/bgdlabs)\ **Post date:** [March 3, 2026, 7:22am UTC](https://governance.aave.com/t/arfc-bgd-aave-v3-7/24075/3 "2026-03-03T07:22:20Z")
After the [pre-approval of the Aave v3.7 upgrade on ARFC](https://snapshot.org/#/s:aavedao.eth/proposal/0x2cdd27eda22b36ddde2303c3d69859f74b330eb93661e632700d18c6095335a8), we would like to inform the community that we will be starting the final security procedures this week. ---
**Author:** ![bgdlabs](https://dub1.discourse-cdn.com/flex013/user_avatar/governance.aave.com/bgdlabs/32/1829_2.png) [@bgdlabs](https://governance.aave.com/u/bgdlabs)\ **Post date:** [April 1, 2026, 5:14pm UTC](https://governance.aave.com/t/arfc-bgd-aave-v3-7/24075/4 "2026-04-01T17:14:12Z")
We would like to inform the community that all security procedures for v3.7 have now been completed, and the upgrade is nearly ready to be proposed to the DAO for activation in production. Same as on previous upgrades, the following is the list of resources for the community to have visibility on: - The Aave Protocol v3.7 codebase can be found [HERE](https://github.com/aave-dao/aave-v3-origin/pull/175). As always, this will be merged to `main` line if/when the Aave Governance approves and performs the upgrade on-chain from the current v3.6 to v3.7. - The codebase of the AIP itself performing the upgrade and everything surrounding can be found [HERE](https://github.com/bgd-labs/protocol-v3.7-upgrade). _Important. There could be minor changes before submission on-chain_. - The security procedures performed in the codebase have been the following: - All our (BGD) internal testing and evaluation, including making the Aave v3 fuzz suite compatible with v3.7. - Security review by [Certora](https://www.certora.com/) ([HERE](https://github.com/bgd-labs/aave-v3-origin/blob/97bc70d016a2da687c9dca30e4963fdd82288546/audits/2026-03-29_Certora_Aave-v3.7.pdf)) including review of the adaptation of formal verification rules of Aave v3. - Security review by [Enigma Dark](https://x.com/EnigmadarkLabs), [HERE](https://github.com/bgd-labs/aave-v3-origin/blob/97bc70d016a2da687c9dca30e4963fdd82288546/audits/2026-03-31_Enigma_Aave-v3.7.pdf). - Security review by [MixBytes](https://mixbytes.io/), [HERE](https://github.com/bgd-labs/aave-v3-origin/blob/97bc70d016a2da687c9dca30e4963fdd82288546/audits/2026-03-26_MixBytes_Aave-v3.7.pdf). - Security review by [Pashov Audit Group](https://www.pashov.com/), [HERE](https://github.com/bgd-labs/aave-v3-origin/blob/97bc70d016a2da687c9dca30e4963fdd82288546/audits/2026-03-27_Pashov_Aave-v3.7.pdf). - Supervised AI review by [Savant Chat](https://savant.chat/), [HERE](https://github.com/bgd-labs/aave-v3-origin/blob/97bc70d016a2da687c9dca30e4963fdd82288546/audits/2026-03-30_Savant_Aave-v3.7.pdf). - Supervised AI review by [Sherlock AI](https://sherlock.xyz/), [HERE](https://github.com/bgd-labs/aave-v3-origin/blob/97bc70d016a2da687c9dca30e4963fdd82288546/audits/2026-03-26_Sherlock_Aave-v3.7.pdf). _The governance proposal will include a budget allocation to cover performed audits for a total of $74,662._ * * * The next step will be to finalize the review procedures of the upgrade proposal and submit it to Aave governance for on-chain voting. Similar as with v3.6, considering the type of changes included, this proposal will be splitted in two phases, to be more conservative security-wise. More precisely, this is the networks included on each phase: - **Phase 1**. Sonic, Optimism, Gnosis, Scroll, Celo, MegaEth, XLayer and Ethereum (EtherFi). - **Phase 2**. Ethereum (Core, Lido), Polygon, Avalanche, Arbitrum, Base, BNB, Linea, Plasma and Mantle. ---
**Author:** ![bgdlabs](https://dub1.discourse-cdn.com/flex013/user_avatar/governance.aave.com/bgdlabs/32/1829_2.png) [@bgdlabs](https://governance.aave.com/u/bgdlabs)\ **Post date:** [April 15, 2026, 10:26am UTC](https://governance.aave.com/t/arfc-bgd-aave-v3-7/24075/5 "2026-04-15T10:26:36Z")
We have submitted to the Aave governance to vote on Phase 1 of the v3.6 → v3.7 upgrade, covering instances in the following networks/pools: Sonic, Optimism, Gnosis, Scroll, Celo, MegaEth, XLayer, and Ethereum (EtherFi). Voting will start in approximately 24h, participate 👻 [https://vote.onaave.com/proposal/?proposalId=473](https://vote.onaave.com/proposal/?proposalId=473) ---
**Author:** ![bgdlabs](https://dub1.discourse-cdn.com/flex013/user_avatar/governance.aave.com/bgdlabs/32/1829_2.png) [@bgdlabs](https://governance.aave.com/u/bgdlabs)\ **Post date:** [May 24, 2026, 8:33am UTC](https://governance.aave.com/t/arfc-bgd-aave-v3-7/24075/6 "2026-05-24T08:33:26Z")
After a delay requested due to the rsETH incident resolution by other contributors, we have now created the proposal for the Part 2 upgrade of all v3.6 pools to v3.7. More precisely, covering this time Aave v3 Ethereum (Core and Prime), Polygon, Avalanche, Arbitrum, Base, BNB, Linea, Plasma, and Mantle. Voting will start in approximately 24h, participate 👻 [https://vote.onaave.com/proposal/?proposalId=489](https://vote.onaave.com/proposal/?proposalId=489) ---
**Author:** ![MconnectDAO](https://dub1.discourse-cdn.com/flex013/user_avatar/governance.aave.com/mconnectdao/32/14398_2.png) [@MconnectDAO](https://governance.aave.com/u/MconnectDAO)\ **Post date:** [May 24, 2026, 3:24pm UTC](https://governance.aave.com/t/arfc-bgd-aave-v3-7/24075/7 "2026-05-24T15:24:23Z")
Thank you BGD Labs for the thorough security procedures and the phased rollout approach for v3.7. As a governance researcher, I appreciate the conservative two-phase deployment strategy it reflects responsible risk management, especially in light of the recent rsETH incident that delayed Phase 2. That kind of caution builds community trust. I’d like to add a few suggestions for consideration as v3.7 moves toward full activation: 1. Governance Visibility on eMode Changes The simplification of eModes’ configuration (isolated flag) and removal of isolated collaterals is a meaningful change for users and integrators. I’d suggest BGD or Risk SPs publish a clear migration guide or impact summary for protocols/users currently relying on these features, particularly on high-TVL instances like Ethereum Core and Arbitrum. 2. Post-Upgrade Monitoring Dashboard Given the append-only reserves list and removal of the drop reserve flow, a community-facing monitoring dashboard showing protocol health post-upgrade would increase transparency and allow delegates to track any anomalies early. 3. L2 Sequencer Oracle Removal Risk Acknowledgment The removal of the L2 sequencer oracle is noted. I’d recommend a brief public risk acknowledgment from the Risk SPs confirming that downstream L2-specific risk scenarios have been evaluated and mitigated through alternative mechanisms. 4. AI-Supervised Audit Disclosure I commend the inclusion of Savant Chat and Sherlock AI reviews this sets a strong precedent. For future upgrades, it would be valuable to clarify the scope and weight of AI-supervised reviews versus traditional audits in security communications. Looking forward…