DAOs & Legal Risks

Pre-DAO and Post-DAO Legal Risk Assessment, an article by Kevin Chen

This article outlines Pre-DAO and Post-DAO Legal Risk Assessment, an article written by Kevin Chen (@anothrkevinchen) in collaboration with the DAO Research Collective (@DAOResearchCo).

Kevin is an attorney at Homiak Law LLC based in Denver, Colorado. He advises cryptoasset and blockchain technology companies on a wide variety of matters such as formation of new startup companies, venture financings, and securities law compliance.

For an audio version, you can listen to this article in a future Law of Code Podcast.

Enjoy.

Pre-DAO and Post-DAO Legal Risk Assessment[1]

By Kevin Chen

Introduction

For crypto builders in the U.S. laying the groundwork for DAOs, legal risk management presents serious challenges.[2] The U.S. federal regime has not provided safe paths for core phases of DAO development, such as public token distribution, smart contract creation and deployment, and establishing a decentralized network. At the same time, the Securities and Exchange Commission (SEC) and other regulatory agencies have brought serious enforcement actions against persons involved in cryptoasset projects, relying on decades-old legal rules and principles.[3] While applying these rules and principles through enforcement actions can be warranted (e.g., prohibitions against fraud), the application of others is akin to fitting square pegs into round holes (e.g., the legal tests for what constitutes a “security”). By regulating predominantly through enforcement, the SEC merely outlines what not to do when building decentralized systems under U.S. law. Unfortunately, crypto builders still lack clear guidance from the U.S. government on how to build DAOs in a legally compliant manner.

Faced with this reality, how should DAO projects approach legal risk management?

It is a daunting challenge, to be sure.[4] This guide offers a practical framework for approaching legal risk management. The framework encourages builders to consider their project as two separate and distinct phases, the “Pre-DAO” and “Post-DAO Launch” Phases. This distinction is useful because each phase presents its own set of challenges and because the allocation of potential risk shifts dramatically as a project moves from the first phase to the second phase. 

Following this dual-phase approach, this guide identifies relevant U.S. federal law domains, presents a non-exclusive core legal risk in each domain, and suggests key risk management questions for builders to discuss with their attorneys. The purpose of this paper is to synthesize the existing work in the space and add value to projects that are currently working through these issues. Much appreciation and credit goes to the brilliant minds who contributed to the concepts cited within. 

Defining “Legal Risk”

“Legal risk,” as used here, means the potential for losses for failing to comply with laws and regulations that are enforced primarily by government regulators through judicial or administrative proceedings.[5] Under conventional Enterprise Risk Management (ERM) terminology, this particular definition of “legal risk” may be called “compliance risk.”[6] This article does not address all potential legal risks facing DAO builders. Instead, it focuses on core legal risks likely to arise during a DAO’s developmental lifecycle. The core legal risks discussed here arise under the following U.S. federal legal domains: securities law, commodities law, money transmission law, tax law, and legal entity law. To be clear, this article is not a comprehensive guide. It provides DAO builders key concepts for discussing legal risk management strategies with their attorneys.[7]   

Defining “DAOs”

Although “[t]he boundaries of what qualifies as a DAO are still evolving,” Aaron Wright has provided a clear, foundational concept of what DAOs are: “in their current form, DAOs rely on blockchains, autonomous smart contracts, and digital assets to support organizations that operate natively on the Internet and have the capability of scaling globally from their birth.” [8]  

Very, very broadly speaking, and based on common industry usage, DAOs can be grouped into two categories: (1) “Protocol” DAOs and (2) “Native” DAOs. Generally, a Protocol DAO relies on smart contracts to perform significant aspects of its operations and allows members to collectively decide changes or upgrades to the protocol’s underlying smart contracts. In contrast, Native DAOs are more reliant on off-chain, human performance of significant aspects of their operations. Both types of DAOs can manage treasury assets.

The Protocol DAO and Native DAO classifications are not rigid categories with clearly defined borders. Indeed, these labels are perhaps better understood as ends of a continuous spectrum, on which individual DAOs can be situated based on their particular characteristics. That said, the Protocol DAO-Native DAO distinction is useful for understanding differences between DAOs’ project development cycles. A helpful—albeit unsophisticated—way to classify DAOs is to ask: “If the DAO element (i.e., DAO governance contracts and DAO members)is removed from the project, what remains?” If what remains is a functioning, smart contract protocol that continues to perform operations, then the DAO looks like a Protocol DAO. By contrast, if the project is essentially non-operational after the DAO element is removed, then the DAO looks like a Native DAO. Under this simple test, DAOs for DeFi projects like Compound and Uniswap look like Protocol DAOs, while more socially-focused projects like Friends With Benefits look like a Native DAO.  

Ultimately, Protocol DAOs and Native DAOs face many of the same legal risks. But compared to Native DAOs, Protocol DAOs have more consistently approached the Pre-DAO Phase (i.e., the period before governance has been released to members and before the DAO has actually been formed) as an area of potential legal risk exposure and an opportunity to secure funding for their projects in advance of DAO governance being launched. This difference is easily explained by the tendency for Protocol DAO projects to require more extensive planning and development periods lead by a core team. However, Native DAO projects also benefit from leveraging the period during which the project is under centralized control to effectuate careful planning and contemplation of the project’s future needs. Accordingly, the Pre-DAO-Post-DAO framework discussed here is relevant to both Protocol DAOs and Native DAOs.   

Two Phases to DAO Development

Current scholarship and practice indicate that a DAO is generally developed in phases.[9] As described thoroughly elsewhere by others, the process of building a Protocol DAO typically involves at least the following steps: (i) a core developer team (i.e., the builders) develops a smart contract protocol; (ii) the core developer team deploys the smart contract protocol to a blockchain network; (iii) tokens to be used for protocol governance (among other potential uses) are distributed to participants in the protocol’s ecosystem; (iv) a Protocol DAO consisting of token holders forms and on-chain DAO governance commences; and (v) the entire project (hopefully) operates without the core developer team, or any other entity, exercising centralized control.[10] Depending on the situation, the core developer team might continue to operate a client or interface layer allowing users to access the protocol even after the Protocol DAO launches.[11]

Given the variety inherent to DAOs generally and Native DAOs specifically, the project life cycle is much less defined for Native DAOs.  However, nearly every Native DAO has considerations around its funding, purpose, utilization of technology, tokenomics, and governance policies and implementation. Many of these considerations are decided, or at least substantially addressed, by a core developer team before the Native DAO launches.  

Thus, for Protocol DAOs and Native DAOs, project development can be grouped into two intuitive phases: (1) “Pre-DAO” Phase and a (2) “Post-DAO Launch” Phase. In other words, the project has distinct lives before and after the DAO launches.

Pre-DAO Phase: Design and Development

Assume that, at the outset, control over a project is centralized in a core developer team—an outcome that seems practically unavoidable, as these core developers program the smart contracts upon which the DAO is founded. Without a “developer legal entity” (e.g., a corporation) protecting the team, the individual developers potentially face personal liability for legal risks. Thus, in almost all cases, a core developer team benefits from forming a legal entity to build and launch its project.

To put it bluntly, centralization during the Pre-DAO Phase is probably a good thing. In a recent paper, Miles Jennings proposes that builders of decentralized systems should treat legal compliance as a fundamental component of system design.[12] As he puts it, technical, economic, and legal decentralization “should be considered as a single design challenge, with technical decentralization providing a foundation upon which both economic and legal decentralization can occur.” [13] Intuitively, it is easier and more efficient for a single entity to tackle this foundational design challenge and to take the project to the DAO launch (at which point the entity may cede control).  

Leaving aside the process of raising capital from investors (more on this later), the sections below focus on the risk implications of protocol design and functionality, as well as operational activities. During the Pre-DAO Phase, the core developer team’s legal entity (the “DevCorp”) faces potential legal risks under the legal domains outlined below, each of which also includes a “core risk.” It is worth reiterating that during the Pre-DAO Phase, the DevCorp is effectively assuming most of the potential legal risk exposure related to the project, notwithstanding the developers’ intention to form a decentralized system.     

Securities Law

Core Risk: DevCorp has issued tokens that are considered securities

The reader is likely already aware of the core risk under U.S. securities law,[14] as well as the SEC’s enforcement actions against token projects allegedly violating securities laws[15] and the Howey Test. Still, it is helpful to step back and restate the fundamental character of a “security” under the U.S. federal securities law regime. As Lewis Cohen has stated, “a security is an economic relationship between someone who has capital . . . and someone who wants to deploy that capital.”[16] Paradigmatically, this relationship exists when the capital provider is a passive investor and the capital recipient operates an enterprise to generate returns to the investor. The various legal tests for analyzing whether a security transaction has occurred (including Howey) ultimately serve to assess whether this kind relationship exists between the affected parties. The goal for builders, then, is to design and implement a system where the relationship between the DevCorp and token holders is not a security.    

Courts and regulators continue to rely primarily on the Howey Test to analyze token transactions. Under this test, a transaction is an “investment contract,” and therefore a security, if: (i) a person invests money (ii) in a common enterprise (iv) with a reasonable expectation of profits (iv) to be derived predominantly from the efforts of others.[17] In analyzing cryptoassets under the Howey Test, many practitioners draw from the Telegram and Kik cases,[18] the SEC’s 2017 report on “The DAO,”[19] a 2019 SEC staff memo titled “Framework for ‘Investment Contract’ Analysis of Digital Assets” discussing the application of the Howey Test to tokens,[20] and the SEC’s recent enforcement actions involving cryptoassets.

In at least two cases, BlockFi and DeFi Money Market, the SEC has asserted the companies engaged in unauthorized securities transactions under the Reves Test.[21] The Reves Test is a separate judicially created test for determining whether instruments constitute “notes” that are treated as securities for federal securities law purposes (under federal law, not all “notes” are considered securities).[22] In the BlockFi and DeFi Money Market actions, the SEC gave little insight on how it was applying the Reves Test—the SEC applied the Howey and Reves Tests in both cases, and its application of the Reves Test reads like a rehashing of its conclusions from applying the Howey Test.[23] While there is conceptual overlap between the Howey and Reves Tests, applying the latter is arguably an even more convoluted exercise. In its fullest form (i.e., assuming all steps of the test apply to the situation) the Reves Test requires a court to first answer a threshold question; then apply a rebuttal presumption; then compare the transaction in question to an unenumerated list of types of notes; and finally apply a multi-factor balancing test.[24]

It is unclear what role the Reves Test will play going forward. On the one hand, the BlockFi and DeFi Money Market actions suggest the SEC may begin utilizing the Reves Test to evaluate token projects more frequently—perhaps as an additional, not an alternative, standard to the Howey Test. On the other hand, Benjamin Naftalis et al. have argued that the Reves Test is conceptually “a poor fit for protocol-driven DeFi platforms,” for numerous reasons.[25] To illustrate just one complication: the multi-factor balancing step of the test analyzes “whether a particular note is bought and sold as an investment.”[26] But, as Naftalis et al. explain, “in many DeFi protocols, a buyer-seller or investor-investee relationship is hard to identify” because parties frequently “transact[] directly with a liquidity pool operated by a smart contract.”[27]

Additionally, builders are encouraged to not overlook the Landreth Test,[28] which has yet to receive the same enforcement attention as Howey, but can in many ways be applied to DAO operations. As yet another judicially created test, the Landreth Test is used to determine whether an instrument is “stock” and therefore a security.[29] Under this test, an instrument may be considered stock if it exhibits some or all of the following characteristics: “(i) the right to receive dividends contingent upon an apportionment of profits; (ii) negotiability; (iii) the ability to be pledged or hypothecated; (iv) the conferring of voting rights in proportion to the number of shares owned; and (v) the capacity to appreciate in value.”[30] Although we lack precedent or concrete guidance for the application of the Landreth Test to token projects, it would seem that governance tokens conferring rights to receive profits alongside voting rights may be at risk of being classified as stock under this standard. 

Key Risk Assessment Questions

· Is there a plan to distribute profits to token holders? (Profit distribution to token holders is a potential red flag)

· What are the project’s use cases?

· Who will the project’s users be?

· Who is responsible for the development, improvement, operation, or promotion of the protocol?

· What are the DevCorp’s tasks and responsibilities in connection with the protocol?

· How does DevCorp expect to generate revenue for itself?

· What do the users expect the DevCorp to do after the protocol launch?

· What rights or privileges does the token give the holder?

· Will the token be traded or transferable on a secondary market?

· At the time of the protocol’s launch, will the protocol be fully developed and operational?

In light of the current state of the guidance, the prevailing (but not consensus) view is that a project is most likely to comply with federal securities laws if it achieves a state of “legal decentralization”[31] or “sufficient decentralization.”[32] The list above consists of suggested questions for builders to discuss with their attorneys. The issues raised by this list are likely to be relevant to both system design and identification of project characteristics that may increase risk. The questions implicate factors relevant to the Howey, Reves, and Landreth Tests, but the questions are not ordered to correspond to specific tests. Builders should consult with their attorneys to understand how and why particular factors matter under specific legal tests.   

Commodities Law

Core Risk: DevCorp is engaged in token transactions that constitute regulated derivatives transactions

With much of the collective cryptolaw focus centering on risks arising under federal securities law, relatively less attention has been paid to federal commodities law. U.S. commodities law is an incredibly complex regime in its own right and a perhaps underexamined source of potential risk to crypto projects, although a few astute experts have offered insightful analyses on the topic.[33]  The Commodities Exchange Act (CEA) is the core statute, and it “focuses on regulating transactions and markets in derivatives, i.e., contracts whose value derives from the value of a referenced underlying ‘commodity.’”[34] The Commodities Futures Trading Commission (CFTC) is the federal agency charged with regulating and enforcing the CEA. Generally, firms and individuals trading in regulated derivatives transactions must register and comply with a host of regulatory requirements.

Determining whether a transaction falls within the CEA’s scope and the CFTC’s regulatory reach often requires a complicated and nuanced analysis. A threshold question is whether the transaction involves an asset that is an underlying commodity. Read literally, the CEA’s statutory definition is almost absurdly broad: a “commodity” includes a paragraph long list of specific items and “all other goods and articles … and all services, rights, and interests … in which contracts for future delivery are presently or in the future dealt in.”[35] If the relevant asset is a commodity, then the transaction may be subject to regulation, and the inquiry likely shifts to examining the characteristics of the transaction at issue. Many (but not all) derivative transactions are regulated under the CEA, including, but not limited to, futures, swaps, and options.[36] An additional wrinkle, however, is that the analysis also requires asking “what type of commodity is the asset?” Different rules and exceptions apply based on the type of commodity involved in the transaction. 

Against this backdrop, the CFTC has thus far asserted authority to regulate “virtual currencies,” including Bitcoin, as commodities, and at least one federal court has agreed.[37] Last year, the CFTC filed charges against a number of crypto exchanges for failing to register as futures commission merchants or making false and misleading claims of having registered with the CFTC.[38] The Commission has settled charges with Tether, BitMEX, and Kraken, in each case for significant monetary penalties.[39]

In a detailed report examining regulatory treatment of digital assets, the American Bar Association (ABA) has observed that, while courts and the CFTC have recognized virtual currencies are commodities, they have thus far left open a number of interpretative questions relevant to determining the particular kinds of transactions falling within the CFTC’s jurisdiction.[40] Further, the ABA has pointed out that the boundaries between the SEC and the CFTC’s respective regulatory powers over cryptoassets are not clearly demarcated.[41]

On April 28, 2022, a bipartisan group of federal lawmakers reintroduced a bill, the Digital Commodity Exchange Act, that would expressly grant the CFTC regulatory oversight over “digital commodities.” [42] Among other things, the CFTC would be empowered to regulate digital commodity exchanges, including trading venues offering spot markets.[43] The bill defines “digital commodity” as “any form of fungible intangible personal property that can be exclusively possessed and transferred person to person without necessary reliance on an intermediary.”[44] However, a “digital commodity” does not include “(i) any equity or debt interest in a company, partnership, or fund; (ii) a profit or revenue share derived solely from the managerial efforts of others; or (iii) an entitlement to any interest or dividend payment.”[45] By including these carveouts, the bill seeks to avoid challenging the SEC’s jurisdiction over securities.    

Key Risk Assessment Questions

· How is the token transaction settled?

· What role does the DevCorp play in facilitating or settling token transactions?

· When is the token delivered to the recipient as part of the transaction?

· How is the token delivered to the recipient as part of the transaction?

· Is the token transfer contingent on the occurrence of any event?

· Is the token being sold for future delivery?

· Does the transaction involve any leveraged trading or trading on margin?

Given the CFTC’s current position on virtual currencies and proposed federal legislation, it may be prudent to assume a project’s token is a commodity under the CEA. Above are some basic questions that are relevant to assessing whether a token transaction is a regulated derivative transaction. DAO builders must be aware that these questions are just a starting point. In light of the numerous different categories, classifications, and exemptions at play when analyzing derivatives transactions, builders are strongly encouraged to speak with seasoned attorneys well versed in commodities law.

Money Transmission Law

Core Risk: DevCorp is engaged in money transmission

At the federal level, the Financial Crimes Enforcement Network (FinCen) regulates “money transmitters” pursuant to the Bank Secrecy Act, which requires U.S. financial institutions to assist government agencies to detect and prevent money laundering. Among other things, FinCen regulations generally require money transmitters to register, comply with reporting and recordkeeping requirements, and implement an anti-money laundering (AML) program. Crucially, failure to comply with the Bank Secrecy Act or its regulations can result in civil and/or criminal penalties. Additionally, states generally require licensure for money transmitters.

Under FinCen regulations a money transmitter is any person “that provides money transmission services.”[46] “Money transmission services” means “the acceptance of currency, funds, or other value that substitutes for currency from one person and the transmission of currency, funds, or other value that substitutes for currency to another location or person by any means.”[47] The regulations provide for certain narrow exceptions, including if the person “accepts and transmits funds only integral to the sale of goods or the provision of services, other than money transmission services” or if the person provides only “the delivery, communication, or network access services used by a money transmitter to support money transmission services.”[48]

In 2019, FinCen issued a guidance document summarizing and consolidating its prior interpretative guidance on the application of money transmitter regulation to cryptoassets.[49] The guidance is grounded in the concept that money transmission can be accomplished through transmission of “convertible virtual currency” (CVC).[50] According to FinCen, CVC is “a type of virtual currency that either has an equivalent value as currency, or acts as a substitute for currency.”[51] Whether a person is a money transmitter of a CVC depends on how the person controls the CVC, how the CVC flows through the system, and whether a specific exemption applies. For instance, the guidance suggests that decentralized exchanges are less likely to be considered money transmitters because the CVC buyers and sellers post their own bids and offers and settle any matched transactions themselves.[52] In contrast, a centralized exchange would likely be a money transmitter if the exchange purchases CVC from the seller and then sells the CVC to the buyer.[53]

Notably, FinCen and the DOJ brought claims against the centralized derivatives exchange BitMEX and its founders (civil and criminal charges, respectively) on the grounds that BitMEX was engaged in money transmission without complying with the Bank Secrecy Act and related regulations.[54] BitMEX settled its case with FinCen for a $100 million civil penalty, and the founders plead guilty to DOJ’s criminal charges.[55] The criminal charges pursuant to a BSA action vary based on the type of violation and enforcement authority, but if the violation is part of a pattern of conduct involving more than $100,000 over a 12 month period and involves the violation of another US criminal law, the penalty carries a maximum sentence of 10 years imprisonment.[56]

Key Risk Assessment Questions

· Which persons or entities, if any, custody private keys on behalf of users?

· Which persons or entities are able to initiate the transfer of tokens through the system?

· What degree of control does the DevCorp have over the movement of tokens through the system?

· To what extent does the DevCorp “touch” tokens as they move through the system?

· How do the tokens flow from start to finish in the system?

Based on the available FinCen guidance, it seems prudent for builders to assume that tokens generally fall under FinCen’s category of CVC. Similar to analysis under securities law analysis, the legal risk analysis under money transmission law is inextricably linked to system design, particular the flow of funds within the system’s architecture. The questions above should be discussed with attorneys and serve to both inspire system design and identify areas of potential risk.[57]

Tax Law

Core Risk: Token distributions result in large, unforeseen tax liabilities to DevCorp and team members

For many DAO projects, the DevCorp’s contemplated token-related activities in the Pre-DAO phase may result in token transfers whose taxable basis must be understood to ensure proper tax treatment. Additionally, once it forms, the DAO itself has a number of international and U.S. tax considerations around the membership’s control of the DAO, production of income, and realizable events within the treasury.

The latest guidance from the Internal Revenue Service (IRS) considers cryptoassets to be “property” and not “currency.”[58] As a result, traditional US tax law principles concerning the disposition of property, property as income, and capital gains on property, should apply. Under these principles, capital gains tax events include using cryptoassets to purchase goods and services and trading one cryptoasset for another.[59] Income tax events include receiving tokens from an airdrop, earning tokens from liquidity pools and staking, and receiving tokens as payment for work.[60] Generally, an individual or an entity’s compliance with tax obligations requires determining or justifying a cost basis for the relevant cryptoasset transaction.

As Silva et al. have observed, a DevCorp’s token-based awards to founders, employees, and consultants commonly “emulate traditional equity-based awards, including restricted tokens, token options, and restricted token units.”[61] As such, they note that tax law and rules governing traditional equity awards should also apply to token-based awards.[62] For instance, if a DevCorp awards a recipient restricted tokens subject to vesting—akin to restricted stock—the recipient may have the option to file an election under Section 83(b) of the Internal Revenue Code (an “83(b) Election”). Making this election should allow the recipient to pay tax on the total fair market value of all tokens at the time of grant, as opposed to paying tax as the tokens vest.[63] Similar to restricted stock grants, paying the tax for token awards up front may be advantageous to the recipient if the tokens increase in value over time.[64]

Key Risk Assessment Questions

· What is the DevCorp’s plan for distributing tokens to employees, consultants, and/or project contributors?

· Does the DevCorp intend to distribute tokens in addition to, or in lieu of, other forms of compensation to employees, consultants, and/or project contributors?

· What is the DevCorp’s plan for distributing tokens to DevCorp’s investors?

· When will the DevCorp distribute tokens to DevCorp’s investors, employees, consultants, and/or project contributors relative to the token generation event?

· Will the tokens be restricted from trading on secondary markets, and for how long?

· Does the DevCorp intend on retaining a qualified third-party firm to conduct an appraisal or valuation of the token?

· How is the DevCorp using tokens to pay for goods and services?

· Is the DevCorp receiving tokens through mining, staking, providing liquidity to pools, or other similar activities?

Tax planning is highly complex, and builders should consult with qualified tax experts to formulate appropriate strategies for both the DevCorp and themselves as individuals (as token recipients). The list above captures core concepts for builders to explore with their experts. For many projects, a key consideration will be determining the appropriate cost basis for tokens at various distribution moments during the project’s lifecycle. Generally, a property’s cost basis is the total amount the owner has paid for the property, including fees.[65] The IRS has indicated that a token’s cost basis is typically the original price paid for the token, plus any transaction fees incurred. If tokens were freely airdropped, the cost basis is typically zero.[66]

Pre-DAO Phase: Raising Capital

Return now to the question of how to assess legal risk associated with raising capital from investors. A DAO’s capital raise implicates many of the legal concepts and core legal risks discussed above, particularly in the realms of securities law and commodities law, albeit with added complications. Builders considering raising outside capital through any means are strongly encouraged to carefully consult with their attorneys.

Securities Law and Commodities Law

Many investors in DAO projects seek token rights as key terms for their investment in a DevCorp. To some extent, governance tokens reflect the ability to control operations through the governance process, although a DAO’s governance process is usually fairly restrictive over what aspects of the smart contracts the membership can control.

In a truly decentralized system, the DevCorp no longer plays a leading role in developing, operating, or maintaining the protocol, and the network’s value should theoretically be separate and distinct from the DevCorp’s equity value. Assuming the system’s decentralization is legally sufficient in the eyes of regulators, the relationship between the protocol token holders and the DevCorp seems unlikely to be a security.

The problem, of course, is that a DevCorp typically seeks outside financing while the project’s core components—such as the protocol’s deployment and functionality and available clients—are still largely under the DevCorp’s control. Accordingly, there is a greater likelihood that any protocol tokens created are considered securities while the project remains in the Pre-DAO Phase. SEC Commissioner Hester Pierce accurately diagnoses the problem under the current U.S. securities law regime:  

We have created a regulatory Catch 22. Would-be networks cannot get their tokens out into people’s hands because their tokens are potentially subject to the securities laws.  However, would-be networks cannot mature into a functional or decentralized network that is not dependent upon a single person or group to carry out the essential managerial or entrepreneurial efforts unless the tokens are distributed to and freely transferable among potential users, developers, and participants of the network.[67]

            Thus, from a securities law perspective, the potential classification of governance tokens (or rights to governance tokens) as the DevCorp’s securities during the Pre-DAO Phase creates a challenge for raising outside capital. Unfortunately—and somewhat ironically—the potential classification of governance tokens (or rights to governance tokens) as commodities for future delivery may also complicate the DevCorp’s fundraising efforts.      

Recall that U.S. commodities law regulates some (but not all) derivatives contracts. A DevCorp might agree to transfer governance tokens to its equity investors at a later date (perhaps when the network is fully developed), conceiving of the governance tokens as commodities. Depending on how this agreement is structured, a regulator examining the transaction might conclude the transaction is a type of futures contract or forward contract, both of which are types of derivatives contracts. A determination that the transaction is a futures contract or a forward contract does not necessarily bring the transaction within the CFTC’s regulatory authority. As explained above, there are numerous sub-classifications and exemptions that might establish the transaction falls outside the CFTC’s jurisdiction.

Key Risk Assessment Questions

· Are all potential investors accredited?

· Does the DevCorp’s offering qualify under an established securities offering exemption?

· What equity interests in the DevCorp are being offered to investors?

· What token rights are being offered to investors?

· Are tokens or rights to tokens being offered to investors expressly in conjunction with an offer of equity in the DevCorp?

· Are tokens being offered for future delivery?

· When will tokens be distributed to investors?

· How will tokens be delivered to investors?

· What transfer restrictions will be placed on tokens distributed to investors?

· How does the timing of token distribution to investors align with the broader token distribution to ecosystem participants?

The list above is a starting point for discussions between builders and their attorneys to manage risk in the fundraising process. Opportunities to invest in the DevCorp are likely limited mostly to accredited investors, as they are permitted to invest in securities not registered with the SEC. The structure of the token-related portion of a deal will likely depend on the DevCorp’s position on whether the tokens, at token generation, begin life as a security or a commodity. If the position is that the tokens are securities at generation but will morph into non-securities once sufficient network decentralization is achieved, then rules and regulations on “restricted securities” likely apply.

On the other hand, if the position is that the tokens begin life as commodities, then it is possible that the CEA regime may apply. Depending on how the DevCorp conceives of the tokens, different instruments, such as token warrants and investor rights to participate in token sales or distributions, may be available as options. Ultimately, because there is no path or safe harbor that has been clearly blessed by regulators, builders should partner with attorneys with experience raising capital to thoughtfully analyze and assess risk and carefully craft instruments appropriate for the situation.

Post-DAO Launch

Assume that the DevCorp has succeeded in its mission to create a decentralized system. Among other things, governance has been successfully deployed, a strong network of users has emerged, and the DevCorp is no longer involved in operational functions. During the Pre-DAO Phase, the DevCorp assumed most of the potential exposure to the foreseeable legal risks. Now, since the DAO controls the protocol, the DAO conceptually replaces the DevCorp as the responsible party and primary risk bearer for the system. Thus, the focus of legal risk management in the Post-DAO Launch Phase shifts from protecting the DevCorp and the core developer team to protecting the DAO members.  

Legal Entity Law

Core risk: DAO members potentially face personal liability for DAO-related activities

Since DAOs are still new organizational forms, it is unclear how courts and regulators will seek to apply legal entity law to them. Unlike the legal domains previously discussed that involved federal law issues, legal entity law in the U.S. is largely a matter of state law, although many general principles are consistent across state jurisdictions. In theory, a court might declare a DAO engaged in a business venture with no legal entity wrapper whatsoever to be an unincorporated general partnership. This determination, in turn, might potentially expose DAO members to personal liability. That said, each DAO should evaluate its facts and circumstances carefully, as not every group relationship gives rise to a general partnership.  

Key Risk Assessment Questions

· What off-chain tasks are essential to the DAO’s operations?

· Will the DAO delegate certain tasks to smaller groups or committees?

· Does the DAO control a treasury?

· What activities does the DAO’s treasury engage in?

· How and to whom is the DAO treasury deploying funds?

· How do DAO members generally participate in the DAO?

· What activities are DAO members currently engaged in as individuals “in the name of the DAO”?

As indicated in the questions above, the legal entity strategy (including the determination of whether a legal wrapper is needed is needed) will likely require thoughtful and careful deliberation on how the DAO will operate in the foreseeable future. Of particular importance are the DAO’s anticipated need to engage in off-chain operations (e.g., signing paper contracts or hiring) and the DAO’s anticipated treasury activities.

Depending on the DAO’s particular purpose and size, certain U.S. entity forms may be suitable options. For instance, some investment DAOs, like FlamingoDAO and Venture DAO, have formed as limited liability companies (LLCs) with sophisticated operating agreements complying with relevant securities laws. [68] To comply with LLC and securities laws, these DAOs follow many organizational and management requirements, such as restricting membership to accredited investors only and requiring identity verification of members. Additionally, some practitioners are exploring the use of cooperatives as entity structure for DAOs.[69] Recently, Jennings and Kerr published an article outlining a framework to assist builders in evaluating their own facts and circumstances to determine whether a legal entity wrapper is useful for their DAO and potentially beneficial entity structures.[70]

While traditional U.S. entity structures may serve certain DAOs, these more conventional structures might not be appropriate for large DAOs that may have multiple de facto operational arms. For DAOs of this nature, there is a tremendous amount of legal innovation underway to find solutions.

---

[1] My tremendous thanks to David Kerr, Connor Spelliscy, and Jacob Robinson for their contributions and insights, and to all of the authors of the works cited herein. This guide draws extensively from, and is deeply indebted to, these cited works. I am also incredibly grateful for, and beholden to, the DAO Research Collective, whose support in editing and drafting made this article possible. For more information on the DAO Research Collective, please visit https://daocollective.xyz/.

[2] DISCLAIMER: This analysis should not be construed as legal advice for any particular facts or circumstances and is not meant to replace competent counsel. None of the opinions or positions provided hereby are intended to be treated as legal advice or to create an attorney-client relationship. This analysis might not reflect all current updates to applicable laws or interpretive guidance and the authors disclaim any obligation to update this paper. It is strongly advised for you to contact a reputable attorney in your jurisdiction for any questions or concerns.

[3] For a list of the SEC’s “Crypto Asset” enforcement actions, see SEC, Cyber Enforcement Actions, (last accessed Apr. 10, 2022), https://www.sec.gov/spotlight/cybersecurity-enforcement-actions.

[4] In a recent survey of 35 crypto founders and operators conducted by Connor Spelliscy, all of the founders reported having altered the design of their product or business in response to legal information learned after starting development. See Connor Spelliscy, Crypto Community Strategies for Dispelling Legal FUD, The Defiant (Jun. 1, 2021) https://thedefiant.io/crypto-community-strategies-for-dispelling-legal-fud/.

[5] See Thomas Fuhrman, Blockchain and Risk: An overview of the risks of blockchain for mid-size businesses, A VECTORmv Viewpoint (2021), https://www.linkedin.com/in/tomfuhrman/overlay/1635481622516/single-media-viewer/ (discussing risk domains relevant to blockchain technology under a conventional Enterprise Risk Management framework). 

[6] See id. (using the term “compliance risk” to mean the potential for losses for failing to comply with laws and regulations).

[7] Conventionally, legal or compliance risk is one of many risk domains, such as strategic risk, financial risk, or operational risk, to be managed under an organization’s ERM framework. An ERM framework typically calls for the organization to implement a process for assessing the likelihood of occurrence of a risk event and the financial cost of each event. See Fuhrman, supra note 5. Builders are strongly encouraged to consider other domains under an ERM framework and work with counsel as necessary to design and implement an ERM framework tailored to their needs.

[8] Aaron Wright, The Rise of Decentralized Autonomous Organizations: Opportunities and Challenges, 4 Stanford Journal of Blockchain Law and Policy 152, 155 (2021).

[9]   See Miles Jennings, Principles & Models of Web3 Decentralization, a16z (Apr. 2022) at 13, https://a16z.com/wp-content/uploads/2022/04/principles-and-models-of-decentralization_miles-jennings_a16zcrypto.pdf (describing web3 developmental model and steps for achieving decentralized systems); Jesse Walden, Progressive Decentralization: A Playbook for Building Crypto Applications, a16z, https://a16z.com/2020/01/09/progressive-decentralization-crypto-product-management/ (proposing “progressive decentralization” model for project financing and building decentralized communities).

[10] See Jennings, supra note 9 at 13; Walden, supra note 9.

[11] For a detailed and nuanced examination of how developer control over client layers affects legal decentralization, see Jennings, supra note 9 at 13–17.

[12] See Jennings, supra note 9 at 3.

[13] Id.

[14] The Securities Act of 1933—one of the core U.S. securities law statutes—provides a definition for “security” containing a paragraph long list of instruments including notes, stocks, bonds, and “investment contracts.” Courts in turn employ various tests depending on the facts and circumstances to determine whether a transaction involves a “security.” If a transaction involves a “security,” then a slew of federal statutes and regulations come into play, including registration requirements and potential liability for selling unregistered securities.

[15] According to one report, the agency brought 20 crypto enforcement actions in 2021, of which 65% alleged fraud, 80% alleged an unregistered securities offering violation, and 55% alleged both. See Cornerstone Research, SEC Cryptocurrency Enforcement 2021 Update, at 1, https://www.cornerstone.com/wp-content/uploads/2022/01/SEC-Cryptocurrency-Enforcement-2021-Update.pdf. According to the same report, from 2013 through 2021, the SEC imposed approximately $2.35 billion in total monetary penalties against crypto market participants. See id.

[16] Jacob Robinson, Lewis Cohen: A Masterclass on Securities, Currencies, and Building a Legal Career, Law of Code (podcast) (Feb. 4, 2022),

(emphasis added).

[17] See SEC v. W.J. Howey Co., 328 U.S. 293, 298–99 (1946).

[18] See SEC v. Telegram Grp. Inc., 448 F. Supp. 3d 352 (S.D.N.Y. 2020); SEC v. Kik Interactive Inc., 492 F. Supp. 3d 169 (S.D.N.Y. 2020).

[19] SEC, Report of Investigation Pursuant to Section 21(a) of the Securities Exchange Act of 1934:

The DAO (2017), https://www.sec.gov/litigation/investreport/34-81207.pdf.

[20] SEC, Framework for “Investment Contract” Analysis of Digital Assets (2019), https://www.sec.gov/corpfin/framework-investment-contract-analysis-digital-assets.

[21] See In the Matter of BlockFi Lending LLC, No. 3-20758 (SEC Order filed Feb. 14, 2022); In the Matter of Blockchain Credit Partners d/b/a DeFi Money Market, No. 3-20453 (SEC Order filed Aug. 6, 2021).

[22] See Reves v. Ernst & Young, 494 U.S. 56 (1990).

[23] See In the Matter of BlockFi Lending LLC, at 8; In the Matter of Blockchain Credit Partners d/b/a DeFi Money Market at 10.

[24] See Reves, 494 U.S. at 65–67.

[25] Benjamin Naftalis, Douglas K. Yatter, and Peter E. Davis, The Limits of Applying Reves v. Ernst & Young to DeFi and the Perils of Regulating Web3 by Enforcement, Latham & Watkins (Jan. 25, 2022),  https://www.fintechanddigitalassets.com/2022/01/the-limits-of-applying-reves-v-ernst-young-to-defi-and-the-perils-of-regulating-web3-by-enforcement/.

[26] See id.

[27] See id.

[28] David Kerr and Miles Jennings, A Legal Framework for Decentralized Autonomous Organizations, a16z (Oct. 6, 2021), at n. 38, https://a16z.com/wp-content/uploads/2021/10/DAO-Legal-Framework-Jennings-Kerr10.19.21-Final.pdf (explaining how the Landreth test could be applied to determine whether a governance token is “stock” and therefore a security).

[29] See Landreth Timber Co. v. Landreth, 471 U.S. 681 (1985).

[30] See id. at 686.

[31] See, e.g., Jennings, supra note 9.

[32] See William Hinman, Digital Asset Transactions: When Howey Met Gary (Plastic) (Jun. 14, 2018), https://www.sec.gov/news/speech/speech-hinman-061418.

[33] See ABA, Digital and Digitized Assets: Federal and State Jurisdictional Issues (Dec. 2020) at 47, https://www.americanbar.org/content/dam/aba/administrative/business_law/buslaw/committees/CL620000pub/digital_assets.pdf; Latham and Watkins, The yellow brick road for consumer

tokens: The path to SEC and CFTC compliance: An update, Global Legal Insights: Blockchain and Cryptocurrency Regulation (2020) https://www.lw.com/thoughtLeadership/the-yellow-brick-road-for-consumer-tokens-path-to-sec-and-cftc-compliance-an-update.

[34] Id.

[35] 7 U.S.C. § 1a(9).

[36] At a very, very general level: (i) a futures contract is a contract for the sale of a commodity for future delivery; (ii) a swap contract can be any one of a broad range of transactions considered to be “swaps” in the CEA, many of which are dependent on the occurrence of an event; and (iii) an option contract is a contract giving the option holder an exercise right to require a counterparty to buy or sell an underlying commodity. See ABA, supra note 33, at 55–56. 

[37] See CFTC v. My Big Coin Pay, No. 18-CV-10077 (D. Mass., Sept. 26, 2018).

[38] CFTC, CFTC Charges 14 Entities for Failing to Register as FCMs or Falsely Claiming to be Registered (Sep. 29, 2021), https://www.cftc.gov/PressRoom/PressReleases/8434-21.

[39] CFTC, CFTC Orders Tether and Bitfinex to Pay Fines Totaling $42.5 Million (Oct. 15, 2021), https://www.cftc.gov/PressRoom/PressReleases/8450-21; CFTC, CFTC Imposes A $1.25 Million Penalty against Kraken for Offering Illegal Off-Exchange Digital Asset Trading and Failing to Register as Required (Sep. 28, 2021), https://www.cftc.gov/PressRoom/PressReleases/8433-21.

[40] ABA, supra note 33, at 82–87.

[41] ABA, supra note, 33, at 243–75.

[42] Nikhilesh De, US Lawmakers Reintroduce Bill to Give CFTC Crypto Spot Market Oversight, CoinDesk (Apr. 28, 2022), https://www.coindesk.com/policy/2022/04/28/us-lawmakers-reintroduce-bill-to-give-cftc-crypto-spot-market-oversight/

[43] See Digital Commodity Exchange Act of 2022, H.R. 7614, 117th Cong. § 2 (2022), https://www.govinfo.gov/content/pkg/BILLS-117hr7614ih/pdf/BILLS-117hr7614ih.pdf.

[44] Id.

[45] Id.

[46] 31 C.F.R. § 1010.100(ff)(5).

[47] 31 C.F.R. § 1010.100(ff)(5)(i)(A).

[48] 31 C.F.R. § 1010.100(ff)(5)(ii).

[49] FinCen, Application of FinCEN’s Regulations to Certain Business Models Involving Convertible Virtual Currencies (May 9, 2019), https://www.fincen.gov/sites/default/files/2019-05/FinCEN%20Guidance%20CVC%20FINAL%20508.pdf.

[50] See id. at 1.

[51] See id. at 7.

[52] See id. at 24

[53] See id.

[54] See FinCen, FinCEN Announces $100 Million Enforcement Action Against Unregistered Futures Commission Merchant BitMEX for Willful Violations of the Bank Secrecy Act (Aug. 10, 2021), https://www.fincen.gov/news/news-releases/fincen-announces-100-million-enforcement-action-against-unregistered-futures.

[55] See FinCen, supra note 49; DOJ, Founders Of Cryptocurrency Exchange Plead Guilty To Bank Secrecy Act Violations (Feb. 24, 2022), https://www.justice.gov/usao-sdny/pr/founders-cryptocurrency-exchange-plead-guilty-bank-secrecy-act-violations.

[56] 31 U.S.C. § 5322(b).

[57] A separate but related risk consideration is compliance with sanctions implemented by the U.S. Department of the Treasury's Office of Foreign Assets Control (OFAC). OFAC administers over 35 different sanctions programs imposing restrictions against trade with certain foreign countries, geographic regions, entities, and individuals. In 2021, OFAC published guidance on sanctions compliance for the “virtual currency industry.” See OFAC, Sanctions Compliance for the Virtual Currency Industry, (Oct. 2021), https://home.treasury.gov/system/files/126/virtual_currency_guidance_brochure.pdf.

[58] IRS, Notice 2014-21 (2014), https://www.irs.gov/pub/irs-drop/n-14-21.pdf.

[59] See id.

[60] See id.

[61] Alfredo B. D. Silva, Ali U. Nardali, and Aria Kashefi, Cryptocurrency Compensation: A Primer on Token-Based Awards, Bloomberg Law (Mar. 18, 2018), https://media2.mofo.com/documents/180319-cryptocurrency-token-based-awards.pdf.

[62] See id.

[63] See id.

[64] See id.

[65] IRS, Publication 551 (2018), https://www.irs.gov/pub/irs-pdf/p551.pdf.

[66] IRS, Frequently Asked Questions on Virtual Currency Transactions, (last accessed June 5, 2022), https://www.irs.gov/individuals/international-taxpayers/frequently-asked-questions-on-virtual-currency-transactions.

[67] Hester M. Peirce, Running on Empty: A Proposal to Fill the Gap Between Regulation and Decentralization (Feb. 6, 2020), https://www.sec.gov/news/speech/peirce-remarks-blockress-2020-02-06.

[68] See Flamingo, What is Flamingo? (last accessed Apr. 10, 2022), https://docs.flamingodao.xyz/; MetaCartel Ventures, Venture DAO (last accessed Apr. 10, 2022), https://metacartel.xyz/.

[69] See Jacqueline Radebaugh and Yev Muchnik, Solving the Riddle of the DAO with Colorado’s Cooperative Laws, The Defiant (Dec. 16, 2021) https://thedefiant.io/solving-the-riddle-of-the-dao-with-colorados-cooperative-laws/ (suggesting Colorado’s Limited Cooperative Association (LCA) entity can be a desirable alternative for DAOs).

[70] Miles Jennings and David Kerr, A Legal Framework for Decentralized Autonomous Organizations: Part II: Entity Selection Framework, a16z (Jun. 2, 2022), https://a16zcrypto.com/wp-content/uploads/2022/06/dao-legal-framework-part-2.pdf.