Hi everyone! Anthony, CEO of Aragon here. Really excited to see governance conversations opening up at Aztec, thoughtful governance is the cornerstone of successful organizations.
We’ve followed Aztec’s governance progress closely, especially after collaborating on a private voting prototype for Nouns and showcasing Aztec Governance on Aragon, The Return of the Jedi here in the forum in 2023, so it’s exciting for us to see the evolution toward this current proposal!
There’s a lot to digest. So i’ve provided some thoughts and some questions below.
Some thoughts:
One of the biggest painpoints in onchain governance has been using single onchain governance processes for making all kinds of decisions. Splitting proposal “types” into distinct “processes”, can help identify which of a project’s stakeholders need to participate, and with what degree of power, depending on the type of decision being made. If understanding the proposal correctly, it seems that all types of actions, whether it’s updating the Registry, Issuance, and Distribution all go through the same two stage process:
- Sequencer Vote (1 sequencer 1 vote)
- Token Vote (1 token 1 vote)
Should sequencers play the same role in issuance as they do in governing the rollup registry? Maybe it’s ok for them to, but I wanted to raise this as a potentially helpful way of reframing them as distinct problems that could have their own optimized governance solutions.
Another helpful framing that we have is thinking of processes as having distinct “stages”. Within each stage, there is a vote. If not, it’s a timelock. In context of this proposal, it could be misleading referring to stakeholders as merely “nominating” proposals. They are infact participating in a governance process, which will be followed up by a secondary stage led by token votes.
As an industry we have started to move away from 1 party governs all permissions in 1 way as it hasn’t been working. The great part is, we have now gotten to a point where we can provide more granular governance designs, onchain. This helps with user participation and decision making effectiveness.
Some more concrete feedback and questions:
-
Optimistic governance: Was was optimistic governance considered in order to help drive upgrades more expediently as a first step? Some L2’s we are working with for example have taken this approach, where token holders have full veto power in a second governance stage, but they don’t have to vote in the affirmative if they are satisfied with the proposal. This starts to approach the other idea floated in the thread around aborting a proposal by a re-vote. Doing so via token vote, from a voter participation perspective, seems like it could be too much to ask.
-
Indirect voting: Perhaps the idea is that voter participation will be driven more with the expectation is that the largest voter is in fact the rollup itself voting on behalf of the sequencers and their stake. This makes complete sense. However, has there been consideration around the potential aggregation problem and resulting preference meaurement loss when the rollup votes? If the rollup is unable to split its votes across yes and no votes as and EXIT_DELAY is too long for unstaking to vote in a specific proposal, token holders get their votes “pooled”. This could lead to results where <50% of the Hypothetical Assets owners (the “popular vote”) are able to reach a majority on the governing contract (due to the aggregation of sequencer tokens). Think districts and their effect on election outcomes.
-
Quorum definition: Seems also like there could be a small mixup between
quorumandvotingDifferentialhere: “Once a proposal garners the minimum number of votes, and the Yea votes exceed Nea by at least thequorum%" -
Double voting: There were a couple comments around how to prevent malicious votes with buying, voting, selling, etc. There’s several solutions for this, either with taking token balance snapshots upon proposal creation, more sophisticated proof-based solutions, or simply locking the token. Since the proposal actually includes locking, this shouldn’t be a threat, and I’m not understanding why there is a separately defined waiting period. The vote counting can simply be dependent on it being locked. For example, we’ve built an OSx governance plugin that can be configured in either way:
- Doesn’t let voters unlock until a proposal is over, so tokens can’t be double counted
- Let’s users unlock during the proposal, and double counting is preventing by subtracting them from the tally upon unlock.
Would love any feedback on any of the above to provide even more extensive feedback and thoughts.
Overall, we are obviously extremely excited about the future of Aztec and Aztec Governance as industry peers in privacy.
Thank you!