Love it, thanks for the proposal Sem!
Thank you! That sounds pretty good already. A requirement of the transfer is that token holders can overrule delegates. The below scenario is an example:
- Tokenholder X has delegated to delegate A
- Tokenholder X disagrees with the way delegate A is voting
- There is a Delegate B voting in alignment with the preferences of Tokenholder X
- Tokenholder X redelegates their decision-making power from Delegate A to Delegate B while the vote is ongoing
Is this natively possible with TAO?
A soft mechanism where delegates should announce their inclination before the vote goes live and give tokehnoders time to redelegate if needed is a potential walkaround (adhering to the announced vote can be a requirement for the delegates and result in vote dispute if broken)ā¦a more tedious and obscure process but still an option
Yes, it is part of the present functionality indeed. It goes this way:
- The voting starts for everyone. Everyone can vote. Delegates can vote on behalf of delegators.
- The delegated voting period ends. Everyone can still vote or change their votes, except for delegates, who can not vote or change the vote on behalf of their delegators anymore. Delegators can change the vote a delegate cast on their behalf during this period.
- The vote time ends. Anyone could vote or change their votes unless the outcome of the voting was changed during the quiet voting period. In that case, the vote is extended for some time defined in the quiet voting extension parameter. It will be extended again and again if the voting outcome keeps flipping.
- Once the vote is finally decided, it wonāt be able to be executed until the execution period has passed, leaving time for people to prepare for the outcome of the vote.
Hey Sem, do you have metrics, or can point to some way to extract those metrics on how the delegation is commonly used? Meaning, although it seems super flexible, do people actually use all of those features (including the quiet ending).
Tagging @mroldann for knowledge. Might be a cool metric for us to explore.
- Disputability is rarely used. Like Aragon Court, Celeste only had 4 disputes since we launched it. It doesnāt mean that itās not helpful (it could be that people do not act maliciously because it is in place), although we do not have enough data to say it is effective.
- Delegation is the most interesting metric to measure. We arenāt currently measuring it, but it would be feasible to create a dune analytics dashboard with the data of a Gardens Tao Voting contract (1hive, for instance) showing the evolution on which addresses receive more support over time.
- I donāt think quiet ending vote has been necessary in any of the Gardens, but again, the fact that it is in place may protect from whales that change the outcome of the vote at the very end of the voting period.
- Execution delay is always applied. I donāt know how beneficial it is in general, but I can foresee cases in which it is a must. It resembles the grace period Moloch DAOs have in place, letting people ragequit before a vote is executed.
Many thx @sembrestels ⦠@mroldann will do q deeper analysis and we can post our findings here as well
Hi there!
Iāve built this Dune dashboard to try to understand how Tao/Disputable voting is being used.
(Also had to fetch all apps in order to check I wasnāt loosing anything)
The DAOs that account for the highest event count from the DisputableVoting
app are Token Engineering Commons, Giveth, 1Hive, BrightID and Agave.
Being the count by topic the following:
topic_name | topic1 | count |
---|---|---|
CastVote | \x1c3607eb5a3925b4a4cae4e90a9345b2a2955daeac124e761d05e5288df11963 | 677 |
not-verified-name | \x9dcff9d94fbfdb4622d11edb383005f95e78efb446c72d92f8e615c6025c4703 | 317 |
ChangeRepresentative | \x3b734cbbc757d28ca321c79f67fd0b3c625ca41fc7aa1aa9cca32e6d6fd0f810 | 174 |
StartVote | \xd7bf7ccb2e4cfc6f0a0a257caed8badff9e8edf074f4d8d53d90cac9c515a683 | 146 |
NewSetting | \x011e4fd6859d1a60bf9566bc5400b22aa9950bb088178451fbb9ff71a9410b36 | 130 |
ChangeVoteTime | \x776dcd10c15e7a1bd4fbb6c824d2a80fa8a40a3a6b401fddc678696b7fb06abe | 101 |
ChangeDelegatedVotingPeriod | \x2c2d753fade2041a1abb2972579386f82ae7d7256809c4d44506c4c152fd01eb | 101 |
ChangeExecutionDelay | \xa917ba4499a7580dd381d63de169b0c5bad43e872db28bbac0f06a1e0047e75d | 100 |
ChangeQuietEndingConfiguration | \xa194c49d80327ca6b93c94de63248b209eabfdf2911b0b258286473d93df92a4 | 97 |
ChangeMinQuorum | \x3172f2e9273c729c2a47cc8bf7e7f18506e3e3035126d562602bd2155bc78a50 | 96 |
ChangeSupportRequired | \x903b617f7f36eb047a29b89d1bf7885fdae31d250c3320fccf11d045c11b396e | 95 |
ScriptResult | \x5229a5dba83a54ae8cb5b51bdd6de9474cacbe9dd332f5185f3a4f4f2e3f4ad9 | 80 |
ExecuteVote | \xbf8e2b108bb7c980e08903a8a46527699d5e84905a082d56dacb4150725c8cab | 80 |
AgreementSet | \x64d4a120bf365888d0b3f10e4d7deb8415919eaad62ee6fb5f5619082d6f6418 | 58 |
QuietEndingExtendVote | \xa5e552089c71c91761a836c6c6b8d6ccd0fb1ee4a7362fc3835a8c1c7aafdc1f | 8 |
CancelVote | \x342b22decf184652237398af8d345da7d9743ae2e1c4122e7c32899c6a81f9a9 | 5 |
PauseVote | \x0acb8ef0fdffe8e5404a8511f8f4c38ed4bd1643888377569fc2d50d5ee8d83a | 5 |
ProxyVoteFailure | \xbf94009f3cb6ffcb2eea43b502ff43295b654a96dfcdc68592c90397148ec256 | 1 |
@sembrestels - does this make sense? Am I losing something? Do you know what the unnamed topic does? Should we focus on ChangeRepresentative
events? Thank you in advance!
cc @ramon
Oh wow, these are excellent insights. It looks like vote delegation is a continually used feature in gardens.
I think that it is worth it to keep exploring this event. Maybe you can try plotting which is the support (in token weight) for each candidate over time or measuring how often somebody who delegated their vote changes it because they do not like what their delegate chooses.
I couldnāt find what this not-verified-name event stands for. It is weird because it is called continually, but Iāve been hashing all the events I suspected: ResumeVote, SetApp, RecoverToVault, and none of them is. So I wonder if you have found a transaction with this emitted event. In that case, we could see where it comes from more quickly.
Awesome work @mroldann
I also like the next steps proposed by @sembrestels . Sem, one question for you, is there a way to differentiate events on gardens from events on Aragon client 1hive version o xDAI?
The distinction between them is unclear, as Gardens are Aragon DAOs created with custom templates. Still, in the end, all of them share most of the code, and they can be accessed through the Aragon Client as well (the only problem is that conviction voting and tao voting interfaces are non-functional in the client, at least for now).
Suppose you want to know which DAOs were created using standard Aragon templates (company, reputation, membership) or which were created using one of the multiple garden templates. In that case, you can filter by the contract which created the DAO. You can find it by looking first at the transaction that created the DAO contract, then looking at the contract with which it interacted. For instance, 1hive DAO was created in this transaction, which was a call to this template. This is how you classify the Aragon DAOs/Gardens into different groups.
Another more straightforward rule of thumb is that:
- If it resides on the mainnet, itās most likely a pure AragonOS DAO.
- Otherwise, if itās on gnosis chain or polygon and it is present in the gardens frontend (data also accessible through the subgraph), then it is a garden.
- Otherwise, itās likely a pure AragonOS DAO.
Hey, thanks!
Iāve done a drilled down for the ChangeRepresentative
event that can be seen at the bottom of the dasboard.
In a nutshell, as of today:
- 9 DAOs used this method, with unique 126 voters and 117 representatives chosen
-
1hive, TEC and Geth are the DAOs that have greater
representative_change_count
thanunique_voters_address
. Meaning, representatives have been chosen/replaced more than once -
Giveth is the only DAO that has more
voters
thanrepresentatives
chosen
dao_name | dao_address | unique_voter_addresses | unique_historic_representatives | representative_change_count | net_representative_change | net_representatives_count |
---|---|---|---|---|---|---|
BrightID | \x1e2d5fb385e2eae45bd42357e426507a63597397 | 47 | 47 | 48 | 1 | 0 |
Giveth | \xb25f0ee2d26461e2b5b3d3ddafe197a0da677b98 | 45 | 37 | 45 | 0 | 8 |
1Hive | \x8ccbeab14b5ac4a431fffc39f4bec4089020a155 | 29 | 29 | 42 | 13 | 0 |
@sembrestels - Is there a way to check on Gardenās UI how representatives are chosen?
As for the unverified event, here is an example for topic 0x9dcff9d94fbfdb4622d11edb383005f95e78efb446c72d92f8e615c6025c4703
Added some DAO creation and template analysis.
Being the most used templates:
template | count |
---|---|
Company | 201 |
Membership | 68 |
Dandelion | 62 |
\xa21b6c0ac58e2d21114ed3e88cec769234e41ece | 62 |
Bare | 58 |
ParticleAccelertor | 53 |
Reputation | 48 |
Karma | 38 |
\xe98e5eaa7c8707f9f55f6e1d5cf22166f2bee0a3 | 20 |
Gardens | 19 |
GardensTemplateWithModVotingFixedApproved | 15 |
Hatch | 14 |
Gardens | 13 |
Hatch | 13 |
GardensTemplateWithModVoting | 12 |
HoneyPot | 12 |
Do I get this right, that in most cases there is no relevant delegation, meaning, 1 person delegates to another person and that is it? Or I got it all wrong?
Is there a way to check on Gardenās UI how representatives are chosen?
In the front page of each garden you can see who is the representative you choose.
When no delegate is selected
When a delegate is selected
You can also see who delegates to who in user profiles.
Delegator profile
Delegate profile
Do I get this right, that in most cases there is no relevant delegation, meaning, 1 person delegates to another person and that is it? Or I got it all wrong?
People do not delegate by default (they are not asked to do so in the UI, so the default state is not to delegate). The data shows that there is more delegations that we thought at first.
Reference forum posts for TAO voting parameter About the Aragon Association Funds Transfers category - #3 by lee0007
Hey everyone,
Itās been great to read all this thread. Thanks @luis for raising the topic in the first place, and @sembrestels @AlexClay @lee0007 @fartunov for adding to the debate.
I agree with the diagnosis Luis shared in his first post: the current AN DAO setup is not suitable for the mass transfer and some changes are needed. I believe that up to here, everyone is in agreement. We need some degree of change, but it seems we donāt have consensus in the Forum on how that change should be implemented.
Before going any further, Iād like to recover a sentence that captured my attention when reading the Aragon Manifesto:
Building tools to create and manage decentralized organizations will unleash a Cambrian explosion of new governance forms, and the competition among them will raise the bar globally. It will finally allow us to experiment with governance at the speed of software.
It will finally allow us to experiment with governance at the speed of software.
Iād like to build on the biological interpretation of that paragraf (Iām biased xD). Change is the basis for evolution. Without change, thereās no diversity, no natural selection, no adaptation. Without that, species and organisms die. Itās thanks to experimentation that species are able to test what works, what doesnāt work, and whatever has higher āecological fitnessā thrives and gets to pass its genes to the next generation. Every generation is built on the learnings of the preceding one, and thanks to that, life adapts to ever-changing conditions. Resistance to change leads to fragile systems, as opposed to what can bend and is malleable, that can adapt to new shapes without breaking (thus, resilient).
I believe our situation doesnāt differ much from that. Around 1 year ago, the initial AN DAO launched under specific initial conditions : it was the first experiment in the journey towards full decentralization. After all these months, weāve been able to gather extremely valuable insights, positive and negative alike. Weāve been able to experiment and see what works, and what doesnāt. Not only at AN DAO level, but also at AA / AL.
Now, almost 2 months after token-holders signaling strong support to execute the last step towards decentralization (Aragon Voice), we need to decide what is the best path to address the challenge we agree to have in front of us. We need to decide how we āmutateā, how we use those learnings and apply change to a desired improved state, more suited to current conditions.
From what Iāve read in this thread and the inputs Iāve received from different stakeholders during the last few weeks, it seems that there are 2 options on the table:
- Upgrade the current DAO, amending the current Charter via CIP Governance Proposals.
- Launch a separate DAO, with a new simplified Charter as a clean slate.
Each has its pros and cons, and either of them should be subject to a final token holder vote to be ratified. Considering the high stakes of the process and for the sake of clarity, I will submit these two options to an ANT token holder signaling vote asap in order to inform on the next steps.
Hereās my take from the manifesto
We are committed to decentralizing power in order to dismantle unjustified power ā which usually springs from centralization.
The existing Charter - as currently the sole basis for decentralised governance legitimacy - requires a proposal of this magnitude must be posted as a Main DAO proposal with minimum 30 days notification and 14 days voting.
Sans a legitimate process itās non-binding on the AN DAO and bias from the outset, proving no intent to operate within the decentralised governance framework already in place.
The vote would be pretense only.
If we are just making up the rules as we go, itās effectively no different to a top down imposed, centralised decision. Just because it will have ANT holder votes doesnāt make it legitimate when thereās no legitimate process applied.
I will higlight also this clause from, the Introduction to the Charter - defined as the most important agreement that supersedes and prevails over all others - requires that
As an ANT Holder, natural or legal person interacting with the Aragon Network, you accept and agree to act in good faith and be bound by this Charter, which forms an agreement between you and anyone else that participates or otherwise interacts with the Aragon Network. If you do not accept and agree to be bound by this Charter, you must cease to access, use, interact and participate within the Aragon Network.
If ANT holders want a new DAO with a new Charter simply propose it via the legitimate governance process and in a minimum 44 days, you may have the legitimate basis to progress that agenda. The only possible blocker would be the
Immutable Guidelines
The guidelines in this section shall not be amended and shall apply to all proposals submitted to the Aragon Network DAO(s). If any other guidelines in this Agreement conflict with these immutable guidelines, the immutable guidelines shall take priority for enforcement purposes.
a. Proposal Compliance
i. Proposals must be governed by this Agreement, or a future version of this Agreement as
modified within the bounds of the Agreement.
ii. Proposals must not disproportionately benefit a majority of ANT Holders voting on a proposal over the minority.
iii. ANT held by the Main DAO and/or Sub-DAOs must not be used to influence proposals nor votes, nor be staked in Aragon Court.