adryenn / op-saft

A one-page simple agreement for future tokens. Learn the definitions in the glossary, learn the terms in the annex, and let's all work together to make fundraising easier.

OP-SAFT-README

Introduction

Hi, thanks for stopping by. In this repo, you'll find the One-Page Simple Agreement for Future Tokens (the “OP SAFT”). The OP SAFT is a free, alpha version, work-in-progress draft of an agreement meant to introduce efficiencies to the early-stage investment process in the digital asset space. A common complaint I've been hearing from founders, venture capitalists, and angel investors alike is that the standard early-stake digital asset investment model (effectuated by a simple agreement for future tokens) is too cumbersome, time consuming, and costly. Neither side wants to be stuck reading dozens of pages of legal jargon and, honestly, lawyers charge too much to review them. Thus, the OP SAFT was born.

The OP SAFT is designed to be remarkably simple; it provides investors with the essential deal terms they need to make a token-related investment decision and eases burgeoning companies’ administrative burden of tracking ongoing obligations. Essentially, the OP SAFT provides for three things: (i) the check size and token allotment, (ii) the token delivery triggers, and (iii) a lock-up. Nearly all definitions and “legal” terms (e.g., a restricted securities legend (to the extent applicable) assignment rights, and representations/warranties) are incorporated by reference from an open source glossary and annex available in this repo. The glossary and annex are designed to allow the digital asset community to coalesce around standardized definitions and terms while permitting parties to publicly fork the same for bespoke transaction considerations. The openness of the repos also facilitates growth within the digital asset community by allowing the community to collaborate on ideas in a pseudo-public domain.

Feel free to use these docs to your heart's content; all I ask is that you make your changes publicly available. We should be collaborative, not competitive to a fault in this nascent industry.

Importantly, the OP SAFT is designed to be a starting point only and should be tailored to meet your specific requirements. Consult an attorney before entering into any binding legal obligations in connection with this OP SAFT. This OP SAFT should not be construed as legal advice for any particular facts or circumstances. Legal minds differ with respect to whether token distributions can be made in the current regulatory environment without bearing some degree of legal risk in the United States. Some folks take the position that there is literally no way to do a fully "compliant" general distribution of tokens without some degree of risk in the United States. Thus, it bears repeating: please consult an attorney before using this form.

Assumptions

The OP SAFT makes certain assumptions critical to its use. Below is a bulleted list of some of these assumptions. I already said this, but please consult an attorney before relying on this OP SAFT or entering into any binding legal obligations. Seriously--—there’s a nonzero risk that this document fails to include terms or conditions material to a grant of tokens from both a legal and business perspective. Use this at your own risk.

This OP SAFT assumes, among other things, that:

1. The Company is a U.S. based software development firm;
2. The Investor is a not a U.S. person;
3. The Token Issuer is a foundation or non-profit entity separate from the Company with a relevant business relationship with the Company (although the Annex does provide for the situation where the Company and the Token Issuer are one in the same);
4. The Token Issuer will assume the token delivery obligation while the Company receives the payment in consideration for such future tokens (i.e., the Company issues to the Investor the right to Tokens to be issued by the Token Issuer);
5. The Token Issuer (assuming it is separate from the Company), has a robust, disinterested board empowered to decline the requests of the Company;
6. Token value is not known at the time of execution of the SAFT, but rather a discount is applied (i.e., price is determined upon a Next Token Pricing or Public Distribution Event);
7. The parties agree that there should be a lockup;
8. Staking is available for the underlying protocol; and
9. The Investor will be subject to certain KYC and AML obligations.

Contributors / Contributions Welcome

If you are an attorney, software developer, or both, your comments would be welcome. You can propose changes through GitHub or can contact me through other channels.

Many thanks to these contributors:

• Gabe Shapiro (https://twitter.com/lex_node)

• Greg Xethalis (https://twitter.com/xethalis)

• Jacob Wittman (https://twitter.com/jakewittman)

About the Author

Brandon Ferrick is an attorney licensed to practice law in the state of New York. Brandon currently serves as the general counsel for Injective Labs (https://injectivelabs.org). More about him may be found at https://t.co/xF0JQrMKsp?amp=1.