After conversation with @eboado regarding the listing of Avalanche assets on Aave, it appears that the Aave governance standards are not as closely adhered to for Avalanche proposals. These proposals see finality with the conclusion of Snapshot votes (and do not have a process similar to the 320K votes required to pass on-chain). With Aave seeing expansions to multiple chains, it is important to create a framework for these proposals going forward.
Summary:
The addition of Avalanche has brought with it specific governance processes that are not currently accounted for in the Aave governance framework. Currently, Snapshot votes are the âdeciding factorâ for proposals brought forth on the Avalanche chain, after which the vote is passed on to the Aave Guardians for implementation. In other cases (Ethereum mainnet) the Snapshot process is used as a platform for a community âtemp-checkâ, with passed proposals moving to an on-chain vote (AIP) afterwards.
Primary . Forum â Snapshot (lower requirements than on-chain) â on-chain governance Temporary . For all cases where for technical reasons Primary canât be applied yet. So Forum â Snapshot (strict requirements) â Guardian executing. Any proposal that doesnât fulfill the defined requirements on Snapshot, is automatically identified as Failed.
(eboadao)
Standard Snapshot guidelines (outlined by @MarcZeller below) should continue to be followed.
Rationale:
Due to the fact that the Avalanche proposals conclude with the Snapshot vote, it seems necessary to enforce a stricter Quorum. I recommend that the Aave community require 320,000 votes âYesâ (with a vote differential of 80,000 âNoâ) on Snapshot for all proposals on the Avalanche chain, and future chains that are not capable of cross-chain messaging. If this quorum is not met, the Snapshot proposal would be considered âfailedâ.
Thanks for bringing up a framework in the cases where cross-chain governance module isnât usable due to lack of messaging in bridges @raho . Using snapshot for these proposals makes sense, however we should definitely try to find a long-term solution where we are able to use the cross-chain governance bridge (maybe we would need to build Aave bridge across all networks). Snapshot vote would help for the time being to form a consensus. Stricter quorum makes also sense to give more comfort for the framework adoption.
Hello @MarcZeller, thank you so much for your response! I will update the post with these standards! These standards apply to all Snapshot votes, correct?
@stani thank you so much for responding! I completely agree with you, there should be a long-term solution in place for this, but I wasnât sure about what the engineering/resource cost of such a solution (building Aave bridge across all networks) would bring. In my own opinion, it would be a cost worth bearing for the sake of governance process (as that is what the Aave community depends on).
Do you by chance have more insight on what the cost would be to create such a bridge for on chain settlement?
Thank you again for your input :)
(Ps. Should I edit the ARC name to reflect that this would be a temporary solution?)
Some thoughts about this, apart from the ones I commented with @raho already.
All governance decisions, in practice, are not the same. We tend to differentiate them depending on the criticality of the system affect (with that, the division of long and short executors), but they are quite frequently heterogeneous in nature: listings of new assets (which criticality is not the same between v2 and v3), update of risk parameters, optimization of economic aspects like interest rates, engagements for work with external entities, funding of initiatives, etc. Still, having simple rules on the on-chain process is something good in my opinion, and that granularity should not be introduced in that layer. But I would not discard introducing that differentiation on the pre-chain phase (forum and Snapshot mainly), as it doesnât introduce so much complexity, and definitely adds value.
For example, I donât see much point in the need for Gauntlet to create a Snapshot (apart from the on-chain vote) for all proposals to update risk parameters. Considering that prior to submitting they are always announcing the change of the forum and open discussion for some days, for me extra Snapshot on that case is just an extra burden for everybody.
So I think maybe it is worth it to define some categories of proposals (not so many actually) and tweak the forum and Snapshot requirements depending on that.
What is pretty clear is that Snapshot kind of loses its filtering nature if, with no standard of quorum/participation/differential, proposals with 5-20k votes and small participation are considered as âsignaled positiveâ by the community.
Regarding cases like Avalanche. The problem on this is systemic: blockchains/networks are not inherently including any bridging infrastructure (in general). More and more we are seeing that even completely different teams are building bridging infrastructure, separated from the development of the chains connected. I think it is obvious that we canât depend on the time desync between the development of the base network where potentially Aave can be available, and the bridging infrastructure to directly control the deployment from Ethereum. So given that Snapshot covers pretty well the case in combination with the Guardian, I think the solution of exactly reproducing the on-chain requirements just works as a temporary solution on any chain until cross-chain governance can be applied.
I am skeptical of developing bridging infra-structure exclusive for the Aave governance. The use case is so narrow compared with the infrastructure development (important), that in my opinion only other bigger kinds of needs, not only governance, would justify it. Together with other projects doing it more specifically out there, Chainlink is in probably an advanced phase developing its CCIP protocol. Then the question will be about the time desync between these solutions and the chain itself too.
If defining a bit more granular rules (basically a more extensive governance framework) I think it is unavoidable for somebody of the community to take a stewardship role on it. Right now, that role is distributed between members of the community, but I donât think it is sustainable.
So as of next steps, I would suggest:
Gather for some more days some ideas from the community and discussion about them.
Define something relatively simple for cases like Avalanche, and also everything else concerning the different types of proposals.
Document in one place the everything, clearly; to be able to direct to only one source to anybody from outside the community looking to propose something.
reboosting this thread in an attempt to enforce a robust framework for future deployments of Aave.
firstly the current framework for V3 deployment adopted by the community is : Snapshot
this decision enforced:
Minimum delay of 5 days between Network governance proposal in the governance forum and creation of a snapshot vote
Minimum quorum of 150k AAVE votes to consider the proposal as adopted.
according to this framework, none of the snapshot votes to deploy V3 on new networks have reached quorum and should retry to do a snapshot vote to be considered valid.
With the evolving market conditions and the landscape of most EVM Alt-L1s, the optimism of âmulti-blockchain worldâ vision is facing some consolidation to most robust actors, also numerous bridge failures have bring spotlights on risks associated with deployment on new networks that are external to Aave intrinsic security.
it is proposed to organize a snapshot vote to reinforce the current framework using @raho parameters and considering community feedback in order to increase slightly the discussion delays to allow the community to discuss the risk/benefits of a deployment alongside the technical evaluation of the candidate network.
here are the proposed guidelines :
Vote should start 24h in the future
the governance thread related to the snapshot vote should be at least 10 days old
Vote should last at least 7 Days
vote should have at least 3 options (YAE/NAY/Abstain)
vote should reach a 320.000 YAE vote quorum with a differential of 80.000 NAE votes.
please consider that risks will always exists, and it should not be a an obstacle to innovation, Aave V3 will allow in the future to use the Portals feature to act as efficient bridges across network.
Aave being present on a diverse set of networks is key to the success of Portals and other Aave features, At the same time, risk should be carefully evaluated by the community and safety should always come first is a key part of Aave Ethos.
Thank you for bringing this discussion back to life! Iâd like to apologize to the community for my absence on this topic! If youâd like, I am more than happy to compile all of the ideas that have been contributed to this topic into a draft so that it can move forward to a Snapshot vote. If you or somebody else has already made progress on this, please let me know!
Thank you again for all that you do to ensure the safety of the Aave community!
We agree with @eboado that governance decisions are not all the same and that the governance process to update risk parameters should be streamlined.
As @raho and @MarcZeller stated, it is useful to align on governance processes for the Avalanche chain because currently, Snapshot votes are the âdeciding factorâ for Avalanche proposals.
Gauntlet proposes the below governance process specifically for updating risk parameters on Avalanche. The process is streamlined in terms of both time and quorum. We are referencing this proposal as precedent for quorum requirements, as it was a proposal to change risk parameters on Avalanche that was successfully implemented.
We welcome thoughts and discussion from the community.
Vote should start 24h in the future
The governance thread related to the snapshot vote should be at least 2 days old
Vote should last at least 3 days
Vote should have at least 3 options (YAE/NAY/Abstain)
Vote should reach a 200,000 YAE vote quorum with a differential of 80,000 NAE votes.
reviving this topic one last time as we failed to escalate the governance process to next governance steps.
I have no opposition to this proposal while being less conservative than initially proposed one:
If not clear opposition is stated in this thread in the next five days, the ACI will escalade to snapshot vote the @Pauljlei proposal to enforce this framework.