ARC: Governance Framework For Alternative Chain Proposals

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’.

3 Likes

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.

2 Likes

thanks a lot @raho

This was definitly needed.

I’ll add a few things to the proposed standard :

  • Vote should start 24h in the future
  • the governance thread related to the snapshot vote should be at least 5 days old
  • Vote should last at least 3 Days
  • vote should have at least 3 options (YAE/NAY/Abstain)
2 Likes

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.
2 Likes