How to give blockchain applications to the community? Here is a manual for progressive decentralization

Original author: Jesse Walden, venture capital firms Andreessen Horowitz block chain is responsible for the area of investment partners

Translator: Lu Jiangfei

Source: Chain News

The founders of crypto projects face some unique challenges. In addition to creating the products that people want, they also need to think about how to make the product work in a decentralized way, making it a protocol that is owned and operated by the user community.

This is a daunting challenge, because many of the factors needed to create a successful product in its infancy, such as product leadership, rapid iteration, and controlled market tactics, will lead to community-owned and regulatory-compliant The path becomes very complicated, and the latter two can guarantee the long-term health of the project.

I have spoken to the founders of many crypto projects about ways to resolve this conflict. In this article, I will propose a "three-step" operation guide to accomplish this task in a step-by-step decentralized method. In the process, the founding team gradually removed control over time. The step-by-step approach allows the founding team to focus on creating a path to regulatory compliance, both to issue tokens and hopefully not violate securities regulations.

Please note that this operation manual is written for crypto startups that create applications on the smart contract platform. It is not very useful for the blockchain computing platform itself, because the blockchain computing platform needs to be sufficiently decentralized from the beginning. To be used by people.

At present, the regulatory framework of community-owned blockchain networks is still unclear. Therefore, the last part of this article can only talk about potential solutions, rather than finding proven winning strategies. Think of this section as just one possible path.

Three elements of a crypto project's success

First I assume that an application running successfully on a blockchain computer has the following three elements:

  • Product-Market Fit;
  • Community involvement;
  • Sufficient decentralization (owned by the community)

Chain News Note: PMF (Product-Market Fit) is both a "product market fit". This concept was first proposed by the well-known investor and entrepreneur Marc Andreessen, referring to the product and market reaching the best fit point, you The products provided exactly meet the needs of the market and satisfy customers, which is the first step in the success of a business.

Product / market fit is obviously essential. If no one wants the product, there will be no users, no business, and it will be difficult to maintain a long-term community. Community participation and decentralized control are not applicable in traditional startup projects, but they are essential for crypto startup projects.

Why is "community participation and decentralization" so important?

The answer is that the participation and control of the community can limit the risks from the platform, because the rules of the platform may change in a direction contrary to the wishes of users. The Web 2.0 platform has proven that this mismatch is possible, such as the platform "kills" the innovative application ecosystem built on its application programming interface (API), such as sacrificing user privacy and well-being. In contrast, a user-owned network can benefit from a cooperative economic model, which can ensure that cryptographic services are consistent with the interests of their users, even with scale expansion.

Another important reason for decentralized community control is compliance. Crypto tokens that promote economic allocation are likely to be considered securities in the Howey test, a regulatory framework used by the US Securities and Exchange Commission (SEC). Distributing securities to a large user base is too challenging and costly for startups to manage. Even "unicorns" like Airbnb and Uber don't know what to do.

However, an analysis of the recent comments and enforcement actions of the US Securities and Exchange Commission will reveal that the true decentralized nature may change the qualitative nature of a startup project's token from securities to "non-securities", as long as the team Centralize operations, eliminate information asymmetries, or rely on the efforts of the founding team to create value. To determine whether an investment will be considered "securities", one of the key indicators is to see whether investors rely on the efforts of others and have profit expectations.

Lianwen Note: In 1946, the United States Supreme Court established a "howey test" in the SEC v. WJ Howey Co case to determine whether a transaction constitutes an "investment contract" and thus a "security." The Howey test contains four elements: (1) capital investment; (2) investing in a common cause; (3) expecting to obtain profits; (4) not directly participating in the business, relying solely on the efforts of the promoter or a third party.

As Scott Kupor, managing partner of Andreessen Horowitz, said, according to the "depending on the efforts of others" in the Howey test, tokens are generally considered as securities before the network goes live. However, at the stage after the launch of the network, if the network becomes sufficiently decentralized, the nature of the tokens will also change from "securities" to "non-securities", as token holders no longer rely on the efforts of others .

Now we have understood several reasons why crypto projects need to be decentralized. Let's look at how to build a step-by-step framework with the goal of building a sustainable, compliant, community-owned product.

Goal 1: Product / Market Fit

The earliest stages of building an encrypted application require all the elements of a common start-up project: an excellent team, lean development, rigorous execution and fast learning. At this stage, the only thing that matters is product / market fit. To find this quickly, remember not to let the committee (or the community!) Design. A product requires an assertive leader to validate assumptions and quickly update prerequisites. In practice this means "administrative authority" for smart contracts. This privilege allows for rapid iterations and product management (including upgrades, shutdowns, or quick parameter settings).

At this stage, there should be no fake decentralization-the core team should drive all necessary product decisions to find product / market fit.

I don't recommend issuing tokens at this stage, because doing so may touch the regulatory red line. "Relying on the efforts of the core team" is one reason a token may be considered a security in the Howey test, and these distracting issues should not be considered during the product development stage.

The idea that the core team controls all aspects of a project may anger some early users, but the founding team should not be afraid. If someone complains about your control of the project, that's actually a good thing! This means that someone cares about the product you make. More importantly, it needs to be clearly stated where control exists. False autonomy can quickly undermine user trust, and transparency is a great way to build trust.

Goal 2: Community participation

If the product shows signs of popularity, such as a growing user base, developer ecology, and network effects, then it's time to invest more time to cultivate a harmonious relationship, namely passive users, more active contributors, and Harmonious atmosphere among core teams.

First, the founder can put more effort into product operation like running an open source project: increase investment in high-quality documents; open development; provide lotteries, grants or other incentives for third-party development forces; hire community leaders People help guide open development; introduce consensus when making decisions.

Next, you can try to eliminate platform risks by imposing technical constraints. For example, in Compound v2.2, the upgrade will take effect 48 hours after the push, which gives users time to exit the agreement or check for issues and raise objections. Urbit implements "Kelvin versioning". If the version number is decremented to 0, no further updates will be made.

For the core team, giving up control means an opportunity to transfer responsibility to the community. But when interacting with community members, incentives need to be reconsidered. Is there any reason for community members to continue contributing to this product?

Incentives (expenses)

Financial incentives are one way to motivate communities to contribute to the project. But where does the economic system come from? Cryptographic services can adopt a practical and familiar business model, which is to charge on demand, like application program interface (API) microservices like Twilio or Stripe. Allocating such a cost stream to active contributors will allow the community to keep pace with the goal of project success.

However, at the initial stage of the project, the charging model may not be reasonable. Given that cryptographic services are open source, it is best to reintroduce fees if the network effect is strong enough to increase the conversion cost to form a moat.

Decentralized exchange Uniswap provides an example of how cryptographic applications with charging capabilities can form a line of defense through network effects.

In Uniswap, if more users contribute liquidity to a trading pair, traders will get better pricing. If you want to provide the same pricing on a “ no fee '' fork chain, you need to coordinate the interests of all liquidity providers and third-party service providers integrated with the original chain, so that they can use the fork of the unified New chain. Together these coordination costs are conversion costs. Although the cost of conversion is not high because the data is public, this cost does exist.

Regardless, in the crypto industry, in order to motivate the community to contribute, the agreement must maintain a minimum of extractiveness-in other words, it should cover related costs rather than seek maximum profit.

Distribution (tokens)

Tokens are an effective tool for distributing the underlying value of a project, including the cost stream. The distribution of tokens can stimulate project participation and help establish a line of defense, but it is more important to consider how to build a fair and effective distribution method.

Many initial coin offerings (ICOs) and airdrops are actually sub-optimal choices, as these approaches introduce under-participated communities and may lead to regulatory scrutiny. Crypto applications focused on product / market fit have the opportunity to do better, by distributing tokens to an already active user base.

First, the project team can select a controlled and licensed population in the community to test the distribution of tokens. Many teams have chosen to allocate some future tokens to early "strong" contributors. For example, through the testnet program, independent community members can register on the testnet and participate in operating a node. A committed and controlled token distribution, if it is targeted at users who have contributed valuable work, will help reduce the community's over-reliance on the founding team.

Next, the project team needs to plan how to distribute the remaining tokens equitably to the participants, considering both past contributions and future incentives to promote continued participation. The design of the token distribution scheme should consider both the core team that builds the product and those who make the product useful.

Doing this is not easy. Although it varies from project to project, the common issues to consider are as follows:

  • What percentage of the tokens should be allocated to the initial team and cap table?
  • How will you reward the various contributors, historical and future, who have contributed to the product or service?
  • What returns will technology leaders receive in the future?

To answer these questions requires analyzing community behavior, modeling rational results, and discussing proposals with community members.

Goal three: adequate decentralization

If you are a founder of a crypto project ready to enter this stage, then you should have realized the early product / market fit, established a strong community that can support the continuous development of the application, and explored a right incentive And a sustainable business model.

Now the last step left is to achieve sufficient decentralization: a wide range of token distribution.

In practice, I think the team will airdrop tokens to users and contributors based on the previously described goals, thereby completing the "retreat to the community" step. At this time, a certain smart contract is triggered, and it is used to mint and distribute tokens. Ideally, once this feature is triggered, the following things will happen:

  • The core team should have withdrawn most of the application's ownership (in terms of cost and control), reducing the risk of the platform by ensuring that the product is owned and operated by the community;
  • If the service is sufficiently decentralized, tokens may be able to be converted to "non-securities." In other words, it is independent of the efforts of a single entity, which may control asymmetric information;
  • This company is sustainable, it retains enough tokens to benefit from fees and growth;
  • Users and owners have achieved a certain amount of revenue growth because the service's cooperative economic model can better configure and add value (value defined by users rather than shareholders).

The core of this goal can be marked with a specific moment: the crypto product company has completed the transition from a traditional product team to a sustainable, community-owned and operated network. (Note: A careful legal review is required to operate a token distribution. I have described very few precedents, so please consult a lawyer beforehand!)

How to avoid getting stuck

Many crypto teams are stuck in the quagmire, either because these goals are being done in the wrong order, because of "forgery" decentralization, or trying to get everything done at once.

For example, if the application team is pursuing community ownership first (starting with extensive token distribution), it may bring speculators to the community rather than real users. If there are no products available, ownership is worthless and the community is not sticky. Many teams that do this can't go back to the previous step, that is, product / market fit, so it is also difficult to start meaningful community participation.

There is also an operation in the wrong order, which is to jump directly from the product / market fit to the decentralized community (skip goal two, community participation). Without true community involvement, your project could fall into the mysterious valley of a decentralized theater. One symptom of being trapped there is the apathy of the community: low participation and strong dependence on the founding team. In such cases, establishing control (for example, through authorization) may be a better way to build trust. Conversely, if you hide under the guise of decentralization, it will cause faster damage to the project.

Another way to get into trouble is to try to do three things at once. The inability to focus is the cause of the death of most startups, as is the application of crypto. In the maze of ideas, these three goals overlap, and need to be considered as a whole, but they must be sorted by time and priority when implemented, and do not try to do their job.

The last thing to note is that even if you operate sequentially, the moment the project switches to being completely owned by the community, the application's governance mechanism will enter a completely unknown area. The question of how effective community decisions can be scaled up is extremely challenging. However, if the Internet community can accomplish a feat like Wikipedia, then I am also optimistic that experimentation and skin-in-the-game (by providing valuable ownership) should enable collaborative decision-making to reach unprecedented levels. scale.

So far, we haven't seen an encryption application that can achieve each of the above goals in order, but some of the most promising encryption project teams I have spoken with have started to follow this operation manual. Through these conversations, I gradually believe that step-by-step decentralization can provide a smooth path for crypto projects, achieve product / market fit, financial sustainability, a highly engaged community in order, and meet regulatory regulations.

Step-by-step decentralized pocket manual

Thanks for the conversations with Robert Leshner, Hayden Adams, Alexis Gouba, Dan Robinson, Ali Yahya, Denis Nazarov and Toby Shorin. Thanks to them, I have the above thinking.