The safe harbor seeks to balance the objectives of protecting token purchasers and providing 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 enabling purchasers to participate in networks of interest. The safe harbor also provides network entrepreneurs the time and regulatory flexibility to build their networks.
Earlier this month, I proposed a securities law safe harbor for token distributions. My motivation was the fear that many crypto entrepreneurs have: that a token distribution might be deemed by my agency – the SEC – to be a securities offering.
How, then, is a would-be network supposed to mature into a functional or decentralized network? Network effects are unlikely to take hold until 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 securities regulators ignore the conundrum our laws create.
“Underlying the three-year grace period is a premise that the nuances and ambiguities in determining whether a token transaction represents a security transaction exist primarily in the earlier stages.”
The safe harbor would provide network developers with a three-year grace period – exempted from the registration provisions of the federal securities laws – within which they could facilitate participation in and the development of a functional or decentralized network, so long as the following conditions are met:
- The team must intend for the network to reach network maturity – defined as either decentralization or token functionality – within three years of the first token sale and undertake good faith and reasonable efforts to achieve that goal.
- The team would have to disclose key information on a freely accessible public website.
- The token must be offered and sold for the purpose of facilitating access to, participation on, or the development of the network.
- The team would have to undertake good faith and reasonable efforts to create liquidity for users.
- The team would have to file a notice with the SEC to rely on the safe harbor.
When I announced the safe harbor, I emphasized that it is a work in progress, one that would benefit from the power of decentralized wisdom. The thoughtful discussion I had hoped the proposal would prompt has begun already. Reactions have ranged from enthusiastically supporting it, to dismissing it as unnecessary. Suggested improvements include clarifying how the safe harbor interacts with the laws of other domestic and foreign jurisdictions, allowing issuers to provide liquidity directly rather than through a third-party trading platform, and recasting the safe harbor around specific contractual obligations. Briefly, I will address two emerging themes in the conversation.
First, some commentators have worried that the proposal would reignite the 2017 initial coin offering craze. The safe harbor is designed to provide a safe path forward for legitimate projects and to make attracting funds more difficult for fraudulent projects. The safe harbor requires the disclosure of specific information about the project and development team, preserves the SEC’s antifraud authority over safe harbor token sales, and excludes bad actors.
“’If this is it, please let me know … if this is it, I want to know.’ If this is not it, I want to know that, too.”
A second area of concern is the lack of a bright-line test for whether a token is a security at the end of three years. To avoid the securities classification at the end of the safe harbor period, the network would have to be decentralized, which means it 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. Alternatively, the network could be functional, which means holders can use the tokens in a manner consistent with the utility of the network.
Underlying the three-year grace period is a premise that the nuances and ambiguities in determining whether a token transaction represents a security transaction exist primarily in the earlier stages of the development of a network. The lack of control over the network or the functionality of the network should be demonstrable within three years, and if not, the development team must be willing to take a clear-eyed look at the viability of the project as originally envisioned in light of our existing regulatory structures.
My preliminary responses to these early concerns should not be taken as discouraging further dialogue on these and related issues. I continue to urge people – this time in the words of Huey Lewis and the News – “If this is it, please let me know … if this is it, I want to know.” If this is not it, I want to know that, too. Give me a call, send me an email, stop by my office, provide feedback at the SEC’s FinHub webpage or post your comments online so that everyone else can see them, too.