Great to see another phase from Bored Ghosts, one of the earliest service providers contributing to the Aave DAO, who have always been available whenever needed.
Leaving some feedback and my opinion:
-
Whenever there is a new smart contract upgrade to the protocol, it’s important to follow a deployment strategy that minimizes risk and potential surface impact. For instance, when an upgrade involves assets or accounting (e.g., the pools), the protocol can be updated first on a single network with low TVL, followed by subsequent deployments on multiple networks. Although we have seen successful upgrades across all networks in the past, and the BGD team is one of the most diligent teams I have worked with, there is always some inherent risk in these deployments. With the protocol now holding over $20B in net deposits, a standardized procedure for this should be adopted across all contributors. Similarly, networks that are not fully EVM-compatible (such as ZKsync Era) could warrant a separate deployment strategy, especially as the TVL on these networks grows.
-
Overall, I personally do not recommend too many changes to the existing V3 codebase unless these upgrades are necessary or involve clear security improvements (as we saw with recent upgrades). The stakes are too high to risk altering the deployed codebase with such significant TVL. From external point of view, any upgrades to the existing code base can be viewed as a risk surface.
-
Over the years, the community has worked with various auditors on the codebase, and while some have been great, it has been challenging to find consistency in the quality of the auditing work. BGD has done an excellent job sourcing new auditors and security engineers, which has been a significant improvement. However, as a community, we should continue investing in the protocol’s security, ensuring we work with auditing firms that not only demonstrate quality output but also have an established brand and a deep understanding of the Aave Protocol, especially for critical infrastructure. This is a challenge, as talent within auditing firms fluctuates, and we haven’t always been satisfied with past work. The number of (quality) auditors should increase as well as the stakes are increasing.
-
Regarding voting, this could potentially be moved to the Aave Network (which should also be ZK-based) when it becomes available. I am very supportive of this idea.
-
The bug bounty program could be entirely owned by the Aave community. It’s difficult to see the added value from ImmuneFi at this point. As I understand it, ImmuneFi has been helpful as a third party in reviewing submissions, but I believe there is enough trust within the Aave community and its core contributors to manage this directly.
-
Regarding Aave Stewards, I agree that governance delegation to specialized entities is very helpful, particularly when fine-tuning risk parameters or managing supply/borrow caps. However, as a community, we should also aim to move toward a permissionless approach and immutability over governance delegation where possible.
-
For security coordination, now is a good time to strengthen “offchain” security procedures, especially regarding the role of Community Guardians.
Supportive of the proposal, and BGD has been a great contributor the the Aave ecosystem.