What Is a SAFT Agreement? Definition and How It Differs From a SAFE
A SAFT agreement is a contract giving an investor the right to receive tokens once a network launches. Learn how a SAFT works and how it differs from a SAFE.
A SAFT agreement, short for Simple Agreement for Future Tokens, is a contract in which an investor provides capital now in exchange for the right to receive tokens at a future date, usually once a network launches or the tokens become transferable. Early-stage token projects use a SAFT agreement to raise pre-launch capital from accredited and institutional investors before there is a live network to sell tokens against.
A SAFT agreement is a financing structure, not a product. It moves capital in ahead of a token, and it does nothing for a project that has no real business underneath. Get the model wrong and no instrument fixes it. This post covers what a SAFT agreement contains, how it works step by step, how it compares to a SAFE, and where securities law fits.
#What Is a SAFT Agreement?
A SAFT agreement is a contract, not a token. The full name, Simple Agreement for Future Tokens, describes the mechanism precisely: the investor buys a contractual right to future tokens, and delivery depends on a triggering event that has not happened yet.
The instrument was modeled on Y Combinator's SAFE, the Simple Agreement for Future Equity, and adapted for token fundraising by Protocol Labs and CoinList around 2017. The goal was to give token projects a clean way to raise from accredited investors before a network existed, without selling tokens that did not yet function.
This is what separates a SAFT from buying tokens on an exchange. A token purchase on a decentralized or centralized exchange is immediate and public. A SAFT agreement is a pre-launch, off-exchange, negotiated instrument, often described as a future token agreement because the token itself does not change hands at signing. The investor holds a claim, and the tokens arrive later.
#How a SAFT Agreement Works
A SAFT agreement moves through a defined sequence. The mechanics are straightforward to describe, even though the negotiation behind each term is not.
Draft the terms. The project defines the valuation cap or discount rate, the token allocation, and the triggering event that will release tokens.
Sign and fund. The investor and the project sign, and the investor wires capital, commonly in USD or a stablecoin, at signing.
Hold the claim. During the interim period, the project uses the capital and the investor holds a contractual claim. No tokens sit in the investor's hands yet.
Trigger the delivery. A defined event occurs, usually a mainnet launch, a token generation event (TGE), or a contractual long-stop date. Tokens are delivered per the agreed conversion terms.
Begin vesting. Any lockup or vesting terms start at delivery. Those terms are separate from the SAFT itself.
The valuation-cap and discount mechanics mirror the SAFE. That shared structure is the reason the two instruments get compared so often, and it is the bridge into the next section. One caution: a SAFT agreement fixes the terms of conversion, not the market value of the token at delivery. What the token is worth when it lands is a separate question the contract does not answer.
#SAFT vs SAFE: Key Differences
The comparison comes up because the SAFT borrowed its structure from Y Combinator's SAFE. Y Combinator introduced the SAFE in 2013 as a way for startups to raise on a promise of future equity. The SAFT applies the same logic to tokens.
The core difference is what the investor eventually receives. A SAFE converts into equity. A SAFT converts into tokens. Everything else follows from that.
| Dimension | SAFE | SAFT |
|---|---|---|
| What the investor receives | Future equity (shares) | Future tokens |
| Underlying asset | Company stock | Network or protocol tokens |
| Typical issuer | Startup, often a Delaware C-corp | Token-issuing entity or foundation |
| Securities treatment | Treated as a security by convention | The instrument is treated as a security; the delivered token's status is fact-specific |
| Origin | Y Combinator, 2013 | Adapted from the SAFE by Protocol Labs and CoinList, 2017 |
One point is commonly misunderstood. The SAFT agreement itself is typically treated as a security regardless of what the token becomes later. The open legal question is the status of the token at and after delivery, not the status of the SAFT instrument. We come back to that in the securities section.
#Securities Law: The Howey Test and Accredited Investors
A SAFT agreement is commonly offered under a securities exemption, typically Regulation D (Rule 506(c)) in the United States, and sold to accredited investors. That is a description of common market practice, not a claim about any specific project's compliance.
The framework regulators and courts apply is the SEC's Howey test. It asks whether an arrangement involves an investment of money, in a common enterprise, with an expectation of profit derived from the efforts of others. When those elements are present, the arrangement is treated as an investment contract, and therefore a security. The SEC publishes the test and applies it case by case.
Accredited-investor status is the practical gate. In the US it generally means meeting income or net-worth thresholds, or, since 2020, holding certain professional certifications recognized by the SEC. The instrument is typically restricted to this investor class because the exemption it relies on requires it.
Here is the line we hold carefully. We do not tell you a SAFT or the token it delivers is or is not a security. That determination is fact-specific and jurisdiction-specific. The firm's read on any individual structure is exactly that, a read, and the classification call belongs to qualified securities counsel in your jurisdiction.
#What a SAFT Template Contains
A SAFT template gives a SAFT agreement its structure, and public versions have circulated since Protocol Labs and CoinList popularized the format. The named components are consistent across versions:
- Purchase amount and payment method. How much the investor commits and in what form.
- Valuation cap and discount rate. The terms that set how the purchase converts to tokens.
- Triggering event. The definition of network launch, mainnet, listing, or a fixed long-stop date.
- Token allocation formula. How the purchase amount converts into a token quantity.
- Most-favored-nation clause. If included, it lets the holder inherit better terms offered to later investors.
- Representations and warranties. Accredited-investor status and no general solicitation, among others.
- Termination and long-stop date. What happens if the network does not launch by a defined date.
- Governing law and dispute resolution. The jurisdiction and forum for disputes.
A SAFT template is a starting point, not a finished agreement. Public templates circulate widely, and every project's terms sit differently against its own facts. Qualified securities counsel should review any SAFT template before it goes in front of an investor.
#The SAFT Round in a Token Launch
The SAFT round is usually the earliest institutional capital a project raises. It comes ahead of any public or community sale, and well before the TGE. In sequencing terms, it funds the build that gets a network to launch.
The terms set in a SAFT round, the cap, the discount, and the allocation percentage, ripple through everything downstream. They interact with later rounds and with total supply and allocation planning. A generous cap in the SAFT round can distort the cap table two years later.
Founders who need the deal-structuring depth behind a SAFT round, the negotiation levers, the investor terms, and how a private token sale is put together, should read our dedicated guide. A SAFT round is one instrument among several a project can use to raise privately, and the structure deserves its own analysis.
#Risks and Criticisms of SAFTs
A SAFT agreement carries risks that founders and investors should weigh plainly.
Regulatory uncertainty. The token's eventual status can stay unsettled even after the SAFT is fully executed. Closing the instrument does not resolve how the delivered token is classified.
Delivery risk. Capital goes in with no fixed delivery date if the network does not ship. A long-stop date defines the fallback, but a fallback is not a launch.
Modeling difficulty. Valuation-cap dilution mechanics can be hard to model against total supply for investors who are new to token structures.
Enforcement scrutiny. Some SAFT-based offerings have drawn SEC attention when the structure was used, in substance, to sell what looked like a public token offering while claiming an exemption. This is a documented pattern in SEC enforcement, not a claim about any specific active project.
A well-structured SAFT does not repair a project that has no value engine underneath. A token without sustainable revenue mechanics is a countdown timer, and the instrument you raise on does not change that.
#The SAFT Agreement in Context
A SAFT agreement is a contract to deliver future tokens for capital paid today, sold under a securities exemption to accredited investors, and built around a triggering event and a conversion cap. That definition holds whether the token later reads as a utility token or a security. The classification is where the analysis gets specific, and where the jurisdiction matters.
The instruments are settled. The regulatory questions around them are not, and they tighten year over year. Projects that treat a SAFT as paperwork to sign, rather than a structure to design, inherit problems at launch that a cleaner setup would have avoided. Founders structuring a raise should read the private-sale deal-structuring guide above, and treat the instrument as one piece of a broader token launch strategy.
If you're building onchain and need your SAFT structure to hold up under institutional scrutiny, book a discovery call. We'll assess your project and tell you whether we're the right fit. Sometimes we're not. We'll tell you that too.