Simple summary
With Aave v4 approaching mainnet release, we think it is valuable for the community to understand which existing Aave v3 tooling should be adapted to maintain similar quality standards across both protocol versions.
This post provides an overview of the tooling landscape and our recommendations for v4 adaptation, covering:
- Governance proposal infrastructure.
- On-chain helpers and testing frameworks.
- Security and risk monitoring tools.
- Peripheral infrastructure and user interfaces.
- Misc.
Context
Aave v3 has benefited from a mature ecosystem of tooling developed over the years, enabling high-quality governance proposals, security monitoring, and infrastructure management. As Aave v4 enters its final release phase, we believe it is the right time to evaluate which tools require adaptation.
Given the architectural differences between v3 and v4 (e.g., the Hub and Spoke model replacing v3’s monolithic design), some tooling will require substantial modifications, while other tools may need only minor updates or remain largely compatible.
Important.
- v4 support is not included in BGD Labs’s current scope of work; however, this document aims to provide visibility into what we believe is required, and in some cases, address ourselves some projects’ adaptations on a best-effort basis.
- Some of the linked repositories will undergo migration to the aave-dao organisation during the following days/weeks, but that doesn’t change any content of this report.
- Aside from what we propose for us to do on a best-effort basis, all other suggested owners can potentially be anybody else capable of delivering them, and in no case is our suggestion any type of mandate.
Adaptation plan
We have categorized the tooling into the following groups:
- Governance infrastructure: Repositories and patterns for protocol upgrades and proposals.
- Protocol helpers and tooling: Libraries and testing frameworks for building on Aave.
- Risk-oriented tooling: Tools for risk assessment and incident response.
- Peripheral/non-protocol systems: Treasury management, oracles, user interfaces, misc tooling, etc.
1. Governance infrastructure
1.1. Aave proposals
https://github.com/bgd-labs/aave-proposals-v3
Summary. Repository containing all Aave governance proposals with standardized structure, testing, and deployment scripts.
Adaptation effort
Recommendation. The existing structure should largely work for v4 proposals. Adaptations may include:
- New base contracts for v4-specific proposal patterns. But a good part of these belong to the Aave v4 codebase or aave-helpers if applicable, e.g., the
ConfigEnginepattern. - Updated imports and interfaces for v4 protocol interactions.
- Additional CI checks for v4 compatibility.
- CLI generator for Aave v4 proposals.
Suggested owner: @AaveLabs, already familiar with Aave proposals, and the entity that knows Aave v4 intricacies.
1.2. Aave Seatbelt
https://github.com/bgd-labs/seatbelt-gov-v3
Summary. Automated governance proposal analysis tool that provides “interpretation” of proposals, verifying their effects and identifying potential issues before execution.
Adaptation effort.
Recommendation. Should be adapted to interpret v4 as another Aave sub-system. This includes:
- Parsing and interpreting v4-specific function calls, parameters, and storage changes.
- Detecting v4-specific risk scenarios if applicable.
Suggested owner: For base work to have compatibility with another sub-system, @bgdlabs. For the specific interpretation of v4 itself, @AaveLabs, as it requires deep v4 knowledge.
2. Protocol helpers and tooling
2.1. Aave address book
https://github.com/bgd-labs/aave-address-book
Summary. Comprehensive registry of all Aave protocol addresses across networks, with automation to detect new deployments (e.g., newly listed assets).
Adaptation effort.
Recommendation. Address book should be extended to include:
- All v4 core contract addresses (Hub, Spokes, Position Managers, etc.).
- Automation to detect new Spoke deployments and asset listings.
- Clear separation between v3 and v4 namespaces.
Suggested owner: @bgdlabs .
2.2. Aave Helpers
https://github.com/bgd-labs/aave-helpers
Summary: Solidity libraries providing testing utilities, proposals’ base contracts, and helper functions for Aave development.
Adaptation effort.
Recommendation. This repository likely requires the most substantial work. Key adaptations include:
- Test helpers. Default (basic) test helpers for v4 proposals to verify basic flows (supply, borrow, repay, withdraw, liquidation) on any proposal affecting Aave v4.
- Helpers for visibility and diff of protocol-state snapshots (e.g. used on Aave Proposals).
- Proposal base contracts per network: New base contracts for v4 payload creation (e.g. AaveV3PayloadEthereumLido to target changes on the Aave v3 Ethereum Prime/Lido pool). Highly possible this pattern needs to be re-evaluated to be adapted to v4’s architecture.
- Treasury management: For peripheral infrastructure like treasury management, our strong recommendation is to reuse the current Collector contract regardless of whether v4 has its own mechanism. Any v4-generated fees should be redirected or periodically distributed to the existing Collector. If not going that route (or even if going that route), treasury management tooling should be modified to support Aave v4 accrued assets/fees while maintaining a unified treasury infrastructure.
Suggested owner: @AaveLabs , as it requires understanding of v4, and for the potentially optional treasury management components, @TokenLogic .
2.3. Aave CLI
https://github.com/bgd-labs/aave-cli
Summary. Command-line interface for Aave development workflows, including creating Tenderly forks with governance proposals passed.
Adaptation effort.
Recommendation. The main feature of clie (setup forks with governance proposals executed) should be agnostic of Aave v3, v4, or any other sub-system, as it operates at the governance/fork level rather than protocol-specific logic.
Suggested owner. @bgdlabs .
2.4. Aave CAPO
https://github.com/bgd-labs/aave-capo
Summary. Development, testing, and deployment of CAPO price oracle adapters of any type.
Adaptation effort.
Recommendation. While the core logic and algorithms should be compatible, v4 has some differences in oracle integration that should be evaluated and addressed if affecting.
This adaptation may already be completed by Aave Labs, as mentioned on December’s update.
Suggested owner. @AaveLabs .
2.5. Aave Permissions Book
https://github.com/aave-dao/aave-permissions-book
Summary. Documentation and mapping of all Aave protocol permissions and access controls.
Adaptation effort.
Recommendation. The repository should be adapted in the following way:
- Add base support to another sub-system of Aave.
- Define and implement the discovery of permissions itself for v4 (different architecture, different roles).
Suggested owner. @bgdlabs .
3. Risk-oriented tooling
3.1. Aave risk agents
https://github.com/bgd-labs/aave-risk-agents
Summary. Automated risk monitoring agents that can execute predefined actions in response to risk conditions.
Adaptation effort.
- The tool should not require any specific adaptation; it is more about developing news agents for v4.
Recommendation. If desired by the DAO, new risk agents specific to v4 should be added, and any adaptation will be pretty ad-hoc depending on the new agents themselves.
Suggested owner. @AaveLabs for new v4 agents, but if there is some infrastructural requirement globally on the repository, we, @bgdlabs, can help on that.
3.2. Aave Proof of Reserve (Avalanche bridged assets only)
https://github.com/bgd-labs/aave-proof-of-reserve
Summary. System for verifying backing of bridged assets, with automatic freeze/LTV-0 mechanisms when discrepancies are detected.
Adaptation effort.
Recommendation. The proof of reserve algorithm (verifying bridged assets to Avalanche) should remain largely the same. However, the freeze and LTV-0 mechanisms are slightly different in v4 compared to v3, requiring adaptation of the emergency action contracts.
Suggested owner. Being a matter of changing the interaction component, @AaveLabs, knowing which are the appropriate emergency mechanisms to apply on v4 (freezing effects, maybe dynamic risk configuration, etc).
4. Peripheral/non-protocol sub-systems
4.1. GHO Direct minter
https://github.com/bgd-labs/ghoDirectMinter
Summary. Contracts enabling direct GHO minting into an Aave pool with specific governance-controlled parameters.
Adaptation effort.
Recommendation. Possibly, not requiring adaptation if GHO is one of the initially listed assets on Aave v4 and Aave Labs already handled the direct minting process.
Suggested owner. If required, @AaveLabs, giving that adapting the tool boils down to changing the way of applying the pattern in Aave v4.
4.2. Aave Umbrella
https://github.com/aave-dao/aave-umbrella
https://github.com/aave-dao/aave-umbrella-scripts
Summary. The new Safety Module system allows users to stake aTokens to cover potential deficit (bad debt) on Aave v3 while earning rewards.
Adaptation effort.
Recommendation. Applying Aave Umbrella has been a concern of Aave Labs during the development of v4, so we assume the adaptation plan will be pretty clear at release time.
Our initial suggestion is to try to apply very similar patterns as on the existing Umbrella (e.g., with tokenisation), but that design decision is up to the developers of v4.
Suggested owner. @AaveLabs, we can provide any feedback regarding the design decisions on the current Umbrella.
4.3. Aave Umbrella UI
https://github.com/aave-dao/umbrella-ui
Summary. Aave DAO’s user interface for the Umbrella system.
Adaptation effort. (Highly dependent on the final approach of Umbrella in v4).
Recommendation. If the Umbrella system for v4 is highly similar to v3’s in terms of user flow (tokenisation, stake/cooldown/redeems steps, data), it should be doable to adapt the current Umbrella DAO UI to cover v3 and also v4.
If the system is relatively different, our suggestion is to have a separate standalone user interface, but still respecting the principle of being fully DAO-owned.
Suggested owner. On the first path with high compatibility, @bgdlabs. On the second path with lower, @AaveLabs.
4.5. Aave debt swap adapters
https://github.com/bgd-labs/aave-debt-swap
Summary. Smart contracts for swapping debt positions between assets on Aave v3
Adaptation effort. DEPRECATED.
Recommendation. Given the migration to CowSwap of the Aave interface, we assume this tool is effectively deprecated and does not require v4 adaptation.
If the community requires the tool, support can always be added by contributing to the repository.
Suggested owner. N/A.
Summary table
| Project | Adaptation Effort | Suggested Owner |
|---|---|---|
| Aave proposals | MEDIUM | @AaveLabs |
| Aave Seatbelt | MEDIUM | @bgdlabs (base), @AaveLabs (v4 interpretation) |
| Aave address book | MEDIUM | @bgdlabs |
| Aave Helpers | HIGH | @AaveLabs , @TokenLogic (treasury) |
| Aave CLI | LOW | @bgdlabs |
| Aave CAPO | MEDIUM | @AaveLabs |
| Aave Permissions Book | MEDIUM | @bgdlabs |
| Aave risk agents | MEDIUM | @AaveLabs (new agents), @bgdlabs (infra) |
| Aave Proof of Reserve | LOW | @AaveLabs |
| GHO Direct minter | LOW | @AaveLabs |
| Aave Umbrella | HIGH | @AaveLabs |
| Aave Umbrella UI | MEDIUM-HIGH | @bgdlabs or @AaveLabs (depends on compatibility) |
| Aave debt swap adapters | DEPRECATED | N/A |
Next steps
We will reach out to the involved parties potentially involved in the adaptations, and we encourage other contributors doing maintenance of DAO-owned tools missing from the list to reach out to us, to keep that infrastructure in mind and add to the list.