Writing in this case as co-founder and one of the leaders of @bgdlabs, not only as an Aave community member.
The conversation has derailed from the topic at hand, which is not beneficial for the goal of this thread.
Therefore, I want to outline what we will do from BGD as the next steps, and reduce our participation to answer any questions regarding what is included in the proposal itself:
-
Early next week, we will create an ARFC Snapshot vote for people to pre-approve v3.4, which is the same as usual. Important, this stage is not the activation of Aave v3.4 in production, but a soft approval for us to proceed with final review, security, and setup steps.
The community can vote against for whatever reason, thats the point of a decentralised organisation. But a clear negative outcome will signal that we should not proceed at all with v3.4, also that the community simply doesn’t trust our base criteria on v3.4 being a good upgrade for Aave. Because let’s be clear, the ARFC stage (not the activation even) on a proposal by an engaged service provider, on a process that has been made multiple times in the past, is also a vote of trust on our work, or the opposite. -
If the vote is positive on Snapshot, we will proceed with the usual security and quality control procedures, engaging third-party auditors and/or organising security contests. Aside from Certora, which is engaged by the DAO, we choose the appropriate ones, negotiate the budget, and cover it before the AIP refund.
During this period, we are happy for anybody with proper credentials, like the case of @Emilio, to review the code if desired, give feedback, or suggest anything of importance.
This should be done obviously via appropriate channels like Github, as this forum is not the place.
And similar to any third-party review, as code owners, we always decide what makes sense to include, what not, changes to do, and changes not to do. Needless to say, nothing will be moved to an on-chain proposal if any finding has any indication of creating problems, but us not having final decision power on our proposal is exactly like any other team developing a system → engaging some auditor, and the auditor dictating what should be finally done or not; it is nonsense, and will not happen as we simply can’t do our work like that. -
Finally, after all security procedures are cleared, we will proceed with an on-chain AIP. Code be 100% public before this stage, audit reports too, and the magic of a decentralized organisation is that people can just take their AAVE → call the governance contracts, and approve the factual upgrade, or not.