Decentralizing Aragon's governance: Possible first steps

[luis]

Goals

• Start transitioning Aragon’s governance from a highly centralized model to a more decentralized one
• Experiment with community participation while still ensuring the safety of the project
• Document and formalize this new process so governance stakeholders can be kept accountable

Description

Right now the governance of the project is fairly simple:

Using the following components, I propose an structured process to start decentralizing governance:

• The Survey app, which lets the DAO query ANT holders with non-binding votes
• The Finance app, which lets the DAO keep track of finances and propose new transactions
• The Voting app, which lets ANT holders vote on binding votes (such as approving or proposing new transactions in the Finance app)
• Frame, which lets anyone vote using hardware wallets

Let’s divide governance decisions into two groups:

• Binding: Governance decisions taken by stakeholders are automatically enforced by code or legal contracts
• Non-binding: Governance decisions taken by stakeholders are not automatically enforced by code and need humans to actually perform the outcome desired by the stakeholders

Since this is a proposal for kickstarting decentralized governance, we still need to keep safety measures in case any possible attack or malfunction happens in the governance system or voting mechanism.

That’s why I would like to propose a mechanism in which:

• The Aragon Association (previously called Foundation), the legal entity that has power over the project, still has power to make governance proposals
  • Either proposes to perform a direct action (like spending funds, or updating legal terms)
  • Or proposes to appoint some entity (a delegate) that will act in behalf of the project (like appointing someone to manage the grants program or the social media channels)
• But ANT holders have power to veto those proposals
  • If ANT holders veto a delegate nomination, the Association must propose different delegates
  • If ANT holders veto a proposal, and it’s clear that there has been an attack on the voting mechanism, the Community Multisig could veto the veto as a last resort

So there would be four types of governance decisions:

• Binding

  • With direct veto
  • With veto over delegate nomination

• Non-binding

  • With direct veto
  • With veto over delegate nomination

Now let’s jump into the actual proposal for decentralizing governance over each component.

Nest grants

Binding, with direct veto over its funding and veto over delegate nomination

We can transform the Nest grants program into its own DAO.

The funding of that DAO would work as follows:

• Nest would have a yearly budget approved by the Association
• The Association would create the transaction to fund the Nest DAO
• ANT holders could veto it

And its governance:

• The Association would propose delegates who would run the program for a year
• ANT holders could veto the proposal

Funds

Binding, with direct veto

Thanks to the split between the Association and the development teams, the Association will perform a few monetary transactions per year, therefore making it possible for ANT holders to have direct veto power.

Examples:

• Giving out a sizable grant to an Aragon development team
• Sending money to the Nest grants program

Social media, Aragon Chat

Non-binding, with veto over delegate nomination

• The Association would propose delegates to run the social media accounts and maintain the Aragon Chat for a year
• ANT holders could veto the proposal

Repositories

Non-binding, with veto over delegate nomination

• The Association would propose delegates to maintain the repos
  • Repos would be software repos but also include the multiple websites that are statically hosted
• ANT holders could veto the proposal

Next step would be to make this a binding proposal by using Pando.

Legal terms

Binding, with direct veto

• The Association would propose versions for
  • The Trademark Policy, that lays out how to use the Aragon brand
  • The Licensing Policy for significantly changing the licenses of the software or content
• ANT holders could veto the proposal, in which case they would remain unchanged

In order to make this binding, the Association would sign a legal agreement stating that it will adhere to the results of the votes for updating or not updating these legal docs.

Technical implementation

This would be achieved by deploying a DAO (Aragon Governance DAO) with:

• A Finance app and a Voting app, for binding decisions

  • The Voting app should require high enough parameters in order to really gauge community discontent. This could be:
    • 25% quorum, so 1/4 of ANT holders would have to vote
    • 51% support, so more than half of the votes are required for a veto to happen

• A Survey app, for non-binding decisions

  • We would need to state the amount of votes that we would consider for a veto
  • As the app is multi-option, each delegate could have its own option, so holders could veto one of the delegates but not the others
    • We could say that in order to veto a delegate, 10% of ANT are required to veto

• Describe some unsolved problems or points of discussion, if there are any.

Uncertainties

As with any token-based voting mechanism, there can be perverse incentives so holders want to veto proposals for their short-term benefit. I believe this is mitigated by making veto the first step, and not full control, therefore giving the Association the power to propose.

Also this should be seen as a transition state, until we have the research and experience in place to give ANT holders full control over the Aragon Governance DAO.

[lyricalpolymath]

without entering into the argument about which properties or restrictions (binding, non-binding) would be appropriate for a certain type of action (choosing delegates, budget allocations etc)

I think that if you map out the possible options in this decision space you will see that there is a larger gamut of options that ANT holders (or any other actor in this game) can play.

I think a visual system helps also in classifying and making it more understandable for the user / participant what things are possible and what (currently) aren’t.
These are some initial thoughts…and while writing this I already see some of the imperfections and improvements but I want to get it out there

Sorry for the long image (I had to hack the restriction for only one image)

1- Mapping the Decision space
this is just an idea, but was inspired by the fact that in your proposal @luis you seem to only offer the possibility to veto, while the community could also propose and vote (that I’m considering as the !veto, the opposite of veto, although probably the opposite of veto is to actually dictate that an action be executed)
Let’s consider Veto = negative only Vote
and a Vote = negative and positive choice

2- To bind or Not to bind
this is a digital variable so I’m guessing that in an analogue space can be represented by either

• a closed lock = binding
• an open lock = non-binding

3- the 6 possible governance actions
from this emerges that there is a greater variation of possible actions that ANT holders (or any other actor in the governance game) could take

This simple matrix could be used to visually and quickly explain inside of a context (for instance allocating budget for the NEST projects) what ANT holders can actually do or not.
If adopted across all apps it could become a quick explainer of powers

of course I understand that there are contexts and phases in which you want to start with “restricted power” and only allow to veto certain things.

what do you think?

ps Maybe I should post this under another post but I was inspired by yours

[stellarmagnet]

Luis, I really like this proposal - I think it’s a good step in the direction of decentralization. While it will be important at one stage to consider community proposals, I think that will consume a lot of leadership time, so it makes sense to utilize veto process in these early stages when a lot of work still needs to be done, and minimizing attack vectors is important, so removing the proposal process does simplify things as you test out decentralized governance.

The main thing that came to mind was thinking about bad actors that may want to ‘attack’ the system by purchasing a lot of ANT and doing vetos.

How about restricting addresses that can veto only to ones who have been regularly participating in other votes in the ecosystem (such as surveys)?

You can do it something like:
Addresses who vote in at least 50% of surveys for the past x months get special non-transferable voting tokens (equal to their balance of ANT). if their average goes below 50% then their voting tokens become burned. You need to maintain a 50% voter participation average over past X months. Only these non-transferable tokens/addresses can do vetos.

[David.ibt]

I like that idea of preventing veto-attacks.

I’m thinking in a mechanism that prevents both veto-attack and de-facto veto powers from a really big ANT holder. Please correct me if I say something senseless

ANT holders in order to be voters, must lock-in their tokens for a period of time. The more time you are willing to lock your tokens, the more votes they represent .

Veto power would only be granted to those who are willing to lock for a period of, let’s say, 6 months.

I believe this desincentivizes bad behaviour (or short term profit over long term project survival).

[lkngtn]

@David.ibt

ANT holders in order to be voters, must lock-in their tokens for a period of time. The more time you are willing to lock your tokens, the more votes they represent

I think using time-locking as a critical part in voting structures is a really useful and promising area of research to explore and experiment with. Its pretty close to the idea of Quadratic Vote Locking (a variation of Quadratic Voting where instead of burning votes you simply lock tokens instead).

I do think though that the nice thing about @luis original proposal is the simplicity of it. It allows ANT holders to have a meaningful role in governance with very little risk (both social and technical).

It seems reasonably safe to try, as the main concern that has been brought up is essentially the idea of a weak version of a 51% attack, where the attacker could veto everything and essentially DOS the network if they have 51% of the voting stake. I’m not sure how big a concern that should actually be, but a simple preventative measure would be allow the community multi-sig to override a community veto, similar to how it is currently used as a last resort in the current process.

[David.ibt]

I agree that simplicity here is crucial, at least until the system demonstrates to works with no flaws. Also to minimize risk in the first step towards decentralization.

For the Voting app, at least a 25% of TOTAL supply of ANT tokens must vote? It seems to be like a really high community engagement. Did I understood this correctly? If this minimum is not achieved, decisiones can’t be made, or they just can’t be vetoed?

[lkngtn]

For the Voting app, at least a 25% of TOTAL supply of ANT tokens must vote? It seems to be like a really high community engagement. Did I understood this correctly? If this minimum is not achieved, decisiones can’t be made, or they just can’t be vetoed?

If the quorum is set at 25% that would mean 25% of total supply. I agree that is probably quite high and might be difficult to reach given typical levels of voter participation. With a support percent of 50 percent, it means that a minimum of ~1/8 of total stake would have to actively disagree with an action for it to be successfully vetoed by the community.

My interpretation of the proposal was that decisions would go through unencumbered after allowing a period for a veto to occur, so in the event that the quorum/support was not reached for the veto the action could still be taken.

Given such a situation, it seems reasonable to assume that some of the proposals might alter the initial support/quorum requirements – so if 25% is too high to be meaningful it could be lowered based on data of actual participation rates.

[luis]

I love this decision space! I actually had a draft in my notebook that was very similar, although yours is much better structured and adds the possibility for the community to propose, which I think could make sense for some situations. I will think about how to incorporate your feedback back into the draft!

EDIT: After revising my first draft, I think that it may be a bit early to introduce the “propose” option into the option matrix. I think after seeing how participation plays out, it’s the next natural step to let the community propose, but I worry it may be a bit overkill before even knowing participation rates

[luis]

I think that makes a lot of sense. Having the Community Multisig override some decisions could mitigate that vector attack. Will add that to the draft!

[luis]

Exactly, I think that we could lower those parameters if we see that there’s no participation. I think that being a veto and not a vote, it is important that the parameters are high enough in order for veto to happen only if the community is very discontent. We also don’t want to fall into the tyranny of the very vocal minority!

[GriffGreen]

Wow! This is exciting! The Aragon DAC will make a huge effort to help test and implement a lot of this!

[lkngtn]

Was thinking a bit about what it would take to implement a dao-kit for this process. Currently its not particularly intuitive how such a process could be constructed using available applications as building blocks. However, the following configuration could be created by employing multiple instances of the token manager and voting applications.

Veto-able Voting Configuration:

• A total of two tokens are assigned. 1 to an entity that has veto priveleges (such as a separate instance of the voting app controlled by ANT holders), and 1 to an entity controlled by a party that is making proposals.
• The permission to create votes is only given to the entity that is allowed to make proposals.
• Support required is 51%, and minimum quorum is set to 50%

This configuration allows the proposal to pass a proposal so long as the vetoing party does not veto, because with just the proposer a proposal will have 100% support and 50% quorum, and if the veto is used there will be less than 51% support.

If we want the community multisig to have the option to step in, the parameters would need to be a bit different.

• A total of three tokens are assigned. 1 to an entity (such as a separate instance of the voting app) controlled by the party that has veto privileges, and 1 to an entity controlled by a party that is making proposals, and 1 to an arbitrator (such as the community multi-sig)
• The ability to create votes is only given to the entity that is allowed to make proposals.
• Support required is 51%, and minimum quorum is set to 33%

If only the propose votes, they will have 100% support and 33% quorum, if the veto is used there will be only 50% support and 66% quorum, and the arbitrator (community multi-sig) effectively has a swing vote.

This type of configuration is a bit unintuitive, and it may make sense in the future to have an application specifically designed for adding Veto steps in a complex governance process, but its nice to know that the existing applications can be used to support this process today!

[luis]

This makes a lot of sense. I think next step would be to formalize the proposal, unify my initial post with your “product spec” and release that as an AGP to the community.

[jorge]

Very interesting scheme @lkngtn. I think given how vetoing and delaying actions before they are executed are a general building block that could be used in many other governance processes, we should build an Aragon app that does that. The base for both delaying and vetoing would be the same, as veto requires a time delay to allow for the veto to take place.

[luis]

Totally agree. I think @jvluso already built the contracts for it https://github.com/BlockRecover/aragon-delay-app

[buchasur]

ANT holders in order to be voters, must lock-in their tokens for a period of time. The more time you are willing to lock your tokens, the more votes they represent .