DAO Design Jam (Week 2) Recap

On Star Wars day, 4 May, we had the second of an ongoing round of discussions about how to think about and design Decentralized Autonomous Organizations. If you like to follow in order, last week’s discussion is summarized here.

Design Brief for Week 2

Last week’s discussion gave us some interesting food for thought as a broad overview of DAO design.

This week, it may prove fruitful, to dig a bit deeper into the specifics of how we could actually build DAO structures. So am proposing that we focus this week’s discussion on value transmission | distribution within a DAO (how are revenues dispersed). Obviously DAOs will have different distribution models, but those models can have prototypes. And those prototypes may have some level of abstraction or commonality to how they work across prototypes. It is this area that I’m proposing for this week’s discussion.

This is meant only as a proposal, not as a prescription, so if there are other ideas please comment! Hope you can join us.

The Discussion

We began by trying to bound the problem a little bit. There was a fairly strong consensus that there are two basic models for value distribution within a DAO: market based mechanisms, and role (or position) based mechanisms.

Role Based Mechanisms

The idea of role based mechanisms is that they would work in a similar fashion to traditional employment mechanisms. Nodes to work, but they receive value distributed to them based on a time base metric rather than necessarily a work output based metric.

These are largely easier to structure that market based mechanisms with respect to DAO structure – to the extent one is talking about value transmission | distribution within the DAO.

The challenge here for DAO designers is in terms of defining a permissions table. One participant who had done some serious thinking in this area has developed the concept of positions and actions. Positions are not positions as analogized to financial positions but rather are positions as analogized to employment positions. A position has a set of actions which that position may take. The design concept is that one central node of the DAO contains a table of what positions there are, what actions those positions may take, and which other nodes are currently in those positions. This allows the central node to control hiring, firing, promoting, and demoting “worker” nodes within the system based on whatever metrics the “HR” department of the DAO’s central node has programmed into it.

One idea which was raised was the concept of assets being separate and distinct from actions and positions. We discussed this, and it is conceptually quite difficult to really put a finger on what assets in terms of a DAO may be. One prevailing train of thought is that assets could be crypto-goods which live on the blockchain and have ownership rights, usage rights, and are necessary to do things. An example may be a private key which allows the owner to take a specific action. Another prevailing train of thought is that assets could be real-world goods which have representations on the blockchain and have similar characteristics as crypto-goods but are simply representational. An example may be drones which a DAO could use in search and rescue operations, or the asset could not be the drones but (minutes) of access to the drones. The point here is that assets could be their own unique “thing” which could be required in order for a position (or role) to accomplish a task. The last prevailing train of thought is that assets do not exist to a DAO because they collapse to a simple permissions table within the permissions unit of the central DAO node (its DOUG).

Market Based Mechanisms

Market based mechanisms are more of a challenge to design than role based mechanisms for a few reasons. The first is the challenge of competency for a node to conduct a certain task. In the real world, when companies outsource they do not simply go with the lowest bidder. There is a two-fold process for outsourcing. First there is a competency threshold filter, and then the company chooses the lowest bidder. But how to design that in a DAO world is difficult. There were a few ideas for addressing this challenge.

One idea was for the DAO not to choose the nodes that accomplish the task, but rather to simply solicit the bids in an appropriate fashion. In this idea, the HR department of the DAO’s central node would solicit resumes, which may simply be magnet links to torrents of real world pdfs of real world resumes. Then the node(s) that are taking the hiring decision reviews and select who is chosen.

Another idea was to build insurance pools, similar to how contractors must be bonded in the real world, and these risk pools accept the consequences for sub par performance by the working node that was contracted to perform the task. This could be a very elegant solution, especially if combined with the concept of guilds where the guild certifies persons to perform the task. The challenge with guilds is that they can easily be corrupted and powerful entities within the guild can control the guild in negative ways. This idea was addressed in this older concept paper.

Yet another idea was for a more globalized reputation mechanism. This could be represented as a personal coin which was traded on a decentralized market place and the value of that coin vis a vis other representational metrics of value (perhaps within a similar field or area) could be used as a proxy for the reputation of the node. Within a globalized reputation mechanism, one has to be very vigilant about reputation because of sybil attacks.

One challenge with a globalized reputation mechanism is how to address the new voices challenge. This is an ongoing discussion within the DAO designer community at this point. In the longer term, when humans live their whole lives being able to sink much of their activity into the blockchain this would be relatively straightforward. Disclose your school records and other activities to a requesting node by simply giving them some private key to some portion of your data, all of which is on the blockchain and accessible. That easy solution, is, however, not currently feasible. Another way in addressing this new voice challenge would be to come at things from the perspective of guilds which presumably have some interest in their profession continuing and in the past have done a reasonably good job at ensuring that their new members have opportunities to grow professionally. Again, guilds can be corrupted by the powerful (high reputation) members of the guild.

Verification of Task Completion

It is probable that most every DAO will link the transmission | distribution of value amongst its nodes after verification to some degree of task completion. We discussed various strategies for tackling this.

One idea was to use the Schelling Coin concept which has some potential for success. Another idea was to use a modified Schelling Coin which has some restricted membership to the parties and (perhaps) a neutral arbiter. If the parties to a contract (or, better, a system of contracts) have sufficiently divergent interests than the reasonably likely chance of collusion would be nominal. These participants within the system, whether open or restricted, would send verification of events which took place in the real world to the central node which would use that.

In the case of large projects there is typically a critical path for the project to succeed. DAO designers could work with their clients to identify these critical paths and then could interpolate other events have occurred depending on where within the critical path the project is. When the points chosen for verification within the critical path were either neutral in their value to either party or were sufficiently structured so that neither party to the contract has reason to care enough to try submitting a wrong answer then such a system could have increased efficiency.

Other ideas include microtasking which would involve perhaps taking a picture which purports to show that a given event has occurred and then sending that picture to a set of non-involved participants to verify whether the picture shows that the event occurred. Also, there was the idea of decentralized experts or umpires who determine whether an event has occurred.

Terminology

One thing which was clear to me during the discussion is that we are currently only in the formative stages of having a common consensus of a DAO’s vocabulary. In a measure of transparency, here is how I will be trying to make sure I use my words:

def participants
                    Participants are always human `actors \|\| nodes` within the system.
end

robots = function() { Robots are always non-human `actors \|\| nodes` within the system.};

actors := Participants() + Robots()
nodes := &Actors

def reputation
                    An actor's history of actions and the results of those actions. Perhaps more
  suitable for a DAO's outside hiring activities.
end

competency = function() { A given actor's suitability to perform a given task within the
  DAO's structure. This is less about reputation (a general term) and more about a specific
                    suitability. Perhaps more suitable for (inside promotions \|\| demotions) {};
};

compensation := Payment for performing a given task. Can be structured in a variety of ways.

def assets
                    Have owners and users. May or may not be needed to perform a given task \|\| action.
                    These are less about currency and more representational of goods either on the
                    blockchain or in the real world.
end

positions = function(){ Positions are roles within a DAO which have a longer period of
                    performance than for outside hiring. They would usually be linked to Actions \|\| Tasks
                    in some way.
};

actions := Required work the DAO needs performed by one of its nodes.
tasks := &Actions

If you disagree or think that one of the above needs changing please comment or send a PR.

Outstanding Questions

• Why should a DAO designer chose a market based mechanism or a role based mechanism to accomplish a particular task or set of tasks?
• If the overall DAO is a hybrid of role based mechanisms and market based mechanisms then how does a designer determine how to structure permissions for one or the other? This has a real world analog in the hire or outsource question.
• If a task is outsourced then how will it be assessed? On the hand, larger amounts of outsourcing (e.g., outsourcing entire projects) are easier to administer. On the other hand, discrete, smaller tasks are easier to handle.
• Real world verification of events to the blockchain will likely be a structural problem for the foreseeable future? How should DAO designers tackle such a problem?
• Unions (or guilds) v. Individuals. This is a very old challenge for humanity going back at least through the industrial revolution. But the challenge is the tension between the present day concept of libertarians who say that nodes should get what they work for and only the strong should survive and the present day concept of liberals who say that while that may be true we still have a duty as human beings to care for the lesser skilled, newer, and less able among ourselves. How does this tension, which will not be solved by crazy math, square with the transmission of value within a DAO?

Next Week

There has been a proposal that next week we turn more to decisions. How should a DAO take decisions? How much consensus is too much consensus? How do we balance efficiency of single node action taking against ideas that participants should have a voice within the organization? These are tough questions, and if you’d be interested in joining us next week please do.

Happy Contracting!

~ # ~