Evaluating the AGP-1 voting results makes me think we need an Aragon Community Token (ACT)

@light I certainly wasnā€™t trying to imply that you all didnā€™t try hard enough ā€“ and indeed the ideas I mention are ones that require more hurdles as external parties are a bit out of owns control!

In thinking about ACT more, the initial proposal had to do with getting a signal from the entire development ecosystem: Flock, Nest, part-time recurring bounty hunters, open source contributors etc. The signal is more valuable if people from all parties buy into it. If the attitude is ā€œgo ahead and organizeā€ but donā€™t count me in, then it does turn into an entirely different dynamic.

So yeah I understand the ā€œno need to ask for permissionā€ stance, but it wasnā€™t about permission in the first place and it wasnā€™t about trying to create this body for the purpose of it developing itā€™s own team, agenda, proposals ā€“ I do see the value for both types of bodies now though!

But my point is - ā€œaragon builder communityā€ signal is a bit different than a group of non-flock folks. And hence there does need to be some buy in from the rest of the community to actually try the originally proposed proposal (since an ethereum address is needed from everyone, if you actually want to measure the percentage of people participating). Iā€™m not demanding this at all, but just clarifying the distinction and difference in signalling or voting between the two.

Perhaps it can be the non-flock that is the SRO on the burning situation though, to remove that administrative burden for others to participate that donā€™t want the bother with the meta governance, but are open minded to try the signalling mechanisms, where all it takes is one extra second to perform the vote on the additional application. Iā€™m actually curious about the reasons why one would want to opt out of receiving the voting token - if all of the votes are just exact copies of any AGP or AIP :slight_smile:

1 Like

Hmmm, Iā€™m not sure of any other way to do it other than to say we are creating this organization and this is the process for being involved, and this is the purpose, do you want to participate?

It probably would not be a very valuable signal if only a small handful of active contributors decide to participate, but it certainly does not require 100% participation to be valuable.

I think it is important to frame it as an organization that is capturing sentiment from active contributors following a specific process of inclusion criteria. So long as the inclusion criteria doesnā€™t produce a bias relative to the group that the signal is meant to represent, then it would provide insight that might otherwise be difficult to gather even if not everyone in that group chooses to participate.

Judging from the comments in the thread it seems like the response has been very much positive with regard to using the organization/ACT for signalingā€“Iā€™m not sure where the impression of ā€œgo ahead and organize but donā€™t count me in came fromā€, it seems more like ā€œgo ahead and organize and lets see what happensā€. I canā€™t speak for anyone else but Iā€™d be happy to participate. :+1:

My language choice with that analysis may have been too extreme ā€“ I think I was trying to further make the case that there are two ways one can think about the group. If you read the thread there are a few different interpretations with what the group may do, or who may participate in it. Maybe I was trying to reach consensus on the general idea and have the birth of it be more cooperative or more of a collective effort :slight_smile:

But yeah I think in general this is all a pretty great exercise. Because it is a brainstorming session, with no rights or wrongs, and with many of us considering and thinking through new governance models and signals! Itā€™s a lot of interesting ideas to marinate on and Iā€™m just trying to sort it all out. Iā€™m very excited about the aragon future :slight_smile:

1 Like

One aspect of ACT that just came to mind is that the votes would be pretty obviously tied to identity, which can have social and political ramifications on an individual voter, whereas ANT votes are pseudonymous and thus relatively privacy preserving. So the dynamic of the votes would be different for that reason alone.

Super interesting thread :vulcan_salute::brain:

an insight form the Web3 Design System research that we are doing, where we interviewed people from other companies who have governance votes like MakerDao:
- voting with cold wallets, especially if multiple parties need to be involved, is still hard and they saw a low participation due to this fact.
they hint at it also in their Foundation proposal approved

My interpretations & theory

  • by now the flippening is over, people who hold ANT, or large quantities of ANT have a long term vision in the project
  • seen as a long term hodling effort, people probably hold the tokens in cold storage or harder to access hardware wallets.
  • Governance tokens are usually bought in large quantities (or will be so) by institutional investors (this is a hunch based on the latest move of a16zCrypto buying Makerā€™s governance tokens)
  • voting from hardware wallets or cold storage has usability challenges, especially if multiple parties need to be involved (solvable, more on that later)
    therefore the motivation to vote needs to be greater than the UX friction and risk of using the cold storage
  • AGP-1 was very likely perceived as a low risk vote, and one where everyone could know in advance the positive outcome ;), therefore there was no real motivation to go through the UX friction and risk of using the wallets to actually vote.
  • probably in this vote there is also a component of too little communication

Possible solutions

  • technical solutions: create a self-liquid-democracy-delegation: whereas owners of ANT, who probably want to keep them safe in cold storage can authorise another hot wallet they own, or a simpler multiSig, to vote on their behalf (that would be the only function available, whereas the Transfer might be disabled and accessible only to the cold-storage) ā€¦ I think a #777 Token could already have this function built in.

  • design solution This solution also requires a new interface, an extension to the permissions app, where ANT token holders can assign those delegates for certain functions of the Token contract (some people authorised to vote, others to transfer and sell),

  • design solutions: our Design research found that also other contexts (ie staking) need to fluidly move from one platform/wallet to another, eg from Desktop to mobile, but also from cold wallet to hot wallet like we said.
    Universal Logins or other patterns where your ā€œwalletā€ is a smart contract, that can have other accounts authorized to operate on its behalf are better suited for this purpose

  • communication solutions: yes to more time for the vote. But I also would like to see a page connected to the proposal where the community discusses it, and where key ANT holders can, optionally, signal their position (although Iā€™m aware this could generate herding)

all this hints that we probably need a ā€œGovernance walletā€ :wink: that has built-in all these features

which is a multiSig that can assign different ā€œownersā€ to the different functions (ie voting owners, transfer owners, investing/staking owners)

and we probably need a voting standard that different dApps can apply?

5 Likes

Didnā€™t have time to read all the thread, thus apologize in advance if this has already been mentioned.

As an ICO investor, I do care for the direction this project is moving. I see the great potential in AN that is in turn strengthened by apps and projects that rely on Aragon infrastructure. Therefore, I am directly interested in exercising my right to vote if this vote can influence the future of the project.

Your proposal to distribute voting rights only among developers is at least unfair, as both developers and investors are the ones that make Aragon a reality. Secondly, there always is a conflict of interests in these two groups - less spending more work vs. less work more spending. To even it out you have to give equal rights to every participant. Iā€™m not even talking about a democratic and decentralized approach here.

The concern that you expressed regarding the abuse of the mechanism is only valid when there is a low turnout. This is the key factor that has to be addressed. I also have my share of fault here as I didnā€™t participate in this vote and there are a few reasons for that - 48 hours to vote is not really enough at this early stage, as holder awareness is too low yet and not everyone is familiar with the mechanics of the process. I agree to someone, who mentioned here, that quarterly votes do not line up with 48 hr duration very well.

In my opinion, there are two key aspects to pay attention: communication and clarity, and ease of use and security. Former is to clearly and timely notify holders of the upcoming vote - for example, the proposal is published on GitHub which is a great platform for developers and collective work but isnā€™t very user-friendly. It might sound retarded, but it took me a while to find the final document. Actually, Iā€™ve only managed to download it after having read the instructions in the blog. The latter applies to the process of voting - it might be easy for some but I didnā€™t have enough time to understand the process and assure myself of the safety of these manipulations, the reliance on Metamask also sows doubt in this process. This becomes even funnier because I consider myself to be an ā€œadvanced PC userā€.

One idea that I can think of right now that might improve voter awareness and reduce abuse, would be creating a whitelist of addresses eligible to vote. Everyone should be allowed to submit the address to the list and only whitelisted addresses should be able to cast the vote and be accounted. The balance on the address could be locked prior to voting for the duration of the vote and whitelisting could be made impossible after the first draft of the proposal has been published to avoid manipulation and abuse. The process of whitelisting may require submitting an e-mail address to receive communication regarding the upcoming votes.

In the longer term, the process of voting should be completely integrated into Aragon dapp, including the support of HW wallets.

4 Likes

Thanks for your feedback! Will address some of the points in your post:

This is certainly open to changing, there is a mechanism in AGP-1 to regularly poll ANT holders about the frequency of votes, we can also add a poll about the duration to the next vote as well.

The proposal was linked directly multiple times in multiple places (e.g. this thread), and in the ā€œFinal detailsā€ blog post there is a line that clearly says:

Read the full AGP-1 proposal here.

That said, if thereā€™s a concrete suggestion you have about how to make the proposal easier to find and read in the future, I am certainly open to suggestions!

There were also details in the ā€œFinal detailsā€ blog post about voting from a cold storage wallet or normal private key using MyCrypto / MEW, so the process wasnā€™t completely reliant on using MetaMask.

But the point about confidence is important and we will be sure to put in more work in the future to try to make voters as confident as they can be in the process.

I donā€™t like the idea of a whitelist but having some communication channel dedicated to alerts about upcoming votes does seem useful.

I donā€™t want to speak for the dev team but imo it is unlikely that Aragon would take on the burden of being a direct interface for wallets when there is already so much good work being done in this area. For example, we have funded a native Ethereum provider (or ā€œsigning interfaceā€ - the terminology is still getting worked out) called Frame that will make it easy to sign transactions even using the native Aragon desktop app. I think this is a better approach than every dapp developer reinventing the wheel to add a signing interface to their dapp.

1 Like

Well, I would say that this is more of a software limitation, and this secret voting proposal should remedy it in the future, right? Aragon Nest Proposal: Secret voting infrastructure using Ring/Threshold signatures Ā· Issue #12 Ā· aragon/nest Ā· GitHub

:slight_smile:

So indeed perhaps it may be too early to implement such a collective if this is a concern for participation.

I think for a lot of use cases, for organizations, public voting is probably okay (like for Roadmaps etc). Right now the Giveth team uses Loomio for voting/signaling, and most of the votes have been public. Iā€™ve just seen a handful where Anonymous was selected as the option.

1 Like