投票进展：DAO Committee 4/7
研究种类：MolochDAO, Commons, Public Infrastructures, Minimum Viable DAO, Ragequitting, MolochLAO, Eth 2.0
贡献者：Jones ,黑白QB, DAOctor@Daorayaki
MolochDAO是一个旨在资助以太坊2.0grants而创建的去中心化自治组织（DAO）。它被设计成一个最小可行的DAO，并使用简单的智能合约功能来减少潜在的攻击。这些智能合约已被分叉，以开发许多其他DAO，如MetaCartel Ventures和Marketing DAO。
Moloch v2是MolochDAO的升级版本，旨在将Molchdao的业务范围从单纯的单一代币公共物品资助扩展到收购和投资（或投资）无限资产组合。它使DAO可以获取并使用多个不同的代币，而不仅仅是一种。v2版本中引入了公会踢（Guild Kick）机制，该机制允许成员强行删除另一个成员（他们的资产会被全额退还）。它还允许以战利品的形式发行无投票权的股份。最后，v2修复了最初的Nomic Labs审核中提出的“不安全批准”问题。
这类问题通常存在于以太坊平台内，更准确地说，是在Eth 2.0的发展中长期存在。正如最近的 “ETH 2.0现状（The State of ETH 2.0） "报告中提到的那样，Eth 2.0的进展缓慢，主要由于研究人员和实施者人数较少且资金有限。尽管所有以太坊项目都能从升级中受益，但只有少数利益相关者直接投入了资金和开发时间。不幸的是，这是理性的经济行为：为以太坊建设基础设施意味着耗费大量的个人成本，但利益却被整个以太坊生态系统所瓜分。
这些类型的问题（称为“ Moloch问题”）需要重新调整激励措施来解决。实现这一目标的方法之一是使用DAO结构来汇集资金并就资金分配进行投票，利益相关者可以更有效地共享以分担成本，从而带来更大的整体生态系统收益。这是作为MolochDAO的一个假设建立起来的，以提供所需的 "激活能量"，触发利益冲突团体间的协调。
James Young：联合创始人，曾是Ablabed_io的创始人，Collab_land的构建者。参与了Prev Zynga（FarmVille），AdToken，Spankchain，DAOs：Moloch，metaCartel。
Ameen Soleimani：Moloch Ventures的创始人，曾是SpankChain的联合创始人兼首席执行官，在离开创建SpankChain之前曾在ConsenSys担任软件工程师近一年。Ameen在Rensselaer Polytechnic Institute任职，创建了Filter的Potomac Code Camp）。
MolochDAO的机制被认为是深受启发的机制之一，其中对核心问题的各种讨论，如 "公地悲剧--Garret Hardin"、"囚徒困境"、"集体行动逻辑--Mancur Olson"、"公地治理--Elinor Ostrom "都是这个DAO的发展支柱。
在构建MolochDAO时，首要考虑的是始终确保存款资金的安全性，创始人将以太坊上过去的重大安全漏洞（如2016年的The DAO黑客攻击和两次Parity multisig黑客攻击）纳入安全开发的设计原则。
例如，如果行会银行持有100 wETH，并在10个成员之间分配股份，而每个成员都有10股股份，则每股价值为1 wETH，每个成员拥有银行的10％。
投票结束后，宽限期开始。如“Ragequitting”中所述，宽限期为7天，允许会员在强烈反对投票结果时退出公会。成员只有在对提案投反对票时才能自由退出。对通过的提案投赞成票的成员将被迫承担该提案的稀释费用。在宽限期结束时，通过调用processProposal函数来处理提案。从10 ETH提案保证金中扣除0.1 ETH作为奖励，发给调用该函数的会员，以激励其及时处理。
IV. Moloch v2
Moloch v2是MolochDAO的升级版本，它使DAO可以获取并使用多个不同的代币，而不仅仅是一种。它引入了公会剔（Guild Kick）提案类型，该类型允许成员强行删除另一个成员（他们的资产会被全额退还）。它还允许以战利品的形式发行无投票权的股份。最后，v2修复了最初的Nomic Labs审核中提出的“不安全批准”问题。
Moloch v2旨在将Molchdao的业务范围从单纯的单一代币公共物品资助扩展到收购和投资（或投资）无限资产组合。Moloch v2中的提案现在指定了 贡品 和一个 支付代币，可以是任何列入白名单的ERC20。提供贡品代币以换取股份的会员提案现在可以提供任何代币，可能有助于平衡DAO投资组合。资助方案现在可以以股份和稳定币支付，以消除波动性风险，甚至可以完全跳过股份支付外部承包商而不授予成员资格。成员也可以提议交易与公会银行交换场外代币，可用于投资、主动投资组合管理、抛售，或仅用于补充用于支付计划费用的稳定币储备。除上述标准提案外，还有两项特别提案。第一种是将新的代币作为贡品列入白名单，第二种是通过公会踢移除DAO成员。两者都遵循与标准提案相同的投票机制（无法定人数，简单多数规则）。
为了限制对营利性部署Moloch v2的成员的法律责任，成员可以选择成立LAO。LAO是包装在合法合规实体（如LLC或C-Corp）中的DAO。LAO可以签订法律合同，托管离线资产（例如SAFT）并分配股息。LAO的投资者必须获得认可，但是以LAO股份补偿的服务提供商可以赚取其LAO投资组合中的股份。当前的Moloch v2合约标准是通过MetaCartel，ConsenSys的The LAO和Moloch之间的协同努力而设计的。MetaCartel Venture DAO是Moloch v2的首次部署，为其他营利性DAO开辟了道路。
V. Moloch v3
Moloch v3的灵感来自于六边形的架构模式，除了将主合约分解成小合约外，还可以提供额外的安全层。有了这个松散耦合的模块/合约，就创造了更容易审计的模块/合约，并且可以很容易地连接到DAO。V3架构主要由3种主要类型的组件组成： 核心模块
- 每个核心模块都是一个智能合约，在其功能上应用了 "onlyAdapter "和/或 "onlyModule "修改器，它不应该以公开的方式暴露其功能（外部或公共修改器不应该被添加到核心模块的功能中，除了只读的功能）。
Github repository: https://github.com/Moloch-Mystics
V. Contact informations:
Official Website: https://www.molochdao.com/
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
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.
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 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.
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.
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.
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
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.
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 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.
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
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.
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.
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).
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.
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).
- 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.
All MolochDAO contracts are available under the following Github repository: https://github.com/Moloch-Mystics
To those whom are interested in the way MolochDAO was inspired and started you can visit the following links listed below:
VIII. Contact informations:
Official Website: https://www.molochdao.com/