The Decentralization Playbook for Web3 Builders and Lawyers: Fully Decentralized

Original article: https://variant.fund/articles/sufficient-decentralization/

Web3 builders have focused on the concept of “sufficient decentralization” since it was introduced by the SEC staff in 2018. It leads builders to focus on distributing efforts to drive crypto asset profits away from centralized corporations to independent community members working towards a common goal.

Given that blockchain is an emerging technology, most legal advice on securities law has focused on the decentralized web3 technology stack. But just as important is the off-chain day-to-day activity of decentralized community contributors. None of this work is done on the blockchain, and they include developing the protocol or software around the protocol, participating in business development, marketing and scaling the protocol, making intellectual property available to all, and advancing protocol governance.

However, these contributions (which this paper defines as off-chain activities) are difficult to automate and add bureaucracy, which means that off-chain activities around decentralized protocols tend to be centralized. In order to achieve robust decentralization, the community must consciously consider how on-chain and off-chain activities are organized.

This article is for (1) web3 founders looking to effectively decentralize off-chain activity while complying with US securities laws and (2) web3 attorneys advising those founders. It explains what "sufficient decentralization" means, how it affects off-chain activity, common mistakes that lead to centralization of Decentralized Autonomous Organizations (DAOs), and how to effectively build communities to achieve "sufficient decentralization."

While this article provides perspective on how to effectively decentralize off-chain activity, it does not mean that the methods envisioned therein are the only way to do so. There is no single, canonical definition of full decentralization, and no perfect way to achieve it. Some of the approaches companies and communities have taken so far may offer alternatives, which in some cases may even be more conservative from a regulatory perspective, even if they may be less efficient.

Investment Contracts: Getting Started

In the United States, issuers of securities must register with the SEC to issue securities, or rely on an exemption. When registering, issuers must disclose material information about the business, market, and offering of securities. These disclosures are intended to protect investors by sharing information that a reasonable investor would want to know. It also creates a "level playing field" by preventing any party, including the issuer, from knowing more important information than anyone else.

One type of security that triggers the registration obligation is an "investment contract". To determine whether a contract, plan, or transaction constitutes an investment contract, courts rely on the "Howey test," a four-pronged analysis devised by the US Supreme Court in 1946 SEC v. WJ Howey Co. . The court concluded that an investment contract is a transaction (1) involving the investment of funds in an ordinary business (3) (2) based solely on a reasonable expectation of profit (4) based on the efforts of others. The court later interpreted the fourth aspect to mean that the reasonable expectation of profit arises primarily from the entrepreneurial or managerial efforts of others. All four aspects must be met for a given transaction to be considered an investment contract. The Howey test still exists today and is used to determine whether a sale of a crypto asset constitutes an investment contract.

Crucial to the analysis of investment contracts is whether, according to Howey's fourth point, the investor expects to profit from the entrepreneurial or managerial efforts of others. Therefore, a key determinant of whether the sale of a crypto asset is also an investment contract is whether web3 contributors can reasonably be expected to drive the value of the cryptocurrency, including through off-chain activity.

What does full decentralization mean?

The idea of “sufficient decentralization” was introduced in a June 2018 speech by William Hinman, then director of the Division of Corporate Finance at the U.S. Securities and Exchange Commission. “If the token or the network on which the token operates is sufficiently decentralized — that purchasers can no longer reasonably expect the necessary management or entrepreneurial effort from an individual or group — then those assets may not represent an investment contract,” Hinman said. Considering Using this framework, Hinman concludes that the current Ethereum sale is not a securities sale because the Ethereum network has become sufficiently decentralized.

Hinman’s notion of “sufficient decentralization” is an endorsement of the final aspect of the Howey test, which assesses whose efforts drive buyers’ expectations of cryptoasset profits. If a protocol or network is not sufficiently decentralized, then the value of the underlying cryptoasset can come from the efforts of a centralized team — a person or group of people that the public perceives as coordinating to increase the value of a centralized team. If the protocol is sufficiently decentralized, the value of the underlying cryptoasset will not come from what the public perceives to be the efforts of a centralized team — there is no identifiable, coordinated group driving the value of the cryptoasset.

In April 2019, the SEC's Center for Innovation and Financial Technology Strategy (commonly known as the FinHub) solidified the notion of adequate decentralization with its "Framework for the Analysis of Digital Asset Investment Contracts." The FinHub framework provides detailed guidance on every aspect of Howey testing. In doing so, it introduces the notion of an "active participant" in relation to the final aspect of the Howey test, namely a "sponsor, sponsor or other third party (or a third party's affiliated group)".

While the FinHub Framework considers active participants to be potential "third-party affiliated parties," the Framework may deviate from its use of the term as defined in SEC regulations when referring to affiliated parties, and instead refers to coordinated actions among a group of third parties . Unlike uncoordinated third-party groups working on agreements, coordinated third-party groups may be entitled to important material information that they are required to disclose under securities laws.

According to the FinHub framework, several factors should be considered when determining “reliance on the efforts of others” – namely, “whether the essential task or duty is expected to be performed by [active participants] rather than independent, decentralized online community users” .

But even if a crypto asset is initially sold as an investment contract, the FinHub framework outlines how it can later be sold as a non-security. Assets may change (meaning that it ultimately will not satisfy the Howey test).

In short, the sale of a cryptographic asset satisfies the final requirement of the Howey test if someone has a reasonable expectation of profiting from it as a result of the entrepreneurial or managerial efforts of others (including the efforts of active participants). However, if that person reasonably expects to profit from the uncoordinated efforts of a wide range of people, then he should not be met; the protocol and its associated activities should be considered "sufficiently decentralized" and should not be considered sold any investment contract.

Legal advisors advising web3 participants on the distribution or sale of cryptoassets often combine the concepts of "sufficient decentralization," "active participant," and mutation. As such, sensible actors have become familiar with the quest to replace the active actors who create value for a centralized protocol with a sufficiently decentralized, uncoordinated group of people.

However, the technology of the protocol and its autonomous operation may not always be the only factor that can reasonably be expected to drive the value of a given crypto asset. People with a reasonable expectation of profiting from cryptoassets can see additional off-chain activity as a value driver. Therefore, to reduce risk for any web3 participant, the community should also seek to decentralize off-chain activities, including:

• protocol development
• business development
• growth and marketing
• intellectual property
• governance decision

How off-chain activities drive the value of cryptoassets — and whether they affect the outcome of Howey’s “efforts of others” test — depends on many factors, including the protocol’s design, target market, and governance mechanisms.

For example, in early-stage protocols, or in protocols that are easily integrated with other protocols, community protocol development may have the greatest impact on driving the value of the associated cryptoasset. Conversely, in communities where protocol design is established or integration is difficult, greater value can be created through business development, growth, marketing, and governance.

What is the scope of decentralization?

In the web3 community, there is often a tension between the efficiency of centralization and the ideology or allure of censorship resistance of decentralization. Every community must balance the desire to benefit from the speed, cost, and operational efficiencies of centralization with the benefits of decentralization—consensus building, censorship resistance, transparency, and independence. The community accepts varying degrees of centralization, so feel free to fall into the "decentralized spectrum".

For performance and efficiency, more centralization is needed; for maximum decentralization, some speed must be sacrificed, and there will be inefficiencies. Each community will determine where its off-chain activities lie on the centralized-to-decentralized spectrum over time, consciously or not. In terms of centralization, the coordination of one person or one company or a small group of people can participate in all off-chain activities. In terms of decentralization, anyone can participate in any off-chain activity at any time without needing to communicate with anyone else participating in off-chain activities of the same protocol.

On a technical level, the so-called Ethereum killers typically enable faster and cheaper transactions than the Ethereum network, at the expense of greater centralization. This is an unacceptable tradeoff for many in the ethereum community, but an appropriate one for the community making the tradeoff (who also often believe their protocol will one day be as decentralized as the ethereum network) .

The same trade-off applies to off-chain activities as well. Small groups of constantly coordinating people, such as corporations, may find it more effective to centralize off-chain activities. For example, centralizing marketing operations through a marketing agency can be very effective because a marketing manager can direct a handpicked team to run multimedia marketing campaigns on Discord, Twitter, Telegram, and other social channels. Since one marketing agency controls access to the protocol's social channels and the content posted on those channels, fast and consistent messaging is possible.

In contrast, a fully decentralized community may allow anyone to participate in any off-chain activity without communicating with other participants. This is inefficient; continuing the example above, without a manager to coordinate the community's marketing efforts, anyone can offer to promote it for themselves, regardless of their ability to do so - or no one can promote the item at all.

As far as the Howey test is concerned, the more concentrated the community, the greater the risk that a sale of a crypto asset will be considered a sale of securities. There are many other factors that affect how decentralized a community is:

• culture
• Historical development of off-chain activities in the community
• Censorship Risks Associated with Community Activities
• leadership within the community
• its strategy to increase the use of the protocol
• Coordination required to adjust parameters or other aspects of the protocol

Despite the fluid nature of the web3 community, community members can still come to a general consensus on the degree of decentralization. The community might even have a de facto "leader", like Vitalik Buterin is the leader of the Ethereum community, to help achieve this consensus. Once achieved, the community should establish processes to protect this level of decentralization and work to defend them.

Decentralization of a community should take into account the sum of all components of the community; the community should accept centralization in areas that may benefit from the greater efficiency it provides, and compensate by further decentralizing other off-chain activities. For example, if early protocol development would benefit from the coordination of a tight-knit group of experts, this centralization could be offset if the community decentralizes other off-chain activities.

Many initial development teams and community members consider the impact of their actions and ask whether an action is problematic for decentralization. One behavior is rarely a problem; instead, all operations should be considered. Whenever someone moves around the protocol, they either help or hurt decentralization. Therefore, the best frame of reference is the constant evolution of decentralization.

Difficulties in decentralizing off-chain activities

Decentralized off-chain activity is possible; doing it efficiently is difficult. It's mostly a communication issue: everyone involved in off-chain activities has to be aware of everyone else's work, without being so closely coordinated that they risk becoming "active participants" under the FinHub framework applying the Howey test, thereby Causing crypto assets to be treated as investment contracts.

Once again, the community has to strike a balance between the two extremes. Close coordination leads to centralization, but chaos can ensue if community members do not share information with other contributors in the community.

For example, if community marketers communicate only among themselves, other contributors will not be able to understand how the protocol is marketed. For example, software developers fail to understand users' needs, resulting in software development based on intuition rather than user feedback received by marketers.

Likewise, if all community members are in constant private communication, they will centralize off-chain activity in the same way a centralized corporation would. Communities engaging in off-chain activities must avoid groups that form the majority of off-chain activities that coordinate agreements. Continuing with the example above, marketing teams should provide updates about their activities (such as timelines, status, plans, and feedback) on public social media platforms and governance forums.

The community needs to determine the most practical means of communicating publicly. This requires careful consideration of appropriate tools. For example, Notion pages can be made public, Zapier can be used to allow anyone to view those public Notion pages, and updates can be logged into Linear. Additionally, Loom videos can be embedded on public Notion pages, and all Discord channels can be made public.

Community members may be concerned about the competition and confidentiality issues inherent in publishing roadmaps and status updates in public communication channels. However, on most community forums, members openly discuss the future of the protocol and off-chain activities, so the most sensitive competitive information is already known. In web3, how the community utilizes competing information will determine its success, not the confidential information it holds. If community members engaged in off-chain activities gain access to confidential information, they may gain significant asymmetric information relative to community members not actively engaged in those activities, which may strengthen the argument in favor of cryptoassets being considered securities.

protocol development

Although tight-knit teams often create protocols initially, after publishing they often open up protocol development to a community of willing programmers. The community may modify existing code or deploy upgraded versions of the protocol. They can also build software that integrates with the protocol, creating greater demand or different use cases for the protocol.

To effectively decentralize protocol development, all deployed protocol code should be open source. Otherwise, the community will not be able to continue building the protocol or the software that runs on it. Since the initial developers of the protocol most likely know the code better than anyone else, they should ensure that the code is clean and properly documented. Additionally, the community should provide strong development and governance guidelines to reduce barriers to community contribution and knowledge asymmetry. This will allow the community to make meaningful contributions to the code and use the protocol.

Of course, since the original developers are more familiar with the code than community members, they are likely still in the best position to develop software involving the protocol. As a result, community developers may not bother to modify or improve the code, hindering the decentralization of protocol development. To incentivize community members to contribute to protocol development, the community can offer grants and bounties.

Where grants are available, the community should identify areas where the protocol might be modified or improved, and then issue requests for proposals to developers who can build them. While it might be difficult for the community to pinpoint these areas without some guidance, open source and public code development should make this easier. This guidance can come from the product team, a roadmap published by a community member, or a high-level strategy for the community developed by the initial development team or another respected community member. Examples of strong grant programs in DeFi are those associated with the Aave protocol, the dYdX protocol, and the Uniswap protocol. Some Layer 1 and Layer 2 networks have significant grant programs in the form of funding, such as those associated with the Polygon network and the Zcash network.

In the case of bounties, the community should ensure that valuable contributors are paid. A formal bounty program can help with this dilemma, as can promoting high-value contributors - think web3's "employee of the month" program. Bounties are more likely to work when contributors are confident that their efforts will be rewarded handsomely and consistently.

For grant programs and bounty programs, the application, evaluation, and funding of initiatives should be public. For example, requests for proposals and community-driven applications should be made available on community forums; evaluation and negotiation of goals, key results, and performance indicators should be available for community review; individual or team grants and grant completion should be publicly announced.

business development

Business development is the practice of increasing protocol usage by establishing targeted personal relationships with third parties, such as other protocols or institutions. After protocol development, decentralization is probably the most difficult off-chain activity. This is because business development relies on a small number of personal relationships, and trust is often built in person.

The following will facilitate successful community-led business development: (1) the community's business developer should be engaged in the role full-time, (2) the community must provide a clear intent on business development goals, (3) the business developer must have appropriate financial Resources and (4) resources should be clearly divided so that a small group of community members can use them to fulfill commitments to counterparties. This approach may prove effective for community members involved in business development.

To limit the information anyone gets in a business development role, the business development function can be split into various jobs such as wallet provider, aggregator and agency. In this way, community members participate in some but not all, without gaining too much important information about the value of the protocol.

Due to the personal relationships formed during the business development process, those engaged in business development are at high risk of receiving material non-public information. One way to address this risk is to have the community pre-approve business development deals, or have these deals get community approval. Alternatively, business developers can have greater autonomy if they are transparent to the community and the community can choose to freeze a given business development activity for further community review. These options can make it difficult for business development teams to assure potential partners that the deal will be closed, but sometimes it may be necessary to protect decentralization.

Growth and Marketing

In contrast, growth and marketing are the easiest off-chain activities to decentralize. While a centralized marketing strategy coordinated by a handful of salaried marketing managers is ideal, a decentralized marketing strategy united around a common message can prove to be very effective. After all, little coordination—or indeed knowledge, skill, or additional financial incentives—is required to fill Telegram chats with memes or yell “FUD” when a project is criticized.

Four factors help to effectively spread out growth and marketing activities:

First, code that can easily integrate with other protocols can decentralize growth and marketing. A license-free agreement allows other protocols to integrate the original protocol without help.

The ease with which one protocol can be easily integrated into another is called composability. A highly composable protocol appeals to a wide range of users because another protocol can integrate the original protocol without input from anyone in the original protocol's community.

An integrated protocol can attract the integration of more protocols and further develop the original protocol. If these protocols are also decentralized, their communities can continue to sell the original protocol at no additional cost. For example, when the Aave protocol was deployed on the Ethereum network, it attracted billions of dollars in crypto assets without the help of the Ethereum Foundation to deploy or market it.

The number of users and transaction volume may grow in tandem with the number of successful integrations. Even if an integrated protocol is built on top of multiple protocols, the activity of its users flows to each protocol it integrates with, resulting in a portion of each protocol's growth and marketing. For example, the integration of the PoolTogether protocol with the Compound protocol has brought tens of thousands of new users to the Compound protocol, increased the strength of the protocol, and brought hundreds of millions of dollars in transaction volume to the Compound protocol.

Protocols also benefit when interfaces and applications are built on top of them. Any users they attract will also become users of the protocol, with no further action required from the protocol community. For example, the 1inch routing application routes orders to multiple decentralized exchanges, including the Uniswap protocol, which pushes volume to the Uniswap protocol without the involvement of Uniswap Labs.

For composability to be most effective, the initial development team should focus on writing clean code with clear documentation and helpful tutorials. This will make it easier for others to integrate with the protocol. All code should be licensed under a permissive open source license so that other developers can use it.

Second, the community can pay developers through grants and bounties, further decentralizing growth and marketing. These grants and bounties can encourage integration and can attract developers to build tools for the protocol, such as frontends and block explorers. Grants and bounties can be done in a manner specified by future protocol development, or they can be automated. For example, the Liquity protocol can automatically reward developers who operate front-end interfaces that integrate their protocol.

Third, grants and bonuses can pay for traditional growth and marketing methods. The community can determine the best growth and marketing strategies to acquire new users, then use grants and bonuses to launch growth and marketing campaigns in these channels. The only difference from traditional growth and marketing is that those who carry out these activities are not necessarily affiliated with the protocol, just aligned with the protocol's vision and funded by grants or prize money.

Fourth, the community can empower other members to develop and market the protocol at their own expense on their own time. This allows for greater creativity, as marketers are free to do whatever they want. Also, since most marketers will have a financial investment in the protocol, they will not need additional funds. Bitcoin is a great example of effective decentralized marketing. Community members sponsored the IndyCar of the Indianapolis 500 and launched a podcast and YouTube channel discussing Bitcoin. This marketing is possible because of the strong community and because every bitcoin holder is incentivized to increase the value of the bitcoin network.

intellectual property

Communities can decentralize intellectual property, including copyrights and trademarks, to prevent one party from creating value for the community.

Copyright protects an original work, such as code, when an author (such as a developer) transforms the work into a tangible form (such as by typing code). A trademark can include the agreement's name, slogan, logo, or a combination of these that identifies goods or services, such as the agreement.

The community can use trademarks and copyrights offensively or defensively. Defensive uses, such as defending against claims of intellectual property infringement, rarely create value because they only protect the holder of that property right. Offensive use, such as diluting brand value by preventing others from using a trademark, often creates value. They protect brand-related agreements and prevent others from using copyrighted code to create competing products.

To decentralize intellectual property, the centralized party should give up all copyrights and trademarks, or transfer them to the community by assigning them to entities in the community's legal structure. This is complicated because the laws governing copyright and trademarks are not consistent across jurisdictions, but it is possible if the community is willing to accept that certain intellectual property rights may be waived or unenforceable.

When the initial development team retains control of the trademark or copyright associated with the protocol, crypto asset holders may reasonably expect to profit from the team's offensive use of the trademark or copyright. Any decentralized structure that contributes to off-chain activities in a coordinated manner has inherently the same profit expectation, unless all other off-chain activities are distributed among other decentralized entities.

To mitigate this risk, development teams or overly coordinated communities should consider issuing public statements, or extremely permissive brand guidelines, that they will only use their intellectual property for defensive purposes and not for offensive purposes. It is important to comply with these statements and guidelines after they have been developed and issued.

governance decision

The decentralized governance system is designed to empower any crypto asset holder to make proposals, vote on proposals, and delegate voting rights to those who have more knowledge or interest in the proposal. Crucially, these proposals are self-executing: they allow anyone to make and vote on proposals that, if successful, are automatically implemented.

Implementations vary by the amount of crypto assets required to make a proposal, the number of votes and yes votes required for the proposal to pass. In some governance systems, crypto asset holders pledge crypto assets to increase their voting power. Increases are usually determined by the length of the power period of the person with the greatest economic interest in the agreement.

Effective governance systems prioritize simplicity and attempt to encourage participation in governance by a wide range of actors. However, the web3 development team is focused on improving the protocol, which they believe is a vital, high-impact activity, rather than improving the governance system, which they consider less important. As a result, the development of decentralized governance systems has largely remained stagnant.

To further decentralize, the governance system must establish appropriate cryptographic asset ownership thresholds for quorum, proposals, and voting; simplify the proposal mechanism; create benefits for participation in governance; eliminate multi-signature wallets with broad authority over the protocol; and encrypted asset payment tools. Developers should create code for basic, repeatable proposals, such as changing common parameters, to increase participation by less-sophisticated crypto-asset holders. The community should consider enlisting the help of third parties who can provide insights to the community on complex topics that are difficult for the community to assess on its own.

The initial development team should also consider issuing a public statement that they will not be involved in governance, to ensure that holders of crypto assets cannot count on profit from the team’s governance efforts. Teams that do so must abide by their statements.

Community and legal structures for efficient off-chain activities

In failing the Howey test, the structure of the community plays an important role in its ability to decentralize off-chain activity and maintain operational efficiency. Structure should be considered from three perspectives: (1) how individuals and groups within the community organize themselves, (2) how the internal structure of the community communicates, and (3) the legal structure used to engage in off-chain activities.

How to communicate to effectively decentralize off-chain activities?

After identifying the off-chain activities that can be decentralized and outlining what decentralization might look like, a question remains: How should community members interact with each other to achieve decentralization?

community structure

At the heart of any implementation is how the community organizes off-chain activities. There are four main structures of the Web3 community:

All community members can participate in every decision.

The community is divided into informal, undefined groups that receive funding from the community, called sub-DAOs. These groups operate independently without any meaningful direction from the community at large.

The community is divided into formal, community-defined sub-DAOs that handle specific off-chain activities. These sub-DAOs operate independently, but receive direction from the wider community.

The community provides direction to the legal entity (usually a foundation or trust) that conducts all activities on behalf of the community.

Over the past few years, the community has used both formal and informal sub-DAOs. Each community determines the level of coordination among sub-DAOs. Sub-DAOs may be an extreme case for securities law compliance purposes. They are:

so effectively coordinated that they will be seen collectively as "active participants" - "others" in the "efforts of others" in the Howe test; or

So inefficient and uncoordinated that their members don't know anything that the public can't easily find out. Investors cannot reasonably rely on any such sub-DAOs to generate profits. These sub-DAOs cannot collectively be called "active participants", so the Howey test would fail.

The goal of each community should be to reduce the coordination of the first group and increase the efficiency of the second, in each case in a way that fails the Howey test.

The "ideal" community further divides sub-DAOs into "supported sub-DAOs" and "operational sub-DAOs".

The supported sub-DAO handles all off-chain activities that create value within the protocol, which can also drive the value of the associated cryptoasset. These usually include the following:

• protocol development
• business development
• growth and marketing
• intellectual property
• governance decision

Operational sub-DAOs are sub-DAOs that provide support for supported sub-DAOs. These usually include:

Finance - aggregates on-chain data about the protocol's financial performance (as Yearn has done in the past), submits sub-DAO budget proposals to the wider community, and holds funds for paying sub-DAO contributors

Legal — Publish legal analysis on the protocol and provide legal advice to sub-DAOs.

Recruiting and Personnel - Hiring candidates for sub-DAOs and other operations, whether full-time employees or independent contractors.

Administration - Handles contracts with third parties that provide tools for the child bDAO, such as software, payroll providers, and payments. Manages all other administrative matters of the child DAO.

Operating sub-DAOs should make supported sub-DAOs as independent as possible from each other. For example, legal DAOs should always publish guidelines in the public domain and create accessible legal forms for use by other child DAOs. Legitimate sub-DAOs can also help other similarly structured communities by making these forms easy to use. Finance sub-DAOs can publish web3-specific financial models and teach the wider web3 community how to build budgets and manage runways across sub-DAOs. A recruiting sub-DAO can provide public guidance on recruiting and compensating quality candidates.

The number of subDAOs supported is a trade-off between centralization efficiency and reduced legal risk of decentralization. The most efficient (but least centralized) structure will consolidate all off-chain activities into one subDAO. The least efficient (and most decentralized) structure would be to split each activity into a separate subDAO. When the community has decided on the appropriate number and functionality of subDAOs for its purpose, it should create subDAOs for each activity and form an appropriate entity.

Virtually all communities need a governing subDAO, whether it stands alone or combined with other operational subDAOs. Otherwise, nothing can be done. The community also needs a governance subDAO (and proposals for a legal subDAO) to form a supported subDAO. Once created, recruiting subDAOs should recruit community members to join supported subDAOs. Hiring employees instead of independent contractors adds administrative and tax complexity. However, this may be necessary if subDAO members are acting like employees.

When subDAOs are funded, the funds required to organize and form each subDAO can be allocated from grant programs with sufficiently broad community approval, or directly from community treasuries. In order to maintain independence from other subDAOs, it is best to have independent proposals to fund and form each subDAO.

effective communication

When recruiting contractors and employees to a subDAO, managing or operating the subDAO should provide a means of communication for all subDAOs engaged in off-chain activities, whether it be Discord, Keybase, or other tools.

Without the structure and communication tools in place, the community is likely to start functioning like a company, at least as far as the Howey test is concerned. They may become like a typical company where business units sit near other business units and discuss issues closely. That is, the company is private - no one outside the company knows what's going on and can't contribute to anything that happens inside the company. Only employees can create value.

The Web3 community cannot become similar to companies in this regard. Coordination must be minimized through open communication. Each subDAO must communicate in the public domain so that members of each subDAO can access the information contained in its messages.

Public communication should be comprehensive, including (1) daily discussions between subDAO members on public channels (such as Discord or other communication platforms); (2) written or video on Notion or similar publicly accessible products Timely, detailed updates of completed projects published; (3) roadmaps for future projects and the status of those projects, posting them on Notion or similar.

When communication is public, subDAOs can operate in an environment around the decisions they make. Also, since everything is public, no subDAO holds private information that could create value for cryptoassets. No group within the community, or even the community as a whole, will have information that no one else does.

This communication structure also means that community members who are not part of the subDAO can make valuable contributions to the community. In fact, community members shouldn't be part of the subDAO at all; they should have the tools to contribute anyway.

In engaging in these activities, subDAOs may obtain information meaningful to the value of cryptoassets, but cannot make it public. However, a decentralized subDAO should reduce the risk that such information could harm crypto-asset holders who are not members of the subDAO.

In particular, each subDAO will lack information held by other subDAOs, so that no member of a subDAO holding meaningful information can use that information to the detriment of crypto asset holders. Even if subDAOs collectively hold enough material nonpublic information that they must disclose their collective information under U.S. securities laws, they should not be sufficiently coordinated for all to work together to make a collectively material disclosure.

Therefore, investors cannot count on any subDAO, or even a group of subDAOs, and reasonably expect to profit from their efforts. Only the individual efforts of each subDAO, based on public information, can create value in crypto assets.

Alignment on mission, vision and values

Communities should consider creating alignment around a shared mission, vision, and values. These can help decentralization by reducing the close coordination necessary between contributors who understand the guiding principles and goals. They enable individual contributors to act independently and provide guidance when contributors encounter ambiguous situations. Granted, missions, visions, and values can create centralization when the individual or team creating them rejects community-suggested changes and considers them to be community-adopted missions, visions, and values when they are created in a centralized fashion. It's crucial that they align with the community really broadly, and may need to change from time to time as the community changes.

Which legal entities should the subDAO use for off-chain activities?

Legal entities, such as foundations and trusts, protect a community or benefit specific community members. They do not directly contribute to decentralization, but they lead to centralization.

The best structure for decentralization would be to construct a separate legal entity for each community member. This would protect every member who contributes to the community, but is costly and impractical. The most centralized structure will bring together all off-chain activities of the community through a single legal entity. This would work, but centralization could cause securities law compliance issues.

A viable middle ground should be created between 5-10 entities carrying out different and sometimes overlapping off-chain activities. These entities should be mapped to each subDAO to protect community members contributing to that subDAO. This would limit their liability, provide the power to sign contracts and ensure subDAOs are tax compliant.

It is not necessary to use the same legal entity for all subDAOs. A foundation might be suitable for one subDAO, a trust for another, and an unincorporated nonprofit association (UNA) for a third.

The entity chosen by the community for a subDAO depends on its goals, the location of the community members, and the need for decentralization. SubDAOs should consider using (1) foundations created in the Cayman Islands or British Virgin Islands, (2) trusts created in Guernsey or Jersey, and (3) UNAs that exist under US state law. In some cases, other entity types or jurisdictions may be more appropriate choices.

The impact of cross-community support on the decentralization of off-chain activities

The most effective way for a community to decentralize its off-chain activity is with the help of other communities. The Web3 community openly shares tools and best practices on program and communication strategies, benefiting the entire web3 ecosystem. If every community shared the output of its off-chain activity — or, frankly, any such output — with every other community, off-chain activity would decentralize at a much faster rate because each community would not have to reinvent wheel.

There are several areas that can help other protocols’ off-chain activities: (1) Governance tools, such as Compound Labs’ governance system, which can be used in any community, and Uniswap Labs’ introduction of governance tools Sybil by mapping on-chain addresses to digital identities (2) legal documents and forms, such as the dYdX Foundation’s use of trust structures in DAOs and their trust statements; (3) identifying (i.e. facilitating) supplementary protocols or applications; (4) creating Best Practices.

Such a contribution would not be an act of altruism. If a community provides value to another community, the likelihood that the other community will return increases. When one community helps another and then posts the help in the public domain, unrelated communities can also benefit, and may be encouraged to provide additional support themselves. Over time, the resources available to the community will provide great value to those who contribute.

Given the breadth of their portfolios, venture capitalists also have an important role to play. If a common problem arises in their community, VCs can solve it for all communities at once — no matter how active they are in a particular community. If a general solution is widely adopted, specific communities have less access to important information.

What other community and VC firms do for the community can have a meaningful impact on Howey's analysis. At scale, these efforts can create significant value in cryptoassets, leading to value creation in cryptoassets by causing their holders to rely less on initial development teams or other active participants.

If only a small number of high-impact communities and venture capitalists provide cross-community support, there may be less reliance on the efforts of the initial development team or any other active players. This will reduce centralization risk, thereby reducing regulatory risk, and increase the speed at which all communities can engage in off-chain activities.

The role of the initial development team in off-chain activities

Initial development teams participating in off-chain activities increase the risk that the community will rely on their efforts for a reasonable expected profit. This has caused these teams to relinquish an overly important role in off-chain activities.

When the community takes over significant off-chain activities, as described in this paper, there is more room for initial development teams to participate in off-chain activities, as the community is less likely to reasonably expect profit by relying on the efforts of these teams.

In other words, when the community is involved in these activities, the original development team is less important. The community then benefits from the fact that the original development team can participate more meaningfully in the evolution of the protocol, even if their contributions are offset by community efforts.

The initial development team should be concerned with more than just their off-chain activities. They should also avoid:

Creating an expectation that transferring crypto assets to the initial development team will incentivize them to increase the value of those crypto assets. As often as it seems to be the case, teams holding crypto assets don’t necessarily seek to create this kind of value.

Facilitate the success of the efforts of the initial development team. Most teams want to publish their successes, but they should seek to balance these publications by publicizing community achievements in which they were not involved. Ideally, the team would not need to balance publications, as the community's contributors would focus on communicating community activity, including that of the subDAO.

Make a statement about centralization, which means relying on the efforts of the centralizing party. A balance should be struck between the risks of publicly disclosing agreements and disclosures that result in potential liability.

Discuss off-chain activities or on-chain operations of the protocol to hint at ways in which the initial development team may perform certain operations. English teachers always teach students to write in active voice, but all descriptions of off-chain and on-chain activities should be in passive voice. The passive voice accurately describes on-chain activity, avoiding any expectation of profit in any party's off-chain activity.

Post or share social media content without the expectation that the original content will be attributed to the team that shared it. If the team disagrees with the content of their retweeted tweet, then they should make it clear.

When referring to the original development team, the term connotes increased importance relative to other teams, such as the "lead" or "core" team. Instead, they can be referred to as "Initial Contributors".

Participate in the governance of the protocol. While the original development team participates in governance, crypto asset holders continue to rely on that team to create value by making the strategic decisions included in proposals, rather than letting the community make those decisions.

The original development team may argue that some of the above actions do not result in third parties having a reasonable expectation of profiting from their entrepreneurial or management efforts. For example, private discussions with exchanges to trade crypto assets that are not publicly known should be considered to create profit expectations from any team effort that is not publicly known. However, perception matters; it's best to avoid needing to address this issue.

While this article aims to address only the issue of “sufficient decentralization,” actions should be considered by initial development teams to prevent them from taking the position that crypto asset holders have no reasonable expectation of profit, including:

• Take any action to list cryptoassets on secondary markets, whether centralized or decentralized exchanges; do the same with another party (e.g. a market maker), or facilitate the existence of secondary markets that another party may create .
• Make any statement about the price appreciation of crypto assets, or create profit expectations that do not yet exist.
• Discusses market structures surrounding crypto assets such as liquidity, selling pressure and demand.

in conclusion

There is no perfect way to achieve full decentralization. In the coming months and years, the community in web3 will test countless ways to achieve full decentralization in all of the above-mentioned off-chain activities. More web3 native tools will be created and developed for the community to facilitate communication between teams and the structures they use to function effectively. As long as the community maintains the open principles in this paper, sufficient decentralization can be achieved while effectively participating in off-chain activities.