Last Sunday, some colleagues and I got together to discuss some of the design constraints and other challenges which will be present for DAO designers. We are in the very early days of even having an idea how to design decentralized autonomous organizations (DAOs), so this very first meet up was really about providing a discussion space more than anything else.

Design Brief

This is what was presented to participants before the discussion began as a mechanism for initiating thought and facilitating discussion more than being restrictive.

Concept

What Ethereum contracts are needed for a simple blog or podcast or YouTube channel?

Constraints

• Participants will have varied roles
• Revenue comes into the DAO via advertising, sponsorships, and/or memberships.
• Operating costs (sound cloud subscription, hosting, etc.) get first take of revenue stream.
• Participants get what’s left over… Divided among them based on some formula.
• DAO does not need to move the money around (yet) but should be able to output a transparent balance sheet to all participants showing the revenue distribution. The humans can transfer the money for now (unless someone can already move BTC with ETH contracts).

Overview

The Hangout will be a brainstorming and collaborative design session. If it is successful and useful could have follow up, more specific sessions, to work on specific portions of this.

All work product will be open sourced. If all participants in the session agree, it can be recorded and submitted to Ethercasts or other similar outlets. If not, only the work product will be released. [ed: this did not happen and likely will not happen in the future]

The Discussion

We spoke (briefly) about six main areas which DAO designers will need to concern themselves with when they work with clients to design DAOs. I may not have these exactly in the order we discussed them, though!

Analytics and Value

The first area we discussed was how a DAO can gain an understanding of analytics. This has to do with understanding where the value is within an organization (with an eventual view toward optimizing resources in the direction of the most valued components of an organization). In the concept of a blog or podcast, gaining an understanding of the analytics of views, downloads, listens, etc. has a direct correlation to the value the organization is outputting. To be clear, the discussion was primarily about a blog or podcast or channel which resides in the current internet rather than on the Ethereum blockchain. At this point, it seems there are a couple of options for DAOs to gain an understanding of analytics. The first option is the Schelling Coin concept which is meant to be a trust-reduce datafeed into the Ethereum blockchain. The second option is a trusted datafeed into the Ethereum blockchain where a given robot would pull analytics from the service provider, sign such and send a transaction to some point in the DAO which is responsible for collecting the analytics.

Participants and Value Distribution

The second area which we discussed (albeit briefly) was participants within the DAO system. It need not necessarily matter if these participants are human or robotic, but the DAO will have to have an ability to distribute resources to the participants in order to incentivize continued | increased | reduced participation within the DAO. This is a difficult area to discuss in the abstract on the one hand because the benefits which participants bring to a DAO will be very closely linked to what the DAO “does”. One of the major concerns that was raised was how does a DAO incentivize reduced participation which is another way to say control spam. I am proposing that in the next discussion that we dig a bit deeper into this area.

Organizational Governance

This seems to be one area where there is a lot of excitement. It is quite interesting to me as a transactional lawyer who has thought more than a good bit about organizational structures and governance of those. There are many key questions which are currently unanswered in this space. Predominantly, what nodes get to vote; what questions go to a vote; and how does voting work? There is a balance in the governance area which is yet to be explored. On the one hand, there is a desire to open up participation widely. Indeed, we all like democracy (or so we tell ourselves). However, there is an obvious trade-off between efficiency and participation. A large amount of participation (needing votes of X% of the Y participants where X and Y are both relatively high numbers) will require time. Time reduces efficiency to a certain extent. We discussed two possible ways to strike this balance. The first possible solution is to have some ability to ratchet what decisions are taken at what level. Another possible solution is to implement proxies – but that in and of itself is a complete topic for future discussions.

Reputation

Closely related to both Governance and Participation is reputation. Closely related to reputation is proof of humanness (and its collateral: proof of robotness). Reputation is important for a DAO because it could be used by many of the other areas. However, reputation is not fungible (this is my thought, we did not get a chance to dig into this too much) as my reputation for performing task A may be high but that does not mean I’m well suited for task B. Of course we all know this, but to mathematically determine the correlation between task A and task B to determine when reputation matters and when it does not is no small feat. One of the proposals was to have proof of humanness have something to do with an address having a history of utilizing services which only humans can use. Robots could use a decentralized dropbox. Robots cannot use a decentralized Air B’n’B.

Task Distribution

Another area which was interesting to me was how tasks the DAO needs to accomplish would be distributed among the DAO participants. One reason some are excited by the idea of DAOs is they have an ability to reduce hierarchy and flatten decision making trees to a certain extent beyond current legacy organizational models. However, in order to do this, but remain organized, focused on mission, and efficient, one must have a proper distribution of tasks. One participant noted the Holacracy concept. Here’s an small introduction to the concept (which seemed appealing to many of the participants):

Holacracy is a distributed authority system – a set of “rules of the game” that bake empowerment into the core of the organization. Unlike conventional top-down or progressive bottom-up approaches, it integrates the benefits of both without relying on parental heroic leaders. Everyone becomes a leader of their roles and a follower of others’, processing tensions with real authority and real responsibility, through dynamic governance and transparent operations.

In the case of DAO’s this concept could become fractal where you have circles on circles on circles with each area governance and operating itself but within the guise of a collective which maintains a common purpose.

Another way of addressing this problem was by using a more market based | bounty approach. The challenge for DAO designers with a bounty approach is likely to be in balancing incentives to focus on the right tasks. The DAO collective brain will need to have an idea of the total value which is coming into the system because it will not want to focus bounties in one particular area but avoid other areas which will be vital to the success of the DAO.

Self Management

The final topic we touched on was how a DAO can manage itself. This is another hard area. It is similar in nature to how a Linux Kernel manages things. In particular one has to dynamically manage permissions to contract storage and restrict actors to a particular action “pathway”. This is an area which will need much more discussion.

Notes

My notes (for whatever limited value they may be worth) are below:

Conclusion

I thought it was a very productive meeting. Participants were interested in follow up discussions, and we will be holding our second discussion this Sunday, May 4 at CET time, or 1400 EDT time. Please join in!

Happy Contracting!

~ # ~