SEC Commissioner Peirce Proposes Safe Harbor for Blockchain Developers

Speaking at the International Blockchain Congress in Chicago on February 6, 2020, SEC Commissioner Hester Peirce proposed a safe harbor from U.S. securities laws so that developers of blockchain protocols could offer and sell tokens for the purpose of developing functioning token networks and creating liquidity for users. Commissioner Peirce’s views are her own, and do not necessary represent the views of others at the SEC. However, Commissioner Peirce’s speech represents important first steps toward regulatory certainty for blockchain developers and, if eventually adopted, could bridge the gap between existing securities laws and the realities of building successful distributed ledger protocols.

Commission Peirce highlighted the dilemma that crypto entrepreneurs currently face: existing SEC regulatory guidance requires, among other things, that distributed ledger networks must be “decentralized” (such that a single person or group cannot carry out essential managerial or entrepreneurial efforts) for a token not to be deemed a security by the SEC. However, for any network to become decentralized in the view of the SEC, any token must be placed with a large, unaffiliated, dispersed community of network users. Generally, before any token can be functional on a network and the network decentralized, the tokens must first be widely distributed to potential users. But if any tokens are in fact, subject to a “distribution”, such tokens must be offered or sold under an effective registration statement or pursuant to one or more exemptions from the registration requirements under the Securities Act of 1933, as amended (the “Securities Act”). Commission Peirce highlights the limitations of the SEC’s current framework for the offer or sale of tokens that may be securities under the test set forth in SEC v. Howey. Most problematic is that no registered offering of digital assets have yet been approved by the SEC or conducted in the U.S. Furthermore, the exemptions from registration requirements available to crypto developers each have certain limitations that hinder the creation of decentralized networks. For example, Regulation D requires that tokens be offered and sold exclusively to accredited investors and be subject to transfer restrictions. Given the limited number of persons that qualify as accredited investors, it would be difficult to achieve the number of users that may be required to make the network viable. Several issuers have attempted to conduct “mini-IPOs” under the Regulation A rules that are intended to smooth capital raising for smaller issuers, better known at “Reg A+”. Even if a developer has the time and financial resources required to get a “Reg A+” offering approved by the SEC, the tokens offered would always be deemed to be securities. As a result, tokens sold under Regulation A must thereafter be purchased or sold as a security and be subject to the requirements of the Securities Exchange Act of 1934, as amended (the “Exchange Act”), including that the securities are sold through a registered broker-dealer or on a registered exchange. Other developers may rely on offshore offerings permitted under Regulation S. Unfortunately, complying with the requirements of Regulation S is challenging due to the technical limits of geofencing and possibility of the flowback of tokens into the hands of U.S. persons. Commissioner Peirce noted that this offshore approach is detrimental to the U.S. economy as Americans are prohibited from participating in these token networks. Commissioner Peirce describes the securities law compliance alternatives as a “regulatory Catch 22”, where network developers cannot get their tokens out into people’s hands because their tokens are potentially subject to the securities law. Networks also cannot develop into functional or decentralized networks unless the tokens are widely distributed and freely transferable amongst participants of the network.

When considering how to provide regulatory relief for developers, Commissioner Peirce asks whether any safe harbor should take the form of no-action letters or an SEC rulemaking. No-action letters may be preferable because any letter would not concede that an offering or sales of tokens fall within or outside of our securities laws, and historically, such grey areas have been an appropriate place for no-action relief. On the other hand, SEC rulemaking would be more durable and would make clear that state laws do not apply. (Moreover, a series of no-action letters could create a regulatory patchwork that results in the same uncertainty that the SEC’s no-action letters were intended to resolve.) Based on the clarity that SEC rulemaking generally provides, Commissioner Peirce elected to propose a safe harbor that she would call Securities Act “Rule 195”.

Commissioner Peirce’s proposition for a new Rule 195 would provide a safe harbor for network developers with a three-year grace period within which developers could facilitate participation in and the development of a functional or decentralized network, exempted from the registration requirements of the federal securities laws, so long as the developers meet five conditions.

Good Faith Intent

The team must intend for the network on which the token functions to reach network maturity—defined as either decentralization or token functionality—within three years of the date of the first token sale and undertake good faith and reasonable efforts to achieve that goal. At the end of three years, token transactions would not be securities transactions if the network has matured into a decentralized or functioning network on which the token is in active use for the exchange of goods or services. To assess decentralization, the team must consider whether the network is not controlled and is not reasonably likely to be controlled, or unilaterally changed, by any single person, group of persons, or entities under common control. To assess functionality at the end of three years, the team must consider whether holders can use the tokens in a manner consistent with the utility of the network. Commissioner Peirce does not suggest what could happen to developers if they are unable, despite good faith and commercially reasonable efforts, to achieve decentralization or functionality after three years. Could the developers, for example, be subject to SEC enforcement action if the network does not work as intended?

Public Disclosure

The team would have to disclose key information on a freely accessible public website. Some of the disclosure suggested by Commissioner Peirce is already made by many developers, for instance, the names and relevant experience, qualifications, attributes, or skills of each person on the development team. But other disclosure, while generally consistent with the disclosure rules applicable to public companies, would be a departure from current market practice. As proposed, developers would be required to disclose the number of tokens owned by each member of the team, provide a description of any limitations or restrictions on the transferability of tokens held by such persons, as well as a description of the team members’ rights to receive tokens in the future. Teams would need to publicly disclose any time that a member sells five percent or more of her originally held tokens over any period of time. Moreover, developers would be required to publicly disclose the source code and transaction history for the protocol. To be sure, as Supreme Court Justice Louis Brandeis stated, “sunlight is said to be the best of disinfectants; electric light the most efficient policeman.” But too much sunlight could burn developers of blockchain networks. When considering Commissioner Peirce’s proposal, market participants will need to consider the appropriate balance between providing important disclosures to token purchasers while maintaining proprietary information regarding the network and the development teams.

Tokens with Bona Fide Purpose

Under Commissioner Peirce’s proposal, the token must be offered and sold for the purpose of facilitating access to, participation on, or the development of the network. She noted that this condition, along with the definition of token, is meant to clarify that the safe harbor is not appropriate for equity or debt securities masquerading as tokens. The proposal would define “tokens” as digital representation of value or rights (i) that has a transaction history that: (A) is recorded on a distributed ledger, blockchain, or other digital data structure; (B) has transactions confirmed through an independently verifiable process; and (C) resists modification or tampering of the transaction; (ii) that is capable of being transferred between persons without an intermediary party; and (iii) that does not represent a financial interest in a company, partnership, or fund, including an ownership or debt interest, revenue share, entitlement to any interest or dividend payment.

Reasonable Efforts to Create Liquidity

The team would have to undertake good faith and reasonable efforts to create liquidity for users. To qualify for reasonable efforts condition, developers who attempt to secure secondary trading for a token on a trading platform must seek a platform that can demonstrate compliance with all applicable federal and state law, as well as regulations relating to money transmission, anti-money laundering, and consumer protection. However, to alleviate existing regulatory uncertainty on the applicability of securities laws that limit the secondary trading of tokens, the safe harbor would also create new rules under the Exchange Act intended to exempt developers that qualify for the safe harbor from the existing definitions of “exchange,” “broker,” and “dealer”. The Exchange Act amendments are crucial for networks to achieve token liquidity (and subsequently, decentralization), but without the risk of violating the rules under the Exchange Act.

Notice

The team would have to file a notice of reliance available on the SEC’s EDGAR system within fifteen days of the date of the first token sale. As part of the public filing, a member of the team would have to attest that all the conditions of the safe harbor are satisfied. The notice filing would also include the website address where investors may access the required disclosures.

Commissioner Peirce’s proposed Rule 195 safe harbor would be a time-limited exemption that expires three years from the date of the first token sold in reliance upon the safe harbor. The safe harbor would not be available if any individual members of the initial development team are “bad actors” subject to disqualification as defined in Rule 506(d) under Regulation D. The safe harbor would be available for tokens that were previously sold in a registered offering or pursuant to a valid exemption under the Securities Act as such teams may need to rely on this safe harbor to permit secondary trading and distribute their tokens more widely to potential users. Tokens already in widespread use on a decentralized network should not be deemed to be securities and, therefore, would not need to take advantage of the safe harbor. Presumably, such tokens, while not securities could be deemed to be a “virtual currency” within the jurisdiction of the CFTC. Commissioner Peirce’s proposal while suggesting a definition of “network maturity” did not discuss when a network would be sufficiently decentralized to cease from being deemed a security or investment contract.

Commissioner Peirce’s proposed safe harbor for blockchain developers is just a speech by one of five SEC commissioners. However, it is an important first step in the path toward regulatory clarity in the U.S. Developers of distributed ledger protocols should consider whether this proposed safe harbor is the right path. In the closing of her speech, Commission Peirce wisely said “I want to get it right. Getting it right means that I need people like those of you in the audience or reading this speech to weigh in and tell me what I have gotten right and what I have gotten wrong.” Commissioner Peirce appears to be on the right path by proposing a regulatory bridge between initial development and decentralization of a blockchain network, but it may be a long road before blockchain developers get the regulatory certainty they need.

Download PDF