Skip to content

Latest commit

 

History

History

dao-case-study-research

description
Interviews conducted July-August 2019

DAO Case Study Research

Following is Research resulting from Genesis DAO proposal here: https://docs.google.com/document/d/10C9ORmxOfrHvFH0HVIeqZMv3xeXlM-2pd04izFUUr-Q/edit#

The purpose of the research is to investigate:

  • What technology are DAOs using today? We are interested in the DAOs themselves, not the companies making the technology.
  • What is working and not working for them in DAO tech today?
  • What technology is missing? What are they doing through non-tech means?
  • Why did they make the software choices they did make?

9 DAOs were interviewed. 2 had nothing significant to say because they were in early stages. 2 DAOs deferred to a later date

Overall findings

The main finding of the DAO Landscape research was that each use case was incredibly different from the other. The methodologies employed for voting and reputation were extremely dependent on the use-case. It is hard to extrapolate “best practices” or specific industry needs based on the use cases, because they are so diverse.

Currently, the nature of the decisions is limited to yes-no acceptance of proposals. Only one of the DAOs (Betoken) has a solution that can choose from multiple options, and that choice is made by an authority decision rather than everyone voting in a multiple-choice way. Said in an informal way, a group couldn’t choose a restaurant together with any system other than Betoken.

Most of the groups are happy with the initial implementations and the functionality of their systems but those using non-proprietary systems (DAOstack, Aragon, GovBlocks) refer to the solutions as experimental and preliminary.

Technology being implemented

  • Identity: None or manual. Issuing tokens was the only method of identifying an individual’s participation.
  • Communications: Most teams were using Telegram or Discord for communications pre-proposal or about the proposal. Although some solutions have built-in forums (Aragon, GovBlocks), those were not in use by any of the DAOs surveyed. All communication was outside of the governance system.
  • Proposal-making. All proposal making was offline and then submitted into the system. None of the systems had proposal-writing as a specific built-in process.
  • Voting: Aragon 3, DAOstack 1, GovBlocks 1, proprietary 1, not chosen yet: 3
  • Execution: Some solutions have auto-execution of smartcontracts on Ethereum.
  • Reputation: Proprietary 3, DAOstack 1.
  • Dispute resolution: None (Kleros runs a dispute resolution system but it’s not designed for their own self-governance)

Underlying themes

  • Most of the use cases were fairly limited in scope: distribution of funds, development decisions, investment decisions.
  • Several people mentioned that most tokenholders simply don’t care about the onchain governance of the chain/code itself, and that is not a problem. A small percentage of people participate and they expect that to always be the case.
  • The people who were happiest with their DAO solution were those who had developed a proprietary solution, specifically for their needs.
  • None of the solutions were beyond a few hundred users, and most were fewer than 10 people in the decision-making module.
  • Only one solution was trying to onboard people outside the crypto community, and they found onboarding of “regular people” to be difficult, and the ongoing education was a major problem for them.
  • One-token-one-vote was used in most systems larger than a dozen people. In systems with fewer than 10 people (most) the implementation was one-person-one-vote. Nobody thought the one-token-one-vote was problematic for their system.
  • Many governing systems did not allow all tokenholders/stakeholders/users to participate in on-chain governance. Governance regarding the system itself was limited to a small group of people, generally the developers of that system. The actual governing group was typically 4-6 individuals and they called this the DAO. In other words, it's a DAO in the sense that each of those individuals holds equal power, but in the sense that the tokenholders of the system are excluded, and that those people determine who else can join, it runs more like an oligarchy.
  • It's interesting to note that 1-token-1-vote was generally considered fine for the entire tokenholder pool, but 1-person-1-vote was always the case inside the oligarchy DAO. As the decisions moved away from the code core, or as the group became more of an "anonymous mass" of people.
  • Nexus Mutual was the only organization which had thought deeply about the implications of 1-token-1-vote, and put in safeguards (10% upper limit) They also gave all tokenholders votes on the board members, so that rather than an oligarchy, they have a representative democracy in which representatives can be replaced at any time.
  • Several people commented that the propsals and discussions would be difficult to scale, and a few of the DAOs already had sub-teams and nests. This is of concern, given that most of the groups were fewer than 100 people and already breaking out into sub-groups.
  • Voter participation and incentivizing schemes for voter participation are an issue for most DAOs.
  • Concerns about scalability are generally in the area of communications and proposal-making. Many people interviewed said they couldn’t even envision a system that would scale for the communication and proposal making systems.

Technology distinguishing factors

  • Aragon and GovBlocks have automatic smartcontract execution, which was an advantage to some of the DAOs interviewed.
  • Reputation in DAOstack and the implementation of 1-person-1-vote was more appealing to other DAOs.
  • GovBocks has a built-in forum for discussion pre-proposal.
  • All systems we interviewed are built on Ethereum.

Suggestions

  • Teams that were interested in scaling felt the communications channels were messy. This was the first problem cited by several people.
  • Aragon’s forum system “feels” like it is off-platform, and it does not require validation of whether the people are ANT holders. Someone without tokens could have a strong voice. Suggestion of better validation methods or identification of the power of people who are discussing proposals in the forum.
  • Connection between the communications methods and the actual proposal was pointed out as a missing. One of the teams said they would like to have more of a record of the reasoning behind a vote, similar to being able to read the minutes of a government or council meeting.
  • Better advocacy and information for the need for DAOs
  • Ability to gatekeep for proposal validity and/or quality was mentioned as a need when the systems scale.

The limited nature of these systems suggests that the technology is addressing a very small range of decision-making in organizations. The inability to compare between options, collaborate on proposals, and vote on multiple options is a limiting factor in the types of problems that these solutions can address. If DAOs are going to replace centralized foundations, the DAO will need to develop tools for deeper discussion and collaboration on complex issues.