DAOrayaki Research｜MolochDAO v1、v2、v3

DAOrayaki

22 min readJun 21, 2021

DAOrayaki DAO Research Grant：

Fund Address: 0xCd7da526f5C943126fa9E6f63b7774fA89E88d71

Voting Result：DAO Committee 4/7 Yes

Grant Amount：200 USDC

Category: (MolochDAO, Commons, Public Infrastructures, Minimum Viable DAO, Ragequitting, MolochLAO, Eth 2.0)

Contributor：Jones ，黑白QB DAOctor@Daorayaki

Chinese Version:https://daorayaki.org/ghost/#/editor/post/60cffbde7d14606fef165266

What is MolochDAO?

MolochDAO is a decentralized autonomous organization (DAO) created to fund Ethereum 2.0 grants. It was designed as a minimum viable DAO and uses simple smart contract functions to reduce the potential attack surface. These smart contracts have been forked to develop numerous other DAOs such as MetaCartel Ventures and Marketing DAO

How it works?

MolochDAO does not utilize a token. Members contribute Eth to a pool and the coinciding wallet address is granted access and voting shares into the DAO, which are ERC-20 incompatible to prevent them from being bought and sold.

I. Background

Purpose

What is the story behind Moloch?

In ancient times, Carthaginians believed that sacrificing a child to Moloch during the war would increase their victory, while members who doesn’t participate are seen as a risk for the tribe’s survival. This practice continued for years, despite the high price they are giving and that is because the tribe incentive structure played a huge roll in this. From this the name “Moloch” was inspired which signifies to the Canaanite God of child sacrifice.

The first-time knowing Moloch for the creators was in “Meditations on Moloch” by Scott Alexander, where he talks about the eponymous character from Allen Ginsberg’s poem, Howl. In Meditations, Alexander points out that, while Ginsberg is typically interpreted as discussing the pitfalls of capitalism, the poet is likely instead referring human beings’ tendency to consistently choose suboptimal solutions to group coordination problem. Alexander gives the following example of a dictatorless dystopia:

“Imagine a country with two rules: first, every person must spend eight hours a day giving themselves strong electric shocks. Second, if anyone fails to follow a rule (including this one), or speaks out against it, or fails to enforce it, all citizens must unite to kill that person. Suppose these rules were well-enough established by tradition that everyone expected them to be enforce.”

With time self-shocking becomes rational to all individuals because if they don’t eventually, they will face death. However, if we flip the coin and assumed that everyone suddenly stops shocking themselves all at once, we are quite sure that this will result a better society for everyone. Alexander goes on to give similar examples from several real-world situations, such as overfishing, arm races, and congress.

All of this was an inspiring reason to adopt Alexander by seeing Moloch as the category of problems associated with collective action, where individual incentives are misaligned with globally optimal outcomes, which needs to be beaten to ensure the long-term survival of humankind. In the context of the MolochDAO, the name “Moloch” is an ironic joke about the possible futility of attempting to solve coordination problems. It is also a meme in and of itself one which is hopefully seen as a solution for the core problem and the recognition of real-life Moloch problems.

What needs to be solved?

Seeing the blockchain “commons” as technology where the total benefit generated by the technology to the community is greater than the individualized benefit to any particular entity, means that the cost for anyone entity to invest in developing infrastructure is disproportionate to the benefit accrued by it, which soon or later will lead to an incentivization problem, often resulting the infrastructure to not be developed at all.

These kinds of problems usually reside within the Ethereum industry, more accurately along the development of Eth 2.0. As the recent “The State of ETH 2.0” report mentioned that the progress towards Eth 2.0 has been slow and conducted mostly by a relatively small group of researchers and implementers with limited funding. Despite the fact that all Ethereum projects stand to benefit from the upgrade, only a few major stakeholders are directly involved in funding and development. Unfortunately, this is rational economic behavior: building infrastructure for Ethereum means incurring a large personal cost but benefit is split between the entire Ethereum ecosystem. What is the incentive to bear that cost while that is the case?

These types of problems, known as the “Moloch problems”, require realigning incentives to solve. One of the ways to do that is using a DAO structure to pool funds and vote on fund allocation, stakeholders share more effectively coordinate to share costs, resulting in a greater overall ecosystem benefit. This was built up as a hypothesis for MolochDAO to provide the required “activation energy” to trigger widespread coordination between groups which otherwise may have competing interests.

MolochDAO vision

MolochDAO mainly concentrates on funding and increasing the development of public infrastructures related to Eth 2.0, which is done by incentivizing coordination between the various Eth 2.0 projects and major ecosystem stakeholders. Additionally, MolochDAO takes into consideration researching collective incentivization and going further to a more generalized version of Moloch that is applicable to an even wider range of suboptimization problems.

II. Team members

- James Young: VP of Engineering (James is the founder of Abriged_io, Makers of Collab_land. Prev Zynga (FarmVille), AdToken, Spankchain. DAOs: Moloch, metaCartel).

- Arjun Bhuptani: Co-founder of Connext (Arjun is the Founder of Connext, an Ethreum developer, game theory enthusiast). Currently, he is the Co-creator of MolochDao

- Ameen Soleimani: Co-founder and CEO of SpankChain (Ameen worked as a software engineer at ConsenSys for almost a year before leaving to start SpankChain. Ameen studied chemical engineer at Rensselaer Polytechnic Institutem founded Potomac Code Camp, Filter). Currently, he is the founder of Moloch Ventures.

III. The ideas Behind MolochDAO’s mechanism

To maintain consistency with the minimum viable DAO architecture there is no on-chain governance mechanism. Instead, upgrades to the protocol are coordinated off-chain by deploying a new DAO smart contract and exiting Moloch if they wish to participate in the upgrade.

MolochDAO’s mechanism is considered one of the heavily inspired mechanisms, where various historical discussions of the core problem such as “Tragedy of the Commons — Garret Hardin”, “The Prisoner’s Dilemma”, “Logic of Collective Action — Mancur Olson”, “Governing the Commons — Elinor Ostrom” was used to identify the pillars of such a DAO.

Aligning Incentives

Finding a solution to this problem requires restructuring incentives so that costs and benefits are split equally amongst all participants. The MolochDAO does this by pooling user funds and locking them up in a contract called the Guild Bank, from the other hand the Guild Bank contributors are given voting rights over how those funds should be spent, proportional to their contribution relative to the total pool.

This mechanism is defined as a core mechanism of MolochDAO which is simple and straightforward. However, additional mechanisms are also included to make the DAO much more interesting:

Members of the DAO are able to liquidate their votes to retrieve a proportional share of the funds from the guild. This gives a strong financial incentive to members to try to maximize the value of their votes either by increasing their proportional ownership of the pool or by increasing the value of the pool overall. Note that liquidating their votes means sacrificing decision-making capabilities over the future of the pool.

Self vs. Group Interest

If, for instance, members need to build shared infrastructure which would result in collective benefit (represented by an increase in the value of the resource), then the value calculus for whether to build the infrastructure is now based on the probability that the group’s total cost would be lower than the group’s total benefit. In other words, for a rational investor, it makes sense to invest in a proposal when that proposal is likely to increase the value of the pool by more than the cost that is split amongst all members. The simplest way of representing this cost is to inflate the supply of the index token so that all members are diluted proportionally. As an analogy, imagine if 50% the companies represented by the S&P500 need some open source accounting infrastructure. This infrastructure would cost any individual company 5% of their stock price to build and would only improve each company’s stock value by 1%. Building the infrastructure would not be economically rational for any company individually, because the cost would far outweigh any benefit. However, if the investors in the S&P500 inflated the supply of the index by just 0.01% (i.e. 5% divided by 500), diluting themselves down by that amount, they could pay that to an independent organization to build and open source the technology and have each company integrate it. This would yield a stock price benefit of 1% across 50% of the companies the index (0.5% benefit to the S&P500 overall) meaning that the investors would have gained 0.49% value on the index.

Note here that the value of the underlying asset (ether, in this first version) is not actually inflating, just of the index (voting shares in the MolochDAO) which represents the asset. This is important because the investors, i.e. the primary beneficiaries of the the index, are the ones who pay the cost of coordination. This holds true in the MolochDAO as well.

Restricting Access

Members of the DAO are assumed to be at least somewhat aligned on overarching purpose — whether it be to fund Eth2.0 development or some other infrastructural goal. Second, it is assumed that members will be willing to sacrifice short term benefit in order to pursue the purpose of the DAO. For ETH 2.0 its assumed that rational long-term ETH holders and projects building on the platform will see the value in contributing to its ongoing development, lest they see the value of their holdings drop and their platform be technologically surpassed. In a truly permissionless paradigm, this would not be acceptable assumptions to make. Instead choosing to restrict access to joining the guild by having existing members vote on new entrants in a similar fashion to funding proposals.

This solves both of the above problems. For the first, existing members are naturally incentivized to only admit new entrants who are aligned with the guild’s interests in order to share costs with them. For the second assumption, it is expected that when considering a new applicant, existing members will consider previous interactions with that applicant which will drive applicants towards longer-term benefit strategies. This is covered more in depth in “Ragequitting” below.

Ragequitting

In any voting-based system, there are a large number of edge cases created by possible collusion or unavailability of stakeholders. To handle these, a catch-all mechanism is builtthat allows participants to exit with their funds if they did not agree with the result of a vote. This is done by allowing members to “Ragequit” the guild within a “grace period” after voting on a proposal completes but before those members’ ownership is affected by that proposal.

Let’s say for instance that 99% of the guild colludes and submits a proposal to issue 99% more Shares to themselves and dilute the remaining 1% down to effectively zero. In this case, the 1% would Ragequit the guild during the grace period, negating the majority voting bloc’s attack.

Note that the remaining members after the grace period ends bear the cost of the proposal. In the case of a contentious vote where a large minority exits (e.g. a 51% attack), this means that cost is greatly increased for those who stay. To enforce this, a restriction for Ragequitting is made to only members who voted “No” in a given proposal if the proposal passes. These forces “Yes” voters to bear the cost of a malicious proposal. This is expected to create an interesting additional meta-incentive for mutual cooperation, since guild members would be strongly disincentivized to submit proposals that might cause a large proportion of other members to ragequit.

Readers may note that an attack vector exists where participants can repeatedly Ragequit to either avoid dilution or grief the guild. This would be an effective method to avoid paying the cost of a single proposal. However, if the member wanted to avoid paying they would have to Ragequit the entirety of their shares, completely removing them from the guild. They would then have to reapply as a member, and it is expected that existing members would be hesitant to readmit the defecting applicant. From existing game theoretic research perspective this will be a strong incentive for members to not abuse the ragequit mechanism.

Hypercompetition and Forked Evolution

The Ragequit mechanism can push Moloch to fragment into sub-entities when contentious disagreements are reached. Also, Moloch is upgraded by having all members ragequit and start over. This is a feature, not a flaw. Moloch is wanted to be forked, upgraded and iterated on rapidly, both with new onchain and offchain mechanisms. A major driver for this will be guild size — members are incentivized towards increasing the pool value since it would mean a lower per-person cost per proposal, but are also incentivized to keep guild small enough to retain voting power and keep guild philosophy aligned on a specific goal. Once this balance is exceeded, strong incentives are there for new applicants to fork the core guild and build their own. Since the code is open source, and since they could easily add rewards for early participants in their own guild, leading eventually create a hypercompetitive market for MolochDAOs

Free Riders

Any solution to the Tragedy of the Commons would be remiss without a discussion of the free rider problem. Simply put, how to ensure that other entities do not also share in the benefit of an ecosystem when the cost is paid only by a single or small group of projects?

Solving this problem is not possible when the Guild Bank is collateralized only with wETH as all ETH holders would always share in some of the benefit of Ethereum’s upgrade and the increased price/utility of ETH. However, there are enough stakeholders who care enough about coordinating around Eth 2.0 that the molochDAO is able to validate the technology and core game theory.

Learn from the old to build the new

In building the MolochDAO, the first concern was to ensure the security of deposited funds at all times, where the founders looked to past major security breaches on Ethereum, such as the 2016 DAO hack and both Parity multisig hacks, to put together a set of design principles for secure development.

First and foremost, a goal of putting only the absolute minimum set of functionality on-chain is set. In the vast majority of edge cases, social coordination mechanisms (offline coordination) can be used as roundabout solutions to problems. By minimizing on-chain coordination, the potential attack surface is reduced to account for.

Second, the founders decided to follow iterative development methodology by choosing to only increase complexity upon validation of core game theory and technology assumptions. For instance, in the DAO MVP, only wETH is allowed as a tribute. While doing it this way does not let us validate the entirety of the game theory proposed above, building the MVP this way allows the MolochDAO to be immediately useful to the ecosystem.

Lastly, complexity tradeoffs to building in upgradeability in contracts are observed. Thus, an experimentation with a library-based architecture is done, but the additional friction of use and increased attack surface were not valuable enough to focus on over validating the core use case. As such, upgrading from the simplest standpoint: participants can coordinate offchain when an upgrade needs to happen by deploying a new DAO smart contract and exit Moloch if they choose to participate in the upgrade.

Moloch Shares

The MolochDAO uses Shares to satisfy game theoretic conditions. Shares are requested on a per-proposal basis and are expected to be issued proportional to the applicant’s tribute amount as compared to the total pooled funds. Shares confer the right to vote on proposals for how the resources in the Guild Bank should be allocated. They can also be irreversably redeemed via Ragequit for a portion of the Guild Bank’s held funds at any time proportional to ownership.

For example, if the Guild Bank holds 100 wETH with Shares distributed among 10 members and each member has 10 Shares, then the value of each share is 1 wETH and each member owns 10% of the GB. If a single member leaves and liquidates their 10 Shares, the Guild Bank total value drops to 90 wETH. However, each member still holds 10 Shares and so still owns 10 wETH. Their relative ownership of the GB (and thus their voting power) changes from 10% → 11.11%.

Shares are not transferable. This means they are incompatible with the ERC20 standard, and that is to ensure that votes cannot be bought and sold on the open market, and so that if members are bribed to submit proposal or votes it can still be more easily attributed to them.

Joining Moloch

Joining the guild requires submitting a membership proposal along with a tribute in wETH. A membership proposal requests a certain number of Shares in return for the tribute. Existing members of the guild vote on the proposal, including whether to grant the requested Shares. If the membership proposal is accepted, the tribute tokens are deposited into the Guild Bank and new Shares are minted and issued to the applicant. If the membership proposal is rejected, the tribute tokens are returned. In order to reduce spam, membership proposals may only be submitted by existing guild members. This means that applicants must convince an existing member to champion their proposal when they apply. Additionally, membership proposals require a 10 ETH deposit, 9.9 ETH of which is returned after the proposal is processed, regardless of outcome. The remaining 0.1 ETH is reserved to incentivize processing the proposal once it is ready

Aborting a Membership Proposal

A vulnerability discussed in this construction is the possibility of a member submitting a proposal with an applicant’s tribute and maliciously requesting fewer Shares than what the applicant was expecting. If the proposal passed, this would mean that the guild purchased the applicant’s wETH at a steep discount.

To counteract this, new applicants are able to abort their membership proposal during an Abort Period that starts immediately when the proposal is submitted. Aborting during this time will prevent submitting any future votes on the proposal and will cause the vote to fail regardless of the votes already cast. Aborting will automatically return all tribute to the applicant just as if their proposal had been rejected. The 10 wETH proposal deposit, however, will still only be returned to the member who submitted the proposal once it is processed. Since it was their fault for submitting the proposal with the incorrect number of shares requested, they should not stand to benefit (by having their deposit returned early) from the applicant aborting the proposal.

Note that, by default, the MolochDAO will have an Abort Period that lasts for 1 day into the Voting Period. This stops potential griefing vectors where applicants maliciously create proposals that they intend to abort in order to waste members’ time. Members can vote with confidence on proposals that have been in the Voting Period for at least 1 day knowing they can no longer be aborted.

Submitting Grant Proposals

Submitting a grant funding proposal utilizes the same underlying contract mechanisms as those used by membership proposals. As above, the proposal may only be submitted by a member of the guild. In this case, the proposal would contain some work to be delivered in exchange for a requested number of Shares. For recordkeeping, the proposal details can be hashed and stored on IPFS.

Members then vote on the proposal. If accepted, the Guild Bank mints new Shares and issues them to the grant funding applicant.

Voting on Proposals

Proposals are voted on in the order that they are submitted and can be parallelized subject to certain limitations. For the MVP, the voting period of each proposal is 7 days. Up to 5 proposals may be submitted per day and so there are a maximum of 35 proposals being voted on at any given time (each staggered by 4.8 hours). Futhermore, votes are won by simple majority with no quorum requirement. Unlike other voting systems where members are immediately locked into the outcome of a vote, because Moloch provides a grace period during which members who voted No can exit.

From the other hand, members are only able to vote once on proposals. Votes are counted and finalized at the end of the voting period but BEFORE the start of the grace period or the subsequent issuance of new Shares. This means that an application for new Shares issued will not be added to Yes or No votes on active proposals. Additionally, members who Ragequit on one proposal will not be removing their votes from the vote on a different active proposal. Because Ragequitting members who voted No do not have their votes deducted and members who voted Yes can’t ragequit, the vote tally for a proposal is final as soon as its Voting Period is complete.

Grace Period

After votes are finalized, the Grace Period begins. As mentioned in “Ragequitting”, the Grace Period lasts 7 days and allows members to exit the guild should they strongly disagree with the outcome of a vote. Members can only freely exit if they vote No on a proposal. Members who vote Yes on a proposal that passes will be forced to bear the cost of dilution from that proposal. At the end of the Grace Period, the proposal is processed by calling the processProposal function. A reward of 0.1 ETH is deducted from the 10 ETH proposal deposit and sent to the member that called the function to incentivize timely processing.

Because proposals are parallelized, there are some edge cases around Ragequitting and the Grace Period. First, Ragequitting a proposal will mean that all active (i.e. being voted on) proposals and all other proposals currently in the Grace Period will not affect the member. This could result in a bad outcome for the member if they were simultaneously issued Shares in another proposal being processed at the same time (thus disincentivizing them from Ragequitting). It could also be the case that a new applicant, after joining and being issued shares, immediately suffers dilution because of a malicious proposal queued directly after theirs. These types of cases are handled by the staggered queue. In the absolute worst case, a member will always have a maximum of 4.8 hours where all previous proposals have completed being processed and they can still ragequit

Dilution Bound

As a safety mechanism, a dilution bound is built to stop a large set of colluding actors from forcing a minority of guild members to experience massive dilution in a single hit by all Ragequitting at the same time. ADilution Bound field is specified in the contract (default = 3) which bounds the maximum dilution that a member can suffer.

For instance, if 80% of the voting power of the guild were to Ragequit all at once, the remaining members would suffer a 5x dilution. When the proposal is being processed, the Dilution Bound would be triggered and the proposal would fail, i.e. no new Shares would be issued. Since Ragequitters would have taken their proportional holdings of ether, the total Guild Bank balance would be reduced but the remaining members would have exactly the same ether as before the proposal was processed. If the remaining members, then wanted to, they could re-submit the proposal.

Initializing the Guild

Since the process of adding new members to the guild and minting new Voting Shares requires a vote of all guild participants, adding the initial set of participants to the guild will require a different process.

For the MVP, the MolochDAO contracts will be deployed with one “summoner” member address in the constructor. Then, this member, utilizing their one vote, will manually add a set of initial founders to the guild by issuing Shares for a fixed entry tribute

IV. Moloch v2

Moloch v2 is an upgraded version of MolochDAO that allows the DAO to acquire and spend multiple different tokens, instead of just one. It introduces the Guild Kick proposal type which allows members to forcibly remove another member (their assets are refunded in full). It also also allows for issuing non-voting shares in the form of Loot. Finally, v2 fixes the “unsafe approval” issue raised in the original Nomic Labs audit.

Design Principles

In developing Moloch v2, molochDAO stuck with its ruthless minimalism, deviating as little as possible from the original while dramatically improving utility. Thus, many features are skipped again and the design represents a Minimally Viable For-Profit DAO, yet one flexible enough to support a variety of use decentralized cases, including venture funds, hedge funds, investment banks, and incubators.

Overview

Moloch v2 is designed to extend MolochDAO’s operations from purely single-token public goods grants-making to acquiring and spending (or investing in) an unlimited portfolio of assets. Proposals in Moloch v2 now specify a tribute token and a payment token, which can be any whitelisted ERC20. Membership proposals which offer tribute tokens in exchange for shares can now offer any token, possibly helping balance the DAO portfolio. Grant proposals can now be in both shares and a stablecoin payment token to smooth out volatility risk, or even skip shares entirely to pay external contractors without awarding membership. Members can also propose trades to swap tokens OTC with the guild bank, which could be used for making investments, active portfolio management, selloffs, or just to top off a stablecoin reserve used to pay for planned expenses. In addition to standard proposals above, there are two special proposals. The first is for whitelisting new tokens to be eligible as tribute, and the second is for removing DAO members via Guild Kick. Both follow the same voting mechanics as standard proposals (no quorum, simple majority rules).

MolochLAO

In order to limit legal liability on members of a for-profit deployment of Moloch v2, the members may opt to form a LAO. LAOs are DAOs wrapped in a legally compliant entity, such as an LLC or C-Corp. The LAO can enter legal contracts, custody offchain assets (e.g. SAFTs), and distribute dividends. Investors in a LAO must be accredited, but service providers compensated in LAO shares can earn their shares of the LAO portfolio. The current Moloch v2 contract standard was designed through a collaborative effort between MetaCartel, ConsenSys’s The LAO, and Moloch. The MetaCartel Venture DAO is the first deployment of Moloch v2 and blaze the trail for other for-profit DAOs to follow.

Security Tokens

To interface with offchain securities like SAFTs, the MolochLAO will issue security tokens that follow the Claims Token Standard ERC-1843 and the Simple Restricted Token Standard ERC-1404. Upon distribution of the SAFT tokens, the LAO custodian would send them to the claims token contract to be distributed to the claims token holders.

For equity, debt, or other revenue yielding securities the LAO custodian would receive the proceeds, liquidate to a token suitable for dividends (e.g. DAI) and then send the dividend tokens to the claims token contract to be distributed to the claims token holders.

Members that ragequit and receive their fraction of all LAO-held security claims tokens will still be able to use their various claims token to withdraw their dividends from each claims token contract.

Transfer restrictions will be enforced such that the security claims tokens can only be transferred to other DAO members, or other addresses whitelisted by the LAO admins.

V. Moloch v3

Even though Moloch is very useful and powerful, it has a lot of unnecessary features. Also, there are a few features that are missing and are hard to change. This is why a more modular approach has been introduced to Moloch architecture, which will provide:

- Simpler code, each part would do something more specific, this means easier to understand.

- Adaptable, each part is adaptable of the DAO to the needs of the ones using it without the need to audit the entire code bade every time.

- Upgradable, it should be easier to upgrade parts once the need evolves. The best example is voting, maybe the way of voting evolve with time and it is good to be able to upgrade that economic, such as some modules being used by multiple DAOs without the need to be redeployed

Moloch v3 was inspired by the hexagonal architecture pattern that can provide additional layers of security in addition to breaking the main contract into smaller contracts. With this loosely coupled modules/contracts has been created, which are easier to audit, and can be easily connected to the DAO.

V3 architecture is mainly composed of 3 main types of components:

- Core Modules:

- Core modules keep track of the state changes of the DAO.

- Each ore Module is defined via Interface, implemented, and registered into the DAO registry module when the DAO is created.

- The core module name Registry keeps track of all registered core modules, so they can be verified during call executions.

- Only Adapters or other Core Modules are allowed to call a Core Module function.

- Core modules do not communicate with External World directly, they need to go through an Adapter.

- Each core module is a Smart Contract with the “onlyAdapter” and/or “onlyModule” modifiers applied to its functions, it shal not expose its functions in a public way (external or public modifier should not be added to core module functions, except for the read-only functions).

- Adapters:

- Public/External accessible functions called from External World.

- Adapters do not keep track of the state of the DAO, they might use storage but the ideal is that any DAO relevant state change is propagated to the Core Modules.

- Adapters just execute Smart Contract logic that changes the state of the DAO by calling the Core Modules, they also can compose complex calls that interact with External World to pull/push additional data.

- Each Adapter is a very specialized Smart Contract designed to do one thing very well.

- Adapters can have public access or access limited to members of the DAO (onlyMembers modifier).

- External World:

RPC clients responsible for calling the Adapters public/external functions to interact with the DAO Core Modules

The main idea is to limit access to the contracts according to each layer. External World (e.g: RPC clients) can access core modules only via Adapters, never directly. Every adapter will contain all the necessary logic and data to provide to the Core modules during the calls, and Core Modules will keep track of the state changes in the DAO. An initial draft of this idea was implemented in the Financing Adapter which allows an individual to submit a request for financing/grant. The information always flows from External World to the Core Modules, never the other way around. If a Core Module needs external info, that should be provided via an Output Adapter instead of calling External World directly.

VI. Contracts

All MolochDAO contracts are available under the following Github repository: https://github.com/Moloch-Mystics

VII. References

To those whom are interested in the way MolochDAO was inspired and started you can visit the following links listed below:

Moloch Wikipedia Page

Meditations on Moloch — Scott Alexander

Howl — Allen Ginsberg

Logic of Collective Action — Mancur Olson

The State of Ethereum 2.0 — Kyokan

Funding the Evolution of Blockchains — Fred Ehrsam

The Tragedy of the Commons — Garrett Hardin

The Prisoner’s Dilemma