Running on Empty: A Proposal to Fill the Gap Between Regulation and Decentralization

Thank you George [Chikovani] for that kind introduction.  I appreciate the opportunity to be with all of you today.  Before beginning, I have to remind you that the views I express are my own and do not necessarily represent those of the Securities and Exchange Commission or my fellow Commissioners.[1]  Indeed, the views I will express today are not fully formed in my own mind and may not reflect my own opinions in the months to come.  To that end, I welcome the feedback of all of you and anyone else with an interest in the regulation of digital assets.  These issues are difficult, and many bright minds on the Commission’s staff and outside are trying hard to develop a reasonable framework.  As I thought about talking with you today, a story—one that predates my career as a regulator, but nevertheless informs it—bubbled out of my memory. 

More than two decades ago, I was on a road trip.  I was lost.  I did not have a cell phone.  It was very late at night.  It was pouring.  The gas gauge was on empty.  There was no gas station in sight.  I was distraught until two things happened.  First, I saw the lights of a lone gas station blinking in the not-too-far distance.  Second, I realized that I was in New Jersey!  Recalling something a college friend had told me, I would not have wanted to be anywhere else on a stormy night with an empty gas tank.  This friend, who had grown up in New Jersey, had never pumped gas in her life—a deficiency she attributed to a New Jersey law that allowed only gas station employees to pump gas.  Everybody else was prohibited from pumping gas.  That law sounded a little silly at the time, but now that I was in New Jersey about to enjoy this mandated luxury on a rain-drenched night, it sounded just wonderful.  Relieved that the fumes in my tank got me to the station, I pulled up to the pump, which, incidentally, was not under a roof substantial enough for even a rain shower, let alone this downpour.  There it was—the unequivocal sign saying that it was illegal for anyone other than a gas station attendant to pump gas.  I waited expectantly for the station attendant, roused from a comfortable slumber by my arrival, to emerge from his booth and start the pump.  He looked at me.  I looked at him.  He pointed at me.  He pointed at the pump.  His message was clear—forget the law, there would be no full service on that dark and stormy night.  I will not tell you what choice I made, but let’s just say that the soundtrack for that drive was Bruce Springsteen’s State Trooper: “New Jersey Turnpike ridin’ on a wet night ‘neath the refinery’s glow . . . I got a clear conscience ‘bout things I done.  Mister state trooper, please don’t stop me.”[2]  A sensible regulatory framework would have not prevented my pumping the gas rather than being stranded in the rainy dark of night.  Perhaps the New Jersey law had a hardship exemption to cover just such situations, but the empty gas tank and sign prohibiting me from filling it seemed irreconcilable at the time.

In any case, the memory of that incident brought with it a basic lesson as I think about regulation of digital assets.  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.

Entrepreneurs across the crypto landscape are facing just such a scenario in their attempts to develop worthwhile and beneficial products.  Whether it is issuing tokens to be used in a network, launching an exchange-traded product based on bitcoin, providing custody for crypto assets, operating a broker-dealer that handles crypto transactions, or setting up an alternative trading system where people can trade crypto assets, our securities laws stand in the way of innovation.  While I look forward to working with people in the community to develop solutions to each of these problems, today, I am going to focus on how to address the regulatory difficulties faced by people who want to build functioning token networks.

Before detailing my proposal for a safe harbor, I will first outline the problem.  Many crypto entrepreneurs are seeking to build decentralized networks in which a token serves as a means of exchange on, or provides access to a function of the network.  In the course of building out the network, they need to get the tokens into the hands of other people.  But these efforts can be stymied by concerns that such efforts may fall within the ambit of federal securities laws.  The fear of running afoul of the securities laws is real.  Given the SEC’s enforcement activity in this area, these fears are not unfounded. 

The SEC has scrutinized token sales through the lens of SEC v. Howey,[3] a now infamous case describing what an investment contract is.  An investment contract is one type of security under our federal securities laws.  The Howey case dealt with the sale of orange groves, and subsequent cases have involved the sale of a host of other esoteric assets.[4]  In the Howey case, purchasers of units in the orange grove were deemed to be purchasing securities because they were buying the managerial efforts of others along with their piece of the orange grove. 

The SEC has tried to apply the Howey analysis to crypto, but doing so is not particularly easy. For example, some commentators have pointed out that we have elided the distinction between the token and the investment contract.[5]  The “contract, transaction or scheme” by which the token is sold may constitute an investment contract; but, the object of the investment contract—the token—may not bear the hallmarks of a security.  Conflating the two concepts has limited secondary trading and has had disastrous consequences for the ability of token networks to become functional.  Also of concern, suggesting that tokens will increase in value, combined with securing secondary market trading, can trigger a conclusion that those tokens are being sold pursuant to an investment contract.  There are circumstances in which the security label fits, but, in other cases, promises made about tokens increasing in value are nothing more than expressions of the hope that a network will succeed and be used by lots of people.  I would argue that the analysis should focus on the objective nature of the thing offered to the purchasers.  If the token seller is simply discussing the potential for an increase in the value of a token in the same manner that a seller of any number of other consumer products might appeal to purchasers’ desire to buy a product of lasting or even increasing value, it there an investment contract?  The subjective intent of any particular purchaser should not be controlling.  If it were, then is there any end to the Commission’s authority?  How would that logic apply to a shoe company, which, as it sells you a pair of sneakers, promises to hire some prominent athletes to promote the brand, thus focusing your mind on how sky high the price will go on StockX[6] rather than on how high your new kicks will enable you to jump on the basketball court?

The SEC’s approach in these cases has made it extremely difficult for a company to distribute a token—a process that typically includes planning for a future in which people use the network and talking positively about its prospects for success—without running into a charge that the company is engaged in a securities offering.  We have even hinted that a token airdrop in which tokens are given out freely might constitute an offering of securities.  How is a person supposed to get a network up and running when she cannot even give away the tokens necessary to use the network?

One option is to stay far away from the securities laws by simply releasing a white paper, publishing the open source code, mining the genesis block, and then stepping back to allow a network of users blossom organically.  Other entrepreneurs, however, might choose to remain actively and publicly involved in building a network for some time.  Some of these people have chosen to proceed with their token offerings as planned in the hopes that they can avoid scrutiny under the securities laws and perhaps convince the SEC that their networks are sufficiently functional to avoid the securities label.  This approach is risky because proving that tokens have utility prior to being distributed to a widespread user base is difficult. 

Another option is for the developers to sell the tokens in a registered offering or pursuant to an exemption from registration.  To date, no registered offering of tokens has been conducted in the United States.  Many token offerings have proceeded under exemptions from registration, typically Regulation D exemptions that require tokens be sold exclusively to accredited investors with transfer restrictions.  Given the limited pool of persons qualifying as accredited investors based on the current wealth and income tests, it can be difficult for these projects’ networks to take off.   

Several issuers of tokens have opted for conducting exempt offerings pursuant to Regulation A.[7]  However, the costs of conducting one of these so-called “mini-IPOs” can be prohibitive.  Even if a team has the financial resources to take this route, once the token is a security, it must trade as a security.  A core benefit of a token network is its non-reliance on intermediaries; people transact directly with one another.  Having to buy or sell tokens through a registered broker-dealer or on a registered exchange certainly puts a damper on the development of a thriving, decentralized crypto network.  Particular problems arise because there are unique challenges related to broker-dealers and exchanges handling digital assets.

Other projects have sought to sever any ties with the United States to avoid the reach of our securities laws.  This approach is risky because invariably some activity occurs in the United States.  Moreover, this approach is detrimental to the US economy because it prevents American citizens from participating in budding token networks.  It is evident that any route chosen by a team to distribute tokens into the hands of potential users is fraught with uncertainty under the securities laws.

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.  The securities laws cannot be ignored, but neither can we as securities regulators ignore the conundrum our laws create.

There is, I think, a way to address the uncertainty of the application of the securities laws to tokens.  The safe harbor I am laying out this morning 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.  Accordingly, the safe harbor protects token purchasers by requiring disclosures tailored to their needs, preserving the application of the antifraud provisions of the securities laws, and giving them an ability to participate in networks of interest to them.  The safe harbor also provides network entrepreneurs sufficient time to build their networks before having to measure themselves against a decentralization or functionality yardstick. 

I have spoken openly about my intention to sketch out a safe harbor, and in response, I have gotten some very helpful feedback.  But before detailing the specifics of my proposal, I want to emphasize that this remains a work in progress.  I look forward to additional input, and, if I am able eventually to convince my colleagues to add consideration of such an approach to the SEC rulemaking agenda, many other voices, I hope, will weigh in.  For now, the text of the proposed safe harbor is available for viewing as an appendix to this speech at sec.gov and will be posted on social media so that unfiltered critics can apply their editorial hacksaws to it.  You also can give me a call, send me an email, stop by my office, or provide feedback at FinHub.  After all, I am very much a believer in the value of drawing on the creativity and ingenuity of as many people as possible.  That is why I find decentralized networks such a powerful phenomenon, and one that will allow society to benefit from the talents of people who—because of societal or geographic barriers—have heretofore been excluded.

I call particular attention to the definitions section of the safe harbor.  I am a securities regulator, not a technologist, and am eager to learn how the definitions can be improved.  The challenge is accurately capturing the technology without baking-in terminology that will become outdated in a short period of time. 

One struggle I have had in constructing this safe harbor is the appropriate scope.  My core concern is for projects that are looking to build a decentralized network, but have difficulty bridging the legal gap.  Additionally, our staff has issued no-action letters to centralized networks.[8]  While sales of tokens intended for these networks seem much less likely to implicate the securities laws, the existence of the no-action letters could be interpreted to suggest otherwise.  Hence, I am suggesting that the safe harbor be available for these types of projects also.

Another unsettled matter is that the safe harbor could take the form of a rule or a Commission-level no-action position.  In taking a no-action position, the Commission would pledge not to bring enforcement actions against project developers that fall within the parameters laid out in the position.  A no-action position may be preferable to a rule because it would not concede that the token sales it covers fall within or outside of our securities laws.  Such grey areas are an appropriate place for no-action relief.  On the other hand, a rule-based approach would be more durable and would make clear that state laws do not apply.  For purposes of this discussion, I will lay out the safe harbor as a rule. 

Getting into the specifics of the proposal, the safe harbor would provide network developers with a three-year grace period within which they could facilitate participation in and the development of a functional or decentralized network, exempted from the registration provisions of the federal securities laws, so long as the conditions are met.  This objective is accomplished by exempting (1) the offer and sale of tokens from the provisions of 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 initial development team would have to meet certain conditions, which I will lay out briefly before addressing several in more depth.  First, 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.  Second, the team would have to disclose key information on a freely accessible public website.  Third, the token must be offered and sold for the purpose of facilitating access to, participation on, or the development of the network.  Fourth, the team would have to undertake good faith and reasonable efforts to create liquidity for users.  Finally, the team would have to file a notice of reliance. 

The first requirement—that the initial development team must intend for the network to reach network maturity within three years—is intended to focus project teams’ minds.  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.  The mere theoretical possibility of a 51% attack, for example, would not prevent a team from determining that the network is decentralized under this definition.  Nor would the participation of the team in a network alteration achieved through a predetermined procedure in the source code that involves other network participants prevent a team from determining that the network is decentralized.  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.  For example, can holders use the tokens for the transmission and storage of value, to prove control over the tokens, or to participate in an application running on the network?  

The tests laid out in the safe harbor are meant as proxies for the considerations raised in the SEC’s Howey analysis and attempt to bring clarity on when a token transaction should not be considered a securities transaction.  These tests should be easier to pass at the end of three years than when the network is first launched.  Once the network cannot be controlled or unilaterally changed by any single person, entity, or group of persons or entities under common control, the token that operates on that network will not look like a security.  Even for a network that remains centralized—think of the networks outlined in the TurnKey Jet and Pocketful of Quarters no-action letters—once the tokens are actually in use to buy and sell the services for which they were intended, the securities laws will be clearly inapplicable. 

Three years is a long time and token purchasers need certain protections during this grace period, which brings me to the second requirement detailing the disclosure that must be provided.  The disclosure requirement of the safe harbor addresses information asymmetry concerns and mandates that certain information be provided on a freely accessible public website.  The team launching a token project knows details about the project that would be useful for potential token buyers to know.  Of primary importance is the source code and transaction history.  The safe harbor requires this information to be publicly available and encourages the development of a block explorer, or similar tool, for verifying the transaction history.  Token purchasers also need to understand the purpose and mechanics of the network.  For example, the team would have to explain the launch and supply process, including the number of tokens to be issued in the initial allocation, the total number of tokens to be created, the release schedule for the tokens, and the total number of tokens outstanding.  Public disclosure also would include information about how tokens are generated or mined, the process for burning tokens, the process for validating transactions, and the consensus mechanism.  The team also would have to explain the governance mechanisms for implementing changes to the protocol. 

Another key disclosure would be the plan of development, including the current state and timeline for the development of the network that provides a roadmap to how and when the initial development team plans to achieve network maturity.  To demonstrate how realistic these plans are, a team could explain, for example, how the network development will be financed and who is on the development team.  To provide insight on the initial development team, the names and relevant experience, qualifications, attributes, or skills of each person that is a member of the team must be disclosed.  Required disclosure also includes the number of tokens owned by each member of the team, a description of any limitations or restrictions on the transferability of tokens held by such persons, and a description of the team members’ rights to receive tokens in the future.  In addition, teams would need to disclose any time that a member sells five percent or more of her originally held tokens over any period of time, which would help to guard against fraud.  Additionally, team token sales could be an indication of flagging commitment to the project.

To further demonstrate their commitment to building a functioning network, teams will be required to update the posted disclosures to reflect any material changes.  Changes affecting the token economics, the network’s functionality, or the team developing the network will be of great interest to potential users of the network.  A team committed to building a widely used network likely would provide these updates regardless of whether we mandated it. 

The third condition is that the token must be offered and sold for the purpose of facilitating access to, participation on, or the development of the network.  This condition, along with the definition of token, is meant to clarify that the safe harbor is not appropriate for debt or equity securities masquerading as tokens. 

The safe harbor’s fourth condition requires the team to attest that it intends to, and will undertake, good faith and reasonable efforts to create liquidity for users.  To the extent the team attempts to secure secondary trading of the token on a trading platform, the safe harbor requires the team to seek a trading 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.  Moreover, to alleviate existing regulatory uncertainty on the applicability of securities laws to the secondary trading of tokens, the safe harbor would exempt persons engaged in certain token transactions from the definitions of “exchange,” “broker,” and “dealer” under the 1934 Act.

Admittedly, the liquidity condition may surprise observers of SEC staff positions in which attempts to facilitate secondary trading have been viewed as indicia of a securities offering.  In the context of the safe harbor, by contrast, secondary trading is recognized as necessary both to get tokens into the hands of people that will use them and offer developers and people who provide services on the network a way to exchange their tokens for fiat or crypto currency.  To the extent it is aware, the team would disclose any secondary trading platforms on which the token trades.

The final condition is the need for the team to file a notice of reliance on EDGAR within fifteen days of the date of the first token sale in reliance on the safe harbor.  As part of the 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 where the required disclosure may be accessed.  None of the disclosures required by the safe harbor would be provided in the notice filing on EDGAR.

Having outlined the conditions of the safe harbor, I would like to emphasize a few points concerning its scope.  SEC enforcement has played an important role in combating fraud in connection with token sales.[9]  The safe harbor would not provide immunity from such actions.  First, the safe harbor would not be available to a team if one or more members of the team is subject to disqualification as a bad actor under the securities laws.  Second, the safe harbor would reserve the SEC’s antifraud authority with respect to token sales under the safe harbor. Although the safe harbor would preempt state securities laws, it would not stand in the way of state antifraud actions.  If anyone lied in connection with selling tokens pursuant to the safe harbor, the SEC or a state could bring an enforcement action.  This provision is not directed at teams that set forth a plan for a network and work earnestly toward building it, but fail to bring it to fruition.  Rather, it is designed to ensure that the SEC can bring suit against a team that sets out to defraud token purchasers by materially misrepresenting or omitting key information.  We all know that there are plenty of those kinds of “projects” polluting the crypto space. 

It is also important to note that 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.  These teams 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.  Tokens that already are in widespread use on a decentralized network presumably are not securities and, therefore, would not need to take advantage of the safe harbor.  It is during the development phase that questions about the securities/non-securities line seem to be most difficult to resolve.  Once a token network is up and running, few people would advocate application of the securities laws.[10]  By essentially buying time for this question to be answered, the safe harbor makes it much more likely that the question as to whether something is a security can be answered in the negative.

Now that I have outlined the safe harbor, I suspect some of you are asking, “Who cares?”  I get the point.  I am one of five Commissioners.  I cannot write rules unilaterally.  However, to quote another of the Boss’s songs: “you can’t start a fire without a spark.”[11]  It does not hurt to get the ball rolling.  People change their minds.  Moreover, if we are going to do something like what I suggest today, 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.[12]  Don’t be that guy in New Jersey telling me I have to do this all by myself.

---

Appendix

Token Safe Harbor Proposal

Office of Commissioner Hester M. Peirce

February 6, 2020

Proposed Securities Act Rule 195 – Time-limited Exemption for tokens.

Preliminary Notes:

1.  Distributed ledger technology may be used to offer and sell digital assets, such as tokens, to raise capital and for other purposes.  The U.S. federal securities laws may apply to such transactions, depending on the particular facts and circumstances, without regard to the form of the organization or technology used to effectuate a particular offer or sale.

The analysis of whether a token is offered or sold as a security is not static and does not strictly inhere to the digital asset.  A token may be offered and sold initially as a security because it is wrapped in a transaction involving an investment contract, but that designation may change over time if the token is later offered and sold outside of an investment contract.  For example, a token sale may no longer be the sale of an investment contract if purchasers could no longer reasonably expect a person or group to carry out the essential managerial or entrepreneurial efforts.

However, in order for a network to 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, the tokens must be distributed to and freely tradeable by potential users, programmers, and participants in the network.  Additionally, secondary trading of the tokens typically provides essential liquidity for the users of the network and aids in the development of the network.  The application of the federal securities laws to these transactions frustrates the network’s ability to achieve maturity and prevents the transformation of the token sold as a security to a non-security token functioning on the network.

Accordingly, this safe harbor is intended to provide Initial Development Teams with a three-year time period within which they can facilitate participation in, and the development of, a functional or decentralized network, exempt from the registration provisions of the federal securities laws so long as the conditions are met.  The safe harbor is also designed to protect token purchasers by requiring disclosures tailored to the needs of the purchasers and preserving the application of the anti-fraud provisions of the federal securities laws.

Upon the conclusion of the three-year period, the Initial Development Team must determine whether token transactions involve the offer or sale of a security.  Token transactions may not constitute securities transactions if the network has matured to a functioning or decentralized network.  The definition of Network Maturity is intended to provide clarity as to when a token transaction should no longer be considered a security transaction but, as always, the analysis will require an evaluation of the particular facts and circumstances.

2.  Rule 195 is not an exclusive safe harbor. A person who does not meet all of the applicable conditions of Rule 195 still may claim any other available exemption under the Securities Act of 1933 for the offer and sale of the securities.

(a)  Exemption.  Except as expressly provided in paragraph (d) of this section, the Securities Act of 1933 does not apply to any offer, sale, or transaction involving a token, as defined herein, if the following conditions are satisfied by the Initial Development Team, as defined herein.

(1)  The Initial Development Team intends for the network on which the token functions to reach Network Maturity, as defined herein, within three years of the date of the first sale of tokens and will undertake good faith and reasonable efforts to achieve such status;

(2)  Disclosures required under paragraph (b) of this section must be made available on a freely accessible public website.

(3)  The token must be offered and sold for the purpose of facilitating access to, participation on, or the development of the network.

(4)  The Initial Development Team intends to and will undertake good faith and reasonable efforts to create liquidity for users.  If the Initial Development Team attempts to secure secondary trading of the token on a trading platform, it will seek secondary trading platforms that can demonstrate compliance with all applicable federal and state law and regulations relating to money transmission, anti-money laundering, and consumer protection.

(5)  The Initial Development Team files a notice of reliance in accordance with paragraph (c) of this section.

(b)  Disclosure.  The Initial Development Team must provide the information described below on a freely accessible public website.  Subsequent to the date of filing the notice of reliance pursuant to paragraph (c) of this section, any material changes to the information described in subparagraphs (1-4), (6), and (7) below and the information described in subparagraph (8) must be provided on the same freely accessible public website as soon as practicable.

(1)  Source Code.  A text listing of commands to be compiled or assembled into an executable computer program used by network participants to access the network, amend the code, and confirm transactions.

(2)  Transaction History.  A narrative description of the steps necessary to independently access, search, and verify the transaction history of the network.

(3)  Token Economics.  A narrative description of the purpose of the network, the protocol, and its operation.  At a minimum, such disclosures should include all of the following:

(i)  Information explaining the launch and supply process, including 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)  Information detailing the method of generating or mining tokens, the process for burning tokens, the process for validating transactions, and the consensus mechanism;

(iii)  An explanation of governance mechanisms for implementing changes to the protocol; and

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

(4)  Plan of Development.  The current state and timeline for the development of the network to show how and when the Initial Development Team intends to achieve Network Maturity.

(5)  Prior Token Sales.  The date of sale, number of tokens sold, any limitations or restrictions on the transferability of tokens sold, the amount raised, and the type of consideration received.

(6)  Initial Development Team and Certain Token Holders.  Furnish the following information.

(i)  The names and relevant experience, qualifications, attributes, or skills of each person who is a member of the Initial Development Team;

(ii)  The number of tokens or rights to tokens owned by each member of the Initial Development Team and a description of any limitations or restrictions on the transferability of tokens held by such persons; and

(iii)  To the extent members of the Initial Development Team have a right to be rewarded tokens in the future in a manner that is distinct from how any third party could obtain tokens, describe how such tokens may be rewarded.

(7)  Trading Platforms.  Identify secondary trading platforms on which the token trades, to the extent known.

(8)  Sales of Tokens by Initial Development Team.  Each time a member of the Initial Development Team sells five percent of his or her tokens as disclosed pursuant to paragraph (b)(6)(ii) of this section over any period of time, state the date(s) of the sale, the number of tokens sold, and the identity of the seller.   

(c)  Filing of Notice of Reliance.  The Initial Development Team offering or selling tokens in reliance on Rule 195 must file a notice of reliance on the safe harbor no later than 15 calendar days after the date of the first token sold in reliance upon the safe harbor, unless the end of that period falls on a Saturday, Sunday or U.S. federal holiday, in which case the due date would be the first business day following.

(1)  The notice must contain the following information:

(i)  Names of the Initial Development Team, including each individual member;

(ii)  Date of the first token sold in reliance upon the safe harbor;

(iii)  Attestation by a person duly authorized by the Initial Development Team that the conditions of this section are satisfied; and

(iv)  The website where disclosure required under paragraph (b) may be accessed.

(2)  The Initial Development Team must file an amendment to a previously filed notice to reflect a material change in the information provided, as soon as practicable after the change.

(3)  A notice of reliance must be filed with the Commission in electronic format by means of the Commission’s Electronic Data Gathering, Analysis, and Retrieval System (EDGAR) in accordance with EDGAR rules set forth in Regulation S-T.

(d)  Limitation.  The exemption provided in paragraph (a) of this section does not apply to the provisions of Section 12(a)(2) or Section 17 of the Securities Act of 1933.

(e)  Duration of Exemption.  The relief provided by this section will expire three years from the date of the first token sold in reliance upon the safe harbor.  If the Initial Development Team is relying upon paragraph (f) of this section, the exemption will expire three years from the date of the filing of a notice of reliance by the Initial Development Team. 

(f)  Tokens Previously Sold.  Tokens previously sold pursuant to a valid exemption from registration may rely upon this section if the conditions of paragraph (a)(1), (2), (4), and (5) are satisfied.  The notice of reliance required by paragraph (c) of this section must be filed as soon as practicable.

(g)  Definition of Qualified Purchaser.  For purposes of Section 18(b)(3) of the Securities Act of 1933, a “qualified purchaser” means any person to whom tokens are offered or sold pursuant to reliance on paragraph (a) of this section.

(h)  Disqualifications.  No exemption under this section shall be available for the tokens of any Initial Development Team if it or its individual members would be subject to disqualification under Rule 506(d).

(i)  Definitions.

(1)  Token.  A token is a 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.

(2)  Initial Development Team.  Any person, group of persons, or entity that provides the essential managerial efforts for the development of the network prior to reaching Network Maturity.

(3)  Network Maturity.  Network Maturity is 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.

The definition is not meant to preclude network alterations achieved through a predetermined procedure in the source code that uses a consensus mechanism and approval of network participants.

Proposed Exchange Act Rule 3a1-2.  Exemption from the definition of “exchange” under Section 3(a)(1) of the Act.

An organization, association, or group of persons shall be exempt from the definition of the term “exchange” to the extent such organization, association, or group of persons constitutes, maintains, or provides a market place or facilitates bringing together purchasers and sellers of tokens satisfying the conditions of Rule 195 of the Securities Act, or otherwise performs with respect to such tokens the functions commonly performed by a stock exchange as that term is generally understood.

Proposed Exchange Act Rule 3a4-2.  Exemption from the definition of “broker” for a person engaged in a token transaction.

A person is exempt from the definition of the term “broker” to the extent it engages in the business of effecting transactions in tokens satisfying the conditions of Rule 195 of the Securities Act of 1933 for the account of others.

Proposed Exchange Act Rule 3a5-4.  Exemption from the definition of “dealer” for a person engaged in a token transaction.

A person is exempt from the definition of the term “dealer” to the extent it engages in the business of buying and selling tokens satisfying the conditions of Rule 195 of the Securities Act of 1933 for such person’s own account through a broker or otherwise.

Proposed Exchange Act Rule 12h-1(j).  Exemptions from registration under Section 12(g) of the Act.

Issuers shall be exempt from the provisions of section 12(g) of the Act with respect to the following securities:

New paragraph (j):

(j)  Any token offered and sold in reliance on Rule 195 of the Securities Act of 1933.