How to Raise Money For Your Blockchain Project Before You Issue Your Token

1.1Invest now!

This early risk is borne by investors who will expect to see this reflected in the terms you offer.

Typically, this is done via some form of discount on the future price of your token.

A typical Simple Agreement for Future Tokens (SAFT) template will specify this discount as a % over the future token price.

The template we use with clients and which we share here as a guide (reliance upon which is entirely at your risk) defines this as the Discount Rate.

To calculate the Discount Price, i.e. the price at which your investor will buy your future tokens, one simply multiplies the future price of the token with the Discount Rate.

The Purchase Amount under the SAFT will then determine the amount of tokens an investor receives by simply dividing this amount by the Discount Price.

Quoted from the entry

“Example: A Purchaser sends a Purchase Amount of USD 10,000 in DAI to the ERC20 wallet specified in your SAFT. The Discount Rate is 60%. The price of your token on issuance is USD 1. The Discount Price is hence 60 dollar cents (Main Sale Price x Discount Rate). Your investor will receive 16,667 tokens (USD 10,000/USD 0.6) compared to token buyers in the main sale who get 10,000 tokens when contributing USD 10,000 in the main sale.”

— Otonomos, 19 November 2020

Note that you may want to specify investor contributions in either fiat or stablecoin, even if you let Purchasers make payment in crypto.

1.2Reference price vs. absolute price

The elegance of the SAFT’s reference price mechanism is that there is no need to set an absolute price for your token before it is issued.

Practically, this will make your pre-sale a lot easier to manage, as it avoids manually slotting in absolute prices in your sales documents and having to specify the amount of tokens each investor receives under their agreement.

An added benefit is that this mechanism gives you the option to use a price discovery mechanism at the point of main sale, for instance by using an auction mechanism during your main sale. By using a reference price, pre-sale investors have the certainty that whatever the main sale price of your token, they get the discount price.

Finally, we have seen that using a reference price mechanism rather than an absolute price, on which investors may fixate, saves clients a lot of grief by avoiding hand-to-hand negotiation over price.

One way to make it easier to maintain the same discount or pre-sale token price for all investors is by using a “most-favored nation” clause, which guarantees that any terms given to one investor would need to be granted to all.

1.3The “Network Launch”

SAFTs typically make reference to a Network Launch which will trigger conversion of the aggregate purchase amounts into actual token allocations.

In essence, this Network Launch is the event that will have you tabulate how many tokens are to be issued to your SAFT Purchasers and to the buyers in your main sale.

In our template, the Network Launch is defined as “a bona fide transaction or series of transactions, pursuant to which the Company (i.e. the issuer) will sell the Tokens to the general public in a publicized product launch”.

However, the wording can be adapted to suit an event of any kind in which tokens are created and distributed in consideration of certain activities by the token holders such as voting, providing liquidity, etc.

Note that this token creation does not have to be by the issuer of the SAFT but can be e.g. by an unincorporated DAO.

1.4Can I get a refund?

Irrespective of whether the Network Launch is a main sale or a token distribution, it is important to give investors some visibility on timeline: There should not be too much of a time lag between when the SAFT is offered and when the Launch Event is expected.

This is partly for historical reasons, as the SAFT grew out of the SAFE (Simple Agreement for Future Equity) which triggers conversion upon a Future Equity Event (vs. a Network Launch under the SAFT).

Typically, under the SAFE mechanism there are certain guarantees that if this Future Equity Event does not happen by a specified date and/or raises a minimum amount, Purchasers get refunded.

SAFTs diverge from this standard quite significantly and typically only partly refund Purchasers and only upon a Dissolution Event, as defined. In essence, this means a SAFT can simply expire by the deadline and no refunds would be due.

Our template tries to bring some balance by adding a clause that if the SAFT sale fails to bring in a threshold amount, the issuer is obliged to repay all investors. However this clause too is of course optional.

1.5A SAFT alternative

Some clients use a Token Purchase Agreement (TPA). Arguably, this is a more primitive document compared to a SAFT but can be suitable if a token has already been pre-mined but is not yet generally available.

Investors then simply buy tokens at the price specified in the TPA.

Because they typically only receive the tokens in their wallet once some sort of main sale or network launch has occurred, in practice the TPA works fairly similar to the SAFT, be it that perhaps it offers (even) less protections against non-performing teams.

A more sophisticated alternative to the TPA is for an issuer to just write call options to investors at a certain price that entitle them to purchase tokens at the exercise price specified in the call option agreement.

From a regulatory point of view, since options are generally only considered an investment when they in turn give the right to acquire or dispose of an investment, if your token is not considered an investment then any call option you issue over it would not be considered an investment.

The options would also not be seen as contracts for difference (CFDs) and hence a financial instrument since the Purchaser ultimately takes physical delivery, which is not the case with financials CFDs.

However this general analysis is very much subject to a case-by-case examination of the token and its function.

1.6Holy Trinity

Irrespective of whether you choose the SAFT, TPA or the call option route, there has to be a counterparty to the agreement you present to your investors for signature.

As a general rule, nothing should ever, EVER be done in your personal name (which is probably why Satoshi Nakamoto chose to stay anonymous!).

Legal entities provide a shield against personal liability, except in the proven case of fraud (and even then enforceability may be difficult). For this reason, we are generally not recommending code be pushed from a DAO: if challenged, a DAO would most likely be traced back to its lead devs who could be held personally - and unlimitedly! - liable for what went wrong.

For a proper risk-mitigation approach, you’ll need (1) an entity that issues the funding instrument (the SAFT/TPA/Option), which may or may not also be the issuer of your eventual token, (2) an entity that stewards your project post token generation event, and (3) an entity that does the development work.

Here at Otonomos we refer to these three entities as the “Holy Trinity”:

1. The SAFT/TPA/Option counterparty and token issuance vehicle

   This Special Purpose Vehicle (SPV) is the one you’ll slot in the square brackets at the very top of your funding instrument as the issuer of the SAFT or TPA or the legal entity selling the options.
   
   Since a capital raise is seen as a one-time event and not a sale of goods, tax can be a secondary consideration. However some jurisdictions e.g. Singapore may not share this analysis and could look at this as a sale of goods, which attracts Goods and Services Tax or VAT.
   
   Therefore, instead of spending on structuring tax away, it may make more sense to incorporate the SPV in a zero- or low-tax jurisdiction e.g. B.V.I. or Cayman, or to use a pass-through entity such as a U.S. LLC owned by an offshore Member.
   
   Many of our users who formed a Delaware or Wyoming LLC via otoco.io, our onchain company assembler, use their LLC specifically for this purpose.
   
   As indicated earlier, in addition to being the issuer of the pre-sale agreements, the token itself could be issued and sold or distributed from this SPV.

2. Foundation or Trust

   So you used above SPV to enter into pre-sale agreements and raised some money. You may also have sold your actual token from the SPV and are now sitting pretty with wallets brimming with crypto assets (or fiat if you managed to open a bank account in name of the SPV to cater to fiat investors). What to do next?
   
   This is where a Foundation or Trust enters the picture. It is the entity that will receive and manage the proceeds of your sale, which can either be pledged to it by the SPV or paid to it by way of dividend (if the Foundation owns the SPV).

   Why a Foundation or Trust vs. a holding company on top of your legal stack?
   
   Simplified, a Foundation or Trust will give you much more flexibility not only in how you manage your investment proceeds but also how you structure and decentralize the governance of your project:

   • Stakeholders in your Foundation or Trust can become Beneficiaries, whilst in a company they would have to become shareholders in order to have voting rights and/or receive a revenue share.

   • Your Foundation or Trust may also be the holder of any IP (if any) on behalf of its Beneficiaries.

   • Crucially, Foundations can give grants e.g. to developers who help with the project.

3. Operational entity (“OpCo”)
   
   Such grants can also be given to any operational entity you already own or create for this purpose.
   
   Such grants would then typically cover the OpCo’s working capital and can be in crypto and converted into fiat at the OpCo level, since the OpCo is likely to have (or will be able to open) a bank account.
   
   Most projects may have already formed an operational entity before they raise money, typically where the project leads live or work.
   
   If this not the case, a cheap and cheerful entity can be quickly incorporated for this purposes. Ideally this should be somewhere where you can easily open a bank account, sign an office lease etc.
   
   Generally, OpCos are in first-world, high-tax locations which is okay, since the entity is not meant to ever turn a profit and only has to cover payroll, rent and other fiat expenses out of the grants it receives.
   

1.7End State

The sequence and end state of the above setup would broadly be as follows:

• You first set up a Special Purpose legal entity that signed a SAFT or wrote call options over tokens still to be issued (or signed a Token Purchase Agreements if tokens have already been created).
• This entity received the aggregate Purchase Amounts collected and holds these proceeds in its wallets (and if it took fiat, its bank account).
• From that moment, you started to use the funds received to get everything in place for your main token sale/distribution (further development, community, infrastructure, code audits etc.).
• When you’re ready to generate your token, you used the same SPV as your pre-sale entity to create and sell it.
• Alternatively, you set up a new entity for this purpose to further firewall the legal risks of issuing and selling a token. Note that a fair number of users who spun up an onchain LLC using our otoco.io company assembler seem to use it for this purpose: since ownership is hidden behind their Ethereum wallet, they may be getting the best of both worlds from using a real-world limited liability wrapper whilst preserving anonymity.
• You now completed your sale and raised your target amount, which sits pretty in wallets that belong to the SPV.
• The SPV then pledges or dividends out the sales proceeds to the Foundation, which ideally should be memberless.
• You can then gradually (or instantly) decentralize the Foundation’s governance and hand your project to the community, who can table and vote on proposals.
• With grants now decided by your token holders or a subset of them, to be consistent you could also make the receipt of working capital by way of grant to your own OpCo subject to a community vote.
• Alternatively (or concurrently), the Foundation could own your OpCo outright and exercise its control as a shareholder, rather than a mere grantor. However, OpCo’s in OECD jurisdictions that are owned by offshore Foundations may find difficulties in onboarding with traditional and even crypto service providers, so it may be preferable to not have cross-ownership between the Foundation and your OpCo.

As always, a quasi infinite numbers of permutations are possible, and many aspects of your pre-token sale funding will be specific to your project.

If you want to discuss your project with us, please schedule a FREE 30 minute call here so we can guide you better.