SEC Commissioner Proposes Groundbreaking Safe Harbor For Blockchain Token Developers

On February 6, SEC Commissioner Pierce gave a speech at the International Blockchain Congress in Chicago where she unveiled her proposal for a safe harbor that would temporarily exempt blockchain tokens from federal securities registration requirements if the developers and tokens meet certain criteria. Perhaps most encouraging for those in the blockchain and cryptocurrency industries, Commissioner Pierce prefaced her comments on a recognition of the regulatory “conundrum” that existing securities laws create for blockchain developers:

“It is important to write rules that well-intentioned people can follow. When we see people struggling to find a way both to comply with the law and accomplish their laudable objectives, we need to ask ourselves whether the law should change to enable them to pursue their efforts in confidence that they are doing so legally.”

The need for change

She explained that the current regime has “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.”

With that backdrop, Commissioner Pierce unveiled her concept of a safe harbor proposal that “recognizes the need to achieve the investor protection objectives of the securities laws, as well as the need to provide the regulatory flexibility that allows innovation to flourish.” Her idea is to retain those investor protections “by requiring disclosures tailored to [the needs of token purchasers” while preserving the application of securities antifraud provisions, but at the same time providing network entrepreneurs “sufficient time to build their networks before having to measure themselves against a decentralization or functionality yardstick.”

Safe harbor exemptions for three years

Commissioner Pierce’s proposal is called the “Token Safe Harbor Proposal” or “Proposed Securities Act Rule 195 – Time-Limited Exemption for Tokens.” The proposal seeks to strike the desired balance between maintaining investor protection and facilitating blockchain innovation by exempting (1) the offer and sale of tokens from the Securities Act of 1933, other than the antifraud provisions, (2) the tokens from registration under the Securities Exchange Act of 1934, and (3) persons engaged in certain token transactions from the definitions of “exchange,” “broker,” and “dealer” under the 1934 Act. The exemptions would apply for three years, during which time developers “could facilitate participation in and the development of a decentralized network.” However, network developers would need to meet five requirements in order to utilize the safe harbor.

Requirements for exemption

(1) Intention to reach network maturity

The development 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.” The proposal defines “Network Maturity” as “the status of a decentralized or functional network that is achieved when the network is either:

(i) Not controlled and is not reasonably likely to be controlled or unilaterally changed by any single person, entity, or group of persons or entities under common control; or

(ii) Functional, as demonstrated by the ability of holders to use tokens for the transmission and storage of value, to prove control over the tokens, to participate in an application running on the network, or in a manner consistent with the utility of the network.

(2) Disclosures of key information on publicly-accessible website

The developers must make the following information freely and publicly available online:

(a) Source code – the code used by network participants to access the network, amend the code, and confirm transactions;

(b) Transaction history – a narrative description of the steps necessary to independently access, search, and verify the transaction history of the network.

(c) Token economics – a narrative description of the purpose of the network, the protocol, and its operation, including at a minimum information:

(i) describing the launch and supply process, the number of tokens to be issued in an initial allocation, the total number of tokens to be created, the release schedule for the tokens, and the total number of tokens outstanding;

(ii) detailing the method of generating or mining tokens, the process for burning tokens, the process for validating transactions, and the consensus mechanism;

(iii) explaining governance mechanisms for implementing changes to the protocol; and

(iv) sufficient for a third party to create a tool for verifying the transaction history of the token (e.g., the blockchain or distributed ledger).

(d) Plan of development – narrative detailing the current state of the network and a timeline for how and when the development team intends to achieve network maturity.

(e) Prior token sales – listing of sale dates and quantities sold, any limitations or restrictions on transferability, the amount raised, and the type of consideration received.

(f) Initial development team – the names and relevant experience and qualifications of each member of the initial development team; the number of tokens or rights to tokens owned by each member and a description of any restriction on the transfer of such tokens; and any rights the members have to obtain future tokens distinct from how a third party could obtain tokens.

(g) Trading platforms – the identity of secondary trading platforms on which the token trades, to the extent known.

(h) Sales of tokens by initial development team – each instance where a member of the initial development team sells five percent of his or her tokens, the dates of the sales, the number of tokens sold, and the identity of the seller.

(3) Tokens must be sold for purposes of accessing, participating on, or developing the network

The network developers must demonstrate the tokens are sold for one of these three purposes. This requirement dovetails with the purpose of the safe harbor in encouraging the development of truly decentralized networks and not, according to Commissioner Pierce, exempting “debt or equity securities masquerading as tokens.”

(4) Reasonable efforts to create liquidity

The developers must attest they intend to and will undertake “good faith and reasonable efforts to create liquidity for users.” Commission Pierce acknowledged that secondary token trading may be a pathway to create liquidity for users, despite the SEC’s previously-voiced opinions that secondary trading is an indicia of a securities offering. In addressing that issue, Commissioner Pierce remarked that such trading “is recognized as necessary” to facilitate the distribution of tokens to those who will use them, as well as providing a way to exchange tokens for fiat currency.

(5) Notice of Reliance

Within 15 days of the first token sale in reliance of the safe harbor, the development team must file a notice of reliance on the SEC Electronic Data Gathering, Analysis, and Retrieval System (EDGAR) in accordance with EDGAR rules set forth in Regulation S-T. Among other items, the notice must identify the development team members, the date of the first token sale, contain an attestation that the conditions of the safe harbor have been met, and identify where the required disclosures are publicly available online.

Fraud remains actionable

Commissioner Pierce made clear that qualifying for the safe harbor does not immunize the sale of the tokens from action under the SEC’s – or any state’s – antifraud authority. Thus, the safe harbor would not immunize developers from federal or state antifraud action if, for example, the developers made false, misleading, or incomplete disclosures about the tokens.

Applies to prior sales

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.” Commissioner Pierce noted that the developers of such tokens “may need the safe harbor in order to permit secondary trading to occur and to distribute their tokens more widely into the hands of potential users.”


Acknowledging that she is only “one of five Commissioners” and cannot write rules unilaterally, Commissioner Pierce emphasized her desire to “get the ball rolling” and her hopes that she can “convince [her] colleagues to add consideration of such an approach to the SEC rulemaking agenda.” She also requested commentary and feedback from the blockchain and cryptocurrency community and others “to weigh in and tell me what I have gotten right and what I have gotten wrong.”

The community is listening, and already at least one open letter has issued with proposed modifications to Commissioner Pierce’s proposal. In large part, the blockchain community has lauded Commissioner Pierce’s efforts. While there is no way to predict if this proposal will ever make its way to the SEC’s rulemaking agenda, Commissioner Pierce has undoubtedly created a spark that will continue to build with the industry’s increasing desire for regulatory clarity that will facilitate fundraising and innovation in the blockchain space.

A copy of Commissioner Pierce’s speech and the safe harbor proposal is available on the SEC’s website.

Latest Thinking

View more Insights
Insights Center
Knowledge assets are defined in the study as confidential information critical to the development, performance and marketing of a company’s core business, other than personal information that would trigger notice requirements under law. For example,
The new study shows dramatic increases in threats and awareness of threats to these “crown jewels,” as well as dramatic improvements in addressing those threats by the highest performing organizations. Awareness of the risk to knowledge assets increased as more respondents acknowledged that their