Web3 Handbook for Builders and Lawyers: How to Effectively Decentralize Off-Chain Activities?


The builders of Web3 have focused on the concept of “sufficient decentralization” since it was proposed by SEC staff in 2018. It allows builders to focus on distributing the efforts that drive the profits of crypto assets from a centralized company to independent community members working for a common goal.

Since blockchain is an emerging technology, most legal advice on securities law focuses on the decentralized Web3 technology stack. But equally important is the off-chain day-to-day activities of decentralised community contributors. None of this work takes place on the blockchain, including developing or software around the protocol, engaging in business development, marketing and growing the protocol, making intellectual property available to all, and advancing protocol governance.

However, these contributions (which this manual defines as off-chain activities) are difficult to automate and add bureaucracy, meaning off-chain activities around decentralized protocols tend to be centralized. To achieve robust decentralization, the community must consciously consider how to structure on-chain and off-chain activity.

This playbook is intended for (1) Web3 founders who wish to effectively decentralize off-chain activities while complying with U.S. securities laws, and (2) Web3 attorneys advising these founders. It explains what “sufficient decentralization” means, how it affects off-chain activity, common mistakes that lead to the centralization of decentralized organizations (DAOs), and how to effectively build communities to achieve “sufficient decentralization” .

Although this handbook provides perspectives on how to effectively decentralize off-chain activities, it does not imply that the approaches considered therein are the only ways to achieve this. There is no single normative definition of adequate decentralization, nor a perfect way to achieve it. Some of the approaches taken by companies and communities to date may offer alternatives, and in some cases may even be more conservative from a regulatory perspective, although they may be less efficient.

Investment Contracts: Getting Started

In the United States, securities issuers must register with the SEC or rely on exemptions to issue securities. At the time of registration, issuers must disclose important information about the business, the market and the offering of securities. These disclosures are designed to protect investors by sharing information that rational investors want to know, and 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-way analysis devised by the U.S. Supreme Court in the 1946 SEC v. WJ Howey Co. case. The Supreme Court concluded that an investment contract is a transaction (1) involving the investment of funds (2) a reasonable expectation of profit in an ordinary enterprise (3) (4) based solely on the efforts of others. The court later explained the fourth aspect that reasonable expectations of profits come 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. This test is still in use today to determine whether the sale of a cryptoasset constitutes a sale of an investment contract.

Crucial to the analysis of investment contracts is whether the investor expects to profit from the entrepreneurial or managerial efforts of others, according to the fourth principle of the Howey test. Therefore, a key determinant of whether the sale of a cryptoasset is also an investment contract is whether one can reasonably expect Web3 contributors to drive the value of the cryptocurrency, including through off-chain activity.

What does full decentralization mean?

In June 2018, William Hinman, then director of the SEC’s Division of Corporate Finance, proposed the idea of ​​“sufficient decentralization” in a speech. Hinman said: “If the token or the network the token runs on is sufficiently decentralized — in which case buyers would no longer reasonably expect a single person or group to undertake the necessary managerial or entrepreneurial efforts — these assets may not represent an investment. Contracts.” With this framework, Hinman concluded that current ethereum sales are not securities sales because the ethereum network is sufficiently decentralized.

Web3 Handbook for Builders and Lawyers: How to Effectively Decentralize Off-Chain Activities?

Hinman’s concept of “sufficient decentralization” is a nod to the final step of the Howey test, which assesses whose efforts drive buyers’ expectations of cryptoasset profits. If a protocol or network is not sufficiently decentralized, the value of the associated cryptoasset can be derived from the efforts of a centralized team — a person or group of people who the public believes coordinate to increase the value of the cryptoasset. If the protocol is sufficiently decentralized, then the value of the underlying cryptoasset does not derive from what the public perceives as the efforts of a centralized team – there is no identifiable, coordinated team driving the value of the cryptoasset.

The SEC’s Center for Innovation and Financial Technology Strategy (better known as FinHub) cemented the concept of full decentralization in April 2019 with its “Contract Analysis Framework for Digital Asset Investments.” The FinHub framework provides detailed guidance on every aspect of the Howey test. In doing so, it introduced the idea of ​​an “active participant” as a “facilitator, sponsor, or other third party (or an affiliate of a third party)” associated with the last branch of the Howey test .

While the FinHub framework recognizes that active participants may be “third-party affiliated groups,” when referring to affiliated groups, the framework may deviate from the term defined in SEC regulations, referring to coordinated actions among third-party groups. Unlike the uncoordinated third-party group that works on the agreement, the coordinated third-party group may have access to material information that must be disclosed under securities laws.

According to the FinHub framework, several factors should be considered when deciding to “rely on the efforts of others” – namely “whether important tasks or responsibilities should be performed by one (active participant) rather than by an independent, decentralized Network user community to complete”.

But even if a cryptoasset is initially sold as an investment contract, the FinHub framework outlines how it can subsequently be sold as a non-securities. If the entrepreneurial and managerial efforts of an active participant, including anyone who later becomes an active participant, cease to be “significant to the value of the digital asset investment” or “impact the success of the business”, the asset may undergo a mutation (meaning that It will eventually fail the Howey test).

In short, the sale of a cryptoasset satisfies the last aspect of the Howey test if one reasonably expects to profit from the cryptoasset through the entrepreneurial or managerial efforts of others (including those of active participants). However, if a person reasonably expects to profit from the uncoordinated efforts of a wide range of people, he should not be satisfied; the protocol and its related activities should be considered “sufficiently decentralized” and should not be considered Sell ​​any investment contracts.

Legal advisors advising Web3 participants on the distribution or sale of cryptoassets typically incorporate the concepts of “sufficient decentralization,” “active participants,” and mutation. Thus, sensible players have become familiar with how to replace the active players of a centralized protocol with a sufficiently decentralized, uncoordinated group of people who drive the value of the protocol.

However, the technology of the protocol and its autonomous operation may not always be the only reasonable factor driving the value of a given cryptoasset. Those who reasonably expect to profit from cryptoassets may perceive the additional off-chain activity as value-driven. Therefore, to reduce the risk for any Web3 participant, the community should also seek to decentralize off-chain activities, including the following:

  • Protocol development
  • business development
  • Growth and Marketing
  • intellectual property
  • governance decisions

Web3 Handbook for Builders and Lawyers: How to Effectively Decentralize Off-Chain Activities?

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

For example, in early protocols, or where protocols are easily integrated with other protocols, community protocol development may have the greatest impact on driving the value of the underlying cryptoasset. Conversely, in communities where protocol design is established, or where 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 censorship-resistant charisma of decentralization. Every community must balance the desire to benefit from the speed, cost, and operational efficiency of centralization with the benefits of decentralization—consensus building, censorship resistance, transparency, and independence. Communities accept varying degrees of centralization, and as such, there is no perfect order on the “scope of decentralization.”

To improve performance and efficiency, more centralization is required; to maximize decentralization, some speed has to be sacrificed, so there are inefficiencies. Each community will over time, knowingly or not, determine the centralization to decentralization range of its off-chain activities. In terms of centralization of the spectrum, the coordination of one person or a company or a small group of people can participate in all off-chain activities. In terms of decentralization of the spectrum, anyone can participate in any off-chain activity at any time without having to communicate with anyone else participating in the same protocol.

On a technical level, 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 that makes it (who also often believe that their protocol will one day be like the Ethereum network) decentralization).

The same tradeoff applies to off-chain activities. A small group that is constantly coordinating, such as a company, may find it more efficient to centralize off-chain activities. For example, centralizing marketing operations through one marketing agency is very effective, as a marketing manager can guide a hand-picked team to deploy multimedia marketing campaigns on Discord, Twitter, Telegram and other social channels. Speed ​​and consistent messaging are achieved because one marketing agency controls access to and content published on the protocol’s social channels.

Conversely, a fully decentralized community might allow anyone to participate in any off-chain activity without communicating with other participants. This is inefficient; continuing the example above, without a manager coordinating the community’s marketing efforts, anyone can proactively promote it for themselves, regardless of their ability to do so — or no one at all can promote the project.

As far as the Howey test is concerned, the more concentrated the community, the greater the risk that the sale of cryptoassets will be seen as a sale of securities. However, many other factors also affect how decentralized a community is:

  • culture
  • Historical development of off-chain activities within the community
  • Censorship Risks Associated with Community Activities
  • leaders in the community
  • Expand the strategic use of the protocol
  • Coordination required to adjust protocol parameters or otherwise

Web3 Handbook for Builders and Lawyers: How to Effectively Decentralize Off-Chain Activities?

Although the Web3 community is inherently incomplete, community members can still reach a general consensus on the degree of decentralization. The community may even have a de facto “leader”, like Vitalik Buterin is the leader of the Ethereum community, to help achieve this consensus. Once this is achieved, the community should establish processes to protect this level of decentralization and work to defend them.

Community decentralization should take into account the sum of all components of the community, and the community should embrace centralization schemes that may improve the efficiency of the protocol and compensate by further decentralizing other off-chain activities. For example, if an early protocol development would benefit from the coordination of a tight group of experts, this centralization may be offset if the community further decentralizes other off-chain activities.

Many initial development teams and community members will consider the impact of their actions and ask if an action is problematic for decentralization, and few actions are problematic; instead, all actions in centralization should be considered. Whenever someone engages in activity around the protocol, they either help or hurt decentralization. Therefore, the best frame of reference is the ongoing development of decentralization.

Web3 Handbook for Builders and Lawyers: How to Effectively Decentralize Off-Chain Activities?


Difficulties in Decentralizing Off-Chain Activity

Decentralizing off-chain activity is achievable; doing it effectively is difficult. This is primarily a communication issue: everyone involved in off-chain activities must be aware of the work of others without the need for close coordination, and under the Howey test application of the FinHub framework, they risk becoming “active participants”, leading to Crypto assets are considered investment contracts.

Again, the community must strike a balance between the two extremes. Close coordination can lead to centralization, but it can lead to confusion if community members do not share information with other contributors in the community.

For example, if community marketers only communicate among themselves, other contributors will not understand how the protocol is marketed. For example, the inability of software developers to understand the needs of users results 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 as centralized companies. Communities engaged in off-chain activities must avoid forming coordination agreements that are largely off-chain activity groups. Continuing the example above, marketing teams should provide updates on their activities (such as timelines, status, plans, and feedback) on public social media platforms and governance forums.

Communities need the most practical means of communication and need to consider or identify tools suitable for community collaboration. For example, Notion pages can be exposed, Zapier can be used to allow anyone to view these exposed 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 on public communication channels. However, on most community forums, where members openly discuss the future of the protocol and off-chain activity, the most sensitive competitive information is already known. In Web3, how a community enforces competing information will determine its success, not the confidential information it holds. When community members engaged in off-chain activities gain access to confidential information, they may receive materially asymmetric information relative to community members who are not actively involved in these activities, which may strengthen arguments in favor of treating cryptoassets as securities.

Web3 Handbook for Builders and Lawyers: How to Effectively Decentralize Off-Chain Activities?

In Web3, confidentiality is not an issue because most information is not or need not be kept secret. This concern remains for members of the business development, marketing community who cannot share confidential information obtained from third parties. To some extent, this can be resolved by agreeing with a third party that the relationship or contract is not considered confidential. In such cases, community members with confidential information should attempt to provide the information or create a general description of the confidential situation. When the issue cannot be resolved in this way, it is the responsibility of these community members to ensure that important information does not impact crypto asset holders.

How to decentralize off-chain activities?

Depending on the nature of cryptoassets, off-chain activities by the initial development team may result in cryptoasset holders having a reasonable expectation of profiting from these efforts, and the strategies outlined below reduce such expectations.

When properly implemented, they will be expected to be distributed among wider populations that do not require coordination with any other groups. This increases the expectations of crypto-asset holders to profit from the efforts of this wider group, and lowers the expectations of profit from the efforts of the initial development team or any other coordinating group.

Web3 Handbook for Builders and Lawyers: How to Effectively Decentralize Off-Chain Activities?

Protocol development

While tight-knit teams usually create the protocol initially, after publishing the protocol, they often open up protocol development to a community of willing programmers. Groups can modify existing code or deploy upgraded versions of the protocol, and they can also build software that integrates with the protocol, creating larger requirements or different use cases for the protocol.

In order to effectively develop a decentralized protocol, all deployed protocol code should be open source. Otherwise, the community cannot continue to build the protocol or software that runs on it. Since the original developers of the protocol will most likely know the code better than others, 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, which will allow the community to meaningfully contribute to the code and use the protocol.

Of course, since the initial developers are more familiar with the code than community members, they may still be in the best position to develop the protocol. As a result, community developers may not modify or improve the code, hindering the decentralization of protocol development. To incentivize community members to contribute to protocol development, the community can provide bounties.

In the presence of contributors, the community should identify possible areas for protocol modification or improvement, and then issue requests for proposals to developers who can build on the protocol. While it can be difficult for the community to identify these areas without guidance, open source and public code development should make this easier. This guidance can come from a roadmap published by the product team, a community member, or a high-level strategy developed for the community by the initial development team or other respected community member. Strong grant programs in DeFi include those related to the Aave protocol, the dYdX protocol, and the Uniswap protocol. Some Layer 1 and Layer 2 networks have major grant programs in the form of funds, such as those related to the Polygon network and the Zcash network.

When it comes to bounties, the community should ensure that valuable contributors are paid. A formal bounty program helps address this dilemma, as does promoting the work of high-value contributors. For example, a Web3 is a “Employee of the Month” program, and bounties are more likely to come into play when contributors believe their efforts will be rewarded handsomely and consistently.

business development

Business development is the increased use of an agreement by establishing targeted personal relationships with third parties such as other agreements or agencies. It is probably the most difficult off-chain activity to decentralize after the scheme is formulated, because business development relies on a small number of personal relationships, and trust is usually established face-to-face.

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

To limit the information anyone can acquire in a business development role, business development functions can be split into various jobs, such as wallet providers, aggregators, and institutions. In this way, community members participate in some but not all of the effort without gaining too much important information about the value of the protocol.

Because of the personal relationships formed during the business development process, those involved in business development are at high risk of receiving material non-public information. One way to address this risk is for the community to pre-approve commercial development transactions, or have these transactions receive community approval. Alternatively, business developers can have more discretion if they are transparent to the community and the community can choose to freeze specific business development activities for further review by the community. These options can make it difficult for business development teams to assure potential partners that transactions 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 around a common message may prove very effective. After all, there is little coordination — or really knowledge, skills, or additional financial incentives — to flood Telegram chats with memes or yell FUD (panic/uncertainty) when projects are criticized.

Four factors contribute to the effective decentralization of growth and marketing campaigns:

First, code that can be easily integrated with other protocols can be grown and marketed in a decentralized way, without permission agreements allowing other protocols to integrate the original protocol without help.

The ease with which one protocol can be integrated into another is called composability. Highly composable protocols attract a wide range of users because another protocol can integrate the original protocol without the help of anyone in the original protocol community.

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

The number of users and capacity can grow in tandem with the number of successful integrations. Even if an integration protocol is built on multiple protocols, its users’ activity 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 brought thousands of new users to the Compound protocol, increased the strength of the protocol, and brought the Compound protocol hundreds of millions of dollars in scale.

Protocols also benefit when interfaces and applications are built on top of them. Any users they attract also become users of the protocol without further action by the protocol community. For example, the 1inch Aggregate DEX routes orders to several decentralized exchanges, including the Uniswap protocol, which links volume to the Uniswap protocol without the involvement of Uniswap Labs.

To make composability more 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 open source and permissionless so that other developers can use it.

Second, the community can support developers with grants and rewards, further decentralizing growth and marketing. These grants and rewards can encourage integration and can entice developers to build tools for the protocol, such as frontends and block explorers. Grants and rewards can be done as specified in future protocol development or automatically. For example, the Liquity protocol can automatically reward developers who operate front-end interfaces that integrate its protocol.

Third, grants and bonuses can pay for traditional growth and marketing methods. Communities can determine the best growth and marketing strategies for acquiring new users, then use grants and rewards to execute growth and marketing campaigns across those channels. The only difference from traditional growth and marketing is that the people running these activities are not necessarily affiliated with the agreement, just aligned with the vision of the agreement and funded by grants or bounties.

Fourth, the community can empower other members to develop and promote the protocol on their own time and at their own expense. This allows for greater creativity, as marketers are free to do whatever they want. Also, since most marketers will be making a financial investment in the protocol, they will not need additional capital. Bitcoin is a great example of effective decentralized marketing. Community members sponsored IndyCar at 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 has an incentive to increase the value of the Bitcoin network.

intellectual property

The community can decentralize intellectual property, including copyrights and trademarks, to prevent a single party from creating value for the community.

Copyright protects an original work, such as code, when an author (such as a developer) brings that work into tangible form, such as entering code. Trademarks may include the agreement’s name, symbol, logo/badge, or a combination of these identifying goods or services such as the agreement.

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

In order to decentralize intellectual property, a centralized party should relinquish all copyrights and trademarks, or distribute them to the community by assigning them to an entity in the community’s legal structure. This is complicated because copyright and trademark management laws in different jurisdictions are inconsistent, but it is possible if society is satisfied that some intellectual property rights may be waived or unenforceable.

When the initial development team retains control over the trademark or copyright associated with the protocol, cryptoasset holders may reasonably expect to profit from the team’s aggressive use of the trademark or copyright. Any decentralized structure that facilitates off-chain activity in a coordinated manner has the same profit expectations, except where all other off-chain activity is distributed among other decentralized entities.

To reduce this risk, communities with overly coordinated development teams should consider issuing a public statement, or extremely lax brand guidelines, proving that they will only use their intellectual property for defensive purposes, not offensive ones. It is important that these statements and guidelines are followed after they have been issued.

governance decisions

Decentralized governance systems are designed to empower any crypto asset holder to make proposals, vote on proposals, and delegate voting power to those who know better or are interested in proposals. Crucially, these proposals are self-executing: they allow anyone to propose and vote for a proposal, and if the proposal is successful, it is automatically executed.

Implementation varies based on the number of cryptoassets required to make a proposal, the number of votes and affirmative votes required for the proposal to pass. In some governance systems, crypto asset holders hold crypto assets to increase their voting power. Increased voting power is typically weighted by who has the greatest financial interest in the protocol by the length of time their tokens are staked.

Effective governance systems prioritize simplicity and try to encourage a broad range of actors to participate in governance. However, the Web3 development team has focused on improving the protocol, which they see as a critical, brand-boosting activity, rather than improving governance systems, which they see as less important. As a result, the development of decentralized governance systems has largely stalled.

To further decentralize, governance systems must establish appropriate cryptoasset ownership thresholds for quorum, proposals, and voting; simplify proposal mechanisms; create benefits for participation in governance; eliminate multi-signature wallets with broad authority over protocols; improve communications and cryptoassets Payment instrument. Developers should create code for basic, repeatable proposals, such as changing a public parameter to increase participation by less sophisticated cryptoasset holders. The community should consider seeking the help of third parties who can help provide insights to the community on complex topics that are difficult for the community to evaluate on its own.

The initial development team should also consider issuing a public statement that they will not participate in governance to ensure that holders of cryptoassets cannot expect to rely on the team’s governance work for profit, and teams that do so must abide by their statement.

Community and legal structures for efficient off-chain activities

Without passing the Howey test, the structure of the community plays a meaningful role in decentralizing its off-chain activities and maintaining operational efficiency. The structure should be considered in three dimensions: (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 effectively decentralized off-chain activities?

After identifying off-chain activities that can be decentralized and outlining what decentralization looks like, one 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 structures off-chain activity, and the Web3 community structures itself in four main ways:

  1. All community members can participate in every decision.
  2. The community is divided into informal, undefined groups that receive funding from the community, defined as SubDAOs. These organizations operate independently without any meaningful guidance from the community.
  3. Communities are divided into formal, community-defined sub-DAOs that handle specific off-chain activities. These subgroups operate independently, but are directed by the wider community.
  4. The community provides guidance to the legal entity (usually a foundation or trust) to carry out all activities on behalf of the community.

Web3 Handbook for Builders and Lawyers: How to Effectively Decentralize Off-Chain Activities?

Over the past few years, the community has used both formal and informal sub-DAOs. Each community determines the level of coordination between child DAOs. For securities law compliance purposes, child DAOs may fall at the extreme end of a spectrum. they are:

  • Coordination so efficiently that they will be collectively seen as “active participants” will not be able to avoid the Howey test.
  • So inefficient and incoherent that their members don’t know anything that the public can’t easily discover. Investors cannot reasonably rely on any such sub-DAO to generate profits. These child DAOs cannot collectively be considered “active participants” and thus the Howey test fails.

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

The “ideal” community should further split child DAOs into “supported child DAOs” and “operational child DAOs”.

Supported child DAOs handle all off-chain activities in the protocol that create value, which can also drive the value of the underlying cryptoasset. These typically include the following:

  • Protocol development
  • business development
  • Growth and Marketing
  • intellectual property
  • governance decisions

Operate child DAOs, and in order to support child DAOs, they can provide support for other child DAOs. These usually include:

  1. Finances — Aggregate financial performance of data on the protocol chain (as Yearn has done in the past), submit sub-DAO budget proposals to the wider community, and hold funds to pay sub-DAO contributors.
  2. Legal – Publish legal analysis on the protocol and provide legal advice to child DAOs.
  3. Recruitment and Personnel – Recruiting candidates for sub-DAOs and other businesses, either as full-time employees or as independent contractors.
  4. Administration – Processes contracts with third parties that provide the child DAO with tools such as software, payroll providers, and payments, and manages all other administrative matters for the child DAO.

Operating child DAOs should keep the supported child DAOs as independent of each other as possible. For example, a legitimate child DAO should always publish guidelines in the public domain and create an accessible legal form for use by other child DAOs. By making these forms easy to use, legitimate child DAOs can also help other similarly structured communities. A finance sub-DAO can publish Web3-specific financial models and tell the wider Web3 community how to build budgets and manage runways across the sub-DAOs (runways aren’t ready, planes can’t take off), and a recruiting sub-DAO can recruit and compensate qualified candidates for People provide public guidance.

The number of sub-DAOs supported is a trade-off between centralization efficiency and decentralization legal risk reduction. The most efficient (but least centralized) structure would consolidate all off-chain activities into a single child DAO. The least efficient (and most decentralized) structure would split each activity into separate sub-DAOs. When the community decides on the appropriate number and functionality of sub-DAOs suitable for its purpose, it should create sub-DAOs for each activity and form appropriate entities.

As a practical matter, all communities need an executive sub-DAO, whether it is standalone or merged with other action sub-DAOs. Otherwise, nothing can be done operationally. The community also needs a governance sub-DAO (and a proposal for a legal sub-DAO) to form a supported sub-DAO. Once created, a recruiting child DAO should hire community members to join a supported child DAO. Hiring employees, rather than independent developers, will add administrative and tax complexity, but may be required if child DAO members are behaving like employees.

When funding sub-DAOs, the funds required to organize and form each sub-DAO can either be approved broadly enough from the community or allocated directly from the community treasury. In order to maintain independence from other sub-DAOs, it is best to have independent proposals to fund and form each sub-DAO.

effective communication

As contractors and employees are recruited into sub-DAOs, administrative or business sub-DAOs should establish a means of communication for all sub-DAOs engaged in off-chain activities, be it Discord, Keybase, or other tools.

Without the proper structure and communication tools, the community is likely to start functioning like a company, so that the Howey test cannot be avoided. They might turn into a typical company with business units sitting next to other business units discussing 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 the employees can create value.

The Web3 community cannot become corporate-like in this regard, and coordination must be minimized through public communications, in which each child DAO must publish information so that members of each child DAO can access the information contained within.

Public communications should be comprehensive and include (1) daily discussions among sub-DAO members on public channels (such as Discord) or other communication platforms; (2) written or video postings on Notion or similar publicly accessible products Detailed updates on completed projects; (3) Roadmaps for future projects and the status of those projects, posting them on Notion or similar.

When the communication is public, child DAOs can operate in the full context of the decisions they make. Also, since everything is public, no child DAOs hold private information that could create value for the cryptoasset. No group in the community, or even the community as a whole, will have information that no one else has access to.

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

In participating in these activities, sub-daos may gain meaningful information about the value of the crypto-asset, but cannot make it public. However, a decentralized sub-DAO should reduce the harm and risk of information to crypto asset holders.

In particular, each sub-DAO will lack information held by other sub-DAOs, so that no member of the sub-DAO holding meaningful information can use that information to the detriment of crypto asset holders. Even if child DAOs collectively hold enough material non-public information that they are required to disclose their collective information under U.S. securities laws, they should not be coordinated enough for all to work together to make collective disclosure significant.

Therefore, investors cannot count on any sub-DAO, not even a sub-DAO, and reasonably expect to make a profit from their efforts. Only the individual efforts of each sub-DAO, based on public information, can create value in cryptoassets.

Align on mission, vision and values

Communities should consider aligning on a common mission, vision, and values. These measures can help decentralization by reducing the need for close coordination between donors who understand the guiding principles and goals. They empower individual contributors to act independently and provide guidance when contributors encounter ambiguous situations. Granted, when missions, visions, and values ​​are created in a centralized fashion, they can create centralization when the individuals or teams that create them reject community-suggested changes and consider them to be community-adopted missions, visions, and values. The point is that they align with the community really broadly and may require occasional changes (mission or vision) as the community changes.

Which legal entities should child DAOs use for off-chain activities?

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

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

An actual middle ground would create five to ten entities to carry out different and sometimes overlapping off-chain activities. These entities should be mapped into each sub-DAO to protect community members who contribute to that sub-DAO. This will limit their liability, provide the power to sign contracts, and ensure that affiliated DAOs comply with taxes.

It is not necessary to use the same legal entity for all child DAOs. A foundation might fit into one child DAO, a trust might fit into another child DAO, and an unincorporated nonprofit association (UNA) might fit into a third child DAO.

The entity the community chooses for a sub-dao depends on its goals, the location of community members, and the need for decentralization. A subdao should consider using (1) foundations created in the Cayman Islands or British Virgin Islands, (2) trusts created in Guernsey or Jersey, and (3) UNAs existing under U.S. state law. In some cases, other entity types or jurisdictions may be more appropriate options.

In a nutshell, the chart below lists the advantages and disadvantages of each entity type, or not using a legal entity at all.

Web3 Handbook for Builders and Lawyers: How to Effectively Decentralize Off-Chain Activities?

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

The most effective way for a community to decentralize off-chain activities is with the help of other communities. The Web3 community openly shares tools and best practices in processes, communication strategies, and benefits the entire Web3 ecosystem. If each community shares the output of its off-chain activity—or frankly, the output of any off-chain activity—with other communities, decentralization can be accelerated because each community doesn’t have to reinvent the wheel.

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

Such a contribution is not an altruistic act. If one community provides value to another, the likelihood of other communities returning increases. When one community helps another and then publishes that 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 significant value to those who contribute.

Given the breadth of the portfolio, venture capitalists also have an important role to play. If a common problem arises in their community, venture capitalists can address all communities at once – no matter how active they are in a particular community. If a common solution is widely adopted, there will be less access to material information for a given community.

Community input from other communities and VCs can have a meaningful impact on Howey’s analysis. At scale, these efforts can create significant value in the cryptoasset, making its holders less reliant on the initial development team or other active participants to generate value in the cryptoasset.

If only a few high-impact communities and VCs provide cross-community support, there is less reliance on the initial development team or other active participants. This will reduce the risk of centralization, thereby reducing regulatory risk, and increase the speed at which all communities can participate in off-chain activities.

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

Initial development teams engaged in off-chain activities increase the risk because the community reasonably expects to profit from their efforts, which results in these teams not playing as much of a role in off-chain activities.

When the community takes over significant off-chain activities, as described in this handbook, the initial development team has more time to participate in off-chain activities because the community is less likely to reasonably obtain the expected profits by relying on the efforts of these teams.

In other words, when the community is involved in these activities, the initial development team is less important. The community then benefits from the fact that the initial development team can more meaningfully participate in the development of the protocol, even if their contribution is outweighed by the community’s efforts.

Initial development teams should focus on more than just their off-chain activities, they should also avoid:

  • Create an expectation to transfer cryptoassets to the original development team, incentivizing them to increase the value of those cryptoassets. While this is often the case, it does not mean that teams holding crypto assets will seek to create this value.
  • Drive the initial development team’s efforts to success. Most teams want to publish their successful results, but they should balance publicizing the accomplishments and promoting the community’s accomplishments. Ideally, the team does not need to check and balance the achievement of publicity, as the community has contributors focused on communicating about community activities, including the activities of sub-DAOs.
  • Make a statement about concentration, which means relying on the efforts of the party in the concentration. A balance should be struck between the risks of public disclosure agreements and disclosures that result in potential liability.
  • When discussing off-chain activity or on-chain operations of the protocol, it is implied that the initial development team performed some action. English teachers will always teach students to write in the active voice, but all descriptions of off-chain and on-chain activities should be in the passive voice. The passive voice accurately describes on-chain activity, avoiding any expectation of profit in any group’s off-chain activity.
  • Post or share social media content without the expectation that the initial content will be attributed to the team that shared it. If the team disagrees with the content of the tweet they retweet, then they should make it clear.
  • When referring to the initial development team, the term implies increased importance relative to other teams, such as the “leader” or “core” team. Instead, they can be called “initial contributors”.
  • Participate in the governance of the protocol. When the initial development team is involved in governance (early), crypto asset holders continue to rely on that team to create value through strategic decisions contained in proposals, rather than letting the community make the decisions.

The original development team could argue that some of the above actions do not lead to a reasonable expectation of third parties to profit from their entrepreneurial or management efforts. For example, a private discussion with an exchange to list a crypto asset for trading, which is unknown to the public, should be viewed as generating profit expectations for any team’s efforts, which are unknown to the public. Opinion is important, however; it is best to avoid this problem. 

While this playbook seeks to address “sufficient decentralization,” initial development teams should consider actions to prevent them from arguing that crypto asset holders have no reasonable profit expectations, including:

  • Take any action to list a cryptoasset on a secondary market, whether on a decentralized or centralized exchange; cooperate with another party, such as a market maker, or facilitate the existence of a secondary market that the other party may create.
  • Make any statement about the price appreciation of the cryptoasset, or create an expectation of profit that does not yet exist.

Posted by:CoinYuppie,Reprinted with attribution to:https://coinyuppie.com/web3-handbook-for-builders-and-lawyers-how-to-effectively-decentralize-off-chain-activities/
Coinyuppie is an open information publishing platform, all information provided is not related to the views and positions of coinyuppie, and does not constitute any investment and financial advice. Users are expected to carefully screen and prevent risks.

Like (0)
Donate Buy me a coffee Buy me a coffee
Previous 2022-08-07 23:14
Next 2022-08-07 23:16

Related articles