Current DAO unsuitable for fund transfer

As i tried to clarify - not suggesting a different token at all. I used the fork as a metaphor (clearly unsuccessfully) about the DAO not the token.

As I stated in the beginning the TLDR of best course of action in my view:

Focus on the future needs of the DAO and build with that sole focus, free from administrative/governance debt/burden - path 2 outlined in the original post

1 Like

Ok cool thanks for clarifying.
Thoughts then on @alibama’s proposed use of our own origins and using Client? which I understand others - 1Hive EVMCrsipr - have continued to upgrade

1 Like

Sometimes also State Constitution provide for immutable principles. For example the Italian Constitution states that it is not possible to abandon the “Republic” as form of governance.

Nevertheless, also these immutable principles may be changed by a double modification of the Constitution. First, you amend the provision that make them immutable and then you modify the provision as such. One could think about a particular quorum to do so. But every provision can be changed due to the fact that the charter relies on a social consensus that can be modified over time.


I don’t have enough knowledge of the technology to weigh in. Also, the choice of the stack, although lengthier in evaluation, is secondary to the principal design.

1 Like

@sembrestels tagging for some important input since we are discussing EVM-crispr and 1Hive.


Hello everyone, at 1Hive I’ve been working with many different AragonOS DAOs, and I would be glad to help with my knowledge and experience to the constitution of this new stage of Aragon if you decide to go the Aragon Client path.

The first proposal I can do in regards to implementing a DAO that is controlled by delegated-ANT would be to create a new custom AragonOS DAO with the following apps:

  • Token Wrapper
  • Tao Voting
  • Finance
  • Agent

Token Wrapper

It is an audited AragonOne application that allows wrapping an ERC20 into a MiniMe token, making it compatible with the rest of AragonOS ecosystem. ANTv1 already was a MiniMe token, but it was simplified in the migration to ANTv2, making it not compatible with the ERC20Snapshot interface. Although we may find alternative better solutions, wrapping ANTv2 would make it compatible again with Tao Voting without much hassle.

Tao Voting

It is a finished and renamed version of Aragon’s Disputable Voting used by 1hive in their Gardens framework.

It has three main differences from the normal AragonOS voting:

  • It is disputable. This means that if a vote does not comply with the Agreement (DAO Manifesto, Charter, Covenant…), anybody can dispute the vote and freeze it until Aragon Court / Celeste decides if the vote is compliant with the Agreement or not.
  • It ends quietly. So if the direction of the vote changes right before the voting ends, there is an extension of the voting time, so whales can’t change the direction of any vote with unintended consequences when the participation is low. See a better explanation here.
  • It can be delegated. Token holders can set a delegate who will use their voting power for them.

Not all of these extra features need to be used. We could make votes non-disputable, or set the quiet ending to zero, and still use the vote delegation capabilities of Tao Voting.


This app offers a frontend to do payments from the Vault/Agent to other addresses. It is mostly used to create immediate payments (because the user interface is only offering this option), but it can be also used to set up budgets for specific amounts of time and to create recurrent payments. You can refer to the EVMcrispr documentation page to see the full functionality of this app.


It is the core of the DAO, the place where the funds are going to be held, and the one that can be used to interact with external contracts. As an example, you can see how NFTX uses its agent to do all kinds of operations to its protocol here.

This is the most simple way to proceed into an token-delegated Aragon DAO that I can imagine. If you decide to go this path, we may be able to propose some modifications, so the DAO design is more convenient and resilient to attacks, but this is a good functional first approach to the migration.


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

1 Like

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

1 Like

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?

1 Like

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 than unique_voters_address. Meaning, representatives have been chosen/replaced more than once
  • Giveth is the only DAO that has more voters than representatives 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

cc @ramon @sembrestels

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?

AFAIK yes but would ask @sembrestels to confirm