The purpose of “OpenRaise v2” is to provide a permissionless instrument for bootstrapping and scaling community-owned Dapps/DAOs. OpenRaise v2 helps founders attract and align the incentives of investors, team members, and early adopters. These proposals are written by Philippe Honigman.
"This post results from conversations with friends at Aragon, Fairmint, the Commons Stack, MetaGame and dOrg, as well as from two previous projects that have now stalled. I figured that the ideas discussed then should be shared publicly in order to have a chance to be recycled in other initiatives.
The intent is to deliver a bonding-curve fundraising app as a permissionless instrument for bootstrapping and scaling community-owned Dapps / DAOs / protocols, that would help founders to attract capital and align the incentives of investors, team & community members, and early adopters.
The three improvement proposals below can be combined as a whole in order to achieve this purpose. They can also be unbundled. They are drawn from previous work on two other projects (Tribute & MetaScale).
Proposal #1: Tokens for contributors
Thanks to the DAICO model, investors get more control on how project teams use their money, by controlling how much funding is made available for spending each month. However, this model is essentially a way to protect investors from abuse, rather than a positive incentive for the buidlers to deliver a working product.
Aligning interests of investors and workers is an essential driver of performance for any project. Just like pools of stock-options are commonly used by venture-backed startups in order to motivate advisors, executives and employees, pools of tokens may be set up in order to incentivize any contributor of work with a share of the future value created by the project, usually captured by the sole contributors of capital.
OpenRaise may enable any project to set up a pool of so-called ‘contributive tokens’ or ‘Work Contribution Tokens’ (WCT) by defining a percentage of newly minted tokens that go to this pool instead of being sent to the investor. The default value of the percentage is zero, so that all new tokens go to contributors of capital, unless the project team decides to use the option of a pool of WCTs. In addition, vesting should be applied to WCTs, so to avoid a selling pressure adverse to the interests of new investors.
Project teams make their own decisions regarding the allocation of WCT to their contributors. It can be:
● the direct decision of the person who controls the address of the pool,
● a collective decision subject to a vote (for instance, via Aragon Agent for a stand-alone version of OpenRaise, or via a DAOstack proposal when OpenRaise is used as part of a DAOstack scheme),
● used as the collateral of Moloch v2 or Colony revenue-sharing schemes.
Tokens for the commons
The rise of blockchain-based projects enabled a new way of funding based on token economics. OpenRaise precisely offers a new way to fund projects that are or can be profitable. What would it take to close the loop, i.e. to nurture the digital commons that every project is using, but that do not have any business model?
Base protocols and open source components are the foundations upon which anyone can build valuable services. However, funding independent open source development is notoriously difficult. Relying on volunteering is not sustainable, and foundations’ grants are limited and discretionary. There have been several recent attempts to decentralize the allocation of funds to open source projects on Ethereum, like Moloch DAO or Gitcoin’s CLR grants. While this is great as it enables the community to decide where the funds should go, it doesn’t solve the need for predictable upstream sources of funding.
OpenRaise could include a mechanism to that end, in the form of an optional token pool for the commons. Each project raising funds using OpenRaise would have the option of sending a percentage of newly minted tokens to their own commons pool and signal to the community their active participation in public goods funding. Impact investors can use this information in order to select projects serving the causes or the ecosystems they want to help, and to signal their support publicly as well.
My assumption here is that the signalling virtue will easily offset the slight dilution for investors. In addition, the mechanism should be painless to project teams as it comes as a way to attract capital and that it won’t result in an immediate cost. Nevertheless, as with the contributive token pool, the default value of newly minted tokens going to the commons pool should be zero and the decision to create positive externalities left to each project team.
Lastly, in order to protect investors from attempts to game the system, possible beneficiaries of transfers from commons pools will be white-listed through a decentralized and transparent process (see Kleros TCR for instance).
NB: Tokens for the commons are just a subset of ‘tokens for contributors’. Commons (or public goods) can be seen as a form of passive contributors. It may be simpler to ignore this particular option and let each project decide whether they want to allocate part of their WCTs to such causes. On the other hand, there’s a signalling virtue in integrating the option in the product.
Proposal #2: 3-Step Funding Cycle
The current cycle of fundraising with OpenRaise is made of one continuous phase with a special sequence at the beginning called the kickstarter or initialization phase. I suggest expanding it to a 3-step process: Start, Build and Run. The rationale is to serve better all stakeholders across the full cycle of a project, as opposed to the sole investors.
In addition, it may help to smooth some compliance issues (initial steps may be permissioned, and the last one permissionless when the Dapp/DAO is running).
Start - initial exploration & design
The Start phase takes place before the kickstarter/initialization phase of the current OpenRaise implementation. During this step, founders and early contributors ideate, design or prototype a Dapp/DAO, without 3rd-party funding.
When they are ready to move forward and raise funds, they can use OpenRaise for pre-minting WCTs, i.e. tokens meant to reward the contribution of work.
When a team starts using OpenRaise, they set the address that will be controlling a number of decisions, such as the number of contributive tokens to be minted, or the cap of the fundraise. This address can belong to an individual, a multisig contract, or a full DAO. In order to keep things simple, we refer to this address as “the project team” in this note. Just bear in mind that it could designate any actor type in charge of making these decisions.
The project team may decide to immediately allocate a part of the tokens to themselves and to early contributors. The rest is kept in a “contributive pool” for future allocations.
The policy for contributive token distribution is set by each project. OpenRaise doesn’t create any constraint in that regard. The actual distribution can actually be performed using another system, such as Aragon Open Enterprise or Colony.
At this stage, tokens have no value. They have been minted out of thin air, with no collaterals. They are essentially a promise, a right to receive a fair reward of the long-term result of one’s efforts. They also are a recognition for the work done by early contributors, in a time of high risks and no immediate compensation.
Tokens allocated to contributors are locked, they cannot be transferred to anyone.
Build - funded development
When the project is in need of external funding and advanced enough to attract investors, the ‘Build’ phase begins.
Investors can buy tokens from OpenRaise’s bonding curve contract. Just like with the current version of OpenRaise, the price they pay is determined by the supply of tokens at the time of their investment so that they are incentivized to invest early. A kickstarter/initialization phase is also offered.
OpenRaise is the custodian of the capital allocated by investors during the Build phase. The capital is progressively released to the people who build the Dapp/DAO, according to a “tap” mechanism. Allocation of capital within the team of contributors is out of the scope of OpenRaise (some projects might be under the control of a benevolent dictator, some others might use a DAO framework to decentralize proposals and funding of contributions, or anything in between).
NB: this is the DAICO mechanism of course, I understand it was planned as a part of OpenRaise but I don’t know if it has been developed.
One suggested difference from dxDAO’s OpenRaise is that investors can neither sell their tokens on a secondary market nor sell them back to the smart contract at a price defined by the bonding curve. The intention is to avoid competitive speculation between investors and to have funds flowing between investors without any being invested in the actual project, past the initial investments (I’d be curious to know about lessons learned with dxDAO’s spread between secondary markets and the bonding curve).
On the other hand, I suggest enabling investors to “ragequit”, i.e. withdrawing the capital they invested, minus the part that has been already allocated to the contributors through the tap. It protects investors in case the development stalls, and it incentivizes developers who may lose their funding if they act in a way detrimental to the project.
The objective of the Build phase is to deliver the first working version of the Dapp/DAO in production and to kick off its economy. As such, the project team should define the capital requirements to achieve this goal and set it as a cap. Once the cap is reached, attempts to buy more tokens are to be rejected by OpenRaise.
More options: an additional limit on the number of investors could be defined, in order to comply with local regulations regarding the number of investors in private equity sales. Public addresses of investors may be whitelisted in order to enable the application of a KYC process when needed.
During the Build phase, work contributors receive cash compensation for their work, thanks to the capital made available by investors. In order to keep them vested in the long-term success of the project, work contributors may also be granted with WCT from the pool created during the Start phase.
While investors can liquidate their tokens using the ragequit function, contributors are still locked during the Build phase.
Run - the Dapp/DAO is live!
Finally, the Run phase starts when the Dapp/DAO is in production and can be operated in a sustainable way.
Two on-chain events trigger the new phase:
● income starts flowing from the Dapp/DAO to the OpenRaise bonding curve contract of the project,
● the project team confirms the transition from “Build” to “Run”.
Entering the Run phase means that the Dapp/DAO starts functioning as a sustainable economy, thanks to the inclusion of the 3rd type of stakeholders: users.
There are two ways a revenue-generating Dapp/DAO can be integrated into the token economy of the bonding curve:
● when users pay for using the Dapp/DAO, a part of it is sent to the reserve pool of the bonding curve contract
● users can also buy a discount token on the bonding curve, so that they don’t pay for using the Dapp/DAO, or they pay less
In the latter case, users willing to pay less must hold their tokens. This is a form of staking conducive to the appreciation of the token. Users holding tokens have therefore a vested interest in the success of Dapp/DAO economy, just as work and capital contributors.
When users (or new investors) buy tokens in the Run phase, their funds can be used to pay for the maintenance of the project (via the tap mechanism) and to increase the reserve pool. In that respect, the 3rd phase is the closest one to the way the current OpenRaise operates. It is also possible to mint new WCTs instead of giving all the new tokens to buyers, so that more people are incentivized to develop the project and get a share of its success.
Finally, once the Run phase is started, WCTs are progressively unlocked, according to a vesting schedule initially set up by the project team. WCTs can now be sold to the bonding curve contract at a spot price determined by the current supply, just as tokens bought by investors and users.
Proposal #3: OpenRaiseDAO
OpenRaise is an open-source software whose development was performed by dOrg and LevelK and funded by dxDAO. This proposal aims at building a sustainable, permissionless fundraising-as-a-service offering, built, delivered, and controlled by a DAO.
OpenRaiseDAO’s purpose is to help Dapps and DAOs projects to raise funds. OpenRaiseDAO uses OpenRaise to reward not only its direct work and capital contributors, but also to incentivize its users and to support the Ethereum/open source software ecosystem at large.
What is special about OpenRaiseDAO (compared to Fairmint, Aragon Fundraising, OpenRaise v1):
● a permissionless take on continuous token offerings (in the Run stage, see the 3-step process),
● a standalone DeFi component dedicated to Dapp/DAO funding & scaling, composable with other DeFi services,
● an inclusive token economy (serving the needs of all the stakeholders),
● the ability to create network effects (via its own token and the master bonding curve).
OpenRaiseDAO uses OpenRaise to fund itself. If the 3-step model is applied, some WCTs could be minted during the Start phase and allocated to dxDAO, dOrg, Fairmint, Level K, Commons Stack, and/or individuals who contributed work to bonding curve fundraising in general and OpenRaise in particular.
Once in the Run phase, OpenRaiseDAO gets its primary revenue stream from a fee (the “Fundraise Fee”) paid by each project using OpenRaise to fundraise. The Fundraise Fee may be defined as a percentage of the amount invested in each project, so that the cost is proportional to the value delivered by OpenRaiseDAO (fundraising mechanism + investment network).
OpenRaise smart contracts are open source and it is technically possible to fork them so as to avoid paying any fee. While it is expected to see some projects reusing OpenRaise code without paying fees, most may choose to save the costs of deploying their own contracts and appreciate the additional benefits of participating to the OpenRaiseDAO:
● projects receive OpenRaiseDAO tokens (ORD) as a result of the payment of fees
● projects have a voice in the governance of the network (see Governance section below)
● projects enjoy exposure as part of a curated network of investment opportunities
In order to incentivize fundraising on OpenRaiseDAO, projects paying the Fundraising Fee receive ORDs issued on the “master” bonding curve of the OpenRaise project itself.
As an alternative, the option of buying and staking ORDs may be offered, so that they are used as discount tokens (as described in the 3-step process proposal). ORD holders would either pay no Fundraising Fee or would have a discount on it.
In the Run phase, the Fundraising Fee is allocated to both the Funding Pool (in order to cover operation costs of the DAO and the maintenance of OpenRaise) and to the Reserve Pool (so as to increase the value of the token). The allocation ratio between the Funding Pool and the Reserve Pool is set by the network (see Governance section below).
OpenRaiseDAO members may have a voice on:
● changes on fee structure, token distribution, curve...
● allocating funds to the commons: whitelisting new addresses (if “tokens for the commons” option is used)
● changes of governance rules
● technical upgrades
Members are ORD holders/stakers. I suggest using a m ultistakeholder governance system, so that each group of stakeholders (users, investors, workers) has an equal voice, and that voting rights are token-weighted.
OpenRaiseDAO for DXdao
I hold REP in DXdao but I’m not very familiar with their practices. I was thinking that having OpenRaiseDAO as part of their collectively owned products would make sense:
● DXdao funded the development of the first version and they used it to raise funds for themselves, hence they are well positioned to promote such service
● since DXdao is willing to grow and operate DeFi protocols and products, a permissionless fundraising component seems to be a relevant addition to their portfolio
● DXdao could also use OpenRaiseDAO as an instrument to fund their future initiatives, so that each one can access its own independent funding, while benefiting the DAO as a whole (through the Fundraising Fee mechanism)
Composability of OpenRaise v2
As an independent DeFi service, OpenRaise v2 could be combined with other DeFi bricks, for instance:
● assets in the Reserve Pool (DAI, WBTC...)
● generating interests on funds in the reserve (Compound)
● using DAOs to control funding parameters (Aragon)
● allocating WCTs based on tokenized reputation/rewards (SourceCred, Colony)
Credit: https://medium.com/@phil_h/ Thanks to Thibauld Favre, Griff Green, Olivier Sarrouy, Ori Shimony, Thomas Spofford. Let's set up a call meeting with Philippe Honigman !!! And talk with Simon from ADAN about this model!
We have already explored the Aragon Company, Dandelion and Gardens Template and have a preference for the Gardens setup. Currently there is no xDai based Gardens template on https://aragon.1hive.org/#/ Unsure when this will launch. Right now, we are mainly using the Abridged platform, so the DAO is completely Discord and Telegram-native.
Gardens is a great fit for our web3zine, and the template used for the surfbnb project is a good way to experiment but our LTL Maps DAPP would no doubt benefit from having a template like OpenRaise. Who can assist us with V2?
Keen to hear Jack Laing's opinion on the proposals regarding OpenRaise V2. Above you'll find his post with a great overview of some of the building blocks.