Chapter Ten: Approaching Investors, the legal framework

In our previous chapters we discussed how to potentially build ICOs that will not be considered as a security and therefore regulated under security laws. We outlined the reasons for protection, the types of investors that are exempt from protection and how to strip away the definition of a "security" from a token. 

In this chapter we'll list the few popular legal frameworks to allow investors to invest in an ICO, and explain their benefits and risks.

The first agreement that most people who participate in ICOs are familiar with is the SAFT, the "sample agreement for future tokens". SAFT is based, somewhat on the SAFE, the sample agreement for future equity; the SAFE was provided by the startup accelerator Y-Combinator to help founders raise capital with a standardized form, that does not carry any material obligations save for the conversion of a payment to future equity when the company raises funds. The SAFE has its benefits and risks, but it is meant to allow people to raise money for future equity, meaning against the issuance of shares.

The SAFT, on the other hand, is an agreement stating other things (read some here). Most of the agreement is drafted in a sense that upon the finalization of the sale event, the payment shall be converted into tokens bearing the value of the tokens, and after a discount of specific percents. While this became somewhat of the standard in token issuance, this agreement still refers to the transaction in some senses as an investment in securities. It also contains a section stating that the SAFT investment may not be later resold or transacted in any way according to the law, if they are a security. 

The major problem with a SAFT is that it may only be offered to accredited investors, meaning not to the general public, and that SAFTs are not really anything but a nice paper where the issuing company intends to issue tokens based upon. Recently, the Securities and Exchange Commission actually based investigations on SAFTs, and used the agreement to show that the investors intended to generate profits, due to the discount rates and other representations.

Another method is the token participation agreement; A token participation agreement is an agreement where the investor acknowledges that, mostly, the technology is not yet developed, the features of the token he is buying are not finalized, the token may not be later defined as a security, and he will not use it as a security, and that in some cases the there are both caps and discounts provided to others. 

The problem with such participation agreement is that while it defines the inherent risks in the token issuance, it does not contain any guarantees on behalf of the company issuing the token. In more extreme cases, like the Tezos crowdsale agreement, terms were so vague, as the purchase was associated with a Swiss non-profit, and the method was as following: a non-profit agreement received a donation; if the non-profit decided that the contribution was sufficient, it issued back a token as a reward, but the foundation may decide otherwise; meaning that there's an inherent risk.

In my opinion, any agreement meant to represent the relationship between the token generator and the buyers which is not hard-coded into the framework will be invalid later on. A legal agreement goes only between the parties to the agreement; meaning that repurchases and off-market sales may limit the rights and representations brought in any token sale agreement.

Therefore, the solution is not in the agreement, but the legal coding made. For example, bitcoin has a double-spending protection: it does not allow people to use the same coin in two different transactions. While this could be done in an agreement, where each bitcoin purchaser agrees not to double spend, it was hard-coded into the system and code. The same goes for token sales; if you want to prohibit the use or sale of tokens to specific parties, it should be coded into your smart contract's protocol.

But here comes the first problem: most people who perform a pre-sale do not even have a beta version of their smart contract; they have a token which might be used later on, or may be replaced with the real token. This is the first problem. The smart contract should be presented to the investors as a first line of defense from legal liability.

The second thing is that the sale agreement should not be considered as a security by itself. In the SAFT, one of the major issues is the discount for early investors. The SAFT tool provides discount from the market price instead of setting a specific price. This means that the SAFT is a tool designed as a financial instrument, allowing investors to generate a discount on future purchases, and they can just sell the token on day-one, henceforth being an investment contract.

The third issue is allowing as many people to participate in the token allotment, meaning not just approaching accredited investors. In order to do that, the SAFT/Purchase model is not optimal. The SAFT is designed in similar phrasing of the SAFE and in order to allow people to participate in funding methods that are for accredited investors; where they assume risks and receive the option to participate in future revenues. The regular joe should be able to purchase tokens at the end as well. If the tokens shall later on be traded in an exchange, they should be free from all restrictions and tradeable. 

This also means that the lock-up period specified in some ICO agreements should be coded into the smart contract; not allowing people to transfer their tokens before a certain period expires.

The way to do this is by entering this into the code of the blockchain or decentralized application. For example, that tokens have an expiry date or maturity date, and that their restrictions are coded. The agreement should be comprised on representations relating to the technology (meaning, we can't guarantee that it will work, and the regular disclaimers) and to issue the tokens upon the execution of the  agreement where they are free from all claims.

Any other restriction, only imposed by an agreement, will ultimately fail.

In our next chapter we'll review some crowdsale disclaimers and explain why were they placed; and how to phrase them in your agreement.

I'm Jonathan Klinger, I'm a master of law, certified to practice in Israel. I've explored the blockchain, and now I'll be helping you in deciding on whether you should raise funds via a token generating event. I highly recommend you avoid it. Read my blog for more info.Previous Chapters:

Preface
Chapter One: Other People's Money, an Introduction.
Chapter Two: Scams, or why do we need investor protection?
Chapter Three: The Investors, or who doesn't need protection.
Chapter Four: What is a security, or: the Howey test, simplified.
Chapter Five: Avoiding the Howey Test.
Chapter Six: Airdrops.
Chapter Seven: Valueless Tokens.
Chapter Eight: Token Burns; another way to avoid Howey.

Chapter Nine: Limited Supply Does Not Mean Increase In Value.