Simple Agreements for Future Tokens: Structure and Application

The SAFT (Simple Agreement for Future Tokens) is an investment contract widely used for pre-token-launch fundraising. A SAFT allows projects to raise capital today in exchange for tokens delivered at a future date - typically at token launch or when milestones are achieved. SAFTs have become standard for pre-token fundraising, particularly in US jurisdictions, though their legal status remains debated.

The SAFT's appeal is simplicity and perceived regulatory advantage. Rather than addressing securities regulation at fundraising, a SAFT defers securities concerns to the future - when tokens are delivered, they allegedly become utility tokens or non-securities. This framework separates the investment (SAFT) from the resulting asset (utility token), theoretically allowing compliant fundraising even if tokens would otherwise be securities.

However, SAFTs face increasing regulatory scrutiny, particularly from the SEC. The SEC has suggested through enforcement and guidance that SAFTs may not avoid securities classification - if underlying tokens are securities, the SAFTs funding them are also likely securities. Legal scholars have criticized SAFTs as devices for avoiding proper securities compliance rather than meaningful regulatory solutions.

This guide covers what SAFTs are, how they function, regulatory characteristics, key contract terms, and practical alternatives. If considering SAFTs for fundraising, understanding regulatory risks and ensuring proper documentation is essential.

A SAFT is a contract where an investor provides capital today in exchange for an obligation that the issuer will deliver tokens at a future date. The SAFT investor has no immediate token right - only a contractual right to receive tokens when the trigger event occurs (typically token launch or development milestone achievement).

Mechanics: An investor purchases a SAFT by sending funds (fiat currency or crypto) to the issuer. The SAFT contract specifies token delivery terms: the number of tokens to deliver, timing or conditions triggering delivery, price or calculation method for token quantity, and special terms. When the trigger event occurs, the issuer delivers tokens to the investor's wallet - automatically through smart contracts or through manual distribution.

The SAFT structure separates temporal and regulatory concerns. At investment time, the investor owns a contract (SAFT) - not tokens. The contract is not a security (theoretically) because it doesn't represent security-like economic rights. The investor has a contract right to receive tokens, but not yet the tokens themselves. The SEC's theory is that this separation allows SAFTs to avoid immediate securities regulation - the contract is a straightforward purchase agreement, not a securities sale.

When tokens are delivered, the investor receives utility tokens (the theory goes) that are not securities. Securities regulation then applies to the tokens themselves (trading, etc.), but original SAFT fundraising is characterized as capital-raising through a non-securities instrument.

This theory has substantial critics. Regulators question whether SAFTs genuinely avoid securities classification if underlying tokens would be securities. From an investor's perspective, the SAFT represents an expectation of profit from token appreciation - the essence of securities classification. Temporal separation may be a technicality rather than genuine regulatory avoidance.

Three primary instruments compete for pre-token fundraising: SAFTs, SAFEs, and Token Purchase Agreements. Each has different characteristics and regulatory implications.

SAFT vs SAFE: A SAFE (Simple Agreement for Future Equity) is a tech startup instrument where investors provide capital in exchange for future equity or token rights, but the agreement explicitly doesn't create immediate investor rights or obligations. SAFEs are popular in venture funding because they defer valuation and security classification - the startup raises capital without agreeing on post-money valuation. At a future "priced round," the SAFE converts to equity at a discounted rate.

SAFEs and SAFTs serve similar functions in different contexts. SAFEs are designed for private companies planning future equity raises. SAFTs are designed for token projects where the future asset is a token, not equity. SAFTs are more explicit about token delivery mechanics; SAFEs maintain ambiguity about whether investors receive tokens, equity, or other rights.

In practice, many token projects have used SAFEs for token fundraising, treating SAFE conversion as producing tokens rather than equity. However, using an equity instrument (SAFE) for token fundraising creates conceptual confusion - SAFEs were designed for equity conversion, not token delivery. Using a SAFT (designed for token delivery) is more technically appropriate even if legal distinctions are minimal.

SAFT vs Token Purchase Agreement (TPA): A Token Purchase Agreement is a straightforward token sale contract. The investor buys tokens directly, with delivery immediate or at a specified date. The TPA explicitly addresses whether tokens are securities (or claims they aren't), rather than deferring the question.

TPAs are simpler and more direct than SAFTs. They eliminate the two-instrument framework and immediately address the core question: are these tokens securities? If yes, the TPA must be structured through registered offerings or exemptions. If no, the TPA is a straightforward commercial agreement. TPAs have clarity advantage - no pretense that temporal separation avoids securities regulation. They have the disadvantage of forcing immediate securities regulation engagement rather than deferring it.

Comparative advantages: SAFTs are attractive when the project wants to emphasize the contract/future tokens distinction, when investor relationships are complex or multi-year, or when suggesting securities regulation doesn't apply. SAFEs are appropriate when the project is genuinely ambiguous about future form (tokens vs equity) or when traditional VC conventions matter. TPAs are appropriate when the project accepts that tokens may be securities and wants to structure compliant transactions from the outset.

Well-drafted SAFTs address critical issues determining investors' rights and issuers' obligations. Key provisions include:

Investment terms: The investment amount, currency or means (fiat, stablecoins, etc.), and investor's purchase price per token (if determined upfront) or the calculation method for token quantity (e.g., tokens = investment amount ÷ token price at launch).

Token delivery: The trigger event or date for token delivery, delivery mechanism (direct transfer, smart contract, manual distribution), and conditions that must be satisfied before delivery (successful token launch, regulatory approval, etc.). This should be explicit about what happens if the trigger event doesn't occur (investor refunds?).

Investor representations: Representation that the investor is accredited and sophisticated, that investment is for personal benefit (not resale), that the investor understands risks, and that applicable law permits the investor to hold tokens. These representations support the securities law exemption defense (accredited investors can purchase certain exempt offerings).

Lock-up and transfer restrictions: Many SAFTs include lock-up periods preventing investor token sales for a specified period after delivery (typically 6–24 months). Lock-ups serve multiple purposes: demonstrating investors aren't speculating for short-term profit (supporting utility claims), limiting initial token secondary market supply, and reducing short-term volatility. Transfer restrictions should be clearly stated and integrated into the token contract itself.

Governance and decision rights: Whether token holders receive voting rights or governance authority beyond those allocated to all token holders. Most SAFTs grant only rights allocated to all token holders - investors don't receive special governance. However, some projects grant investor advisory rights or observation rights, which should be explicitly documented.

Dispute resolution and jurisdiction: Specification of governing law (typically US law if US-based issuer, Swiss law for Switzerland-based, etc.) and whether disputes are resolved through arbitration or litigation. These provisions become critical if conflicts arise.

Conditions and contingencies: What happens if the project doesn't launch tokens? What if regulatory action prevents token distribution? What if the development timeline extends beyond expected dates? Contingencies should address refund rights, delay provisions, and alternatives.

The regulatory status of SAFTs is debated among legal experts and regulators. Understanding the risks is essential for projects using SAFTs and investors purchasing them.

SEC perspective: The SEC hasn't explicitly addressed SAFTs in formal guidance, but through enforcement and comments has indicated skepticism about SAFT legal theories. The SEC has pursued enforcement against projects that raised capital through SAFTs when resulting tokens were securities. The SEC's position: if underlying tokens are securities, the SAFTs funding them are likely also securities or investment contracts, and SAFT investors may have securities law claims.

This SEC perspective undermines the SAFT's primary theoretical advantage - the suggestion that temporal separation from the underlying token avoids securities regulation. If the token is a security, the SAFT is likely a security investment contract as well, and both should have been structured through compliant securities offerings.

State law considerations: Some US states have provided guidance suggesting SAFT-like instruments are permissible. Wyoming's DAO legislation and similar frameworks suggest certain token instruments can be compliant if structured appropriately. However, this guidance typically addresses specific token types (utility tokens, DAO tokens) rather than endorsing SAFTs generally.

International regulatory views: Swiss FINMA has indicated that SAFTs and similar instruments are subject to Swiss securities law if they represent interest-bearing contracts or economic rights. MiCA regulation in the EU treats SAFT-like instruments as investment products subject to financial regulation. Singapore regulators have indicated SAFTs may be securities if underlying tokens are securities. This international skepticism reinforces that SAFTs don't provide universal regulatory clarity.

Risk mitigation: If using SAFTs to raise capital: ensure investors are accredited and sophisticated (supporting reliance on securities law exemptions), include robust investor representations warranting understanding of risks and legal status, obtain clear legal opinions about delivered token utility status (restructure as compliant securities sale if tokens are likely securities), document token classification analysis thoroughly (showing regulators thoughtful analysis demonstrates good faith), and consider securities law compliance even if relying on SAFT structures (securities compliance provides a better defensive position than claiming SAFT exemption if challenged).

How tokens are actually delivered to SAFT investors is an underappreciated area creating practical and legal implications. Several approaches are used, each with advantages and limitations.

Direct transfer at launch: When the token launches and becomes transferable, the issuer directly transfers tokens to investor wallets. This approach is simple but requires the issuer to maintain investor wallet address records and perform manual transfers. Risks include loss of wallet addresses, failed transfers if wallets are invalid, and disputes if wallet addresses change between SAFT purchase and delivery.

Smart contract automation: Some projects deploy smart contracts that automatically distribute tokens to SAFT investor addresses when specified trigger events occur (e.g., token launch). This approach is efficient and transparent - contract code clearly specifies distribution rules. However, smart contracts create operational risks (code bugs, unexpected edge cases) and require investor technical sophistication (investors must maintain private key control for specified wallets).

Custodial delivery: Some projects deliver tokens through custodians (exchanges, custody providers) that maintain investor accounts and transfer tokens at the appropriate time. This approach is user-friendly for investors and provides recovery mechanisms if something goes wrong. However, it creates counterparty risk (custodian must be trustworthy and solvent) and may create additional regulatory complexity (custody providers may be regulated).

Bridge mechanisms: For sophisticated token structures, some projects create smart contract bridges that convert SAFTs to tokens automatically. The investor's SAFT balance is recorded on-chain, and the bridge automatically converts that balance to tokens at the launch event. This approach is technically elegant but requires sophisticated token contract design.

Practical recommendations: Document the delivery mechanism clearly in the SAFT contract. Specify exactly what event triggers delivery, exactly how tokens will be delivered (direct transfer, smart contract, custodian), and what happens if delivery becomes impossible. For investor protection, ensure the mechanism is transparent and observable on-chain if possible. For issuer protection, ensure adequate mechanisms to verify investor wallet addresses and prevent fraudulent delivery claims. Projects have faced SAFT investor disputes when delivery mechanisms were ambiguous - clarity eliminates most disputes.

Reviewing dozens of SAFT agreements reveals several recurring mistakes creating legal and operational problems:

Mistake 1: Insufficient investor representations. Many SAFTs lack robust representations from investors warranting they are accredited, sophisticated, and legally permitted to hold tokens. Without these representations, the project loses important securities law exemption support. If challenged, the lack of investor qualifications undermines claims that the SAFT was a compliant exempt offering.

Mistake 2: Ambiguous token delivery trigger. Vague language about token delivery timing ("shortly after launch," "at an appropriate time," "pending regulatory clarity") creates disputes. Investors may believe delivery should have occurred; the issuer may believe conditions precedent aren't satisfied. Explicit trigger events (token deployed at specific smart contract address, trading enabled on specified date) eliminate ambiguity.

Mistake 3: No contingency for failed launches. Many SAFTs don't address what happens if the token project fails or is abandoned. Do investors receive refunds? How long must the issuer work on the project before refund rights trigger? Without clear provisions, failed projects face investor litigation.

Mistake 4: Conflicting legal frameworks. Some SAFTs specify Swiss law in one section and US law in another, or specify arbitration in one jurisdiction and litigation in another. These conflicts create confusion if disputes arise. Use clear, consistent choice of law and dispute resolution mechanisms throughout.

Mistake 5: Insufficient lock-up provisions. Lock-ups are typically included in the SAFT contract but not enforced in the token contract itself. When tokens are delivered, nothing prevents immediate sale, undermining the project's argument that investors aren't speculating. Implement lock-ups both contractually (in the SAFT) and technically (in the token contract code, through vesting contracts, or custodial restrictions).

Mistake 6: Missing risk disclosures. Many SAFTs lack explicit warnings about total-loss risk, regulatory risk, token liquidity risk, and technical risk. These disclosures are essential for securities law compliance and demonstrating investors understood what they were purchasing. Without disclosures, investor reliance claims become stronger if losses occur.

Mistake 7: Inconsistent with token utility claims. Some SAFTs include language suggesting investment returns, price appreciation potential, or other characteristics inconsistent with non-security token claims. This inconsistency is immediately apparent to regulators and courts - it demonstrates the issuer knew tokens had securities characteristics but was trying to avoid regulation.

Given regulatory debates around SAFTs, several alternative approaches are increasingly used for pre-token capital raising:

Registered offerings: The most straightforward alternative is registering the offering with applicable securities regulators (SEC in US, FCA in UK, etc.). This requires detailed disclosure, regulator review, and higher cost (100,000+ USD for full US registration). However, registered offerings create regulatory certainty - once registered, the offering is clearly compliant. For larger capital raises (over 10M USD), registration may be cost-effective compared to the regulatory risk of alternative approaches.

Regulation D offerings (US): Accredited investors and institutional investors can purchase securities through Regulation D exempt offerings. Rule 506(c) allows advertising to accredited investors (though verification is required); Rule 506(b) allows limited non-accredited participation (up to 35). A Regulation D offering can raise unlimited capital (unlike crowdfunding) while avoiding full registration. Many US token projects use Regulation D structures, issuing tokens or token-linked securities (convertible notes, SAFEs) in Regulation D compliance.

Regulation A+ offerings (US): Smaller companies can conduct public offerings up to 75M USD under Regulation A+ without full SEC registration. This approach allows broader investor participation (including non-accredited investors) but requires more extensive disclosure than Regulation D. For projects seeking to democratize investment, Regulation A+ can be attractive despite higher compliance costs.

Cayman Islands exempted offerings: Some projects register as exempted companies in the Cayman Islands and conduct token offerings under Cayman's exempted offering framework. This approach avoids US securities registration and creates legal clarity through Cayman's sophisticated regulation. However, it may still be subject to other jurisdictions' securities laws if investors are in those jurisdictions.

Equity alternatives: Some projects raise capital through traditional equity or debt instruments (priced equity rounds, convertible notes, loans) rather than directly raising through tokens. This approach uses well-established legal structures and defers the token issuance question to a future point. It's more complex than SAFT fundraising but may be more legally sound than SAFT structures claiming securities law exemptions without proper foundation.

Hybrid approaches: Some projects combine multiple approaches - raising core capital through registered or exempt securities offerings, with smaller token-specific raising through alternative mechanisms. This approach diversifies regulatory risk and allows different investor classes to participate in the most appropriate manner for their circumstances.