A SAFT is an investment contract used to raise capital from accredited investors before a token exists, with tokens delivered at a later generation event. Under US law the SAFT itself is treated as a security even when the eventual token may not be, which shapes how the round and its disclosures must be structured.
A SAFT is a compliance starting point, not a solution. It handles the pre-token raise, but it does not determine the token's own classification at delivery.
How it works
A SAFT obligates the issuer to deliver tokens at a future generation event in exchange for current payment. It was proposed in 2017 as a Reg D-exempt vehicle that would let founders raise legally before a token network existed, with the expectation that the eventual token would be a non-security utility instrument.
The SAFT itself is unambiguously a security under Howey: purchasers invest money, in a common enterprise, expecting profits from the team's efforts to build and launch. It must be sold only to accredited investors under Reg D, and the issuer must file a Form D within 15 days of the first sale. That is the minimum legal floor, not an optional step.
Design consequence
The critical question is the relationship between the SAFT and the eventual token. The framework assumes a conversion at the generation event where the security interest is exchanged for the token. But if the eventual token is also a security, the conversion just delivers a security and resolves nothing. For the token to be a non-security on delivery, the network must be functional and decentralized enough that Howey's third and fourth prongs are not met.
Common mistake
Teams treat the SAFT as the whole compliance answer. Completing a Reg D raise handles the pre-token phase, but it says nothing about the token's own status. Teams that raise on a SAFT and then launch a revenue-sharing token have simply moved the security from one instrument to another.
A better-positioned conversion happens when the protocol is already live, has paying external users, and is no longer upgrade-controlled by the team. That token can argue it is now consumptive. A token converting into a pre-launch beta with full team upgrade control cannot.
See Token Launch Strategy and Round Structure for how this applies in practice.
More in Compliance and Classification
Know the terms but not sure how they apply to your project? That is what an engagement is for. We design, document, and stress-test the whole token economy inside the Tokenomics Data Room.
80+ projects advised. Complete tokenomics in 4 to 6 weeks.