ARC - Greenlight Aave Sagl (the company) to do certain types of changes without having to go through the AIP process

Let’s greenlight the company behind Aave to do any of certain types of changes without asking for community approval first! Without going through the AIP process, without even polling for sentiment. It’s a waste of time for most types of decisions. At this stage, it’s better for us if we iterate faster. We can always revoke this decision later.

As long as the changes improve the protocol, the UI/UX, or the APY of staked AAVE, do we really threads for stuff like:

  • new markets (of course, we’ll vote Yes on any new market, we want more volume and composability)
  • risk parameters
  • UI/UX of aave.com
  • … (what else?)

I repeat, the big advantage of approving this AIP will be that we’ll move faster than competitors. I’ll formalize the proposal after we get a discussion going. I’m especially curious on which types of decisions they could take by themselves; they could chime in with a list themselves.

2 Likes

I forgot to add a poll. It doesn’t show who voted what, therefore do not worry about your privacy.

  • Yes, let’s do this!
  • No.

0 voters

Feedback that I agree with from Discord, related to this AIP:

Having governance for every single decision is never going to work any way. Has to be targeted.

1 Like

Perhaps we can circumvent this without having to deal with centralizing governance. As it stands, I believe your proposition essentially gets rid of the entire purpose of a DAO.

We need to get to the point where we can efficiently churn out proposals, votes and executions. Maybe what we’re missing is a system of vote delegation, so we can delegate to prominent contributors!

4 Likes

Right now, there’s an AIP that we’ll vote for in order to have AAVE as collateral. We can expect a lot more of these bullshit decisions if we don’t greenlight Stani’s team to make certain types of decisions automatically. @stani or @MarcZeller, can you please propose the types of decisions that could be included in this greenlight?

We could also set a timespan for it, for example November 1, 2020 to the end of 2022.

Technically speaking, the next update of the protocol would have the ability to delegate votes to other addresses. This means that anyone can delegate to whom they might fit to vote on their behalf. That is something that can help technically if such objectives are required.

Currently the Aave Protocol is open-source and runs autonomously on Ethereum. If there is any significant changes, these should go trough governance decision making especially if it involves incentives. It’s important that there is wide decentralization and mandate to cover this decision making by the token holders as they are end of the day bearing the risk of the protocol.

However, governance does not need to be slow or inefficient, this means that there should be many various topics open for discussions and those topics that are more progressed could progress to a formal proposal accordingly to the AIP framework.

What could be important is to set different kind of minimum thresholds of various voting topics such as assets listings, small protocol upgrades in the future and incentives changes, for example what would the minimum voting period be set. This might provide the needed flexibility to AIPs and their progresses.

One of the things that takes time is usually configuring the payload to correspond the execution of a voting outcome or might be an external factor (for example in case of listing AAVE, the price feeds by Chainlink was recently set as the asset was available on multiple market venues).

I guess the bigger question of this thread is as @Laur pointed out: what kind of actions or ideas we could come up with to keep the agile progress on AIPs without compromising the security/diligence of code deployment and ensuring that there is due process in voting. Would definitely like to hear more opinions on this topic.

This topic is especially important since I would imagine in the future that there are multiple different stakeholders participating in the risk assessment of the protocol assets, contributing to the codebase and other works as well.

4 Likes