What Is a SAFT and Why It Matters
The Simple Agreement for Future Tokens (SAFT) emerged in 2017 as a framework for token pre-sales that aimed to comply with securities laws. The concept was straightforward: sell an explicit security now (the SAFT), then deliver tokens later once the network is functional and decentralized, with the hope that those tokens would not be securities.
In my practice, I advise dozens of token projects, and the SAFT structure remains one of the most commonly requested instruments. However, following the SEC's enforcement action against Telegram in 2020, the SAFT framework's legal viability has come under serious scrutiny.
This guide explains how SAFTs work, compares them to other fundraising instruments, analyzes SEC treatment, and provides practical guidance for projects considering a SAFT-based raise.
Critical Warning: Post-Telegram Reality
The SEC v. Telegram case fundamentally challenged the SAFT premise. The court held that the entire scheme—SAFT plus token delivery—constituted a single integrated securities offering. This means the delivered tokens may still be securities subject to registration requirements, even after network launch. I advise all clients that SAFTs do not provide a regulatory safe harbor.
How a SAFT Works
A SAFT is a contractual agreement where an investor provides capital now in exchange for the right to receive tokens in the future, typically upon the occurrence of specified network launch events.
Basic Structure
- Investment Phase: Accredited investors purchase SAFTs, providing capital to the development team
- Network Development: Team uses funds to build protocol, develop software, and create token infrastructure
- Trigger Event: Specified milestone occurs (mainnet launch, sufficient decentralization, functional network)
- Token Delivery: Investors receive tokens according to the SAFT terms (quantity, vesting, any discounts)
- Post-Delivery: Investors hold and potentially trade tokens (subject to securities analysis)
Key SAFT Terms
| Term | Description | Typical Range |
|---|---|---|
| Purchase Amount | Capital invested per SAFT | $25K - $10M+ (accredited minimums) |
| Token Quantity | Number of tokens to be received | Fixed quantity or formula-based |
| Discount Rate | Discount vs. anticipated public sale price | 0-50% (higher for earlier investors) |
| Trigger Event | Condition for token delivery | Network launch, sufficient decentralization, functionality threshold |
| Vesting Schedule | Token release timeline post-delivery | Immediate, linear over 6-24 months, cliff + vest |
| Governance Rights | Investor participation in decisions | Minimal to none (SAFT is not equity) |
The SAFT Theory
The original SAFT framework rested on this legal theory:
- Phase 1 (SAFT Sale): The SAFT itself is explicitly treated as a security under federal securities laws. Sold under an exemption (typically Reg D 506(c)) to accredited investors only.
- Phase 2 (Token Delivery): Once the network is "sufficiently decentralized" and the token has genuine utility, the delivered tokens are arguably not securities under Howey because purchasers are no longer relying on the efforts of the development team.
The Theory vs. Reality Gap
This theory has significant problems. The SEC and courts have shown they will look at the entire transaction—from initial investment through token trading—as a unified scheme. If tokens are marketed or traded as investments, the securities analysis applies regardless of the SAFT structure.
SAFT vs SAFE: Critical Differences
SAFTs are modeled after SAFEs (Simple Agreement for Future Equity), which are widely used in startup fundraising. However, the two instruments serve different purposes and have different risk profiles.
SAFT (Future Tokens)
- Instrument Type: Contract right to receive tokens
- Asset Delivered: Digital tokens (may or may not be securities)
- Investor Returns: Token appreciation, utility value
- Conversion Trigger: Network launch event
- Equity Stake: None (no ownership in company)
- Governance: Potentially via token voting (post-delivery)
- Liquidation Rights: None
- Securities Status: SAFT is security; tokens may be
SAFE (Future Equity)
- Instrument Type: Contract right to receive equity
- Asset Delivered: Company shares (always securities)
- Investor Returns: Equity appreciation, dividends, exit
- Conversion Trigger: Priced equity round or liquidity event
- Equity Stake: Yes (ownership upon conversion)
- Governance: Shareholder rights (post-conversion)
- Liquidation Rights: Subordinate to preferred (if no MFN)
- Securities Status: SAFE and shares both securities
Detailed Comparison
| Factor | SAFT | SAFE |
|---|---|---|
| When to Use | Pre-network launch for token projects | Seed/early-stage equity rounds |
| Investor Base | Crypto VCs, accredited token investors | Traditional VCs, angel investors |
| Regulatory Clarity | Low (challenged post-Telegram) | High (well-established framework) |
| Future Value Depends On | Network adoption, token utility, market demand | Company growth, revenue, exit valuation |
| Delivery Timeline | 6-24 months (network launch dependent) | 12-36+ months (next equity round dependent) |
| Resale Restrictions | 12 months if under Reg D (may be longer) | Securities restrictions until public exit |
| Tax Treatment (Investor) | Complex (see tax section below) | No tax until conversion or sale |
| Tax Treatment (Issuer) | Potentially taxable upon delivery | No immediate tax event |
Hybrid Instruments: SAFE with Token Warrant
Some projects use a SAFE for the equity component plus a separate token warrant or side letter providing token rights. This approach:
- Pros: Appeals to VCs who want equity upside; provides token exposure; flexible timing
- Cons: Complex to document; uncertain tax treatment; potential conflicts between equity and token holders; SEC may challenge
In My Practice
I generally recommend SAFEs for traditional startups and SAFTs only for projects with clear token utility and realistic decentralization timelines. For early-stage crypto companies where tokenomics are uncertain, I often advise a pure equity raise (priced round or SAFE) with the option to distribute tokens later through airdrops or governance decisions.
SEC Treatment and Securities Analysis
The SEC's position on SAFTs has evolved from initial ambiguity to hostile scrutiny following major enforcement actions.
The Howey Test Applied to SAFTs
Both the SAFT instrument and potentially the delivered tokens must pass the Howey Test to avoid securities classification:
| Howey Prong | SAFT Analysis | Delivered Token Analysis |
|---|---|---|
| 1. Investment of Money | Clearly met (investors pay cash) | Arguably met (purchased via SAFT) |
| 2. Common Enterprise | Met (pooled funds for development) | Debatable (depends on token economics) |
| 3. Expectation of Profits | Met (investors expect token value increase) | Critical issue—depends on marketing and use case |
| 4. Efforts of Others | Met (team builds the network) | Key question—is network sufficiently decentralized? |
SEC Enforcement: The Telegram Case
SEC v. Telegram Group Inc. (S.D.N.Y. 2020) is the seminal case on SAFTs. Key facts:
- Raise: Telegram raised $1.7 billion from 171 investors through SAFT sales
- Structure: SAFTs sold under Reg D 506(c) to accredited investors, with tokens to be delivered upon network launch
- SEC Action: SEC obtained preliminary injunction blocking token distribution
- Outcome: Telegram abandoned the project, returned $1.2B to investors, paid $18.5M penalty
The Telegram Court's Holdings
The court made several critical findings that undermined the SAFT framework:
- The initial SAFT sales and subsequent token distribution were part of a single integrated offering of securities
- SAFT purchasers would resell tokens to the public in unregistered transactions
- Even with network functionality, tokens would remain securities due to Telegram's ongoing essential managerial efforts
- The offering did not qualify for a registration exemption because SAFT holders were not purchasing for their own accounts but for resale
Other Notable SEC Actions
- Kik Interactive (2020): $5M penalty for unregistered $100M token sale; court rejected utility defense
- Block.one (2019): $24M settlement for $4B unregistered token sale of EOS
- Munchee (2017): First SEC order against token offering; project abandoned after cease and desist
Current SEC Stance
Based on enforcement actions and public statements, the SEC's current position appears to be:
- SAFTs Are Securities: The SAFT instrument itself is always a security
- Delivered Tokens Are Likely Securities: If sold under a SAFT to fund development with expectation of profit
- Integrated Offering Theory: SAFT + token delivery is one offering, not two separable transactions
- Exemption Skepticism: Reg D may not apply if SAFT holders are acquiring for resale rather than investment
- Decentralization Is Not a Defense: Even functional, decentralized tokens may be securities if the totality of circumstances shows investor expectation of profit from promoter efforts
Network Launch Triggers and Sufficient Decentralization
The critical moment in a SAFT agreement is when the trigger event occurs and tokens are delivered. Defining this trigger and achieving genuine decentralization is essential but difficult.
Defining the Network Launch Trigger
SAFTs typically include one or more of these trigger conditions:
Functional Network Trigger
Language: "Tokens will be delivered upon launch of the Network, which is deemed to occur when the Protocol is operational on mainnet and Users can engage in Transactions using Tokens."
Issues: What constitutes "operational"? Minimal viable product or full feature set? Who determines when this is met?
Decentralization Trigger
Language: "Tokens will be delivered when the Network achieves Sufficient Decentralization, meaning no single entity controls more than 20% of validator nodes and the Protocol can operate without reliance on the efforts of the Development Team."
Issues: How is decentralization measured? What metrics? What if it's never achieved?
Utility Trigger
Language: "Tokens will be delivered when Tokens have Functional Utility, meaning Tokens are required to access or use the Network Services and such Services are available to the public."
Issues: Is utility enough? Does it address expectation of profits from promoter efforts?
The "Sufficient Decentralization" Standard
The SEC has referenced "sufficient decentralization" as a factor in securities analysis, but has never provided clear metrics. Based on SEC statements and case law, relevant factors include:
| Decentralization Factor | More Decentralized | More Centralized |
|---|---|---|
| Node Distribution | Thousands of independent validators | Development team runs most nodes |
| Token Distribution | Widely distributed, earned through participation | Concentrated with team, investors, foundation |
| Protocol Updates | On-chain governance by token holders | Team controls upgrades |
| Development | Multiple independent teams | Single development company |
| Marketing | Organic community promotion | Team-funded marketing campaigns |
| Liquidity | Organic market development | Team provides or incentivizes liquidity |
Decentralization Timeline Reality
In my experience, true decentralization takes years, not months. Projects that promise token delivery within 6-12 months of SAFT sale are unlikely to achieve meaningful decentralization in that timeframe. This creates legal risk under the Telegram theory that tokens remain securities despite network launch.
Documenting Decentralization Progress
I advise clients to maintain detailed documentation showing decentralization efforts:
- Regular measurement of node distribution, geographic diversity, operator independence
- Token distribution metrics and vesting schedules
- Governance proposals and voting records
- Third-party development contributions
- Transition milestones from centralized to decentralized operations
Token Delivery Mechanics
The mechanics of token delivery from SAFT to investor wallet involve legal, technical, and compliance considerations.
Delivery Process Steps
- Trigger Determination: Development team (or independent party) certifies that network launch criteria have been met
- Investor Notification: SAFT holders notified of pending token delivery and any additional KYC/compliance requirements
- Updated KYC/AML: Re-verify investor identity, sanctions screening, eligibility (may have changed since SAFT sale)
- Wallet Verification: Investors provide and verify control of receiving wallet addresses
- Token Generation/Allocation: Tokens generated or allocated from reserves according to SAFT terms
- Transfer Restrictions Implementation: If tokens are securities, implement transfer restrictions (lockup smart contracts, whitelisting)
- Delivery Execution: Tokens transferred to investor wallets
- Vesting Implementation: If tokens vest over time, use smart contracts or manual release schedules
- Recordkeeping: Document delivery date, quantity, recipient, basis for tax and regulatory purposes
Vesting Structures
| Vesting Type | Structure | Use Case | Implementation |
|---|---|---|---|
| Immediate | 100% of tokens delivered at once | High confidence in network launch and stability | Simple transfer transaction |
| Cliff + Linear | 0% for X months, then linear release over Y months | Standard startup-style vesting (e.g., 1-year cliff, 3-year vest) | Vesting smart contract or periodic manual releases |
| Linear from Delivery | Tokens released in equal installments over time | Reduce sell pressure, align long-term incentives | Vesting contract or scheduled transfers |
| Milestone-Based | Tranches released upon achieving milestones | Tie token release to adoption metrics | Manual review and release (governance-controlled) |
Transfer Restrictions for Security Tokens
If delivered tokens are securities (likely under current SEC analysis), transfer restrictions must be implemented:
- 12-Month Holding Period: Rule 144 requires 12-month hold for Reg D securities (6 months for reporting companies)
- Smart Contract Lockups: Implement on-chain restrictions preventing transfers until holding period expires
- Whitelisting: Restrict transfers only to verified, compliant addresses
- Legend Requirements: Include securities legend in token metadata (if technically feasible)
- Transfer Agent: Consider using regulated transfer agent for securities token compliance
Unregistered Resales Risk
The Telegram case emphasized that unregistered resales by SAFT holders to the public constitute securities violations. If your tokens are securities, you must prevent SAFT holders from transferring to non-accredited investors until the holding period expires or registration occurs. Technical enforcement (smart contract restrictions) is more reliable than contractual restrictions.
Investor Rights and Protections
SAFTs provide limited investor protections compared to equity instruments. Understanding what rights investors do and do not have is critical.
Rights Typically Included in SAFTs
| Right | Description | Strength |
|---|---|---|
| Token Delivery | Contractual right to receive specified token quantity upon trigger event | Strong (enforceable contract right) |
| Information Rights | Quarterly or annual updates on development progress | Moderate (often not enforced) |
| Pro Rata Rights | Right to participate in future token sales at same terms | Moderate (depends on future offerings) |
| Most Favored Nation | If better terms offered to other SAFT purchasers, investor receives same | Strong (common provision) |
| Network Launch Transparency | Notice of when trigger event has occurred | Strong (triggers delivery obligation) |
Rights NOT Typically Included
- Equity Ownership: SAFT holders have no ownership stake in the development company
- Board Seats or Voting: No governance rights in the company (tokens may have governance rights post-delivery)
- Liquidation Preference: No priority claim on assets if company winds down
- Anti-Dilution: No protection if additional tokens are issued
- Veto Rights: No ability to block company decisions
- Redemption Rights: Generally no right to demand return of capital
Investor Protection Provisions to Negotiate
Sophisticated investors negotiate for enhanced protections:
Use of Funds Restrictions
Language: "Proceeds from SAFT sales will be used exclusively for development of the Protocol and Network infrastructure, and not for team compensation exceeding $X or for purposes unrelated to Network launch."
Value: Prevents misappropriation of funds; aligns interests with network success
Token Cap Provision
Language: "The total supply of Tokens will not exceed [X] tokens, and the Company will not issue additional tokens except through on-chain governance mechanisms after Network launch."
Value: Protects against dilution from excessive token issuance
Minimum Network Launch Criteria
Language: "Network launch will be deemed to occur only when (i) the Protocol is operational on mainnet with at least [X] independent validators, (ii) the Token has functional utility for [specific use case], and (iii) [other objective criteria]."
Value: Prevents premature token delivery before network is viable
Failure to Launch Remedy
Language: "If Network launch does not occur within [24/36] months of SAFT execution, Purchaser may elect to: (i) extend the deadline by [12] months, (ii) convert SAFT to equity in the Development Company at a $[X]M valuation cap, or (iii) receive a refund of [50-100]% of Purchase Amount."
Value: Provides exit if project fails or indefinitely delays; rarely included but highly valuable
Enforcement Challenges
SAFT investor rights are difficult to enforce:
- No Equity Stake: Investors cannot force company actions through board control
- Limited Remedies: Breach of SAFT typically results in damages action, not specific performance
- Offshore Entities: Many token issuers are offshore, making legal action expensive and uncertain
- Team Anonymity: Some projects have anonymous teams, making accountability impossible
- Asset Dissipation: If funds are misused, there may be no assets to recover
Tax Implications for Issuers and Investors
SAFT tax treatment is complex and uncertain, with significant implications for both projects and investors. The IRS has not issued specific guidance on SAFTs.
Tax Treatment for Issuers (Development Team/Foundation)
SAFT Sale Proceeds
- Likely Treatment: Advance payment for future property (tokens) or prepaid income
- Tax Consequence: May be taxable income upon receipt of SAFT proceeds (not deferred until token delivery)
- Alternative Argument: Treat as loan or deposit, recognizing income only upon token delivery
- Risk: IRS may assert immediate income recognition, creating tax liability with no offsetting deduction
Token Delivery
- If Income Recognized at SAFT Sale: Token delivery is not a second taxable event (already taxed)
- If Income Deferred to Delivery: Fair market value of delivered tokens is income at delivery
- Valuation Challenge: Determining FMV of tokens at delivery (no established market pre-listing)
Issuer Best Practices
- Engage tax counsel to determine income recognition timing
- Consider offshore entity for token issuance to minimize US tax
- Document FMV methodologies for token valuation at delivery
- Reserve funds for potential tax liabilities
- If US entity, consider Section 83(b)-style election arguments (though not directly applicable)
Tax Treatment for Investors
SAFT Purchase
- No Immediate Tax: Purchasing a SAFT is a capital outlay with no immediate tax consequence
- Basis: Investor's basis in the SAFT equals the purchase price
Token Receipt
The tax treatment when tokens are delivered is highly uncertain:
| Theory | Treatment | Tax Consequence | Likelihood |
|---|---|---|---|
| Property Exchange | SAFT exchanged for tokens; realized gain/loss | Tax on FMV of tokens received minus SAFT basis (likely short-term capital gain) | Moderate |
| Continuation | Token delivery is non-taxable continuation of SAFT investment | No tax until tokens sold; basis carries over from SAFT; holding period may continue | Low (IRS likely disagrees) |
| Ordinary Income | Tokens are compensation or ordinary income | FMV of tokens taxed as ordinary income at delivery | Low (for investors; higher for team grants) |
| Debt Repayment | SAFT is a loan repaid in tokens | Gain/loss on difference between FMV and basis | Very Low (substance over form issues) |
Token Sale by Investor
- If Taxed at Delivery: Basis is FMV at delivery; holding period starts at delivery; gain/loss on sale is capital
- If Continuation Theory: Basis is original SAFT purchase price; holding period may include SAFT holding period; gain/loss likely capital
- Holding Period: Short-term (held ≤1 year) vs long-term (held >1 year) determines capital gains rate
Tax Reporting Challenges
Investors face significant challenges:
- No Form 1099 typically issued for token delivery or sales (unless through US exchange)
- Uncertain cost basis and holding period
- FMV determination at delivery may be arbitrary (pre-listing)
- Vested tokens may create multiple taxable events (each vesting release)
- Potential wash sale issues if trading actively
I advise investors to work with a crypto-experienced CPA and maintain detailed records of SAFT purchase, token delivery, FMV at delivery, and all subsequent transactions.
Information Reporting Obligations
Under the Infrastructure Investment and Jobs Act (2021) and subsequent IRS guidance:
- Broker Reporting (1099-B): US-based platforms facilitating token sales must report to IRS (effective 2025+)
- Digital Asset Reporting: Projects may be deemed brokers if they facilitate SAFT or token transactions
- Foreign Account Reporting (FBAR): SAFT holders may need to report if SAFT or tokens held offshore (uncertain)
- Form 8938: Specified Foreign Financial Assets reporting may apply to offshore SAFTs/tokens
Best Practices and Red Flags
Based on enforcement patterns and industry experience, here are best practices for SAFT-based raises and red flags to avoid.
Best Practices for Issuers
- Treat SAFT as Security: Always comply with securities laws for the SAFT itself (Reg D 506(c), Reg S, or Reg A+)
- Accredited Investors Only: Limit SAFT sales to accredited investors with proper verification
- Detailed Offering Docs: Provide comprehensive disclosure of risks, including securities uncertainty, technology risk, team, use of funds
- Clear Trigger Criteria: Define network launch objectively with measurable milestones
- Implement Transfer Restrictions: Plan for 12-month lockup on delivered tokens if they are securities
- Control Marketing: Avoid investment-return language; focus on utility and technology
- Document Decentralization: Create and follow a credible decentralization roadmap
- Engage Counsel Early: Securities, tax, and blockchain counsel from the start
- KYC/AML Compliance: Implement at SAFT sale and again at token delivery
- Conservative Timeline: Build in time for genuine decentralization (18-36 months realistic)
Red Flags (Issuer Side)
These practices attract SEC attention and increase enforcement risk:
- Marketing tokens as investments with expected price appreciation
- Promising exchange listings or providing liquidity
- Anonymous or fake team members
- No functional product or credible development roadmap
- Excessive team token allocations or immediate liquidity for team
- Selling to non-accredited investors or failing to verify accreditation
- Targeting US retail through general solicitation without Reg A+ qualification
- Misuse of funds for team enrichment rather than development
- Unrealistic timelines (network launch in 3-6 months)
- Ignoring transfer restrictions on delivered tokens
Best Practices for Investors
- Legal Review: Have counsel review SAFT agreement before signing
- Team Due Diligence: Verify team identity, experience, and track record
- Technical Assessment: Review code (if available), whitepaper, and development progress
- Realistic Timeline: Assume 2-3x longer than projected for network launch
- Securities Assumption: Plan for tokens to be securities requiring 12-month hold
- Tax Planning: Consult tax advisor on likely treatment and reporting obligations
- Allocation Sizing: SAFT investments are high-risk; size accordingly
- Negotiate Protections: Seek enhanced terms (use restrictions, failure-to-launch remedies)
- Document Everything: Maintain records for tax and legal purposes
- Monitor Progress: Track development and hold team accountable to milestones
Red Flags (Investor Side)
Warning signs that a SAFT investment may be problematic:
- Team refuses to provide identities or backgrounds
- Vague or technically implausible whitepaper
- No code repository or development activity
- Unrealistic promises of guaranteed returns or listing prices
- Excessive focus on token price rather than utility
- Pressure to invest quickly without due diligence time
- Offering to non-accredited investors without proper registration
- Offshore entity with no substance or accountability
- No clear network launch criteria or indefinite timeline
- Large team allocation with immediate vesting
Key Template Provisions
Here are essential provisions that should be included in a SAFT agreement, with explanations of their purpose.
1. Purchase and Sale of SAFTs
Provision: "Subject to the terms and conditions of this Agreement, Purchaser agrees to purchase from the Company, and the Company agrees to sell to Purchaser, a right to certain units of the Tokens (the 'SAFT'), for the Purchase Amount set forth on the signature page."
Purpose: Core contractual obligation; defines what is being bought and sold
Key Terms to Specify: Purchase Amount, number of tokens or formula for calculating quantity, timing of payment
2. Network Launch and Token Delivery
Provision: "Upon the occurrence of the Network Launch (as defined below), the Company shall deliver to Purchaser the number of Tokens equal to [Purchase Amount / Token Price] [or other formula]. 'Network Launch' means the date on which: (i) the Protocol is operational on mainnet, (ii) Tokens have functional utility for accessing Protocol services, (iii) the Network has at least [X] independent validators, and (iv) the Company has provided notice to Purchasers of Network Launch."
Purpose: Defines trigger event and delivery obligation; must be specific and measurable
Key Terms to Specify: Objective launch criteria, token quantity calculation, delivery timeline after trigger
3. Vesting and Lockup
Provision: "Tokens delivered hereunder shall vest over [X] months following Network Launch according to the following schedule: [schedule]. Unvested Tokens may not be transferred. Vested Tokens shall be subject to a lockup period of [12] months from Network Launch, during which Tokens may not be sold, transferred, or pledged except as permitted by applicable securities laws."
Purpose: Implements vesting for alignment; ensures compliance with securities transfer restrictions
Key Terms to Specify: Vesting schedule, lockup period, exceptions (if any)
4. Representations and Warranties - Purchaser
Provision: "Purchaser represents and warrants that: (i) Purchaser is an 'accredited investor' as defined in Rule 501 of Regulation D, (ii) Purchaser is acquiring the SAFT for Purchaser's own account for investment purposes and not with a view to resale or distribution, (iii) Purchaser understands the SAFT and Tokens are securities subject to transfer restrictions, (iv) Purchaser has sufficient knowledge and experience to evaluate the risks of this investment."
Purpose: Establishes securities exemption compliance; protects company from purchaser claims
Key Terms to Specify: Accredited investor status, investment intent, acknowledgment of risks
5. Representations and Warranties - Company
Provision: "Company represents and warrants that: (i) Company is duly organized and validly existing, (ii) Company has the authority to enter into this Agreement and issue the SAFT and Tokens, (iii) the execution and performance of this Agreement will not violate any law or agreement, (iv) Company has provided Purchaser with materially complete and accurate information regarding the Company and the Network."
Purpose: Provides investor with contractual recourse if disclosures were false or incomplete
Key Terms to Specify: Authority, disclosure accuracy, no conflicts
6. Use of Proceeds
Provision: "Company agrees to use proceeds from SAFT sales primarily for development of the Protocol and Network infrastructure. Company may use proceeds for team compensation, marketing, legal and compliance, and working capital, but not for purposes unrelated to the Network."
Purpose: Limits misuse of funds; aligns interests
Key Terms to Specify: Permitted uses, restrictions on team compensation or distributions
7. Securities Law Compliance
Provision: "Purchaser acknowledges that: (i) the SAFT and Tokens have not been registered under the Securities Act or any state securities laws, (ii) the SAFT and Tokens are being offered pursuant to exemptions from registration, (iii) Purchaser may not transfer the SAFT or Tokens except in compliance with applicable securities laws, including Rule 144 holding period requirements."
Purpose: Ensures purchaser understands securities status and transfer restrictions
Key Terms to Specify: Securities status, exemptions relied upon, transfer restrictions
8. Risk Disclosures
Provision: "Purchaser acknowledges the following risks: (i) the Network may never launch, in which case Purchaser may lose entire investment, (ii) delivered Tokens may have no market value or utility, (iii) regulatory treatment of Tokens is uncertain and adverse regulation could impact value, (iv) technology risks including smart contract vulnerabilities, (v) liquidity risk and potential inability to sell Tokens."
Purpose: Comprehensive risk disclosure protects company from fraud claims
Key Terms to Specify: All material risks specific to the project
9. Information Rights
Provision: "Company shall provide Purchaser with [quarterly/annual] updates regarding development progress, including materially significant developments, financial information (if applicable), and anticipated timeline to Network Launch."
Purpose: Keeps investors informed; allows monitoring of progress
Key Terms to Specify: Frequency of updates, type of information provided
10. Termination and Failure to Launch
Provision: "[Optional, rarely included] If Network Launch has not occurred within [36] months of the date of this Agreement, Purchaser may elect to: (i) extend the deadline by [12] months, (ii) convert this SAFT to equity in the Company at a valuation cap of $[X]M, or (iii) receive a refund of [percentage]% of the Purchase Amount from available Company funds."
Purpose: Provides exit if project indefinitely delays or fails; highly investor-favorable
Key Terms to Specify: Timeline trigger, available remedies, refund mechanics
Alternatives to SAFTs
Given the legal uncertainty around SAFTs, many projects consider alternative fundraising structures.
Alternative 1: Direct Equity Raise
- Structure: Sell equity (priced round or SAFE) in the development company; distribute tokens later through airdrop, governance decision, or separate event
- Pros: Clear securities treatment; familiar to all VCs; no Telegram-style integrated offering risk
- Cons: Investors get equity not tokens (may not want equity exposure); token distribution later is uncertain
Alternative 2: Revenue Share Agreement
- Structure: Investors provide capital in exchange for percentage of protocol fees or revenue (not tokens)
- Pros: Aligns with actual protocol success; may avoid securities classification (uncertain)
- Cons: Likely still a security (investment contract); complex tax treatment; requires protocol revenue model
Alternative 3: Post-Launch Token Sale
- Structure: Bootstrap development or raise equity, then sell tokens only after network is fully functional and decentralized
- Pros: Strongest argument that tokens are not securities (no reliance on promoter efforts); avoids Telegram integrated offering theory
- Cons: Requires alternative funding source for development; fewer buyers for functional tokens vs. discounted pre-sales
Alternative 4: Reg A+ Token Offering
- Structure: Qualify token sale under Reg A+ as a securities offering; tokens are freely tradeable upon qualification
- Pros: Can sell to retail investors; tokens liquid immediately; fully compliant with SEC
- Cons: Expensive ($250K-$500K+); time-consuming (4-8 months); ongoing reporting obligations; SEC may not qualify token offerings