The goal of gardens originally was to make it accessible for communities to take advantage of tokenization, and create and form truly decentralized autonomous organizations, like 1Hive.
Creating a community is really hard, but the actual process of creating a DAO shouldn’t be. It shouldn’t raise complex legal questions, it shouldn’t require a legal wrapper, it shouldn’t require forking and deploying new code, and it shouldn’t cost thousands of dollars… it should be something anyone can do, like creating a new sub-reddit or hashtag.
I think there is a ton of value in 1Hive making it easier to create conviction voting based DAOs, but I will admit that there is some truth to this meme:
One thing that makes it confusing is that we have been using the term Gardens to refer to this concept of a DAO creation factory or platform that uses conviction voting… but also a specific DAO template which we had originally intended to support on the gardens platform. The template was heavily inspired and owes a lot to the engineering and design work of the Commons Stack. However, I think conviction voting is really the key component, whereas the the bonding curve mechanism (while useful in its own right) could be replaced with other mechanisms.
When we decided to migrate 1hive to xDai we decided to simplify things by removing the bonding curve component and relying on an issuance policy instead. At the time we called this simplified version the Karma template, but there was a lot of overlap, and the interface for conviction voting we were building and planned to use for Gardens platform was first built to support this new template which we use to interact with the 1hive DAO at 1hive.org, and has since been forked a few times for other deployments including the TEC.
We have also gotten interest from other communities, who want to use conviction voting but already have their own ERC20 token, and so we have discussed creating a third flavor of template to enable that use case.
Over time this has resulted in the use of Gardens referring to Conviction voting based DAOs in general, and we have so far identified 3 distinct configurations that seems to be relevant.
- Single-token issuance based funding (like 1hive)
- Bonding-curve w/ exchange fee based funding (like commons stack and TEC)
- Wrapped token with exogenous funding (like what was proposed for Whaler/TreeDAO)
Each of these have different pros and cons, and may be appropriate for different communities.
The single-token issuance based mode is nice because its simple and self-sustainable (though not necessarily stable). It won’t run out of funds, because issuance and outflows will reach an equilibrium point. It also simplifies things significantly from the legal perspective, because there is no need to raise funds, tokens can be given away to community members to bootstrap, and then naturally find a market value.
The bonding curve with exchange fee based model, that will be used in the TEC, has the nice property that the funds used are in a different token, likely a stable, interest bearing currency. As a result, budgeting and allocation decisions are not as tightly coupled to buy and sell pressures, and the dollar value of funds to be allocated can be made less volatile and less correlated with the staking/governance token itself. Though because of the bonding curve, launching a DAO of this flavor may be more involved both technically and legally, as we have seen so far with the TEC work.
The wrapped token model would essentially allow any existing ERC20 token to be used within a conviction voting DAO. Users would need to deposit their token in order to participate in the staking process, and optionally a percentage of deposited or withdrawn tokens could be moved to the common pool. Alternatively, the DAO would simply utilize signaling proposals or rely on external cashflows in the form of revenue or donations to be routed to the common pool. The big advantage here is that projects that have tokens that may have already been created can simply create an organization, and use their existing token.
With all that said, this leaves the question of what is Gardens today, what is the Gardens swarm working on, and how it all fits together.
- The 1hive.org interface, which is being updated along with conviction and delegative voting contracts (by the celeste swarm) to support integration with Celeste.
- The “commons template” a flavor of a conviction voting DAO being deployed with the help of the the gardens swarm and commons stack for the Token Engineering community.
- A vision to eventually enable people to easily launch a conviction voting DAO using the 1hive.org interface
This ended up being a rather long post, but I wanted to provide some additional context because I think the conception of Gardens has existed within 1hive for a while (predating the xDai migration), and work towards that goal has been happening on many fronts, not just within the Gardens swarm.
While the Gardens swarm has focused their efforts on the TEC and “gardens/commons template”, the Celeste swarm has been working on Celeste and integrating it with the 1hive.org interface, with the intention to extend that from simply being an interface to interact with a single DAO (1hive), to a platform where people can create and interact with DAOs similar to how Aragon/DAOHaus/Colony/DAOstack allow people to create and interact with DAOs of a specific flavor from a single and simple interface, inline with the early conceptions of Gardens.
I’m generally supportive of the work the Gardens swarm is doing on the TEC and personally see collaborating with and supporting aligned communities can be a good use of resources. I’m supportive for the following reasons:
- 1Hive is heavily inspired by the research and work of the Commons Stack, Helping them to launch the TEC feels like a great way to support a community which has worked hard to produce public goods that we have utilized and helped us get to where we are today.
- The Token Engineering community is awesome, and helping them launch the TEC is likely to have long term, intangible benefits to 1Hive as these are some of the brightest and most aligned builders in the space and the public goods they want to fund with the TEC aslo have a lot of overlap with public goods that we are actively using, most notably Conviction Voting, cadCAD, and the Aragon open source stack.
- Working to enable more DAOs on xDai, will result in more usage of xDai, faster improvements to the network, and more native tokens to swap on honeyswap. And more DAOs using our implementation of disputable conviction voting and disputable delegate voting, would also result in more contributors to those code bases, and more users of Celeste, and more demand to stake honey once Celeste is launched.
However, I think that to Will’s point, the lack of clarity in narrative around Gardens is something we need to fix, and we probably need to do so by creating a distinction between the effort to extend the 1hive.org interface into a DAO platform and the effort productionize the Gardens/Common template and launch the TEC.
I would really like to be able to use “Gardens” to describe communities/DAOs on the platform, I like the idea of users (bees) being able to participate in multiple communities (gardens). But we could always use a different term if we think that Gardens should be a more broad term for any conviction voting DAO, and that since the Gardens swarm has formed around that broader conception, that we should use something else to describe the platform concept.
Anyways open to ideas… I think the main thing is just reaching some consensus on what is what and how it may or may not converge over time.