Current DAO unsuitable for fund transfer

Currently, two proposals on the forum to address option #1, which will underpin our ability to upgrade the current AN DAO. I would greatly value your input on these proposals please @luis

Given the deadline for this to happen, it is unlikely indeed that an Aragon product would be ready to address all the needs. But would be quite important that the DAO is open to being “moved” at a later stage and relying on its own work.

1 Like

Thanks for the post @luis. I think the option 1 can be done it is more labour intensive but is also more inclusive of the DAO. Option 2 is faster but less inclusive, just calling the trade-offs. Would like to give the DAO some time to see how far it can get to making the changes. Bottom up change to the charter is preferable as long as it is practical.

Core thing that I think we should be looking at are the process’s and then build the product stack on top of these.

The four core pillars are:

  1. How to elect Delegates
  2. Delegate rules
  3. How to make a financial proposal for a guild/project
  4. How to change the above

These are the core pieces that need to be worked out. Once these have been established the simplest version of these we can pick the stack and work from there. All other pieces can be built on top of this.

If they can be iterated into the current charter then great, if not they will need to be put in a new document. There is a team in dgov who are picking this up and looking to drive the transformation. We need to be as involved in there process as possible as it needs to happen quickly with our input to make it successful.

2 Likes

I disagree with option 2 being less inclusive. It is about focusing attention.

Quick metaphor time:

We have a skateboard. ENS, aave, yearn are surfing around us. If we are looking for a way to move on water (have a functional DAO) do we:

  1. Evolve the skateboard so it floats, ideally without losing the wheels (because we have a personal attachment)?
  2. Have the humility and pragmatism to take a surfboard and maybe add a paddle or so?

Neither approach excludes people, the second just excludes administrative/procedural debt

Obviously, this depends on what our objective is. If the objective is to create an airplane (build governance that no other project has) starting with the skateboard is a completely viable path.

1 Like

Agree with you here! Like the way you have put it. Withdraw my inclusion statement as long as we allow everyone to participate in option 2 which I think we would.

2 Likes

@fartunov to your point on hard fork. Can you clarify what you mean by “AN DAO becomes ETC” What does ETC stand for in this case.

Q: The purpose of the fork is to start a clean slate and rebuild from scratch?
Q: Hard forks how do you see that impacting the contributors of AN DAO?
Q: What do you think the optics of a hard fork are? It has negative connotations for me
Q: Can you link us some examples where a hard fork was useful for community solidarity in any case that was not an emergency.
Q: Is this reminiscent of Jan 2020, I’m aware that pivot seriously undermined credibility and trust throughout the ecosystem.

Questioning only because I am yet to understand the process of what #2 proposes and would really value you answers to perhaps noob questions and some diversity of perspective here

@daniel-ospina @AClay @mheuer @alex-kampa @GriffGreen

ETC stands for ethereum classic.

I don’t really have answers to your questions yet. It’s a hypothetical situation. There is no difference for the contributors - they can contribute to the organisation that functions better (similarly to how most builders work on ETH, not on ETC).

Hard-fork is just an expression to signify that in essence all useful activity will move to the new place.

I get the need for exaggeration for dramatic effect, but as long as the outcome is supported by the majority of active voting power (an nobody is censored) it is the more legitimate action.

Let’s also not lose sight on the current situation - we are asking everyone to comply with some immutable rules that we are not allowed to alter EVER, and were originally approved by less than 0.2% of the network.

Apologies if replying to the wrong thread - it’s jumping back and forth.

False dichotomy, the second imo requires at least as much admin and procedure, if not more.

Given, that I understand you are proposing a move to a third new token? Let’s say ANT becomes ANC the classic version.

Maybe a recap of the admin and procedural debt to move from ANJ to ANT might provide some insight. Was that an easy process? How did that go down with the ANJ community?

I don’t know much about the history here except what I’ve read in the forum, discord, media and sentiment I’ve heard around web3

What have we learned from the past?

In addition to tokens there is still the work to build collective consensus for an entirely new Charter, where would you start @fartunov @luis

@AClay has highlighted key requirements and there’s still the purpose vision mission and values that wrap that. The outcome of evolving will likely be a new Charter. As it currently stands with AN DAO the Charter provides legitimate governance boundaries, which aid focus and discipline upon which to evolve.

While we hypothesise, let’s also act to get the current Charter to a point where we have the ability to propose (and hopefully employ) governance mechanisms that can help us more effectively capture sentiment, build consensus and vote on the changes that are needed.

Agree, not allowed ever is the literal interpretation of immutable. However, if we evolve the Charter to a point where the immutable guidelines do not match the spirit embodied by the broader Charter, then we have grounds to at least propose we remove them.

At this point though, what harm do they cause?

Would appreciate @eaglelex @Tayy @ronald_k advice on this as I bailed law school - best teenage decision - not before understanding that the spirit of the law provides legitimate grounds for legal interpretation.

To be clear my preference for evolving the Charter is that it currently provides our basis for decentralised governance legitimacy. This though is based on my perspective of what it means to govern

Of the definitions provided above I see the charter (agree flawed but not beyond repair) enables us to effectively govern by encompassing the need

to serve as a precedent or deciding principle for

to hold in check

to exercise continuous sovereign authority over

to exert a determining or guiding influence in or over

Be interested to hear from others where we share and diverge on this understanding as I am aware that it’s hard to build concensus without shared understanding of the words we use

Open questions:

Q: If we contravene the Charter as the current basis of legitimacy what precedent does that set?

Q: How do we hold in check future pressure to change rules regardless of established process?

Q: How do we maintain continuous sovereign authority while effectively undermining it?

Q: If not what (Charter) exerts our determining and guiding influence then the question becomes who?

i’m a fan of moving on to client since it has legs & with the evm crispr tooling we can integrate new contracts fairly easily & probably have a deliverable within the timelines suggested… we can also bundle hundreds of interactions in to a single vote and make this a fairly painless experience in theory… regardless of how this is approached it seems like we should be planning on having a model to test fairly soon so we can make determinations based on some hands-on experiences and not just blah blahing in forums

towards tech agnosticism is it worth looking at the 1hive stacks or some of the tooling they’ve developed? their code on the gardens side feels about a year ahead of our client product, and might be a smoother transition along with some of the upgraded OZ contracts that client is missing… all in all super fun project, looking forward to seeing some action :slight_smile:

2 Likes

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.

2 Likes

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.

2 Likes

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.

Finance

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.

Agent

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.

14 Likes

Love it, thanks for the proposal Sem!

3 Likes

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.
6 Likes