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

Governance
1

TL;DR

Given the current market situation and past events (e.g. CRV bad debt), we want to start a discussion about the protocol’s access control, permissions, and procedures for both Aave v2 and v3, in order to improve reaction speed under threats.

Opening for discussion the idea of having faster levers (e.g. Aave Guardian or some type of Risk Council) to change non-invasive risk configurations, in order to react swiftly under urgent circumstances.


Context

Currently, both Aave v2 and part of the v3 instances (those where possible) are controlled via the on-chain Aave governance system. This means that any type of change on assets, codebase, and parameters on each Aave liquidity pool instance, needs to go through an on-chain vote to be approved.

This is intended by design, in order to have a fully decentralized system on which AAVE holders have direct and factual control over everything in the ecosystem.

In practice, it is well known that this generalization over all types of permissions is not completely efficient, and the time delay created by governance (currently on Aave, minimum of ~5 days) sometimes creates a “lock” situation: a potential risk is unfolding, multiple people of the ecosystem know about it, but there is generally nothing to do.

As an example, having a “faster” mechanism on Aave v2 Ethereum would have allowed disabling borrowing on CRV, which almost surely would have reduced the bad debt to 0.

Even if this is more of a community ethos/governance/risk-management decision and not so much technical (our scope), from BGD we think it is important to initiate a discussion around the topic, especially making clear for the community that things can always be improved tech-wise if there is will for it.


Permissions on the Aave liquidity protocol

The system of access control/permission on Aave is not completely straightforward, due to the high customization/power of the protocol, and other aspects like having upgradeable components.

We will be releasing pretty soon a tool to give some extra transparency around all permissions of the Aave ecosystem, but for now, we will focus the discussion on the Aave v2 and Aave v3 sets of permissions, and what can potentially be improved in the really short term.

Aave v2

In what affects the Aave liquidity protocol, and slightly simplifying, the main smart contract managing access control on Aave v2 is the so-called PoolConfigurator, for example, the one for Aave v2 Ethereum HERE

Through this contract, the interactions allowed are:

  • Doing the basic setup of listing a new asset: connecting the necessary smart contracts for the listing (a/v/s Tokens) and misc components like the incentives controller or the collector.
  • Update implementations of aTokens, variable/stable debt Tokens. For example to add some new functionality or fix any bug.
  • Enable/disable borrowing of an asset of the pool (also stable borrowing only).
  • Change the collateral configurations of an asset. Liquidation Threshold, Liquidation Bonus and LTV.
  • Activate/disable an asset. Meaning delisting; only possible if the activity on the asset is null.
  • Freeze/unfreeze an asset. Meaning disabling supplying and borrowing liquidity of the asset, keeping all other actions available.
  • Change the interest rate strategy of an asset. Meaning modifying the dynamics of borrow rates, like changing the so-called “slopes”, and determining the acceleration of the rate after points of inflection of utilisation.
  • Change the reserve factor of an asset. Percentage of the borrowing rate “redirected” to the Aave collector as fees of the protocol.
  • Pause the whole pool. Not enabling any action, to be used only if a major threat affects the system, given that liquidation would be also disabled.

Apart from the permission on PoolConfigurator, it is also important to highlight the one to add/change oracle feeds for assets, but generally, the holder of this is exactly the same as with the previous ones.

Currently, the split on who holds the permissions on v2 instances is pretty simple:

  • An instance of the Aave Guardian (a multi-sig of elected community members) holds permission to pause the whole pool. This is the entity assigned with EMERGENCY ADMIN role.
  • Everything else is controlled by the Aave governance Level 1 (short) executor, controlled via voting by all AAVE holders. This is the entity assigned with POOL ADMIN role.
  • Only 1 entity can have the same role at the same time (but this can be potentially changed).

So for example, in the scenario of CRV, the options were:

  1. pause() the whole protocol “fast” by mobilizing the Aave Guardian. Completely sub-optimal, as the consequences on all other assets are uncertain.
  2. Pass a proposal to reduce somehow risk parameters of assets (e.g. CRV, USDC), disable borrowing, freeze, or any other measure.

Aave v3

Aave v3, as with almost everything else compared with v2, is a way more complex and customizable system, including granularity of permissions.

Interactions are still managed through a PoolConfigurator contract, but there are both more roles defining who has control over what, and it is possible to have multiple parties holding the same role.

Regarding interactions, v3’s are a superset of v2’s, with exactly the same levers as v2, plus:

  • Enable/disable an asset to be borrowable in isolation mode.
  • Set the debt ceiling for a collateral in isolation.
  • Enable/disable an asset for siloed borrowing.
  • Set new supply/borrow caps.
  • Change the liquidation protocol fee, taken as a percentage of the liquidation bonus.
  • Create a new eMode category.
  • Add/remove an asset to/from an eMode category.
  • Update the bridge protocol fee.
  • Update the flash loan fees.
  • Pause/unpause 1 asset, affecting all the positions containing it (different to v2, where the whole pool gets paused).

Currently, and simplifying the cross-chain governance aspects, the direction of the community is relatively similar (emergency admin for extreme measures, pool/risk admin for periodic ones), but with important possibilities already enabled on the codebase:

  • The system has at the moment 4 roles, that can be given to multiple entities: EMERGENCY ADMIN, POOL ADMIN, RISK ADMIN and ASSET LISTING ADMIN.The functionality each one of them controls is also quite granular, and something that can be customized really easily by a technical party. This granularity was introduced to 1) start with automation on smart contracts for different changes, giving temporarily/permanently the required role/s to them 2) as more professional parties onboard for contributions to the community, potentially having a “fast-track” procedure for limited functions (e.g. risk control).

A potential model. Example of Risk Council

As presented in the previous section, Aave v3 has already a quite powerful system of permissions in place, to adapt to any need of the community regarding the liquidity protocol. Aave v2 is behind in functionality, but we can affirm that adding some extra granularity of permissions is potentially doable if really required short term.

From our point of view, there is no step back decentralization-wise on having a fast mechanism (e.g. Aave Guardian or some different Risk Council formed by knowledgeable community members/entities) for certain procedures, especially if these are limited via smart contracts to only be able to execute actions that can’t really produce any harm in the system or its users (not affecting ever negatively their positions), but that can really make a big difference in threatening and urgent scenarios.

Examples of those actions are:

  • Set LTV to 0 on Aave v3. Factually reducing the “borrowing power” of a collateral asset to 0, but not affecting over-collateralization anyhow.
  • Disable borrowing on an asset.
  • Freezing an asset (disable supply and borrowing).

For the community to have a more precise example (only an example!), this could look like the following:

  • An Aave Risk Council is formed via governance approval.
  • 5 members, each one provably independent and without any conflict of interest, contributing only for the sake of a common good like the Aave protocol.
  • A high understanding of Aave and DeFi is required, especially from an economic perspective.
  • At least 2 members with also high understanding of the technical aspects of the protocol.
  • Extremely high availability is required, with immediate replacement if not fulfilled.
  • The Council would be represented on-chain with a multi-sig smart contract (e.g. Gnosis Safe). This multisig would receive the non-invasive permissions described in the previous section.
  • To proceed with any action, 3-of-5 signatures are required. Always with justified reasons, even if not agreeing.
  • By approving the Council initially, the Aave governance would authorize them to act on the limited set of actions at their discretion, with the goal of being as fast as possible under threat. If for security reasons the Council can’t disclose the actions in advance (highly probable), the full rationale of the decision should be disclosed whenever possible to do it in a responsible manner.
  • Every 6 months, the Council’s performance is evaluated via on-chain governance, and potentially members are rotated.
  • The ultimate goal is helping the community, so only really compromised and professional individuals and entities can be considered. Even if some type of compensation can be considered, it is probably wiser to look for members not motivated by it.
  • At any point, the Aave governance has the power to remove all permissions from the Risk Council multi-sig. In addition, all the changes that can be executed by the Risk Council can be executed by the Aave governance too.

Next steps

Given that the potential effort on this is not really technical, but more on establishing a framework of procedures and defining which type of party would have special permissions, we request the community to participate in the discussion and propose different models, using the example of the Risk Council as a base.

From BGD, we will help with all technical aspects if a decision on this direction is taken.

17 Likes
2

Thanks for putting forward the proposal. Would be favour with a Risk Council across all V3 markets (details can be nailed down as the idea gets more support).

Things that would like to ensure is that the work of the risk council includes on-going automated and manual monitoring and weekly reports on how different market conditions (taking actions as well) have been changing backed by verified data, analysis and simulations.

Risk Council should also preferrably be distributed across multiple time-zones and the Risk Council should be incentivized accordingly.

Would also recommend to have a “risk strategy” smart contract between Risk Admin and the Council ensuring that the community can also vote on-chain between how wide mandade to give to that role on-going basis.

Transparency is also a key - Risk Council should agree and publish policies up-front as well to the community.

I also consider that the community should create new procedures for the Emergency Admin role/function including fire-drills and also availability - such role should also be incentivized accordingly.

This idea could be developed further as Ethereum V3 market is getting closer to release.

9 Likes
3

Hi @bgdlabs - we welcome this early discussion.

This Risk Council seems to pave its way towards a future RiskDAO and further unites the community.

I am glad to see @stani’s support - and willingness to establish greater controls, transparency, and incentives. If the community decides this is the best path forward, I would be happy to volunteer.

Some quick qualifications:

  • reviewer at Aave Grants DAO ( ~1-year tenure)

  • delegate for Aave DAO

  • 1/8 ‘Regulars’ on the forum

By supporting this initiative, it establishes around-the-clock coverage, improving communications across different visions, users, and organizations servicing the DAO.

If the community decides on a different direction, it should be to empower more stakeholders.

But the past few days have illustrated the need to reach a consensus decisively - and with vigor.

7 Likes
4

We (Morpho Labs) are in favor of this proposal. If the scope of the role is clearly defined, and it is operated with maximum transparency, it would be a good addition to security of Aave protocols.

2 Likes
5

Generally very much in favor of this proposal.

Regarding incentivization, I’m a bit conflicted.

In the end I guess at least a subset of the members of such a “risk council” should probably be somewhat related to the ppl doing risk and already being engaged with the dao(like gauntlet/chaos) and they are already paid by the dao for monitoring risk - it’s just giving them new means of action. The other members probably should be technical enough (to grasp risk & be part of a multisig), but I wouldn’t expect them to be “constantly monitoring” - so their job is more “validating & signing”.

3 Likes
6

Chaos Labs fully supports this proposal and sees great value in creating mechanisms to act fast and mitigate immediate risk to the protocol in extreme scenarios. As we have seen this past week, a timely response is crucial to protocol security, and waiting for full DAO coordination may not be possible.

As risk management contributors to the protocol, Chaos Labs would be eager to partake in the formation and ongoing management of such a Council under the terms of our engagement and would not expect additional consideration in doing so.

The example outlined by BGD is a great baseline for the proposal. There are a few important points we would like to highlight and provide thoughts around:

  1. We believe the risk council should comprise of the parties/individuals with the most intimate knowledge of the protocol and security expertise. It is natural for these to be current contributors to the protocol, who are also already incentivized for their work. In addition, any other experts from the Aave community members should be able to nominate themselves or others as participants in such a council.

  2. There are two types of actions that we believe the Risk Council should be empowered to take:

    • High impact, high urgency : These are actions similar to last week, where there is a high confidence security threat, and immediate steps need to be taken to protect the protocol and user funds. These actions must be considered temporary and only an immediate first step to allow the community to make knowledgeable and un-rushed decisions on the most appropriate long-term path forward.

    • Low impact, incremental changes : Thus far, the Aave DAO has had to vote on any parameter change for any market regardless of significance. We would propose that the Risk Council have the ability to make incremental parameter changes that fit well-defined, DAO-approved criteria (i.e., no users are liquidated, total change is <X%, 30-day change is <Y%, etc.) without the need for snapshot and on-chain voting.

  3. Decentralization - the Risk Council must be formed by governance vote, electing the council members and deciding on the actions they are authorized to perform. We agree with the proposed 6-month cadence for on-chain votes to evaluate and make changes to the council and its mandate.

  4. Communication and transparency: While the actions are taken directly by the Risk Council, it is imperative that they are communicated on a regular cadence to the community to ensure transparency in the thought process and implications:

    • Any parameter change decision is communicated via the forums within [48]-hours of the council’s decision and implementation

    • Any High Urgency change is to be communicated via the forums once the situation is safe for clarity and future protocol direction, with a community call scheduled for that same week for further discussion and feedback

    • Risk Calls - as part of our engagement, Chaos Labs committed to leading monthly risk calls for the community - we would hope that members of the Risk Council would take an active role in these calls and be available for community Q&A

We suggest that the council’s first order of operation upon creation should be to share a charter with the community for ratification on the limits of their powers, the authorizations, and communications guidelines with the community.

3 Likes
7

This is a really great proposal.

I agree with the strategy of using a 3/5 multi-sig.

I think some good contenders would be: Gauntlet, Chaos, Llama, BGDLabs, Morpho and/or Fig.

My only question is how much should they be paid – this will depend on their scope. If they are high impact / high urgency only, then probably less, but if they are low impact, incremental decisions (what Chaos is proposing), then probably more.

What Chaos is proposing in this thread is that low, impact incremental changes also fall under the scope of the Risk Council – I think this probably makes sense assuming that the changes fit very well-defined, DAO-approved criteria and the changes are communicated on a transparent basis (the current state of affairs is that governance is bogged down with parameter changes that take too long to change and usually always get 100% “yes” rate). Any DAO vote should override the Risk Council’s decisions.

2 Likes
8

Hi @bgdlabs,

Glad to see such a proposal in the forum and I am in full support.

In response to @VonNeumann & @OriN, I would disagree that Chaos or other contracted parties to the DAO should be part of the Risk Council. My view is aligned with the statement provided by BGD:

The Risk Council should be briefed by the risk contributors (Chaos, Gauntlet) and other contributors (BGD, Llama, Aave Companies) and then based on the information presented execute the option that they as the Risk Council believe is in the best interest of the Aave protocol (Like @sakulstra mentioned: "job is more validating & signing).

My only concern is finding 5 members of the community with such knowledge who are already not contributors to the DAO in some form or another and have no conflict of interest with other DAOs.

In support of @fig being the first member of the risk council.

My view on the next steps:

  • Define the risk council’s constitution, role & responsibility
  • Define the compensation model (If there should be one)
  • Define KPIs for the risk council
  • Call for applications & community interview process
  • Vote on the inception of the Risk council and the details.

Look forward to seeing this topic progress.

3 Likes
9

Low impact, incremental changes

I think the risk council should probably have no rights to do this. Errors happen, but are hard/impossible to spot when omitting public procedures. A change of 0.5bps can lead to liquidation and when not going through governance ppl have literally no time to prepare.

I think it should be very carefully evaluated which actions the council should be able to take.

1 Like
10

hello Aave DAO.

i’d like to nominate @sakulstra for the role

watching.

1 Like
11

Hello voicing my support for the Risk council.

As part of half a gazillions multisig, some of them very efficient and some the complete opposite, I strongly suggest not selecting the members of the risk council with a “beauty contest” election, it’s not about giving the role to your favorite guy. it’s about giving the role to someone that will show up and sign even on a sunday at 2am because the protocol needs it.

Strongly suggest :

  1. at least redundancy on ppl that can create tx on their own and prove good knowledge of Aave architecture
  2. ppl with track records of being good multisig signers.

Let’s not replicate the Aave guardian V1…

making myself available for the role if the community has an interest. I have deep knowledge of Aave contracts & good experience in multisigs.

6 Likes
12

Do we believe existing community guardians should be members of the risk council? This will result in community guardians = risk council IMO (if that’s the case guardians should become part of the risk council).

13

I’d personally like to see it move away from strictly community Guardians to encourage more stakeholders to become involved and create added diversity.

Marc would be a strong addition - as would @sakulstra on this council.

1 Like
14

Thx for the support, but I don’t want to be nominated.
Due to personal reasons, I won’t be very responsive/active in the coming months. Also, I don’t have any experience in regard to risk.

That said I’d happily support the nomination of @MarcZeller. Had the pleasure to meet him in Paris two years ago and he’s a quite driven guy with a deep understanding and curiosity for all things blockchain. Also, he’s very active on the forums & not shy to share his opinion on things which imo is a big plus.

5 Likes
15

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
16

Chaos is fully aligned with @bgdlabs and is excited to see this come to fruition. We would be honored to participate alongside our fellow external DAO contributors.
We separately fully endorse @Alex_BertoG as a strong, risk-centered candidate. Chaos Labs has had the pleasure of working with her and the rest of the risk team at @AaveLabs over the past few months (especially since onboarding) and have consulted with them on different proposals and methodologies. Alex has always been super collaborative and has an excellent understanding of risk in all versions of the Aave protocol. She will be a great asset to the risk council and community at large.

4 Likes
17

Given the limited power of the Aave Guardian in both V2 and V3 (especially in V2 where its impossible to pause only 1 single reserve), having a separate entity allowed to enact “special” actions is really valuable for the Aave community and users.

I see a gap between Aave Guardians and Risk Contributors, that can be filled with a “Risk Council” entity.

Such an entity is an enhanced more-powerful version of the Guardian, with the right of executing a set of actions to mitigate potential risks in certain situations. This entity has a good understanding of the protocol and space, is well-connected and acts as a point of contact in case there is a vulnerability or risk vector that puts in danger the Aave Protocol (could play an important role in a Bug Bounty).

However, I believe is crucial to define some guidelines so its work does not overlap with other. Some questions that come to my mind that I would love to see clarified:

  • Which powers would this entity have?
  • Under which circunstances this entity would take action?
  • Which steps would it need to follow in case of taking action on a matter?
18

In favour of creating a Risk Council for V3 pools. It does not make sense for me to have it for V2 because it is gonna be deprecated in a near future (it also works as an incentive for the users → better risk & emergency mgmt)

I do not think this council should provide a full-fledged service to the DAO (just taking actions with limited power under certain risky situations), because it would overlap with others contributors’ work and could jeopardize the decentralized nature of the DAO governance.

19

Hello Aave governance members,

I put together a proposal some time ago regarding a risk committee for the SNX DAO (which can be viewed here SIPs/sip-273.md at master · Synthetixio/SIPs · GitHub), and have viewed the discussion in this thread and would like to share some of my thoughts regarding the concept of a ‘risk committee’.

The problem space highlighted by OP involves the Aave protocol having the capability to make ‘faster’ changes to parameters in order to respond to rapidly changing ecosystem changes. This in itself is a worthy goal, however it should be noted that this is a different in essence to risk and it’s management.

I think what OP is really trying to describe is a organisational group that is empowered to react to changing ecosystems, where those changes are within a subset of the Aave risk appetite.

The topic of a risk committee, whos primary focus would be the development and application of a risk framework is a separate problem spaces which requires thorough consideration independently of the use case that OP, as its scope is much broader and implications further reaching.

20

@bgdlabs

Any update on this discussion?

With V3 live on Ethereum Mainnet it would be great to finalize the discussion and bring additional risk controls to Aave.