SAFT Agreements: Structure, Risks, and When Not to Use One

Whether a SAFT protects you depends not on the name of the instrument but on the structure of the offering, the nature of the token, and whether the entire scheme satisfies the Howey investment-contract test at the time money changes hands.

‍

How a SAFT Works

The structure has three moving parts. An investor — qualified in the US under Rule 506(c) of Regulation D as an accredited investor — pays a lump sum into the issuing entity at a discount to the anticipated public sale price. In exchange, the issuer delivers tokens once two conditions are met: the network is launched and the tokens are "functional." The agreement is itself treated as a security. The issuer sells it under a Reg D exemption, files a Form D with the SEC, and restricts resale under Rule 144. The theory, borrowed from the Protocol Labs / Cooley whitepaper of October 2017, is a two-step analysis: the SAFT is a security today; the functional utility token delivered at network launch is not, because the investor's profit expectation derives from using the token, not from the issuer's managerial efforts.

The economics follow that structure closely. The investor receives a discount — typically 20 to 50 percent off the expected public sale price, plus a pro-rata cap on dilution — in exchange for bearing the development risk. Vesting or lockup schedules govern delivery: some SAFTs deliver all tokens at network launch; others deliver tranches over 12 to 24 months from that date. The issuer gets working capital before the token exists, which is the instrument's commercial appeal.

What the SAFT contains

A SAFT defines the purchase amount, the token allocation formula (often based on the ratio of the investor's payment to the total raise, applied against a token pool), the triggering events for delivery (network launch, security audit, mainnet deployment), and the conditions under which the agreement terminates — most importantly, when the issuer has abandoned the project or returned funds. Risk disclosures acknowledge that no tokens may ever be delivered if development fails, and that no refunds are available absent a termination trigger. The investor acknowledges accredited investor status and that the right being acquired is a security. Standard representations cover no-registration-in-the-buyer's-jurisdiction, no public offering, no advertising.

The original thesis and where it held

The 2017 whitepaper argued that functional utility tokens should not be investment contracts under Howey because a buyer motivated to use a service, rather than to profit from a developer's efforts, is not an investor in the Howey sense. The SAFT existed to handle the pre-functional period. When a token project kept a tight accredited-investor list and genuinely delivered a functioning decentralised network, the SEC was less likely to pursue secondary-market trading as a securities transaction. Several SAFT-funded projects of 2017 to 2019 launched, delivered tokens, and operated without enforcement. The instrument held in narrowly defined circumstances: small private rounds, genuine decentralisation at launch, no marketing to retail investors during the SAFT period.

‍

The Howey Test Applied to a SAFT

The Howey test asks four questions. Is there an investment of money? In a common enterprise? With a reasonable expectation of profit? From the efforts of others? In a SAFT, the first three elements are satisfied on their face. The investor pays cash; it pools with funds from other investors in a shared development enterprise; the discount to the anticipated public price makes profit expectation explicit. The legal contest in every SAFT enforcement action has been fought on the fourth prong: whether profit depends on the issuer's ongoing efforts.

Courts do not apply Howey to the SAFT in isolation. They look at the "economic reality" of the entire fundraising scheme, including the intended distribution path after token delivery. If the issuer plans to sell tokens to the public after the SAFT closes — which is almost always the case — courts have treated the SAFT purchasers and the public sale as a single, integrated offering. The accredited investors, under that analysis, become underwriters, not end-users: they take tokens at a discount and resell into the public market. Their profit does not come from using the network. It comes from the issuer's success in building it and the public's willingness to buy at a higher price.

The integration doctrine

The integration doctrine aggregates formally separate offerings if they are part of a single plan of financing, offered to satisfy the same general need for capital, or offered at the same time. In the SAFT context, the private Reg D SAFT sale and the subsequent public token distribution have been found integrated in two different SDNY decisions. Integration analysis looks at whether the SAFT purchasers agreed to hold tokens for investment, whether the issuer marketed the token publicly during the SAFT period, and whether the gap between SAFT closing and public distribution was long enough to break the connection. A SAFT that closes in January and a token launch that begins in October of the same year provides very little insulation.

Reasonable expectation of profits

Courts also examine what purchasers were actually told. In SEC v. Kik Interactive Inc. (SDNY 2020), Kik's CEO and other company representatives told potential investors that Kin would appreciate in value as the ecosystem grew. The marketing of the potential return, even to accredited investors, weighed heavily in the court's finding that purchasers were motivated by profit expectation, not by a desire to use Kik's messaging service. A SAFT prefaced by investor materials emphasising price appreciation or the upcoming public sale price amplifies the reasonable-expectation-of-profits analysis.

‍

The Enforcement Cases That Shaped the Risk Map

Two cases define the boundary conditions. They involve projects that raised through SAFTs to accredited investors in compliance with Reg D, delivered tokens following network launch, and were still found to have conducted unregistered securities offerings.

SEC v. Telegram Group Inc. (SDNY 2020)

Telegram raised approximately $1.7 billion from 171 initial purchasers — including 39 US purchasers — through SAFTs filed under Reg D in 2017 and 2018. The Grams were to be delivered on launch of the TON Blockchain by October 31, 2019. In October 2019, the SEC obtained a temporary restraining order. In March 2020, the court granted a preliminary injunction preventing distribution. The court's analysis treated the SAFT and the intended public distribution of Grams as a single integrated offering. It found the initial purchasers were motivated by their ability to resell Grams into the public market, not by any utility function of the token. It found Telegram would remain the "guiding force" of the TON ecosystem even after launch, satisfying the "efforts of others" prong. Telegram settled in June 2020, agreeing to disgorge $1.224 billion and pay an $18.5 million civil penalty, and abandoned the project. The SDNY opinion has been cited in every subsequent SAFT-related legal analysis.

SEC v. Kik Interactive Inc. (SDNY 2020)

Kik's Kin token offering began with a private SAFT pre-sale to 50 accredited investors, raising approximately $100 million, and continued with a public Token Distribution Event beginning September 12, 2017. The court found the two phases to be a single integrated offering: Kik designed the pre-sale to fund development, with the TDE immediately following. On summary judgment in September 2020, the court found Kin was an investment contract throughout: Kik's "essential role" in driving the ecosystem meant holders depended on Kik's entrepreneurial and managerial efforts to realise any return. The final judgment required a $5 million civil penalty, a permanent injunction against future securities-law violations, and a three-year obligation to notify the SEC before engaging in digital asset transactions. The Kik case is the first to go through full summary-judgment proceedings on the SAFT framework, and its analysis of the TDE as part of the SAFT scheme has informed every structural review since.

‍

What SEC Release 33-11412 Changes for SAFTs

The joint SEC/CFTC interpretive release of March 17, 2026 (effective March 23, 2026, 91 Fed. Reg. 55) is the first Commission-level interpretation to address SAFTs directly. Prior to this release, practitioners relied on the 2019 staff Framework, which the release formally supersedes.

The release classifies crypto assets into five categories — digital commodities, digital collectibles, digital tools, stablecoins, and digital securities — and explains how the Howey investment-contract analysis applies to each. On SAFTs specifically, the release treats them as "delayed-delivery offerings" in which the non-security crypto asset at the end of the pipeline becomes subject to an investment contract at the time the SAFT is entered into — not at the time of token delivery. The sale is complete for securities-law purposes when the SAFT is signed.

Upon delivery, tokens can separate from the investment contract and cease being subject to securities laws, but only if the issuer has already fulfilled its essential managerial efforts at the moment of delivery. The release gives an example: if the issuer has publicly disclosed completion of all material development milestones before tokens arrive in investor wallets, those tokens may no longer carry investment-contract status. If material managerial efforts are still ongoing at delivery — protocol upgrades, ecosystem development, key partnerships — the tokens remain subject to the investment contract until those efforts are either completed or publicly abandoned.

What this means in practice: a SAFT-based raise for a token that will eventually qualify as a digital commodity (a sufficiently decentralised network) can work within the existing Reg D exemption, provided the issuer tracks the decentralisation milestones carefully and can document that essential efforts were complete before delivery. A SAFT for a token where the issuer intends to continue as a central actor after launch does not lose its investment-contract status on delivery. The release does not create a new exemption; it provides a more precise articulation of conditions for tokens to graduate out of securities status.

‍

The Structure of the Agreement

A SAFT typically contains five substantive sections. Understanding what each clause does clarifies where the legal risk concentrates.

Key terms and the token pool

The "Token Amount" clause governs how many tokens the investor receives. The common formulation is: multiply the investor's purchase amount by the conversion ratio, which equals the investor's purchase amount divided by the total amount raised in the SAFT round, applied against a defined token pool allocation. Variable formulas — where the number of tokens adjusts to the public sale price — are commercially common but create valuation uncertainty for tax purposes. Fixed-formula SAFTs, where the investor knows exactly how many tokens they will receive, are generally simpler on the tax side.

Network launch trigger and termination events

The trigger for delivery is usually the "Network Launch" date: the date on which the network first becomes available to the public. SAFTs may specify minimum functionality conditions (a working mainnet, a security audit pass, a minimum number of active nodes). If the network launch never occurs, the SAFT terminates — typically without a refund obligation, because the investor accepted technology risk at the time of signing. This is the enforceability question if development fails: a SAFT is an unsecured obligation against an issuing entity that may have no assets left. Investors are general unsecured creditors.

Representations and restrictions

The investor represents that they are an accredited investor, that they are acquiring the right to tokens as a security for investment purposes and not for immediate resale, and that they understand the restrictions on transfer. The issuer represents that it will file a Form D, that the SAFT itself is a valid Reg D 506(c) offering, and that it will exercise best efforts to cause the network to launch. Restrictions on the SAFT itself (not the underlying tokens) prohibit transfer without SEC registration or an applicable exemption. These restrictions are what the Telegram court examined when it found the restrictions inadequate — the Grams were to be delivered without restrictive legends, enabling immediate resale.

‍

MiCA and SAFTs Involving EU Participants

If any purchaser in the SAFT round is a person located in a European Union member state, MiCA's classification framework applies from the point of offer, regardless of where the issuer is incorporated.

MiCA Regulation (EU) 2023/1114 applies fully to crypto-asset offers in the EU since December 30, 2024. For tokens that are not asset-referenced tokens (ARTs) or e-money tokens (EMTs), Title II governs. A public offer of Title II tokens requires a whitepaper notified to the relevant national competent authority at least 20 working days before the offer. The key exemptions under Article 4(2) are: offers addressed solely to qualified investors (as defined in the Prospectus Regulation), offers to fewer than 150 persons per Member State acting on their own account, and offers with total EU consideration below EUR 1,000,000 over 12 months. A SAFT round that limits EU participation to qualified investors can use the Article 4(2)(b) exemption and avoid the whitepaper obligation for the private placement.

The Art. 4(3)(c) utility-token exemption — which covers tokens providing access to a good or service already in existence or in operation — does not apply to SAFTs. A pre-launch SAFT token, by definition, represents a right to a good that does not yet exist. The utility token whitepaper exemption is not available for the SAFT instrument.

One further complication: even if the private SAFT round qualifies for an Art. 4(2) exemption, if the token is later admitted to trading on an EU crypto-asset service provider platform, the admission triggers a full whitepaper obligation. The private-placement exemption does not carry through to the trading admission stage. Founders planning an EU listing after a private SAFT round should treat the whitepaper as a post-SAFT deliverable, not an afterthought.

For a fuller analysis of how MiCA applies to token projects at every stage, the Medici Expert insight on what MiCA means for every company provides the wider framework.

‍

VARA and SAFTs in the UAE

If a SAFT involves a UAE-based issuer or distribution to investors located in the Emirate of Dubai, VARA's Virtual Asset Issuance Rulebook (effective June 19, 2025, version VER20250519) applies.

VARA categorises virtual asset issuances into three tiers. Category 1 covers fiat-referenced virtual assets (FRVAs) and asset-referenced virtual assets (ARVAs). Issuing these requires a VARA licence obtained before any issuance, plus prior VARA approval of a whitepaper. If the token that will eventually be delivered under a SAFT is an FRVA — a token that purports to maintain a stable value relative to a fiat currency — or an ARVA — a token backed by a basket of real-world assets, commodities, or other reference assets — the SAFT round triggers Category 1 and the issuer must be VARA-licensed before accepting the first investment.

Category 2 covers all other virtual assets: utility tokens, governance tokens, project tokens not fitting the FRVA or ARVA definitions. Category 2 issuances do not require a VARA licence, but all distribution must occur through or by a licensed distributor. A SAFT round in Dubai for a Category 2 token still needs to route through a VARA-licensed entity for placement and distribution.

The practical implication for founders: before executing a SAFT with UAE-based investors, determine whether the token to be delivered is an FRVA, ARVA, or neither. If the token design has not been finalised, or if the reserve structure could shift the token toward ARVA status during development, the Category 1 licence should be obtained before the SAFT closes, not during. VARA has authority to re-categorise a token if its nature changes during the issuance lifecycle, and Rule I.C.3 of the Issuance Rulebook requires the issuer to comply with the new category requirements before any change takes effect.

Medici Expert's digital assets practice covers VARA structuring, whitepaper preparation, and licence application support for UAE-based and Dubai-targeting token projects.

‍

Tax Treatment

The US tax treatment of SAFTs rests on general property and forward-contract principles, because the IRS has issued no dedicated SAFT guidance. The working framework, drawn from the tax literature and the San Jose State University Tax Institute (January 2026), is as follows.

Investor-side treatment

Entering the SAFT is not a taxable event for the investor. The SAFT is treated as an executory forward contract: a prepayment against future delivery of property. The investor's holding period for capital gains purposes begins when tokens are delivered to their wallet with actual dominion and control — not when the SAFT is signed and not while tokens are held in custody by the issuer or a third party without the investor's full control. Where delivery occurs in tranches (common in SAFTs with vesting schedules), each tranche starts a separate holding-period clock. Tokens held for more than one year from delivery receive long-term capital gains treatment on sale; tokens sold within a year of delivery attract short-term rates. The investor's cost basis in the delivered tokens is the purchase price paid under the SAFT allocated to that tranche.

Issuer-side treatment

Issuers of SAFT-funded tokens face a less settled position. The majority view in the practitioner literature is that a SAFT is an executory forward contract from the issuer's perspective as well: proceeds received at signing are not income until delivery. On delivery, the issuer recognises income equal to the fair market value of the tokens delivered. The basis issue is acute when tokens have no established market at the time of delivery. Issuers should document a defensible valuation method and coordinate it with their accounting treatment under ASC 350-60, which excludes issuer-created tokens from its scope — leaving general principles as the governing framework.

Neither investors nor issuers should treat the SAFT tax position as settled law. The IRS has not issued a revenue ruling on SAFTs. Tax counsel familiar with digital asset transactions should review the structure before execution. Medici Expert's compliance and risk practice includes documentation support for tax-position disclosures in fundraising contexts.

‍

When a SAFT Carries Heightened Securities Risk

The risk profile of a SAFT is not uniform. Certain factual patterns substantially increase the probability that a SAFT-based raise will be treated as an unregistered securities offering or that the tokens delivered under it will retain investment-contract status after delivery.

When the token is already a security by its economic design

A SAFT does not transform a security into a non-security. If the token to be delivered has the characteristics of a digital security — it represents ownership rights, profit-sharing rights, or voting rights analogous to a corporate share; or it is a financial instrument under MiFID II for EU purposes — the SAFT wrapper does not cure that classification. The two-step thesis (SAFT = security now; token = non-security later) only has a chance of working for tokens that would genuinely qualify as digital commodities or digital tools on the release-33-11412 taxonomy once the network is fully functional.

When non-accredited investors are included in the SAFT round

Reg D 506(c) requires all purchasers to be accredited investors and requires the issuer to take reasonable steps to verify accreditation. Including a single non-accredited investor collapses the 506(c) exemption for the entire offering. Rule 506(b) allows up to 35 non-accredited sophisticated investors, but prohibits general solicitation — commercially incompatible with how most token projects market during development. Weak investor verification eliminates the exemption.

When the public sale is integrated with the SAFT round

Telegram and Kik both illustrate the integration problem: the private SAFT round and the public distribution, separated by months, were treated as a single offering because the accredited investors were buying rights to tokens they planned to resell immediately after network launch. Safeguards that courts have identified as relevant — though not dispositive — include lockup periods of at least six to twelve months after token delivery, restrictive legends on the tokens themselves (not just the SAFT), documentation that purchasers acquired tokens for use rather than investment, and a meaningful gap in time and purpose between the SAFT round and any public distribution. None of these guarantees a different outcome; they are factors the SEC and courts weigh.

When the issuer's managerial efforts are essential and ongoing

Under the 33-11412 framework, tokens stay subject to an investment contract for as long as the issuer's essential managerial efforts remain incomplete. A project where the founding team controls protocol upgrades, treasury management, validator set composition, and the primary user-acquisition strategy cannot plausibly claim that tokens graduated out of investment-contract status on network launch. The decentralisation required to satisfy the "efforts of others" prong on exit must be genuine. Governance token distributions to a wide community, on-chain upgrade voting with meaningful distribution, and multiple independent development teams are the structural markers courts look for.

‍

When Not to Use a SAFT

The SAFT is not a universal pre-token fundraising instrument. There are specific scenarios where it fails as a legal tool, creates more regulatory exposure than it resolves, or is simply unavailable.

The SAFT fails when the token will be a security on delivery. If the token is designed to confer profit rights, ownership interest, or investment-contract obligations at network launch — or if the issuer has no credible plan for genuine decentralisation within a defined post-launch period — there is no functional utility at the end of the pipeline. The two-step premise collapses. The correct instrument for a planned security is a security: a Simple Agreement for Future Equity (SAFE) adapted for the token context, or a token-warrant structure with explicit securities-law compliance from the start.

The SAFT is unavailable when the issuer needs retail investors now. Reg D 506(c) is accredited-investors only. A project that wants participation from retail investors — including in jurisdictions where no equivalent accredited-investor category exists — cannot use a SAFT without registration or a jurisdiction-specific exemption. Crowdfunding exemptions under Regulation Crowdfunding or Regulation A+ exist for US retail raises but impose their own disclosure, offering-size, and issuer-eligibility constraints, and neither maps directly onto the SAFT structure.

The SAFT is the wrong instrument when the issuer is in the EU and needs a public offering. MiCA's whitepaper and notification regime applies to public offers in the EU regardless of the instrument's name. A SAFT to unqualified EU retail investors is not exempt simply because it is called a SAFT; the whitepaper obligation attaches. The correct approach for a public EU raise is a MiCA-compliant whitepaper round — not a SAFT.

The SAFT is ill-suited when the network launch timeline is genuinely uncertain. A SAFT that never triggers — because the network never launches — leaves investors as unsecured creditors of an entity with no assets. That outcome is commercially devastating and potentially an independent regulatory problem if the pre-launch marketing amounted to an unregistered securities offer. If a project cannot project a credible launch window with defined technical milestones and funded reserves sufficient to reach that window, the investor protection case for using a SAFT over a direct equity instrument weakens substantially.

Finally, a SAFT creates friction when the token project anticipates a Category 1 VARA-licensed structure in Dubai or an ARVA/FRVA classification from the outset. The VARA Category 1 licence must exist before the first investment is accepted. Running a SAFT while the licence application is pending, on the assumption that a licence will be obtained in time, is a timing risk that VARA's rules do not accommodate.

Structuring token fundraising that works for your specific token design, investor base, and jurisdictional footprint requires analysis beyond the instrument name. Medici Expert's digital assets team works with founders on the full documentation stack — from classification analysis and investor qualification to VARA and MiCA mapping.

‍

Cross-Border Enforceability

A SAFT is a private contract whose enforceability depends on governing law, jurisdiction, and whether the issuing entity has reachable assets. Most SAFTs specify New York or Delaware law and US courts. For offshore issuers — Cayman Islands foundations and BVI companies are the common vehicles — governing law clauses point to a US court, but enforcing a US judgment against a Cayman or BVI entity requires a separate recognition proceeding that is neither automatic nor guaranteed.

Cross-border enforcement also carries an independent regulatory dimension. A SAFT sold into Singapore without exemption under the Securities and Futures Act, or into the EU without MiCA compliance, creates regulatory exposure in those jurisdictions regardless of what the contract says about governing law. The choice-of-law clause does not govern securities classification in the investors' home markets.

Restricting distribution to jurisdictions where the offering is clearly exempt — through geo-blocking, investor certification of residency and accreditation status, and jurisdiction-specific legal opinions — is the operational foundation. Building genuinely enforceable compliance rules for crypto projects requires that legal-infrastructure thinking applied to the fundraising instrument from the start.

‍

Sources

• SEC Release 33-11412 (effective March 23, 2026): https://www.sec.gov/rule-release/33-11412 — dual: 91 Fed. Reg. 55 (March 23, 2026): https://www.govinfo.gov/content/pkg/FR-2026-03-23/html/2026-05635.htm
• SEC v. Telegram Group Inc. and TON Issuer Inc., No. 19-cv-09439 (SDNY). SEC complaint (Oct 2019): https://www.sec.gov/files/litigation/complaints/2019/comp-pr2019-212.pdf; SEC press release 2019-212; preliminary injunction March 24, 2020
• SEC v. Kik Interactive Inc., No. 19-cv-5244 (SDNY Sept. 30, 2020). Summary judgment opinion: https://static.reuters.com/resources/media/editorial/20201001/secvkik--SJopinion.pdf; SEC press release 2020-262: https://www.sec.gov/newsroom/press-releases/2020-262
• VARA Virtual Asset Issuance Rulebook (VER20250519, effective June 19, 2025): https://rulebooks.vara.ae/rulebook/virtual-asset-issuance-rulebook — Rule I.C (categories): https://rulebooks.vara.ae/rulebook/c-va-issuance-categories-and-prior-requirements
• MiCA Regulation (EU) 2023/1114, Arts 4(2), 4(3): https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:02023R1114-20240109
• Original SAFT whitepaper (Batiz-Benet, Santori, Clayburgh, Protocol Labs / Cooley, Oct 2017): https://saftproject.com
• San Jose State University Tax Institute — "Digital Assets and Its Numerous Instruments Governing Formation and Operation" (January 2026): https://www.sjsu.edu/taxinstitute/docs/2026%20BTC%20DA%20Instruments_1-30-26.pdf
• SEC/CFTC practitioner analysis — Buzko Krasnov, "The SEC & CFTC Joint Crypto Release" (2026): https://www.buzko.legal/content-eng/the-sec-cftc-joint-crypto-release-a-practitioners-guide-to-the-new-asset-classification-framework

‍

FAQ

Is a SAFT itself a security?

Yes, under US law. A SAFT is treated as an investment contract sold to accredited investors under Regulation D 506(c). The issuer files a Form D and the SAFT itself carries resale restrictions. Telegram and Kik confirmed this. The two-step thesis — SAFT is a security now; delivered token is not — can hold only if the delivered token genuinely exits investment-contract status at delivery. The SAFT itself never does.

What makes a SAFT round more likely to attract SEC enforcement?

The highest-risk patterns are: marketing materials that emphasise price appreciation or resale profit to accredited investors; a short gap between SAFT closing and public token distribution; accredited investors receiving tokens without transfer restrictions and promptly selling into the public market; and an issuer that remains the central operational actor after network launch. Each of those factors pushes toward a finding that the entire scheme, including the private SAFT round, was an integrated unregistered securities offering.

Does SEC Release 33-11412 make SAFTs safer?

It provides more precision, not blanket safety. The release confirms that a SAFT-funded token becomes subject to an investment contract at the time the SAFT is signed, and that tokens can separate from that investment-contract status only if the issuer's essential managerial efforts are complete at or before delivery. For issuers that can genuinely document decentralisation milestones and publicly disclose their completion before tokens arrive in investor wallets, the release provides a clearer path to exit. For issuers whose ongoing role is central to the project's value, the analysis is unchanged: the tokens remain subject to the investment contract after delivery.

Can a SAFT work for EU investors under MiCA?

It can work within a limited framework. The Article 4(2) exemptions allow a private placement to qualified EU investors (as defined in the Prospectus Regulation) without a MiCA whitepaper. A SAFT round limited to qualified EU investors, properly documented, avoids the whitepaper obligation for the placement itself. However, if the token is later admitted to trading on an EU crypto-asset service provider's platform, the whitepaper obligation re-attaches. The Art. 4(3)(c) utility-token whitepaper exemption — for tokens providing access to a service already in operation — does not apply to a pre-launch SAFT token by definition.

What are the tax obligations when tokens are delivered under a SAFT?

For investors, the taxable event is delivery: the holding period for capital gains begins when tokens arrive in the investor's wallet with full dominion and control. Where tokens vest or are delivered in tranches, each tranche begins a separate holding period. The investor's basis is the portion of the original SAFT purchase price allocated to the delivered tranche. There is no tax on signing the SAFT. For issuers, the dominant practitioner view treats the SAFT as an executory forward contract: proceeds are deferred until delivery, at which point income is recognised. No dedicated IRS guidance exists; issuers should document their chosen tax position with counsel.

When does a VARA licence become required for a SAFT in Dubai?

If the token to be delivered under the SAFT will be a Fiat-Referenced Virtual Asset (an FRVA, essentially a fiat stablecoin) or an Asset-Referenced Virtual Asset (an ARVA, backed by commodities, real estate, or a basket of reference assets), the issuer must obtain a VARA Category 1 licence before accepting any investment. The licence must exist at the time of the SAFT closing, not at the time of token delivery. For tokens that do not fall into the FRVA or ARVA categories, no issuer licence is required, but all distribution must occur through a VARA-licensed distributor.

What happens if the network never launches?

The SAFT terminates without a refund obligation in most standard forms, leaving investors as general unsecured creditors of the issuing entity. Telegram refunded approximately $1.2 billion, but that was compelled by an SEC consent order, not a contractual right under SAFT terms. Investors have no guaranteed downside protection unless the agreement specifically provides a refund trigger, and enforcement of that trigger depends on the solvency and domicile of the issuer.

Is a SAFT the right instrument for a token that will also be listed on US exchanges?

Not unless the token will genuinely exit investment-contract status before listing. A token listed on a US exchange while it still carries investment-contract status would require registration or an exemption for the trading itself. Under Release 33-11412, tokens cease to be subject to an investment contract only when the issuer's essential managerial efforts are publicly complete. Most early-stage tokens do not meet that standard at the point of exchange listing. The intersection of SAFT delivery, listing timing, and the 33-11412 decentralisation analysis should be reviewed by counsel before any exchange application is filed.