In this opinion piece, part of an ongoing series on the state of U.S. law as it applies to initial coin offerings and token sales, he explains the significance (and limitations) of the recently announced SAFT project.
Nearly a year ago, I gave a generalized explanation of how some token sales might violate federal securities laws in the U.S. I also gave some tips on how to build a token and network that would avoid security status.
Unfortunately, many token sellers have continued selling tokens to the public prior to developing the network’s actual functionality in what I’ve taken to calling a “direct presale.” Many commentators, myself included, have found the “direct presale” model to be a blunt and risky strategy. I warned against it at the end of my October 2016 op-ed.
Now the U.S. Securities and Exchange Commission (SEC) has fired its shot across the bow of the industry in the DAO Report, and other countries have imposed outright bans.
In this Part 2, I propose an alternative: a comprehensive transaction framework that could significantly reduce the risk of the token seller running afoul of the securities laws. We’ve been working on developing this structure with a few different participants in the industry, including investors, issuers and developers. A few of our clients are already testing it in the wild.
It’s called the SAFT: Simple Agreement for Future Tokens. Obviously, it’s a play on the Y Combinator SAFE (Simple Agreement for Future Equity). The SAFT is a contract between developers and investors. The SAFT framework is a transaction flow with this contract at its heart.
We didn’t invent the SAFT. It was being used in an unexamined way by token sellers before we started suggesting it. It’s high time someone looked under the hood, though, and examined whether it actually, you know, works.
At a high level, the SAFT looks like this:
- The developer of a token-based decentralized network enters into a written agreement, called a SAFT, with accredited investors. The SAFT calls for investors to pay money to the developer in exchange for a right to tokens once the network is completed. The investors typically get a discount. The developers don’t issue any pre-functional tokens at this stage, but they do file the required forms with the SEC.
- The developer uses the money to develop the network. This could take months or years. Still no pre-functional tokens are issued.
- Once the network’s basic functionality exists, the developer creates the tokens and delivers them to the investors, who can sell tokens to the public on the open market to realize their profit.
- The developers themselves can also sell tokens to the public if they so desire.
The SAFT difference
Compare this two-step process to the direct presale, where developers sell a pre-functional token directly to the public for immediate delivery or for delivery at some date in the future.
The developers raise millions of public dollars, and use that money to develop the network protocol to functionality. The public takes on all the risk that the project fails, and does so without the benefit of standard disclosure principles, fiduciary duties, heightened antifraud standards or accreditation requirements.
I remain a supporter of the token sale in general, but the direct presale is troubling for at least a few reasons. To keep with the theme of Part 1 of this series, I’ll focus on one reason: a direct presale could be considered the sale of a security to the public without a registration statement or exemption in place. That’s illegal in the U.S.
I think the SAFT framework addresses this concern elegantly. The SAFT is a written document (available as an exhibit to this white paper here) that looks like a SAFE, and, like a SAFE, the SAFT is a security. At least we think it has a very good chance of being considered a security – and the parties fully intend for it to be one.
We aren’t trying to avoid the securities laws here. We’re trying to use them.
Investors purchase the SAFT not because they intend to use the tokens on the network once it is developed, but because they seek to sell the tokens on the open market and realize the profit from their discount. There is no (or almost no) consumptive intent here. The investors expect to profit from the efforts of the developer.
Because the SAFT is a security, the developers treat it like one. That is to say, they follow the securities laws when they sell it: they file the requisite form with the SEC, they accredit their investors (if required) and they might even circulate a private placement memorandum.
The investors send their purchase money (in dollars, ether, bitcoin, etc.) to the developers. In exchange, the developers sign a SAFT and work over the next few months or years to develop the network into something genuinely functional.
Once it is functional, the developers create the tokens and deliver them to the investors. Once any lockup period in the SAFT has expired, the investors can then sell the tokens on the open market. The developers can sell them publicly as well.
SAFT semantics
The most common criticism to this approach goes something like this: “OK, the SAFT is a security. You’ve followed the securities laws there. But once the developers sell the tokens to the public, plenty of purchasers will buy them just to speculate by trading on an exchange! Isn’t that a security as well?”
Well, probably not. Remember, just buying something to resell it for a profit on a secondary market doesn’t make the thing a security – not even if all of the other prongs of the Howey test are satisfied. The question is: Where can the buyer reasonably expect that secondary market value appreciation to come from?
Remember from Part 1, for a token to be a security, the Howey test requires that the purchaser expect his profit to result “from the efforts of others.” If the purchaser expects profit, but it’s predominantly from something other than the efforts of others, the thing he bought is not a security under Howey.
For example, when someone buys gold or sugar rights as an investment product (i.e. just to resell it on an open market), that person expects profits, but that profit isn’t from the effort of any particular third party. It’s from the great variety of market factors affecting supply and demand for gold or sugar.
The price of a functioning token is similarly determined. The value of a functioning token being put to its intended use will be determined by a great variety of global supply-and-demand forces. For a pre-functional token, though, the buyer should expect one force to predominate the others: the efforts of the developer who has promised to imbue the token with functionality.
Thus, the “efforts of others” prong of Howey can be satisfied relatively easily by a pre-functional token.
Once functional, the efforts of the developers will no doubt still figure into the value of the token on secondary markets, but it would be difficult to say that protocol upgrades could be the “undeniably significant,” “essential efforts” (both Howey requirements) that typically cause the price to move.
The “essential” efforts of the developers have usually been expended already in creating the functional network. Purchasers of tokens on that already functional network no longer need to rely on the developers to expend those efforts.
Indeed, in most cases it might be difficult to say that the price move was caused by any “efforts” at all. For functional tokens, price moves can be caused by any number of forces affecting supply and demand. To use examples from the SAFT Project white paper: A token acting as a medium of exchange on a decentralized market for graphics processing power (I’m making this one up) could fluctuate with the release of a hit video game franchise or the availability of rare earth elements used in graphics card processing.
A token acting as a simple coupon for a free box of razor blades (making this one up, too) could fluctuate with the price of steel, or even the popularity of beards in a target market. To be sure, the token sellers’ managerial efforts in updating the network will factor into the price, but will it predominate all the other forces? For an already-functional token, not often.
Striking a balance
In a SAFT transaction, the relatively heavyweight securities laws apply at the early stages, when the whole project could fail and they’re most needed.
Recall that the SAFT is a security, so anti-fraud provisions, accredited investor requirements and the like apply to the transaction. The more manageable consumer protection laws apply once the network is functional and, at minimum, buyers expect the network to function.
So, the SAFT framework calls for securities laws when the buyer takes on enterprise risk, and calls for the consumer protection laws when the buyer takes on product risk. That struck us, the authors of the white paper, as the right state of affairs, and we think the SAFT gets us there.
That said, there are plenty of limitations on the flexibility of the SAFT framework. For example, the SAFT:
- Isn’t necessary for developers who can sell a functional token directly to the public on day one. The SAFT bridges the treacherous regulatory waters between accepting funds and delivering a functional token. If you’ve already developed a functional token, the necessity of a SAFT is questionable.
- Doesn’t achieve much for tokens that are themselves securities (e.g. limited partnership interests like the DAO token). Using a SAFT won’t make a securities token any less of a security. The SAFT only works for “utility tokens.”
- Won’t aid even utility tokens where purchasers remain reliant on the efforts of the token sellers (or others) for their expectation of profit after the token is circulating. Examples include situations where the seller relies on the issuer’s promises to buy back the tokens to increase the price, or where the seller promises to develop the truly valuable functionality at some point after the sale.
Even understanding the limitations, the SAFT isn’t quite ready to serve as a market standard. For one thing, the analysis we’ve done is limited to U.S. law. Another reason is that the commercial terms of the SAFT are bare-bones and basic.
For these and other reasons, we’ve launched the SAFT Project. It’s meant to be a forum for discussion and sharing ideas around the SAFT framework. Our door is open for suggestions and criticisms.
In Part 3 of this series, I intend to discuss some SAFT best practices, including tax management strategies and the kinds of tokens that are most compatible with the SAFT framework.
[“Source-timesofindia”]
