SafeHarbor X
Potential Proposed Securities Act Rule 195. Exemption for Qualifying Distributions of Autonomous Cryptotokens.
Proposed Safe Harbor – Exemption for Qualifying Distributions of Autonomous Cryptotokens.
Proposed Securities Act Rule 195. Exemption for Qualifying Distributions of Autonomous Cryptotokens
Prolegomena to Preliminary Notes:
This is a working draft (initially prepared in a single day as part of LeXpunK working group). At this point, it is just a strawman and everything is still very subject to rethinking and revision. A non-exclusive list of mixed definite and possible to-dos is appended to the end of the document.
Preliminary Notes:
The analysis of whether a particular offering or distribution of a digital asset constitutes a securities offering is not static and does not strictly depend on either the nature of the digital asset or the manner of the offering or distribution. It is common practice for developers of autonomous cryptosystems to distribute governance tokens to users of the systems essentially for free (or, put another way, in recognition of or exchange for the usage of the systems by such users). There is significant doubt and debate over whether such distributions--sometimes characterized as "airdrops" and other times as "liquidity mining," depending on the exact details of the distribution--may constitute securities offerings to the public which must be registered with the SEC. It is also common for initial development teams to distribute governance tokens to themselves, subject to long lock-ups. Our view is that, under appropriate conditions, the distributions of governance tokens to builders or users of autonomous software systems advances important public policy goals, does not carry the same risks as the capital-raising and investment decisions designed to be protected by the securities registration laws, and should be exempt from registration with the SEC, regardless of whether the tokens are or may otherwise be involved in other transactions which constitute investment contracts.
Accordingly, this safe harbor is intended to provide initial development teams for autonomous cryptosystems that are governed or accessed through the use of autonomous cryptotokens with an exemption from registration for the post-operational offer and free (non-capital-raising) distribution of such autonomous cryptotokens to users of the autonomous cryptosystem and the pre-operational distribution of such autonomous cryptotokens to the builders of the autonomous cryptosystem. The safe harbor is designed to protect recipients of autonomous cryptotokens by requiring disclosures tailored to the needs of the users and preserving the potential application of the anti-fraud provisions and secondary market provisions of the federal securities laws.
A Q&A explaining certain design decisions underlying the substance of the safe harbor is included at the end of the document.
Rule 195 is not an exclusive safe harbor. A person who does not meet all of the applicable conditions of Rule 195 still may claim any other available exemption under the Securities Act of 1933 for the offer and sale of Tokens.
Proposed Rule 195 Text
(a) Exemption. Except as expressly provided in paragraph '(d)' of this section, the Securities Act of 1933 does not apply to any qualifying distribution of an autonomous cryptotoken if the following conditions are satisfied by the Initial Development Team, as defined herein.
(1) The disclosures required under paragraph '(b)' of this section are made continuously available by the Initial Development Team on a freely accessible public website.
(2) The qualifying distribution of the autonomous cryptotoken is offered and effected for the purpose of facilitating access to, participation on, or the development of the relevant autonomous cryptosystem.
(3) The Initial Development Team files a notice of reliance in accordance with paragraph '(c)' of this section.
(4) The autonomous cryptotokens beneficially owned or controlled by the initial development team, its members and, to the extent known by the initial development team, any of their respective related persons (and all rights, benefits and powers with respect thereto) are not directly or indirectly sold or transferred (except without additional consideration from the initial development team or its members to their respective related persons) for a period of at least 12 months from the date of the first public qualifying distribution of the autonomous cryptotokens pursuant to clause ‘(a)’ of the definition of “qualifying distribution” set forth in paragraph '(g)(8)' of this section.
(b) Disclosure. The Initial Development Team must provide the information described below on a freely accessible public website. Such information must be updated within five business days of a material change of such information; provided, however, that the information described in under paragraph '(a)(1)' of this section will be deemed automatically amended by any public updates made to a code repository which was identified by and deemed to be automatically incorporated by reference into the existing disclosure.
(1) Initial Disclosures. Prior to filing a notice of reliance on the safe harbor, provide the following information. Any material changes to the information required below must be provided on the same freely accessible public website as soon as reasonably practicable after the change.
(i) Source Code. The complete source code for the relevant open cryptoclient and autonomous cryptocode and the complete text of the free software licenses pursuant to which such source code is licensed to the public (each of which may be incorporated by reference from a suitable public software repository).
(ii) Transaction History. A narrative description of the steps necessary to independently access, search, and verify the transaction history of the relevant autonomous cryptosystem.
(iii) Token Economics. A narrative description of the purposes and operation of the autonomous cryptotoken and the corresponding autonomous cryptosystem. At a minimum, such disclosures must include the following:
(A) Information explaining the launch and supply process for the autonomous cryptotoken, including the number of autonomous cryptotokens to be issued in an initial allocation, the total number of autonomous cryptotokens to be created, the release schedule for the autonomous cryptotokens, and the total number of autonomous cryptotokens outstanding;
(B) Information detailing the method of generating, mining (and, if applicable, staking, locking or burning) autonomous cryptotokens and, if the corresponding autonomous cryptosystem is of the kind described in paragraph '(g)(1)(a)' of this section, the process for validating transactions within, and the consensus mechanism for, such autonomous cryptosystem;
(C) An explanation of governance mechanisms for implementing changes to the autonomous cryptosystem;
(D) If the corresponding autonomous cryptosystem is of the kind described in paragraph '(g)(1)(a)' of this section, sufficient information for a third party to create a tool for verifying the transaction history of the autonomous cryptotoken (e.g., the blockchain or distributed ledger); and
(E) A hyperlink to a block explorer for the relevant autonomous cryptosystem of the kind described in paragraph '(g)(1)(a)' of this section.
(iv) Prior Token Sales. The date of sale, number of autonomous cryptotokens sold prior to filing a notice of reliance on the safe harbor, any limitations or restrictions on the transferability of autonomous cryptotokens sold, and the type and amount of consideration received.
(v) Initial Development Team and Certain Token Holders. Furnish the following information.
(A) The names and relevant experience, qualifications, attributes, and skills of each person who is a member of the Initial Development Team who directly or indirectly beneficially owns or has the right to receive or control 1% or more of the total maximum possible supply of the autonomous cryptotokens (an “Executive Developer”);
(B) The number or percentage of the total maximum possible supply of autonomous cryptotokens that each Executive Developer beneficially owns or has the right to receive or control and a description of any limitations or restrictions on the transferability of autonomous cryptotokens that any member of the Initial Development Team beneficially owns or has the right to receive or control;
(C) If the initial development team, any member of the initial development team or, to the extent known to the initial development team, any of their respective related persons has a right to obtain autonomous cryptotokens in the future in a manner that is distinct from how any third party could obtain autonomous cryptotokens, identify such person and describe how such autonomous cryptotokens may be obtained; and
(D) Copies of all material agreements between or among any one or more of the initial development team, any of its members or,to the extent known to the initial development team, any of their respective related persons, in each case, which relate in any material respect to the autonomous cryptosystem or autonomous cryptotokens.
(vi) Sales of Tokens by Initial Development Team. Each time an Executive Developer sells five percent of his or her autonomous cryptotokens as disclosed pursuant to paragraph '(b)(1)(v)(B)' of this section over any period of time, state, within 4 business days after the consummation of such sale, the date(s) of the sale, the number of autonomous cryptotokens sold, and the identity of the seller.
(vii) Related Person Transactions. A description of any actual or proposed material transaction relating in any material respect to the autonomous cryptosystem or autonomous cryptotokens in which the initial development team or any member thereof is a participant and in which, to the extent known by the initial development team, any of their respective related persons had or will have a direct or indirect material interest. The description should identify the nature of the transaction, the related person, the basis on which the person is a related person, and the approximate value of the amount involved in the transaction.
(viii) Warning to Token Purchasers. A statement that the purchase of autonomous cryptotokens involves a high degree of risk and the potential loss of money.
(c) Filing of Notice of Reliance. The Initial Development Team must file a notice of reliance on the safe harbor prior to the date of the first public qualifying distribution of the autonomous cryptotokens pursuant to clause ‘(a)’ of the definition of “qualifying distribution” set forth in paragraph '(g)(8)' of this section.
(1) The notice of reliance must contain the following information:
(i) The name of each Executive Developer;
(ii) Attestation by an Executive Developer that the conditions of this section are satisfied; and
(iii) The website where disclosure required under paragraph '(b)' of this section may be accessed.
(iv) An email address at which the Initial Development Team can be contacted.
(2) A notice of reliance must be filed with the Commission in electronic format through the Commission’s Electronic Data Gathering, Analysis, and Retrieval System (EDGAR) in accordance with EDGAR rules set forth in Regulation S-T.
(d) Limitation. The exemption provided in paragraph '(a)' of this section does not apply to the provisions of Section 12(a)(2) or Section 17 of the Securities Act of 1933.
(e) Definition of Qualified Purchaser. For purposes of Section 18(b)(3) of the Securities Act of 1933, a “qualified purchaser” includes any person to whom autonomous cryptotokens are offered or distributed in a qualifying distribution in reliance on paragraph '(a)' of this section.
(f) Disqualifications. No exemption under this section is available for the autonomous cryptotokens of any Initial Development Team if it or its Executive Developers would be subject to disqualification under Rule 506(d).
(g) Definitions.
(1) "autonomous cryptosystem" means:
(a) the combination of a particular autonomous cryptonetwork and an open cryptoledger maintained thereby; or
(b) the combination of particular autonomous cryptocode, a particular open cryptoledger on which the autonomous cryptocode is verifiably stored and a particular autonomous cryptonetwork which maintains such open cryptoledger and executes such autonomous cryptocode.
(2) "autonomous cryptonetwork" means a peer-to-peer network that: (a) consists of computers running open cryptoclients which transmit and receive data among each other over the Internet, execute operations on such data and record such data and the results of such operations on an open cryptoledger; (b) does not depend for its continuing operation or availability on, and is not owned, controlled or arbitrarily modifiable by, any single person or single group of extrinsically affiliated persons; and (c) permits any Internet-connected, consumer-grade computer running the open cryptoclient to obtain an accurate and complete copy of the open cryptoledger and freely transmit messages to and read messages from all other open cryptoclients on such network, in each case, without any permission, authorization, identification or credentialling of such computer or the owner or operator of such computer.
(3) "open cryptoclient" means free software implementing a peer-to-peer networking and data consensus software protocol that allows participants in a network to form consensus regarding canonical data and perform transactions in electronic units of accounts solely through the use of cryptographic proofs.
(4) "open cryptoledger" means an electronic database that: (a) is created, stored and updated by a peer-to-peer network of open cryptoclients; and (b) can be independently verified through cryptographic methods as having been created and updated in accordance with the data consensus protocol embedded in the open cryptoclients.
(5) "autonomous cryptocode" means free software that is: (a) designed primarily to be run by open cryptoclients and facilitate transactions on an autonomous cryptonetwork; (b) verifiably stored, and has its results of execution recorded by open cryptoclients, on the open cryptoledger of the autonomous cryptonetwork; and (c) is executable by any open cryptoclient within the virtual machine environment of the autonomous cryptonetwork, provided that if the copy of the free software stored on the autonomous cryptoledger consists of bytecode, then the bytecode must be verifiably compiled from free software source code.
(6) "autonomous cryptotoken" means any electronic unit of account that:
(a) is natively created, stored and updated within and by means of an autonomous cryptosystem;
(b) could reasonably be expected to have material pecuniary value;
(c) solely through operation of the relevant autonomous cryptosystems, enables the controller of the electronic unit of account to:
(1) pay for the use of an autonomous cryptosystem;
(2) vote in the governance or control of an autonomous cryptosystem or any parameters or features thereof; or
(3) capture, track, access, receive or otherwise benefit from the value of an autonomous cryptosystem based on the use, popularity or adoption of such autonomous cryptosystem (including any electronic units of account paid into such autonomous cryptosystem as usage fees); and
(d) does not represent the contractual right to receive any payment or distribution from any person (in respect of any payment of principal or interest on a debt, distribution of profits, assets or dividends, or otherwise).
(7) "autonomous cryptotreasury" means an autonomous cryptosystem that exclusively controls either the generation of or issuance of un-generated or unissued autonomous cryptotokens of a given type based on the results of governance voting of issued autonomous cryptotokens of the same type.
(8) "qualifying distribution" means:
(a) the public distribution of any autonomous cryptotokens, in one or a series of transactions, over any period of time after the corresponding autonomous cryptosystem described in paragraph '6(c)' of this section has become publicly operational, to:
(1) any users of the autonomous cryptosystem, solely in exchange for or recognition of using the autonomous cryptosystem in one or more transactions or continuously during a designated period of time;
(2) if the corresponding autonomous cryptosystem is of the type described in paragraph '1(b)' of this section, to users of the autonomous cryptosystem of the type described in paragraph '1(a)' of this section on which the corresponding autonomous cryptosystem is stored and executed, solely in recognition of historical use of the autonomous cryptosystem of the type described in paragraph '1(a)' of this section; or
(3) an autonomous cryptotreasury controlled by holders of the autonomous cryptotokens; or
(b) the private distribution of any autonomous cryptotokens, in one or a series of transactions over any period of time before the corresponding autonomous cryptosystem described in paragraph '6(c)' of this section has become publicly operational, to members of the initial development team, provided that: (1) the percentage of the total possible maximum supply of the autonomous cryptotokens to the initial development team and all its members does not exceed 30% in the aggregate or 5% to any member; (2) within 30 days of the autonomous cryptosystem becoming operational, the initial development team and its members collectively do not beneficially hold or control a majority of the economic benefits or voting powers associated with the autonomous cryptotoken (excluding any such tokens held in the autonomous cryptotreasury).
For the avoidance of doubt, for a distribution of cryptotokens to constitute a qualifying distribution under clause ‘(a)’ of this paragraph '(8)' of this section, neither the initial development team nor any of their respective related persons, may be paid any sale proceeds or capital by users of the autonomous cryptosystem as consideration for distribution of the autonomous cryptotokens; instead, users must be entitled to receive the autonomous cryptotokens solely as a result of their use of their post-operational use of the corresponding autonomous cryptosystem or their historical pre-operational use of the autonomous cryptosystem on which the first autonomous cryptosystem is stored and operated.
(9) "initial development team" means any person, group of persons, or entity that provides the essential managerial efforts for the development of the network prior to the first public qualifying distribution of the autonomous cryptotokens pursuant to clause ‘(a)’ of the definition of “qualifying distribution” set forth in paragraph '(g)(8)' of this section of this section and makes the initial filing of a notice of reliance on this safe harbor and a member of an initial development team means any person, group of persons or entity that provides services to or with the initial development team.
(10) "related person" means with respect to any person, any affiliate or immediate family member of such person.
(11) "extrinsically affiliated" means, with respect to any two persons and any autonomous cryptotokens, that: (a) due to arrangements or agreements outside of the autonomous cryptosystem (such as ownership of one person's equity securities by another), one such person directly or indirectly controls, is controlled by or is under common control with, the other person in respect of their acquisition, holding, voting, using or disposing of the autonomous cryptotokens; or (b) such persons have agreed to act together for the purpose of acquiring, holding, voting, using or disposing of the autonomous cryptotokens; provided, however, that two persons independently using or agreeing to use the autonomous cryptotokens for their intended purposes within the autonomous cryptosystem (such as by participating in a proof-of-stake consensus process that results in agreement among stakers or validators) shall not constitute such an agreement to act together.
(12) "software" means (a) computer programs (including bytecode or source code) that comprise a series of instructions, rules, routines or statements, regardless of the media in which recorded, that allow or cause a computer to perform a specific operation or series of operations; and (b) recorded information comprising source code listings, design details, algorithms, processes, flow charts, formulas and related material that would enable the computer program to be produced, created or compiled.
(13) "free software" means any software that is freely licensed to the general public to run, copy, distribute, study, change and improve in accordance with the definition of "free software" promulgated by the Free Software Foundation.
(14) "source code" means computer programs written in a high-level computer programming language primarily intended to be read and written by humans.
(15) "bytecode" means computer programs compiled from source code into a low-level computer programming language primarily intended to be read and executed by an interpretive computer program within a virtual machine environment.
- Proposed Exchange Act Rule 3a4-2. Exemption from the definition of “broker” for a person engaged in a Token transaction.
A person shall not be included in the definition of the term “broker” solely as a result of engaging in the business of effecting qualifying distributions in autonomous cryptotokens for the account of others.
- Proposed Exchange Act Rule 3a5-4. Exemption from the definition of “dealer” for a person engaged in a Token transaction.
A person shall not be included in the definition of the term “dealer” solely as a result of engaging in the business of buying and selling autonomous cryptotokens in connection with a qualifying distribution thereof for such person’s own account.
- Proposed Exchange Act Rule 12h-1(j). Exemptions from registration under Section 12(g) of the Act.
Issuers shall be exempt from the provisions of section 12(g) of the Act with respect to any autonomous cryptotoken issued in a qualifying distribution in reliance on Rule 195 of the Securities Act of 1933:
Questions and Answers
Q. Why are the definitions so narrow? They exclude my favorite project because <the smart contracts are proxy-upgradeable by a dev multisig/the mempool is read-permissioned/the software code isn’t FOSS>. Unfair!
A. We realize that good autonomous cryptosystem projects come in many shapes and sizes and have many different (sometimes very gradual) decentralization plans. We feel that a safe harbor needs to have a compelling rationale to be accepted by regulators, legislators and even the general public. Unless the goal is to amend all of securities laws (which might be a worthy goal, but is unlikely to be accomplished in the near future), then we need to carefully explain why certain situations should be subject to different (less strict) rules. The best rationale for this is that the systems are not under the discretionary control of any small group and exist as free public digital goods available to all under very trust-minimized conditions. Importantly, because Rule 195 is intended to be a non-exclusive safe harbor, the fact that a particular system or its tokens might not be covered under Rule 195 does NOT entail that a distribution of such tokens definitely is a securities offering--it merely means that the distribution does not rise to the level of a "qualifying distribution" that clearly deserves exemption.
Q. Why aren’t issuances of tokens to the Initial Development Team prior to the autonomous cryptosystem being operational required to comply with the securities laws?
A. We believe the bona fide builders of an autonomous cryptosystem deserve to receive autonomous cryptotokens for their work, even if they are not “accredited investors.” While private placement exemptions such as Rule 701 could work to place securities into service providers’ hands, the conditions of Rule 701 are too restrictive in the context of building autonomous cryptosystems because: (a) many free software teams choose to collaborate on an unincorporated, non-hierarchical basis, and thus there is no “issuer” that they provide services to such that they could qualify to receive a security from that issuer under Rule 701; and (b) many cryptosystems may be developed on a joint-venture-like basis involving multiple development studios, code audit firms, and other types of business entities working in the field of autonomous cryptosystems, and business entities are generally not eligible to receive securities pursuant Rule 701. Moreover, members of the Initial Development Team will typically be fully informed about the risks and rewards of the autonomous cryptosystem and autonomous cryptotokens, have significant influence over their design and exert a significant part of the essential efforts required for their development—thus, the Initial Development Team does not need the protection of the securities laws with respect to their decision to trade labor for autonomous cryptotokens, similar to how the “knowledgeable employees” of an issuer are typically treated as being accredited investors in connection with that issuer’s own securities.
Q. How does this proposal differ from SEC Commissioner Hester Peirce’s proposed Rule 195 Safe Harbor 2.0?
A. This proposal borrows a number of elements, concepts and textual provisions of Hester Peirce’s seminal and deservedly praised Rule 195 / Safe Harbor 2.0 proposal, but has some key differences. We believe the Safe Harbor 2.0 proposal has not garnered the necessary buy-in from cryptoskeptical regulators and politicians, for several principal reasons:
Breadth of the Exemption. Commissioner Peirce’s proposal provides a high degree of clarity-in favor of cryptocurrency enthusiasts—that, during the relevant three-year network maturation period, tokens will not be treated as securities in any context, assuming the absence of fraud. However, to a skeptical regulator or politician, this broad carve-out runs the risk of unintended or unforeseen consequences. For example, what if swaps, indexes or traditional funds relating to these tokens are created on a pure centralized basis that implicates the securities laws—will the SEC still be able to assert jurisdiction over such instruments? What about a hedge fund that seeks to act as a T. Boone-Pickens style “hostile takeover investor” and makes a coercive or preclusive tender offer in an attempt to unfairly acquire a majority of the tokens in a way that damages dissenting token holders—will the SEC have no enforcement tools to use against such a person? What about “insider trading” abuses by third parties beyond the initial development team who somehow gain an outsized influence over the autonomous cryptosystem at a later stage? The securities laws are simply too complex and multifarious for a regulator or politician to be confident it is not “giving away the farm” by exempting tokens wholesale from a large swathe of the securities laws during some period of time.
Tokens vs. Manner of Distributing. Commissioner Peirce’s proposal focuses on tokens and the respects in which they are or are not to be treated as securities during some period of initial network maturation. In doing so, it fails to discriminate among different kinds of transactions in tokens, some of which may be more deserving of securities regulation than others. Selling tokens to the public in a capital-raising or enterprise “exit” transaction implicates many of the same issues as a traditional sale of securities, regardless of the fact that what are being sold are tokens rather than stock, bonds or other traditional securities. By contrast, issuing tokens to team members or users outside of a literal “sale” poses fewer risks to the public and less strongly implicates the securities laws.
Fairness; Regulatory Arbitrage. Another key objection we have heard to Commissioner Peirce’s proposal is that it presents too many regulatory arbitrage opportunities to traditional issuers or technically incapable issuers. Because the proposal exempts tokens even if they are initially under centralized control, so long as decentralization occurs within three years, it confers special regulatory benefits on those who have not yet created, and may ultimately be unsuccessful in creating, a special decentralized technology. Decentralized technology is challenging, and thus, even with the best of intentions, a team may overestimate its ability or time needed to achieve “network maturity.” Alternatively, a traditional technology company could, by issuing a token tied the value of the company’s efforts, get a risk-free three-year jump start on its IPO, provided that it is prepared to ultimately become an exchange-act-reporting company within three years; this would provide an unfair advantage that serves no positive social purpose.
With the benefit of hindsight after engaging in discussions and debates over Commissioner Peirce’s proposal over the course of nearly two years, our proposal takes the aforementioned objections into account (with the hope of gaining broader consensus) by:
(a) Exempting a particular type of distribution of the token—a “qualifying distribution” to users and builders, which must not involve raising capital or exit proceeds for the initial development team—rather than exempting the token itself. This leaves more room for regulators to assert other kinds of securities law issues to address abuses (e.g., by secondary market participants such as cryptoexchanges) or unanticipated issues.
(b) Requiring that only special autonomous software systems that serve an important public policy goal are entitled to this special exemption from otherwise stringent securities registration laws. Whereas in Commissioner Peirce’s proposal the systems may start off as non-special as long as they become special within three years, we require that they be special at the outset. This means that to be eligible, the relevant cryptosystems must already be autonomous, and, in effect, serve as a community-run public good independent of the initial development team. This theme manifests itself in our proposal in a number of ways—for example, unlike in the Peirce proposal, our proposal requires that to be eligible for this special exemption, the relevant software must be free software. This is a sine qua non of a software system that is intended to constitute a public good fulfilling an important public policy purpose and to be independent from a proprietary enterprise. This also dramatically limits potential abuses of the exemption as a regulatory arbitrage strategy for an otherwise traditional business enterprise.
(c) Requiring that the initial development team be subject to a minimum 12-month post-public-launch lockup of their autonomous cryptotokens, which prohibits not only literal transfers of the token but also any divestiture of the rights or benefits or risks of ownership of the autonomous cryptotokens. This mirrors the 12-month holding period applicable to “restricted securities” under Rule 144. As a side note, we would hope that the absence of control over the autonomous cryptosystem by the initial development team moots the need to consider their autonomous cryptotokens “control securities” status under Rule 144--though this proposal is agnostic on that issue.
Q. I noticed that "qualifying distributions" do not seem cover sales of tokens by the initial development team (whether to the public or on the private market). What is the thinking here? If there is no exemption for team token sales, how will they ever sell their tokens in compliance with securities laws?
A. Correct. By design, "qualifying distributions" do not include any sales of tokens by the initial development team. Consistent with the functionalist-minded, transaction-by-transaction approach with which the proposal has been drafted (as discussed above), we feel that sales of tokens by the development team raise heightened policy concerns as compared to free distributions of tokens to users and builders. Therefore, to increase the chances of regulatory or legislative acceptance of this proposal, we are leaving open the possibility that sales of tokens by the development team could constitute securities transactions, which would either require registration or a separate exemption. Whether such sales are securities transactions, and, if so, what exemptions or registration options would be available for such sales, will be a facts-and-circumstances analysis.
Definite and Possible To-Dos For Refinement of this Proposal:
[__] think through whether some more wiggle room should be added for limited 'trustful' features (e.g., Curve-style emergency multisig, multisig with limited security-response authority and a timelock before changes, etc.)
[__] potentially tighten up language/substance around the meaning of control by the initial development team (right now has lazy text about "control of a majority of economic benefits or voting power")--think about total supply vs. circulating supply vs. votable supply and potentially refine the standard around that
[__] consider allowing a 3-month grace period to become fully decentralized, and thus adding back something like the "network maturity" and "exit report" standards from Peirce's safe harbor (it is my observation that most developers are very uncomfortable being decentralized from day 1, for both security-oriented reasons and practical time-to-market reasons) ...OTOH, maybe those things can be addressed by delaying token distribution until after the system has been live for a while
[__] scour other safe harbor forks for potential good ideas
[__] include more fulsome description of the public policy goals achieved by autonomous cryptosystems and autonomous cryptotokens--some good ideas here