Improve permissions management on Aave v2 and define a better strategy for access control roles on Aave v3

Given the Risk Council idea seems to have found support in the community, we would like to highlight some aspects we consider fundamental around it and its potential formation:

  • The actions to be executed by the Risk Council require specific expertise on the mechanics (especially risk) of the protocol. Nobody without such knowledge should probably be considered because it totally removes its utility. This is not trying to dismiss the contributions of community members but seems reasonable given the task.

  • This Risk Council has in practice no relation with the Aave Guardian. The Aave Guardian is just a technical and temporary mechanism used given the lack of enough technological infrastructure to for example bridge decisions of the Aave community to other networks. Its members are just volunteer signers that only execute actions pre-approved by the Aave governance in advance.
    This means that members could overlap or not from our perspective, just depending on expertise.

  • We highly recommend having entities currently engaged with the DAO on the risk side (partially or totally) as parts of the Council. It doesn’t seem reasonable to precisely not use the most expert resources available for the community on it.

  • The Council should probably have a minimum of 4 members and a maximum of 5/6, at least regarding signers.

  • From BGD we are open to advising (and will do) the members of the council from the technical side, as usual, reviewing the actions before execution, together with implementing additional smart contracts and need mechanisms, for example, to automate actions. But we don’t think it is appropriate to be part of the Risk Council itself, as risk is not our expertise.

From our perspective, a reasonable initial set of members could be:

  • 1 representative from each risk-specific entity engaged with the Aave DAO, or with risk-related scopes (e.g. Llama).

  • ACI via its representative @MarcZeller . Contributing to Aave since v1, we think the expertise of ACI/Marc is clearly proven.

  • @Alex_BertoG (if willing to). Part of the risk team of @AaveLabs and a quite active member of the community, giving feedback to multiple forum proposals and initiatives.




We think the different further scopes and organizational topics should be defined by the Council, once selected by the community.

10 Likes