Moloch 2.0: from grant giving to sustainability – MetaCartel

This paper serves as a thought experiment for how multiple DAOs may form to create a self sustaining development ecosystem. The information is built from conversations had surrounding these developments. Please comment with suggestions/corrections!

While the topic primarily revolves around a process built by the Moloch DAO, this does not exclude the value provided by other DAO projects and ecosystems. The future of coordination requires a mixture of collaborative efforts and many teams have built more sophisticated frameworks than what Moloch offers.

This paper proposes a new way to capture and distribute funds through DAOs leveraging Claims Token (CT) contracts (ERC-1843) and a Moloch DAO style framework to form a sustainable, incentive aligned ecosystem between multiple teams and projects.

In particular, we examine a case study of what this could look like for teams collaborating around the development of an application. Under the assumption that there will be revenue generating dApps in the future, the APPDAO concept could act as an engine to provide a sustainable financial path for the grant giving entities existing today in the Moloch and Meta Cartel communities.

The blockchain movement concerns include creating efficient mechanisms for information/value transfer and coordination. DAOs suggest a potential solution to issues involved in the nebulous coordination of today’s society.

For all intents and purposes of this paper, a DAO represents a mechanism that captures value and distributes this value through a decentralized, multi-party decision process. Effectively incentivizing collaboration and coordinating across ecosystems in the public blockchain space is a critical discussion point that has yet to be fully solved. The Ethereum ecosystem in particular has sought to find solutions for effective development of critical network technology since inception.

A first stab at building an ecosystem-wide coordination mechanism manifested in the original DAO of 2016. The experiment quickly failed as an attacker exploited a vulnerability to siphon $50MM of the $150MM from the DAO contract into a child DAO. Today, more than three years after this event, the DAOs of the Ethereum ecosystem begin to re-emerge in a variety of flavors.

While the avenues reaching a revenue generating common resource could shake out in a variety of ways, we see two distinct DAO “types” at play in the newly formed multi-DAO ecosystem.

1. A Funding DAO to collect resources around a particular topic (ETH2.0, APPLayer, Wallets…). These will serve as resource decision making entities.

2. An APPDAO (or project DAOs) to coordinate different teams around a specified project. These DAOs allow for a number of teams to jump into a project together and align themselves via CT.

The relationship between funding DAOs and APPDAOs may be similar to an incubator and a startup, and could vary by situation.

The APPDAOs may apply for funding from the Funding DAO in exchange for DAO Tokens (which they could claim for CT).

Funding DAOs may also submit proposals to APPDAOs if they are keenly interested in contributing to a project.

At the end of the day, the Funding DAOs may hold a portfolio of CT from their ecosystem. All members of the Funding DAO will be incentivized to promote the projects of the claims tokens they hold.

Claims Tokens (CT, ERC-1843)

https://github.com/ethereum/EIPs/issues/1843

Claims tokens start with a Claims Token Contract. This contract will be controlled by the operational entity (like a BBLLC) to govern the initial distribution of the CT. The operating entity will direct revenue generated by the application users toward the Claims Token Contract, constantly filling a fund. Anyone with CT has the opportunity to access their proportional share of the growing revenue in the fund by calling a withdrawal function in the contract.

The token standard mentions the ability for the CT contract to assist in the distribution of all future cash flow “such as dividends, loan repayments, fee or revenue shares…”, the proposed use-case focuses solely on distributing revenue shares generated through the products managed by the operating entity.

MolochDAO Framework

https://github.com/MolochVentures/moloch/blob/master/README.md
https://medium.com/metacartel/molochdao-a-primitive-solution-d11cc522b18e

Moloch DAO was created in February 2018 with an explicitly grant giving mission. The DAO has brought in more than $2MM of community support, reaching the highest amount held in a contract since the original DAO of 2016 (recently surpassed by the dxDAO by Gnosis). On top of this, the implementation has stood for three months without getting hacked. While there are always uncertainties, we see this as a strong sign of the security of the codebase today.

Decisions making in Moloch occur through a very simple proposal and voting design. Members apply with a value of ETH proportional to the amount of voting shares they receive. These voting shares allow the member to weigh in on each vote in a consistent way (proportional to shares).

The purpose of the tools described allows for a simple mechanism to create collaborations via revenue generated from a collaboration (likely a product). This could form a path to sustainability for today’s grant giving DAOs to distribute resources outside of simple tribute.

Step 0 Initial Partnership Formation

CompanyA is building an exciting new app. They share the idea with CompanyB who provide some sort of strategic expertise.

CompanyA wants to manage and operate the app, but want to keep CompanyB involved with the development and launch of the project. Both teams compliment each other in their wants and skills.

After months of part time development, the app is near completion and the two companies begin discussing how to launch. CompanyA agrees to manage the operations and IP around the app, while CompanyB will continue to maintain and update their integrated feature set. The app uses crypto, and the majority of the revenue will come through tokens.

The companies decide that the easiest way to split token revenue is to utilize the Claims Token (CT) standard (ERC 1843). Since CompanyA is taking operational responsibility, they launch the claims contract.

Step 1 Claims Distribution and DAO Formation

CompanyA and CompanyB decide to split the claims tokens. The operating entity will take 50% of the revenue, and the other entity will take 10%. They decide to reserve 40% to attract growth investment at a later date.

They distribute their proportion claims and launch an APPDAO with Moloch-style proposal processing to gather a guild fund and manage the distribution of the reserve CT.

Step 2 Project Launch and Seed Investment

They successfully launch their app after initial user testing and begin generating revenue through fees paid in crypto. A proportional % cashflow is given to each CT holder.

At this time the 40CT in the DAO accrue value to be claimed by DAO members who join and withdraw (burn their shares to access the CT revenue opportunity).

The APPDAO members open the APPDAO for proposals. The APPDAO will administer DOA Tokens (DT) representing voting shares. These shares can be burned to receive a proportional amount of the assets under DAO management (the reserve CT).

The original members establish guidelines based off of budgetary goals. They want $X for product development to be allocated in the next 18 months and let this be known to those writing DAO proposals.

Step 3 Operational Fund Management

With the $$ committed by the DT sale the APPDAO is able to make collective decisions on proposals to progress product development.

Step 4 Exiting to Receive Claims Tokens