SAFT, which stands for Simple Agreement for Future Tokens, has emerged as a popular fundraising mechanism in the blockchain industry. It enables project teams to secure funding from accredited investors by offering the sale of future tokens once they become available. A SAFT is a legal agreement that intermediates a pre-sale of tokens. In other words, investors pay you now and receive the tokens, the moment the network and tokens are launched. Consequently, investors signing SAFTs will not need to make any additional payments later. This is different from token warrants, where investors receive the right to buy tokens in the future at a predetermined price or with a predetermined discounted price.
We believe our research on the best practices for Web3 founders should be freely accessible for everyone. However, please note that we are not lawyers. We just want to get this information out there so you have a starting point before seeking legal council.
In this article, we will explore the key features of SAFTs and discuss what is relevant to consider when using a SAFT.
When are SAFTs signed
SAFTs are most often used at Seed rounds of fundraising and signed in a period just before the network launch, typically around six to 12 months beforehand. Additionally in order to sign a SAFT the project is at a stage where the following are already in place:
- Finalized Whitepaper
- Filanized Tokenomics
- Date of Token Issuance
- A registered Token SPV company
As to why this is the case and the above need to be in place we’ll dive into it in the next section.
SAFT Terms
The terms of a SAFT include the following and therefore the following need to be defined prior to signing the SAFT:
- Token Supply at genesis and the fully diluted token supply
- Token Allocation - part of the tokens percentage that the founders will sell during the pre-sale, via the SAFTs
- Token Price - the price of tokens at the time of transfer to the investor and therefore determine the price of the token and the discount rate for SAFT investors
- Launch Date - choose the exact date of the token release or a deadline for the moment when the SAFT is converted into tokens for the investor
- Vesting and token lock-ups on the investor's tokens
By missing any of these steps and not having them defined, it is nearly impossible to set up a SAFT agreement that will protect investors' rights to receive future tokens. Now let’s look at some more of the terms implications that founders should take into account when considering using a SAFT:
In order to be able to sign a SAFT agreement with investors the project's tokenomics need to be close to finalized. But it is typical that many projects in the early stages of development may not have the details of their token, whether it's the supply, allocation, etc. fully fleshed out. As a matter of fact, it might not even be clear whether a decentralized network with a token will be launched.
Token Price & Launch Date
The SAFT always mentions a fixed price for the token. Without this clause, the "pre-sale" of the token is impossible, but setting a fixed token price through a SAFT can have disadvantages. It is important to keep in mind that regulators closely scrutinize whether founders have control over the initial token price and other network activities. Founder control over the token price implies a level of decision-making authority over critical token-related activities, potentially raising regulatory concerns regarding the token's classification as a security. This is because if the founders are the ones setting a fixed token price, the network might be seen as centralized and fall under the HOWEY Tests criteria: “with an expectation in profits from the efforts of others and from the efforts of a central third party”. Additionally, the accuracy and fairness of the valuation methodology used during the SAFT sale may be questioned which can potentially also lead to regulatory consequences and legal challenges.
Additionally, both the launch date and the price of the token at the time of the initial release are very dependent on market conditions, which are difficult to predict more than twelve months ahead. It might not be clear when the best time for the network's launch will be and if all milestones that are needed can be met within a certain timeframe.
Pricing the Network
By pricing the tokens during the SAFT sale, the project effectively puts a fixed valuation on the network. However, market conditions and other factors can introduce uncertainties and volatility, causing the perceived value of the tokens to fluctuate significantly. This may lead to investor dissatisfaction or a perception of overvaluation or undervaluation of the network. SAFTs may not account for unforeseen developments and changes in the project's value over time.
Tax Implications for Founders and Token Recipients
Allocating tokens to founders or compensating them with tokens may have tax implications. For example, let's consider a blockchain project that allocates a certain number of tokens to its founders as part of their compensation. At the time of allocation, the tokens have a determined value based on the current market conditions, let's say $100,000. In many jurisdictions, including the United States, the value of the tokens received by the founders would be considered taxable income. This means that the founders would need to report the $100,000 as income on their tax returns and pay taxes on it according to their applicable tax rates. However, since tokens can be illiquid initially, making them difficult to sell, the founders might face challenges in covering the required taxes. If the tokens cannot be sold or there is limited demand for them in the market, the founders may need to use their personal funds to fulfill their tax obligations, creating a potential financial burden. Therefore, receiving tokens without a fixed price at the time of allocation can be more advantageous for the team and other token recipients. By not assigning a specific value to the tokens, founders can defer their tax liabilities until the tokens become more liquid and their value is better established. This provides flexibility and allows the founders to plan their tax obligations more effectively, considering the market conditions and liquidity of the tokens.
If a project raises via a SAFT the project can consider to allocate tokens to founders through purchase agreements. In this scenario, the founders would use their personal funds to buy the tokens at a predetermined price. By purchasing tokens, the founders acquire them as individual investors, similar to other participants in the project. This approach avoids the potential tax implications associated with receiving tokens as compensation.
Who Signs the SAFT
In the early stages of a project, the development typically begins within a Dev Lab company established by the founders in the jurisdiction where they are located. The company issuing SAFTs will also be responsible for token minting protocol release and, as a result, be responsible for the SAFT’s conversion into tokens. However, depending on the type of tokens being issued and the regulatory climate required, a Dev Lab may not be the most suitable entity for pre-selling and therefore issuing tokens to investors.
To mitigate regulatory risks and add in an additional layer to protect founders from liabilities regarding the token sale it is important to have a clear legal separation: a separate Token Special Purpose Vehicle (Token SPV) should be established which will be the legal entity responsible for signing the SAFT on behalf of the project and issuing tokens to investors, ensuring compliance and a dedicated focus on token-related matters. This shields the Developer Company and the founders from being liable for the token issuance. Additionally, if the Dev Lab would pre-sell tokens, it might be subject to the tax laws and regulations of the jurisdiction in which the company operates.
As mentioned above it is also important to note that the company that signs the SAFT will also be responsible for the token minting protocol launch, and as a result, the company will be obliged to ensure that all terms of the SAFT have been correctly incorporated into the token minting protocol so that the SAFT conversion will take place properly. Because of these factors, the company in question must be registered in a jurisdiction where:
- The legislation allows the token release (or, in other words, the company is token-friendly), and
- There are defined rules for the taxation of token-sale transactions.
Another point to consider whether to use SAFTa is that setting a Token Issuer Company implies significant legal cost for its set up and to acquire all the legal documents needed for the compliant token minting launch. Without using a SAFT agreement, the Token Issuer Company might not be needed for teams who are not based in the US if they raise via SAFE + Token Side Letter.
Conclusion
SAFTs offer a fundraising mechanism that enables web3 projects to secure capital from investors before token launch while adhering to regulatory requirements through the established SAFT framework. However, SAFTs impose a lack of flexibility and challenges as tokenomics might evolve due to market conditions or other factors and might change leading up to the project's launch. So looking at a SAFT on a high level, the project's tokenomics need to be defined which makes a SAFT not suitable for projects that want to keep flexibility in changing their tokenomics and aren’t certain when the network will be launched. Another important factor to keep in mind is: Moving from equity to tokens is possible, moving from tokens to equity is not. Once a team has pre-sold tokens via a SAFT it can't backtrack
So, when using a SAFT, careful consideration is needed in terms of finalized tokenomics, token pricing, tax implications, and the appropriate entity responsible for signing the SAFT. In summary you could say an easy fix for making the decision is asking yourself if the following three are in place:
1. A usable or near finalized (i.e., not just a draft) White Paper with detailed tokenomics including token distribution, supply, vesting, etc.
2. A Token SPV, on whose behalf the SAFT will be signed, and which, based on the results of the conversion of the SAFT, will issue tokens to the investor
3. A clearly defined date for issuing tokens, or a specified event that will be a trigger in the SAFT for the issuance of tokens and their transfer to investors.
If any of these three criteria are missing, Web3 founders may want to consider raising via a SAFE + token warrant or token side letter, which we will discuss in our next article.
Please find the following templates that might be helpful when considering raising funds via a SAFT agreement: