Community Contribution Opportunity
A new mechanism for capital coordination within decentralized communities
Tl;dr
A Community Contribution Opportunity (CCO) is a new mechanism for capital coordination that increases the amount of capital available to fund projects by strengthening protections and lowering risks for capital contributors.
A CCO uses DAO tooling to orchestrate capital contributions to projects in a non-custodial fashion. Capital contributors maintain custody over their capital and have governance power over how it is spent, embedding them as active participants in the project’s community and protecting them from risks without the need for trusted relationships.
These reduced risks make contributing capital significantly more attractive, making more capital available to fund projects, especially for decentralized communities and DAOs looking to amplify the positive impact they can have on the world.
Decentralized communities and DAOs can conduct a CCO today using the DAOhaus platform.
Current problems in capital coordination
Capital coordination is an incredibly powerful concept that has driven many of the advances in human well-being. But it has yet to reach its true potential.
If humanity were able to better coordinate capital, we could fund many more valuable projects to further advance aggregate human well-being and help alleviate the unjust distribution of that well-being.
What’s stopping that from happening? There are two big, compounding problems. Current capital coordination mechanisms create information asymmetries and require capital contributors to trust project teams with little recourse. Together, these issues exacerbate the inherent risk of any venture and further limit the amount of capital that would-be contributors are willing to make available to fund projects.
The amount of capital available to fund valuable new projects is inherently limited by the risk of contributing capital to those projects. The higher the perceived risk of losing capital with little to no return, the less interested people are in contributing capital to a project.
Downside risk can be offset by the perception of a high likelihood of a positive return (or even a low likelihood of a large return), but the effect is not symmetric: the wealthy are able to accept the high risk of loss in exchange for the chance of outsized returns much easier than the less wealthy, who may not have that luxury. This structural inevitability exacerbates wealth inequality and promotes unjust outcomes.
Information Asymmetry
A key factor influencing a person's perception of risk is information. The more information you have about the project and related factors, the better you can assess each. But access to information is not equal; project teams know a lot more about what’s going on with their project than anybody else, which multiplies the risk perceived by would-be capital contributors.
If left unchecked, information asymmetry can result in fraud and theft. To combat it, current laws and regulations impose significant constraints and responsibilities on both project teams and prospective capital contributors.
In order to raise capital from the general public, project teams must register their securities and/or make long, complicated, and expensive regulatory filings to receive approval from regulators (subject to only certain exemptions) and are often required to report regular updates to regulators and capital contributors.
Capital contributors are often restricted from participating altogether based on an arbitrary threshold of personal wealth. This is (ostensibly) meant as a form of protection for capital contributors to ensure they are knowledgeable and can sustain a “total loss” of the capital they contribute. In reality, it primarily serves to exacerbate wealth inequality and, counterproductively, reduce the total amount of capital available for projects to do good things in the world.
Trust Requirement
Today, capital contributors must fully part with their capital and trust the project team to wisely deploy it towards the stated objectives. Combined with information asymmetry, this trust requirement creates significant risk for capital contributors, and is ultimately largely responsible for reducing the total amount of capital available to projects. The myriad regulations designed to mitigate this problem have unwanted chilling effects of their own, and are only partially successful at achieving their stated goal.
What if there were a way to change the game so that capital contributors didn't need to part with their capital until actually deployed in service of the project? What if capital contributors didn’t need to place their trust entirely in a combination of the project team and a slow, expensive legal system? What if we could enable the kind of transparency and information symmetry that current regulations strive to promote, but without needing costly filings and disclosures? Imagine how much capital could be freed up to fund new, valuable projects!
Community Contribution Opportunity
We think there is such a way.
Using DAO smart contracts, we can enable capital contributors to fund projects while simultaneously maintaining custody and control over their capital. In other words, custody of the capital doesn’t pass to the project team until they actually spend the funds, and, even then, the capital contributors have the ability to withdraw those funds if they disagree with any aspect of how that tranche of funds will be spent.
We can extend this concept even further. By introducing a project token that represents their capital contribution, we can allow capital contributors to maintain custody and control over the value they contributed over the entire life of a project, long after their capital has been deployed.
The same concept of exit rights – the ability to withdraw capital at any time, including in response to an unwanted proposal to spend it – also gives capital contributors a form of governance power over how the collective capital is deployed. This represents yet another form of protection for capital contributors, and by engaging them in governance it also brings them more deeply into the project’s community. For decentralized communities (including DAOs) for whom the size and quality of their community is crucial, the latter is particularly valuable.
We call this new construct a Community Contribution Opportunity (CCO) because it draws capital contributions to a project from within its existing extended community, including the initial project team’s network, the project’s early participants or users, other contributors, etc. Even if some capital contributions happen to originate from outside that network, the active role in governance that a CCO induces them to take brings those contributors into the community. This is in direct contrast to more passive forms of capital coordination in which most investors remain at arms length from the project itself.
One abstract way to think about a CCO is as Reg CF-style crowdfunding but where the contributors a) can pull back their funding if something goes awry, and b) receive governance power over and long term alignment with the project.
How does a CCO actually work? In the next section, we’ll explore that in detail.
CCO Ingredients
The most important part of a CCO is the community (it’s right there in the name!). Within the community, there are two main roles: the project team and the capital contributors. These labels are imperfect and used here solely for the purposes of concreteness. These roles are not necessarily mutually exclusive, and there is often significant overlap – it’s common for members of the project team to contribute their own capital, or for capital contributors to start making other kinds of contributions as well – but we’ll distinguish between them here for the sake of explanation.
The project team comprises the initial members of the group that contribute work, time, and expertise to the project. They are seeking capital for the project in order to expand their ability to dedicate more time, to bring in additional contributors, pay necessary expenses, or a combination of all three in order to advance their project to the next stage.
The members of the project team will have direct governance rights (in the form of voting shares) over the capital contributed by the community. As we’ll shortly see, however, this does not mean that the project team collectively has exclusive control over the capital.
The capital contributors are the members of the community (existing or new) that have capital to contribute to the project. They are seeking some kind of return on their capital, whether to themselves (i.e., similar to an investment) or for the community (i.e., similar to a grant or donation), or both. By design, CCOs promote long-term engagement within the community, so CCO capital contributors tend to be values-aligned rather than speculators.
Through the exit rights conferred by their economic shares (explained below), the capital contributors can exercise indirect governance rights over the capital they contribute. In this way, even those capital contributors that don’t also assume the role of project team member end up taking an active role in the community.
Tools
Together, the project team and capital contributors will use several web3-native tools to coordinate on the CCO:
A Moloch DAO
Capital
Project token
Transmutation minion
Vault smart contract
Moloch DAO
The Moloch DAO framework was inspired by the original Moloch DAO and has since been used by hundreds of DAOs. It has several core properties that are key to a CCO:
Non-transferable membership in the form of shares. There are two types of shares: “full shares” with full voting rights and “loot shares” with economic rights and indirect governance power.
Weighted voting rights, represented by the number of full shares a member has.
Economic exit rights (aka “ragequit”), represented by the total number of shares and loot shares a member has, which is also a limited form of governance power. This is the most important property for a CCO.
Proposals involve a voting period (during which members vote with their full shares) and a grace period (during which any member who didn’t vote yes can ragequit). A passed proposal can be executed only after the grace period.
A Moloch DAO can hold assets (e.g., capital) in its treasury, and that capital is collectively controlled by the members of the DAO. Members with full shares can vote on proposals for how to deploy the capital. Members with loot shares can ragequit at any time to leave with their pro rata portion of the capital in the DAO treasury.
Importantly, the ragequit mechanism allows members to leave the DAO during the grace period after a proposal passes, but before it can be executed. This creates strong protections for members with minority shares, since they’re never at the mercy of the rest of the DAO and can always leave with their capital before it is spent. Ragequit is what gives CCO capital contributors control over their capital — without relinquishing custody! — even while it remains available to fund the project.
In the context of a CCO, individuals on the project team get full shares, typically in proportion to how much value they’ve created for the project thus far. Capital contributors receive loot shares, in proportion to how much capital they contribute.
Capital
Initially held only by the capital contributors, the capital must be in an ERC20 token form. Typically it is a stablecoin like DAI, but could also be some other money-like currency (e.g., wrapped ETH or wrapped Bitcoin), or even other assets such as personal tokens. As long as it can be represented as an ERC20-compatible token, anything that the project can leverage to help achieve its objectives can serve as capital. The project team determines which types of capital the CCO will accept.
Project Token
The purpose of the project token is to represent the value that all individuals contribute to the project, including “sweat” contributions from the project team as well as both capital contributions and governance activities from the capital contributors.
Typically, the token is a standard ERC20 token, though some modifications can be valuable (see the Modifications section for an example).
During the CCO, the token serves as a record of contributions to the project. After the CCO, the token can play subsequent roles depending on the needs of the project. For a project building an open web3 protocol, for example, it could act as the governance token for the protocol. For a project establishing an autonomous social community, it could serve as the social token. Or it could simply remain a record of past contributions.
Depending on the future role the token will play, the project team can select what properties the token should have, such as a fixed or adjustable supply, the initial supply, etc.
Transmutation Minion
Moloch Minions are smart contracts that add capabilities to a Moloch DAO. They allow a DAO to execute more complex actions, and are controlled by the same proposal process as standard Moloch DAO functions.
The purpose of the Transmutation minion is to convert the capital into the project token as the capital leaves the DAO. This is the process that enables the system to be fully non-custodial, giving capital contributors control over the value of their contributions throughout the life of the project.
The Transmutation minion holds enough project tokens to (eventually) replace the capital in the DAO. When the project team makes a proposal to deploy some amount of capital (e.g., for expenses or to pay developers) and the proposal is executed, that amount of capital leaves the DAO. At the same time, the Transmutation minion replaces the capital with the commensurate amount of project tokens.
As capital is deployed in service of the project, it is replaced in the DAO by the project token. Since the capital originally came from the capital contributors, all of the project tokens that replace it go to the capital contributors.
Here is an early example of a Transmutation minion smart contract.
Vault
The purpose of the Vault is to hold project tokens for later distribution to various recipients once a predetermined unlocking condition is met. The allocation of project tokens is hard-coded into the Vault smart contract; each recipient (and only the recipient) can later claim their allocation from the Vault.
The most important recipients are initial members of the project team, and the Vault is where virtually all of their allocation of project tokens will come from over the course of the CCO. Locking up the project team’s tokens until the capital is spent creates a strong incentive for them to complete the planned work, and to do so in a way that the capital contributors support.
Other recipients can include a future project DAO treasury, allocations for future members of the project team, distributions to project participants or users (e.g., in the form of a retroactive airdrop), or anything that is relevant to helping the project succeed.
The unlocking condition is typically when all capital has been deployed from the DAO. At this point, the planned work should be finished and so the project team and capital contributors can start to receive their project tokens (by claiming from the Vault and ragequitting from the DAO, respectively).
Here is an early example of a Vault smart contract.
Lifecycle of a CCO
The life cycle of a CCO breaks down into four distinct phases:
Setup
Contribution
Buidl
Distribution
We’ll walk through each of them to outline the entire lifecycle of a CCO.
Phase 1: Setup
In this phase, the project team gets everything ready for the CCO. This involves the following steps:
Summon the DAO, with the individuals on the project team receiving full shares (typically in proportion to their contributions to the project thus far).
Establish the CCO parameters:
Global min and max contribution amounts.
Individual capital contributor min and max contribution amounts.
Establish the project token allocation (e.g., how much goes to the project team, the capital contributors, and other future recipients).
Establish the exchange rate between capital and the project token. This is important for Transmutation.
Create the project token, with the specified supply parameters.
Deploy the Transmutation minion smart contract.
Send the relevant project token amount to the Transmutation minion.
Deploy the Vault smart contract, instantiated with individual recipient allocation and claim logic.
Send the relevant project token amount to the Vault.
Send enough project tokens to the DAO to back the project team's full shares. This ensures that the capital contributors’ loot shares are not diluted.
Also in this phase, capital contributors get their capital ready.
Phase 2: Contribution
After the Setup Phase, everything is ready for capital contributors to start making their contributions. To make their contributions, each capital contributor makes a membership proposal to the DAO, including their capital as “tribute” and requesting the commensurate amount of loot shares1.
If the proposal is formulated correctly — i.e., tribute is within the between the min and max capital contribution amount and correct number of requested loot shares — the project team will use their full shares to vote yes on the proposal. If it passes, once the grace period is finished, the contributed capital enters the DAO treasury and the proposer receives their loot shares.
Remember, a capital contributor can ragequit their loot shares to leave with their capital at any point. If they see something they don’t like even at this early stage, they can leave with nothing lost.
If and when the global contribution max is reached, this phase is complete and the CCO moves to Phase 3. If the global min is not reached, then, like Kickstarter, the entire thing unwinds and capital contributors can ragequit to retrieve their capital.
Phase 3: Buidl
This is the phase where the magic happens.
The project team works on their project, deploying the capital periodically over time to fund their activities. This can include covering expenses, compensating contributors, or whatever is needed to advance the project towards its goals.
The capital contributors remain involved throughout this phase. As described above, often this is directly as members of the project team themselves. And if they are not already part of the project team, the economic exit rights give them a role in guiding the project team and providing community-building resources.
To deploy the capital, the project team makes proposals to spend it. When capital leaves the DAO it is replaced by (i.e., Transmuted into) the project token at the exchange rate established during Phase 1.
At any time — including after a proposal passes but before it is executed — a capital contributor can ragequit to receive back the remaining portion of their capital along with their portion of the project tokens that have been transmuted into the DAO thus far. This can happen for any reason; remember, the capital contributors maintain full custody of the value they contribute.
For example, a capital contributor could disagree with the way the project team is spending the capital, disagree with the direction that the project has taken, perceive that the project team is not being transparent enough, or suspect that the project team is attempting to steal the funds. They could even simply have found a better use elsewhere for their capital.
Because capital contributors always have this option, they wield a fair amount of governance power over how the capital is spent even though they don’t vote directly on proposals. To ensure that they maintain access to the capital to fund their activities, the project team needs to give frequent, transparent updates to the capital contributors. Often, they will seek preliminary feedback from capital contributors to create alignment before submitting a new proposal for the next tranche of funding.
Once all of the capital has been deployed and only project tokens remain in the DAO, this phase is complete and the CCO moves to Phase 4.
Phase 4: Distribution
At this point, there is no more capital in the DAO for the project team to spend on the project, which triggers two things to happen simultaneously.
For one, the capital contributors can ragequit their loot shares from the DAO to receive their portion of the tokens. The project team can also ragequit their full shares from the DAO, though by design the amount of project tokens they receive in this way is minimal compared to what they receive from the Vault.
Additionally, the Vault’s unlocking condition is triggered. The project tokens become claimable by the recipients, including the members of the project team.
And that’s a CCO! The project has advanced to the next level, the project team has grown and been able to compensate its contributors for their work, and both the project team and capital contributors have received project tokens representing their respective contributions. All without any actor relinquishing custody of their capital until it was deployed in service of the project.
Modifications
Many modifications to this foundational construct are possible. Here are a few ideas.
Capital Contributors Receive Full Shares
Projects that want to involve capital contributors even more deeply in the community can opt to give them full shares instead of loot shares. This needs to be handled with intention and with care to ensure that the distribution of shares remains sufficiently decentralized to avoid plutocratic capture and support true community governance.
Non-transferrable Project Token
Making project tokens non-transferrable until a later date creates flexibility for additional activities prior to the token becoming liquid.
The most basic benefit is to projects that rely on tokens not being available until a particular time or condition. For these projects, a capital contributor receiving some tokens after ragequitting in the middle of the Buidl Phase is a major risk. Making project tokens non-transferrable preserves the non-custodial nature of the CCO, but prevents the ragequitter from doing anything with their early-gotten tokens.
Another benefit is to projects expecting to have multiple phases. Such projects may want to conduct multiple CCOs, which would likely be easier if there aren’t a bunch of loose project tokens floating around.
Yet another use case is for projects that will be making retroactive distributions to users or setting up liquidity in a decentralized exchange. To promote fairness, the project team may not want anybody to receive the project tokens before anybody else, and executing on that goal requires time to set up properly. Preventing token transferability until those activities are fully set up can help align all the timing for maximum fairness.
One thing to consider is that ragequit requires some transferability. The token needs to be transferred from the DAO treasury to the ragequitter’s wallet. We can account for this by creating logic within the token smart contract that allows the DAO, but nobody else, to transfer the token.
No Project Token (Pseudo-CCO)
Some projects do not need or want to have a token at all. Such projects could opt for a pseudo-CCO, where there is no token, no Transmutation, no Vault, and no Distribution Phase. Capital contributors in a pseudo-CCO maintain custody of their capital until it is deployed (to their liking), but they don’t receive a representation of their contribution and have less reason to remain engaged with the community once the CCO is complete.
Other projects may want to have a token but are, for one reason or another, not ready to create one just yet. These projects could also opt to conduct a pseudo-CCO, with a promise to capital contributors that they will distribute a token at some point in the future. Note that this breaks the trustless nature of a true CCO, and therefore carries substantially more risk for all parties involved.
Example: The DAOhaus CCO
In 2020, DAOhaus conducted the first ever CCO to help fund the build-out of our new platform for community-centric DAOs. Here’s a quick rundown on how we did it:
Phase 1: We summoned a new Moloch DAO, with previous contributors to DAOhaus receiving full shares. We created the $HAUS token. We also deployed the Transmutation minion and Vault (which was called the Trust back then). Finally, we created the $HAUS token and transferred the appropriate amounts into the minion and Vault.
Phase 2: We invited members of our extended community (friends, connections, the MetaCartel family, other DAO-focused people and projects) to contribute DAI to the cause. Over the course of 2 weeks, 39 members of the community (including both individuals and DAOs!) contributed capital and received loot shares.
Phase 3: Next, we started building. As the DAOhaus project team wrote code, designed new user experiences, and managed our community, we made Transmutation proposals against the DAO to pay for expenses and compensate contributors. The latter allowed us to double the number of contributors, many of whom are still contributing to DAOhaus today! Along the way, we kept the capital contributors informed of our progress and direction. A number of those capital contributors are now key members of the project team!
Phase 4: After around 6 months, all DAI in the DAO had been transmuted into $HAUS tokens. At that point, capital contributors ragequit the DAO to receive their portion of the $HAUS and the project team claimed their $HAUS from the Vault. We then summoned a new DAO to govern the DAOhaus core contributor activities, which we still use today.
Our CCO helped us build the new version of the DAOhaus platform, expand our community with more contributors and users and advisors, and laid a strong foundation for future sustainable and values-oriented growth. All without requiring that our capital contributors trust us or relinquish custody of their assets.
Conclusion: Benefits of CCOs
We believe that CCOs are a significant advancement in capital coordination. We look forward to many decentralized communities -- and perhaps other types of projects! -- using CCOs to magnify the positive impact they are able to make on the world.
Your decentralized community or DAO can run a CCO today using the DAOhaus platform. We are bringing on alpha partners as we further refine these capabilities. Please reach out to set up a conversation!
To recap, here is a list of the core benefits of the CCO framework:
Benefits to Capital Contributors
Retain full custody of their capital until it is deployed, including the ability to exit if they don’t like the direction things are going
Maintain governance power over how the capital is deployed
Reduced information asymmetry between project team and capital contributors
Built-in tranching of capital
Significantly less requirement to trust the project team
Overall lower risk
Greater opportunity for less wealthy people to participate
Benefits to Projects
More capital available to advance the project’s goals
Folds capital contributors into the community where they can serve as advisors or even fellow builders
Less need to rely on larger capital contributors (e.g., venture capital firms) for funding
Governance of the project remains decentralized
Special thanks to Bill Warren, Jord Lesich, Aaron Soskin, and Yev Muchnik for review and helpful discussion; and to Ven Gist for the lovely infographics.
More DAOHaus 🏰
Web | Blog/Newsletter | Twitter | Discord | Podcast | YouTube
The recommended ratio is 10 loot shares for every 1 unit of capital, which allows the project team to back its own full shares with a relatively lower amount of the project token.