AGP23: Formalize ANT Holder Veto for Foundation Funding Proposals

[lkngtn]

Title: Formalize ANT Holder Veto for Foundation Funding Proposals Author: Luke Duncan and Luis Cuende Status: Draft Created: 2018-08-19

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

This AGP is related to a discussion on the research forum about possible practical first steps towards decentralizing the projects governance. At a high level this AGP would require the Aragon Association (formerly called the Foundation) to make proposals to ANT holders in order to allocate funds and assign executive responsibilities.

This process can be accomplished by deploying an Aragon DAO with the following Applications and Permissions:

• Voting App (ANT Veto): An instance of the Voting app would be deployed using ANT as the voting token. Support Required: >50%, and Minimum Quorum is set to 1%.
• Voting App (Proposals): An instance of the Voting app would be deployed along with 3 non-transferrable tokens. One token would be assigned the instances of Voting app used for ANT Vetos (above), one would be assigned to the Foundation multi-sig, and one would be assigned to the Community Multi-sig. Support Required: >50%, and Minimum Quorum is set to 33%.
• Finance app and Vault : An instance of the Finance app and Vault is used to store funds, the only entity with permission to move funds is the Voting App (Proposals) described above.
• Survey App (ANT Surveys) : An instance of the Survey app would be deployed using ANT as the voting token. The Foundation multi-sig would be granted permission to make proposals.

The foundation would move funds from the Foundation multi-sig into the Aragon DAOs vault. At which point any further movement must go through the Voting app (Proposals). The specific configuration ensures that if ANT holders vote to veto the proposal it cannot go through, unless the community multi-sig overrides the veto.

For decisions which are not directly related to moving funds, or which require some legal action on behalf of the Association the Survey app can be used.

This process would be too cumbersome for most regular administrative tasks, so the intention is for this process be used to approve lump sum operating budgets for organizational functions or approve delegation of responsibilities for organizational functions periodically.

The following are specific actions and how they would be carried out under the proposed process.

Nest grants

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

Funding Development

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

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

Repositories

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

Once Pando is ready, this process could be converted to use the Voting app as a binding on-chain action.

Legal terms

Binding, with direct veto

• The Association would propose versions using the Survey App 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.

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, one of the key funding proposals may be to move funds into experimental DAOs that have different governances processes and expectations for ANT holders.

The proposal has the ANT Veto app configured to require 51 percent support and 50% quorum, which based on participation rates in past surveys may need to be adjusted.

[mariapao]

@lkngtn @luisivan I really like how things are shaping out.

Minor questions I have:

1. We say the association will present proposals to the token holders but in this case is not for them to directly vote on those proposals (and have them passed/approved) but for them to exercise their veto power, right? So this feels more like Association's decisions presented/proposed to the token holders to give them the opportunity to veto them.

Regarding the uncertainties, when you say: "I believe this is mitigated by making veto the first step, and not full control, therefore giving the Association the power to propose" You mean, the association in any case (even if the ANT holders exercise their veto power) is going to be able to move forward with its decision, right?

In some parts we use decisions/proposals indistinctly which is ok, but I wonder if this could be a bit confusing specially once the project will start having proposals for the community to decide on.

2. In the case of the Association presenting its decision on delegates who would run the program for a year, why do we use the voting app here and not the survey app? I would say this is a case in which decisions are not directly related to moving funds.

[luisivan]

@mariapao good points! Replying to them here

1. That's correct!

Regarding that uncertainty: I didn't mean that, but rather that since the Association is the one proposing, rogue proposals will not make it through since only the Association can make them

2. I think because in some cases we will want actions to be binding, like for example appointing who can spend funds on the Nest DAO. That could be binding since it's a permission change inside the Nest DAO

[lkngtn]

Created the following diagram to help visualize the proposal/veto process:

EDIT: updated to reflect change to quorum and support as suggested below.

[john-light]

The proposal has the ANT Veto app configured to require 51 percent support and 50% quorum, which based on participation rates in past surveys may need to be adjusted.

My comment from Aragon Chat:

my thinking around this has been starting really small (maybe even 1% for some low-stakes votes to start) and progressively raising quorum from there after consistently making quorum, say if we get three votes in a row where we make quorum then we raise it to the next level. Go from 1% -> 2% -> 5% -> 10% -> 20% etc until we max out, and lower it a level if we fail to meet quorum twice in a row.

Also fwiw Maker is doing their first MKR vote soon and they will have no quorum requirement on the first vote.

[lkngtn]

I think the approach of starting with 1% and working up is a reasonable. If there are no objections to this I can edit the parent issue to reflect that.

[bingen]

Really loved this! A couple of comments/doubts:

• Why are we using 51% for support? With that threshold, if I'm not wrong, a 510 Yay votes over a total of 1001 would have a negative result, which sounds weird to me. It's asking for more than absolute majority. See for instance: https://en.wikipedia.org/wiki/Majority#Erroneous_definitions
• If I understood correctly that graph, in case of Aragon Association and Community Multisig voting yes on a proposal,and Aragon Veto voting No, the result would be positive, right? So Aragon Veto wouldn't be actually vetoing then. I find that name a little bit confusing (or I just misunderstood).

[lkngtn]

Why are we using 51% for support? With that threshold, if I'm not wrong, a 510 Yay votes over a total of 1001 would have a negative result, which sounds weird to me. It's asking for more than absolute majority. See for instance: https://en.wikipedia.org/wiki/Majority#Erroneous_definitions

Fair point. The intention is for a simple majority >50% for the support requirement!

If I understood correctly that graph, in case of Aragon Association and Community Multisig voting yes on a proposal,and Aragon Veto voting No, the result would be positive, right? So Aragon Veto wouldn't be actually vetoing then. I find that name a little bit confusing (or I just misunderstood).

This is true strictly from the technical implementation, however, from a practical/social perspective the assumption is that the community multi-sig would not actively participate in the process unless there was some obvious manipulation or vulnerability that enabled an attacker to veto every proposal and essentially cause the funds to be locked indefinitely. So you can think of it as ANT holders can veto the foundation, but the community multi-sig has the option of overriding the veto.

It seems like a natural next step to remove this safety net at some point, and arguments in favor of doing so from day one can definitely be made, but personally I don't think the inclusion of the community multi-sig as described should have a meaningful impact on the voting behavior of ANT holders and the marginal extra safety is nice particularly as a first step.

[bingen]

Gotcha! Thanks for the explanation!

[izqui]

After thinking about it for some time, and given the current limitations for transaction pathing to actions not protected by the ACL (like casting a vote in the Voting app) as explained on this issue in aragon.js, the proposal to veto should be created 'automatically' when the Foundation creates a new proposal, rather than waiting for a token holder to go to the main Voting app and trying to vote NO. Also allowing token holders to create arbitrary proposals in the veto Voting app could result in multiple proposals for vetoing the same proposal or even completely unrelated ones.

A way to have veto proposals created 'automatically' could be by introducing a 'daemon app' that can execute an action if some condition is met. Because of how Ethereum works, you cannot schedule a transaction to be executed at a particular time, but there could be a small economic incentive to make sure that action is performed as soon as possible after the condition evaluates to true. In this particular case, we would want to create a bounty for executing a function in this daemon smart contract right after a proposal has been created in the main Voting app. The action that will then be executed would be creating a proposal in the veto Voting for voting NO to the recently created proposal in the main Voting app. This 'daemon app' wouldn't need to have any UI at all and it would be the only entity with permission to create new proposals in the veto Voting app.

Regarding the quorum for the veto Voting app, starting with a relatively small amount such as 1% seems like a good idea to me, given that the Veto app won't be able to execute actions directly. I wouldn't add a mechanism for the quorum to automatically vary, but would leave the option for the main Voting app to modify the quorum of the veto Voting app.

Something that we should be careful with is the 'social agreement' about whether a proposal that is vetoed can be proposed again by the AF. My worry is that there won't be enough incentive to vote NO to veto proposals for holders that agree with the proposal and decide not to veto. A holder that doesn't want to veto will probably only vote against the veto if there is enough support for vetoing. If this is the case, a rational holder that supports the veto will wait until the very end of the voting period to cast their vote, leaving no time to react for holders against the veto. I think it should be fine for the AF to re-propose something that was vetoed, but this should be properly communicated.

[sohkai]

@lkngtn @john-light Can we close this in favour of AGP-1?

[john-light]

@sohkai if AGP-1 passes (and chances are looking good) then we will archive this repo and move any AGPs we want to preserve through the new process. I would leave this open until then.