It’s no secret the regulatory regime in the US hasn’t been friendly to budding decentralized projects. This is because the SEC has tried to apply Howey analysis to crypto projects that effectively classify any token that requires management as a Security.
Since the token value of an early stage crypto project depends on the efforts of the team to achieve decentralization, the tokens for such projects are classified as securities under the Howey lense.
Securities have limitations for distribution. One such limitation is purchasability. For example, the tokens can only be purchased by accredited investors, meaning purchasers need to have at least $1 million in liquid assets. This limits users from purchasing tokens to use them.
This created a regulatory catch-22. Projects need to distribute tokens to achieve decentralization but cannot do so in a compliant manner.
Recently, SEC Commissioner Hester Peirce proposed a framework that allows promising decentralized projects to distribute (sale/drop) tokens in the US and avoid being regulated as securities as long as they satisfy a set of five conditions.
Disclaimer: I’m not a legal professional and this is not legal advice; this is merely my analysis and opinion.
1. Meaningful Decentralization in Three Years
The initial project must enable the network to achieve meaningful decentralization in three years, upon which the token will no longer be considered a security. To assess decentralization, the network should not be controlled by a single individual or a group of individuals, or entities under common control–this goes beyond just preventing 51% attacks.
Another assessment would be if the token is actually used to exchange value pertaining to the network by the end of three years. For example, a token used to trade compute cycles or storage is moving value in the network.
2. Disclose Key Information
Since three years is a long period, the team should disclose key information to address asymmetry concerns and should be on a freely accessible public website. A minimum set of disclosure falls into three key categories: protocol design, token metrics and economics, and operational transparency.
2.1 Network
- Any key information that affects the token value should be disclosed.
- The source code and all the transaction history must be made public.
- The token buyers need to clearly understand the purpose and the mechanics of the network.
- The team should encourage the development of block explorers, dashboards, and wallets.
- The team must explain the launch and supply process for the token.
- There has to be a governance mechanism for making changes to the protocol.
2.2 Token Mechanics
The Team must disclose the below information pertaining to the token:
- 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
- The total number of tokens outstanding
- The token mining (generation) protocol
- Token burning protocol
- The process for validating transactions
- The consensus mechanism
2.3 Operational Transparency
- The team must publish a roadmap with the development plan, the current state, and the timeline for development and how and when the team plans to achieve network maturity.
- The team must explain how they’ll finance the roadmap.
- The team must disclose the team member profiles with names, relevant experience, qualifications, and skills.
- The team must disclose the number of tokens owned by each member of the team with the transferability (lockup) limitations.
- The team must disclose any time a member sells 5% or of their originally held tokens over any period of time.
- The team must periodically publish development updates or updates to token economics or network protocol.
3. The Token Must Have Utility
The token should be sold for facilitating access to, participation on, or the development of the network. Meaning the safe harbor does not apply for debt or digitized securities (STO for eg).
4. Ensure Token Liquidity
The project team should ensure sufficient liquidity for the token. If the team chooses to secure secondary trading of the token on a trading platform (OTC for eg), the platform should comply with state and federal laws relating to money transmission, anti-money laundering (AML), and consumer protection. SEC recognizes secondary trading is necessary to get tokens into the hands of people that will use them, and to offer developers and people who provide services on the network a way to exchange their tokens for fiat or cryptocurrency. The team should also disclose to the public any secondary trading platforms on which the token trades.
5. The Team Would Have to File a Notice of Reliance.
The final condition is that a team member must 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.
Conclusion
I believe this proposal is a great first step towards creating a healthy regulatory climate for decentralizing innovation in the US and around the world. If you see an error in my analysis or would like to discuss further, please reach out to me on twitter at @GregOsuri.
