Yesterday’s speech from SEC Commissioner Hester Peirce is worth a read. It’s great that she’s a supporter of innovation generally and cryptoassets specifically. A few thoughts on why this is helpful but still not enough:

1/ It’s great that “Tokens sold for use in a functioning network, rather than as investment contracts, fall outside the definition of securities.” This is important, because we cannot treat usable tokens as securities, otherwise token-powered networks don’t work.

2/ But there’s still a lot of confusion about whether and when a token itself is an “investment contract” and therefore a “security” under US law.

3/ Specifically, if there is an “investment contract,” is the token itself the IC or is there some type of formal or informal agreement surrounding the token (e.g., sales agreement, informal “services” agreement based on sales promises) that constitutes the IC? Or both?

4/ Many have argued that tokens themselves, if they are merely usable software such as consumer utility or general payment tokens, should not be treated as “investment contracts.” Two notable advocates of this position are @valkenburgh and @NYcryptolawyer.

5/ They are correct as a matter of policy, at least under existing laws. The alternative just doesn’t “work” and will prevent projects from launching usable token-based networks.

6/ Nonetheless, as @awrigh01 has warned, there’s always been the risk that the SEC will try to treat the tokens themselves as securities. Even if the SEC is wrong as a matter of law, they can do a lot of damage to innovation before this is decided by the courts.

7/ Unfortunately, Commissioner Peirce still seems to describe the tokens themselves as securities:

8/ True, she later mentions that “a token sold in a securities offering might later be sold in a transaction that does not constitute a securities offering.”

9/ But that was in the context of a project becoming “truly decentralized,” and, as I explain, that’s not a sufficient trigger for the SEC allowing usable software to shed status as a “security.”

10/ The core problem with this approach is not disclosure obligations. Most projects are happy to provide transparency, and if there were clear disclosure requirements, I’m confident projects would comply.

Click here and finish reading Patrick Berarducci’s thoughts