diff --git a/.gitignore b/.gitignore index ee41ec1..1eeff73 100644 --- a/.gitignore +++ b/.gitignore @@ -6,3 +6,4 @@ docs/_templates/ docs/_static/ build/ reports/ +.idea/ \ No newline at end of file diff --git a/README.md b/README.md index f537ffe..4270c7e 100644 --- a/README.md +++ b/README.md @@ -1,12 +1,12 @@ -# SFT Protocol +# ZAP Protocol ## Description -The SFT protocol is a set of smart contracts, written in Solidity for the Ethereum blockchain, that allow for the tokenization of financial securities. It provides a robust, modular framework that is configurable for a wide range of jurisdictions, with consideration for real world needs based on today’s existing markets. SFT favors handling as much permissioning logic on-chain as possible, in order to maximize transparency for all parties involved. +The ZeroLaw org-Augmentation Protocol (ZAP) is a set of smart contracts, written in Solidity for the Ethereum blockchain, that allow for the tokenization of financial securities. It provides a robust, modular framework that is configurable for a wide range of jurisdictions, with consideration for real world needs based on today’s existing markets. ZAP favors handling as much permissioning logic on-chain as possible, in order to maximize transparency for all parties involved. ## How it Works -SFT is designed to maximize interoperability between different network participants. Broadly speaking, these participants may be split into four categories: +ZAP is designed to maximize interoperability between different network participants. Broadly speaking, these participants may be split into four categories: * **Issuers** are entities that create and sell security tokens to fund their business operations. * **Investors** are entities that have passed KYC/AML checks and are are able to hold or transfer security tokens. @@ -21,7 +21,7 @@ Security tokens in the protocol are built upon the ERC20 token standard. Tokens ## Components -The SFT protocol is comprised of four core components: +ZAP is comprised of four core components: 1. **Token** @@ -57,7 +57,7 @@ In-depth documentation is hosted at [Read the Docs](https://sft-protocol.readthe ## Develoment Progress -The SFT Protocol is still under active development and has not yet undergone a third party audit. Please notify us if you find any issues in the code. We highly recommend against using these contracts prior to an audit by a trusted third party. +ZAP is still under active development and has not yet undergone a third party audit. Please notify us if you find any issues in the code. We highly recommend against using these contracts prior to an audit by a trusted third party. ## Testing and Deployment @@ -111,4 +111,4 @@ SecurityToken.transfer confirmed - block: 14 gas used: 192451 (2.41%) ## License -This project is licensed under the [Apache 2.0](https://www.apache.org/licenses/LICENSE-2.0.html) license. +The code in this project is licensed under the [Apache 2.0](https://www.apache.org/licenses/LICENSE-2.0.html) license. The ZAP Whitepape r and SFT Yellowpaper are licensed under [Creative Commons - Attribution-NonCommercial-NoDerivatives 4.0 International](https://creativecommons.org/licenses/by-nc-nd/4.0/legalcode). All model legal forms, including all documents contained in the "model-legal-forms" folder, are licensed under [Attribution-ShareAlike](https://creativecommons.org/licenses/by-sa/4.0/legalcode). diff --git a/docs/model legal forms/Model-DAO-Charter-Unincorporated Association-QDC.md b/docs/model legal forms/Model-DAO-Charter-Unincorporated Association-QDC.md new file mode 100644 index 0000000..25afbd2 --- /dev/null +++ b/docs/model legal forms/Model-DAO-Charter-Unincorporated Association-QDC.md @@ -0,0 +1,177 @@ +# DAO CHARTER + +## FOR THE ___________ /*INSERT NAME OF DAO*/ DAO + + +--- +*IMPORTANT NOTE*: This is an alpha release of a potential model DAO Charter for DAOs wishing to function as unincorporated associations. + +There are a large number of assumptions embedded in this document. Among the most important is that the DAO shares/membership interests are NOT securities. This model form would not be suitable for DAOs whose tokens/membership interests are securities. + +Because there is no limited liability vehicle (such as an LLC or corporation) contemplated for the DAO in this model form, to be quasi-safely used in practice, the approach would need to be implemented with various extrinsic safeguards, such as specific public disclaimers regarding the ability of DAO Members to bind other DAO Members, and specific contracting practices when DAO Members are contracting with third parties regarding use of DAO funds, etc. It would not be appropriate for all use cases. + +Code deference exists along a spectrum, with one end being "code is law" and the other being "code is no substitute for law whatsoever." The code deference approach taken by this form may be characterized as "qualified code deference" and builds on the example set forth in the "Simple Code Deference Agreement." For more on qualified code deference & the rationale thereof, see here: https://www.youtube.com/watch?v=hzbMPLxiht4. + +This document does not constitute legal, financial or other advice and is not intended to be relied upon or used by any person for any purpose, other than informational and educational purposes. No attorney-client relationship or privilege is intended to be created or implied. No representation or warranty is being made as to the quality or fitness for any purpose of this document. Furthermore, this document is not recommended for use, but only for research. + +This document is currently copyright ZeroLaw LLC but will be made open-source after further refinement and clean-up. Please do not use or quote without permission. + +By reading, transmitting or copying this document or any portion thereof, you consent and agree to the foregoing terms.*/ + +--- + +### I. NATURE OF DAO CHARTER + + (a) This charter (this “***Charter***”) is the official legal charter of the ___________ /*INSERT NAME OF DAO*/ (the “***DAO***”). This Charter is intended to be a legal agreement & contract binding upon all DAO Members and the other DAO Participants, enforceable in accordance with its terms under the laws of ___________ /*INSERT NAME OF LEGAL JURISDICTION*/. Certain capitalized terms used in this Charter are defined in Section 6. + + (b) If you have received any DAO Membership Token or are otherwise a DAO Member, you consent to & agree to become legally bound by this Charter as both a DAO Participant and more specifically a "***DAO Member***". + +### II. NAME, PURPOSES AND STRUCTURE OF THE DAO + + (a) The name of the DAO is ___________ /*INSERT NAME OF DAO*/. + + (b) The DAO is a "decentralized autonomous organization"--i.e., an unincorporated association of individuals, entities, associations and/or other persons or groups of persons. + + (c) The activities and purposes to be conducted or promoted by the DAO are described at [________]() /*ADD HTML LINK TO DESCRIPTION OF DAO PURPOSES OR MISSION STATEMENT*/, as they may be updated from time to time in accordance with this Charter (the "***Purposes***"). + + (d) The DAO is not intended to, and shall not be deemed to, be a legal person or have a legal personality separate from the DAO Members. Without limiting the generality of the foregoing, the DAO is not intended to be, and shall not be deemed to be, a partnership. + + (e) The DAO Members shall utilize the Designated Smart Contract (a smart contract deployed to the Designated Blockchain at the Designated Blockchain Address) as the exclusive method of holding. allocating among the DAO Members and spending or otherwise distributing any Tokens that are DAO Property, of minting and issuing DAO Membership Tokens and holding and recording votes of the DAO Members. The DAO may also utilize the Designated Smart Contract to administer and facilitate certain other arrangements and transactions involving the DAO, the DAO Members and/or third Members. + + ### III. DAO SHARES & MEMBERSHIP + + (a) A person shall be deemed to be a DAO Member if and only if an instance of the Membership struct has been created with respect to such person in the Designated Smart Contract. Each Membership struct shall record the public key with respect to which the DAO Member may exercise its rights as a DAO Member through the Designated Smart Contract and the number of DAO Membership Tokens issued to and held by such DAO Member, and may also record any other relevant information regarding a DAO Member, as determined by the available key: value pairings within the Membership struct of the Designated Smart Contract. + + (b) Membership rights in the DAO shall be represented by Tokens (the "***DAO Membership Tokens***") minted and issued through the Designated Smart Contract. + + (c) DAO Members shall have the rights, powers and privileges that are possible to be taken or exercised by DAO Members through the Designated Smart Contract as further set forth in Section 4. Additionally, DAO Memrs shall have the rights, powers and privileges set forth at [________]() /*ADD HTML LINK TO DESCRIPTION OF DAO PURPOSES OR MISSION STATEMENT*/, as they may be updated from time to time in accordance with this Charter. The rights, powers and privileges of DAO Members are referred to herein as the "***DAO Membership Rights***". + + (d) Status as a DAO Member does not (and shall not be deemed to) create, and the DAO Membership Rights do not (and shall not be deemed to) include, any authority, right or power on the part of a DAO Member to act as the agent, representative or attorney of or otherwise act on behalf of the DAO or any other DAO Member, to bind the DAO or any other DAO Member to any Contract or Liability or to Convey any DAO Property or any asset, right or property owned or held by or on behalf of the DAO or any DAO Member. Without limiting the generality of the foregoing, no DAO Member shall be deemed the partner of the DAO or any other DAO Member. No DAO Member shall state, purport, imply, hold out or represent to any person that such DAO Member or any other DAO Member has any such authority, right or power. + + (e) To the maximum extent permitted by applicable law, no DAO Member shall be (or shall be deemed to be) Liable for any Liability of the DAO or any other DAO Member. This clause "(e)" shall not (and shall not be deemed to) create or imply any obligation of the DAO or any DAO Member to indemnify or compensate any DAO Member from, or hold any DAO Member harmless against, any Liabilities incurred by such DAO Member under any applicable law, in connection with the DAO Member's participation in the DAO or otherwise. + +### IV. BINDING EFFECT OF THE DESIGNATED SMART CONTRACT + +(a) *General Binding Effect.* + +(i) *Smart Contract Deference.* Except as set forth in Section 4(b): + + (A) the results of operation of the Designated Smart Contract shall be determinative of the rights and obligations of, and shall be final, binding upon and non-appealable by, each of the DAO Members with respect to the DAO, the DAO Purposes, the DAO Shares, the DAO Property and the Distributed DAO Property (the "***DAO Matters***")' + + (B) each DAO Member has the unconditional right to take any action or exercise any right, power or privilege that is possible to be taken or exercised by a DAO Member with a DAO Membership Token or by interacting with the Designated Smart Contract, including transferring a DAO Membership Token (to the extent the Designated Smart Contract permits such transfers), calling any function of the Designated Smart Contract, Conveying any Token to the Designated Smart Contract or receiving any Token from the Designated Smart Contract; + + (C) no DAO Member has any duties or responsibilities to make any particular use of the DAO Membership Token or interact with the Designated Smart Contract at all or in any particular way; *provided*, *however*, that this clause "(C)" does not and shall not be deemed to limit any other provision of this Charter, including the requirement set forth in the preceding clause "(A)" that a DAO Member shall be bound by the results of operations of the Designated Smart Contract; + +(ii) *Smart Contract Preempts Contrary Legal Contracts.* Except as set forth in Section 4(b), if in connection with any DAO Matters there is any conflict or inconsistency between: (A)(1) this Charter or (2) any other Contract between or among any DAO Members; and (B) any Contract created or implied by, or embodied in, the machine, assembly or other code, or the results of operation, of the Designated Smart Contract, then the Contract referred to in the preceding clause “(B)” shall prevail over the Contract referred to in the preceding clause “(A).” Notwithstanding the foregoing, particular DAO Members may opt out of this Section 4(a)(ii), solely as to themselves and without any adverse effect on other DAO Members, to the extent expressly provided in a written legal agreement, provided that the execution of such agreement is announced to all DAO Members and an accurate and complete copy of such agreement is made readily available to all DAO Members. + +(iii) *Prohibition of Legal Proceedings & Transfers.* No DAO Member shall, without the prior written unanimous consent of the other DAO Members, directly or indirectly take or attempt to take any of the following actions: + + (A) except as set forth in Section 4(b) or to the extent necessary to enforce the express provisions of this Charter, commence or continue any Legal Proceeding, assert any Claim or enforce any judgment or other Order, in each case, that (1) is against or involves any other DAO Member(s), (2) relates to this Charter or the matters contemplated by this Charter, the Designated Smart Contract, the DAO Property or any of the other DAO Matters, including, for the avoidance of doubt, any Legal Proceeding or Order *in rem* pertaining to the DAO Property or any Legal Proceeding or Claim challenging the enforceability of any provision of this Charter; + + (B) Convey any of the DAO Property other than such DAO Member's Distributed DAO Property (it being understood that for a DAO Member to “***Convey***” any of the DAO Property means for such DAO Member to, or to enter into any Contract that may obligate such DAO Member, any other DAO Member or the DAO to: (1) create, perfect or enforce any Lien on, (2) pledge, hypothecate, grant an option or derivative security, swap or other instrument with respect to or (3) convey, sell, transfer or dispose of such DAO Property or any right or interest of the DAO or any DAO Member to or in such DAO Property); or + + (C) cause, assist, encourage or facilitate, a Material Adverse Exception Event. + +(b) *Exception Handling.* Notwithstanding anything to the contrary set forth in Section 4(a), if there is a Material Adverse Exception Event, then the rules and procedures set forth in this clause "(b)" shall determine the rights and obligations of the DAO Members relating to the DAO Property. + + (i) *Exception Notice.* If any DAO Member becomes aware that there is a Material Adverse Exception Event, such DAO Member (the “***Sending Member***”) shall deliver to the other DAO Members (the “***Receiving Members***”) a notice (an “***Exception Notice***”): + + (A) certifying that the Sending Member believes in good faith that there is a Material Adverse Exception Event; + + (B) describing in reasonable detail the events, facts, circumstances and reasons forming the basis of such belief; + + (C) if and only if desired, describing in reasonable detail a proposal by such DAO Member of the actions to be taken, the agreements to be entered into, and the remedies to be sought by the DAO Members in response to the Material Adverse Exception Event an “***Exception Handling Proposal***”; + + (D) including copies of any written evidence or other material written information, and summaries of any other evidence, relevant to, and material for the consideration of, the Material Adverse Exception Event and the other matters referred to in the Exception Notice; and + + (E) containing a representation by the Sending Member, made to and for the benefit of the Receiving Members with the understanding that the Receiving Members will rely thereon, that, to the Sending Member’s knowledge, the certification and statements made pursuant to the preceding clauses “(A)” and “(B)” are accurate as of the date of the Exception Notice, and, considered collectively, do not contain any untrue statement of a material fact or omit to state any material fact necessary in order to make such statements, in light of the circumstances in which they were made, not misleading. + + (ii) *Exception Standstill.* During the period starting on the date of delivery of an Exception Notice and ending with the DAO Members entering into an Exception Handling Addendum or receiving a final decision of an arbitrator in accordance with Section 4(b)(iii) (the “***Standstill Period***”), each DAO Member shall: (A) treat all of the Distributed DAO Property of such DAO Member that may have been Transferred to such DAO Member as a result of the Material Adverse Exception Event as if it were DAO Property, including by disregarding the parenthetical exceptions for Distributed DAO Property in Section 4(a)(iii); and (B) deposit and maintain such Distributed DAO Property in a segregated Account Address to be treated, to the extent permitted by applicable Legal Requirements, as a custodial trust held for the benefit of the DAO Members. + + (iii) *Determination of Exception Handling.* + + (A) The term “***Exception Handling Addendum***” refers to an addendum to this Charter setting forth the DAO Members’ agreement on the existence or non-existence of a Material Adverse Exception Event and the actions to be taken, the agreements to be entered into, and the remedies to be sought in response thereto. Each Exception Handling Addendum shall automatically and without further action of the DAO Members be deemed incorporated into and to form a part of this Charter. + + (B) During the continuous 10-day period beginning on the date of delivery of hte Exception Notice (the “***Negotiation Period***”), the DAO Members shall use commercially reasonable efforts to negotiate in good faith to agree upon the existence or non-existence of a Material Adverse Exception Event and, if so agreed, the actions to be taken, the agreements to be entered into and the remedies to be sought by the DAO Members in response to the Material Adverse Exception Event. If the DAO Members agree upon such matters during the Negotiation Period, the DAO Members shall promptly enter into an Exception Handling Addendum reflecting the same. + + (C) If the DAO Members fail to reach an agreement resulting in an Exception Handling Addendum during the Negotiation Period, then either DAO Member may initiate an arbitration action to resolve the issues in accordance with the procedures set forth at [________]() /*ADD HTML LINK TO DESIRED ARBITRATION PROCEDURES*/ (the “***Arbitration Procedures***”). The decision resulting from the Arbitration Procedures shall include, among any other determinations, a determination of the treatment of any Distributed DAO Property and whether to extend, modify or terminate the covenants applying to the Distributed DAO Property during the Standstill Period. The decision resulting from the Arbitration Procedures shall be non- appealable, binding and conclusive upon the DAO Members. Judgment upon such decision may be entered in any court of competent jurisdiction. + +### V. Representations and Warranties + +Each DAO Member (as the "***Representing DAO Member***") hereby represents and warrants, to and for the benefit of each other DAO Member, as of all dates that such Person remains a DAO Member, as follows: + +(a) *Authorization and Enforceability.* The Representing DAO Member has all necessary power, authority and capacity to enter into, agree to the terms and conditions of, become bound by this Charter. This Charter has been duly entered into by the Representing DAO Member and constitutes a legal, valid and binding obligation of the Representing DAO Member, enforceable against the Representing DAO Member in accordance with its terms, subject only to the effect, if any, of (i) applicable bankruptcy, insolvency, moratorium or other similar laws affecting the rights of creditors generally, and (ii) rules of law governing specific performance, injunctive relief and other equitable remedies. If the Representing DAO Member is an entity, then the Representing DAO Member is duly formed, organized, validly existing and in good standing under the laws of the jurisdiction in which it was formed. + +(b) *No Conflicts or Required Unobtained Consents.* The execution and delivery of this Charter by the Representing DAO Member do not, and the performance of its obligations under this Charter by the Representing DAO Member will not: (i) conflict with or violate any Legal Requirement or Order applicable to the Representing DAO Member or by which the Representing DAO Member or any of the Representing DAO Member's assets is bound; or (ii) result in or constitute (with or without notice, lapse of time or both) any breach of or default under, or give to any other Person (with or without notice, lapse of time or both) any right of termination, amendment, acceleration or cancellation of, or result (with or without notice, lapse of time or both) in the creation of any Lien on any of the DAO Property (or any right, entitlement or interest of the Representing DAO Member therein) pursuant to any Contract to which the Representing DAO Member is a DAO Member or by which the Representing DAO Member or any of the Representing DAO Member's assets is bound. The execution and delivery of this Charter by the Representing DAO Member do not, and the performance of this Charter by the Representing DAO Member will not, require any consent, permit or exemption from any governmental authority. + +(c) *Title.* The Representing DAO Member exclusively owns, controls and has good and valid title (free and clear of any Liens) to any Tokens deposited by or on behalf fo the Representing DAO Member into the Designated Smart Contract and exclusively owns controls, controls and has good and valid title (free and clear of any Liens) the private key corresponding to the public key designated in the Representing DAO Member's member struct in the Designated Smart Contract. Without limiting the generality of the foregoing, the Representing DAO Member has not directly or indirectly Conveyed any of the DAO Property. + +(d) *Reliance on Own Due Diligence; Informed Consent.* + +(i) The Representing DAO Member has received and carefully reviewed a copy of this Charter and all source code for the Designated Smart Contract sufficiently in advance of becoming a DAO Member to make an informed decision regarding becoming a DAO Member. The Representing DAO Member has been given a full and fair opportunity to: (A) to ask questions of, and to receive answers from, the other DAO Member regarding the subject matter of this Charter and the Designated Smart Contract and (B) to obtain any additional information that is necessary to evaluate this Charter and the matters contemplated thereby. The Representing DAO Member is a Person who is, or in connection with this Charter and the matters contemplated thereby has received the advice of Persons who are, knowledgeable, sophisticated and experienced in making, and qualified to make, evaluations and decisions with respect to the quality, security and intended and expected functionality of the Designated Smart Contract and the other matters contemplated by this Charter. + +(ii) Other than the representations and warranties of the other DAO Member expressly set forth in this Section 5, the Representing DAO Member has not relied on any statement, information, representation or warranty including oral statements, due diligence presentations, etc., or any omission of any statement, information, representation or warranty, made by or on behalf of the other DAO Member in determining to enter into or perform this Charter or otherwise making any evaluation or determination of the Designated Smart Contract or any other matter contemplated by this Charter. The Representing DAO Member understands that the other DAO Member has not made, and has not authorized any of its representatives to make, any representation, warranty or other statement intended to be relied upon or to give rise to any claim, obligation or liability based on the accuracy or completeness thereof, other than the representations and warranties of such DAO Member expressly set forth in this Section 5. + +### VI. Definitions + +(a) “**Account Address**” means a public key address on the Designated Blockchain Network that is uniquely associated with a single private key, and at which no smart contract has been deployed. + +(b) “**Claim**” means any past, present or future dispute, claim, controversy, demand, right, obligation, liability, action or cause of action of any kind or nature. + +(c) “**Confirmation**” of a transaction shall be deemed to have occurred if and only if such transaction has been recorded in accordance with the Consensus Rules in a valid block whose hashed header is referenced by at least _________ /*ADJUST BASED ON DESIGNATED BLOCKCHAIN SECURITY MODEL ETC.*/ subsequent valid blocks on the Designated Blockchain. + +(d) “**Consensus Attack**” means an attack that: (i) is undertaken by or on behalf of a block producer who controls, or group of cooperating block producers who collectively control, a preponderance of the means of block production on the Designated Blockchain Network; and (ii) has the actual or intended effect of: (A) reversing any transaction made to or by the Designated Smart Contract after Confirmation of such transaction, including any “double spend” attack having or intended to have such effect; or (B) preventing inclusion in blocks or Confirmation of any transaction made to or by the Designated Smart Contract, including any “censorship attack,” “transaction withholding attack” or “block withholding attack” having or intended to have such effect. + +(e) “**Consensus Rules**” means the rules for transaction validity, block validity and determination of the canonical blockchain that are embodied in the Designated Client. + +(f) “**Contract**” means any: (i) written, oral, implied by course of performance or otherwise or other agreement, contract, understanding, arrangement, settlement, instrument, warranty, license, insurance policy, benefit plan or legally binding commitment or undertaking; or (ii) any representation, statement, promise, commitment, undertaking, right or obligation that may be enforceable, or become subject to an Order directing performance thereof, based on equitable principles or doctrines such as estoppel, reliance, or quasi-contract. + +(g) “**DAO Property** means any Token or other asset, right or property licensed to or on deposit with or owned, held, custodied, controlled or possessed by or on behalf of the DAO, including any Token on deposit with or held, controlled, possessed by or on deposit with the Designated Smart Contract. + +(h) “**Designated Blockchain**” means at any give time, the version of the digital blockchain ledger that at least a majority of nodes running the Designated Client on the Designated Blockchain Network recognize as canonical as of such time in accordance with the Consensus Rules. For the avoidance of doubt, the “Designated Blockchain” does not refer to [____________] /*INSERT ANY APPLICABLE REFERENCES TO COMMONLY KNOWN FORKS--E.G., ETHEREUM CLASSIC*/ or any digital blockchain ledger commonly known as a “testnet”. + +(i) “**Designated Blockchain Network**” means [____________] /*INSERT REFERENCE TO DESIRED BLOCKCHAIN NETWORK--E.G. “the Ethereum mainnet (networkID:1, chainID:1)”*/, as recognized by the Designated Client. + +(j) “**Designated Client**” means [____________] /*INSERT REFERENCE TO DESIRED BLOCKCHAIN CLIENT--E.G. “the Official Go Ethereum client available at https://github.com/ethereum/go-ethereum” CAN ALSO REVISE FOR MULTIPLE CLIENTS--E.G., HAVE 3 DESIGNATED CLIENTS AND SAY THAT THE DESIGNATED BLOCKCHAIN IS THE ONE AGREED UPON BY 2-OF-3.*/. + +(k) “**Designated Smart Contract**” means the smart contract deployed at address [____________] /*INSERT REFERENCE TO ADDRESS OF DEPLOYED SMART CONTRACT*/ on the Designated Blockchain. + +(l) “**Distributed DAO Property**” means any asset, right or property that was once DAO Property and has been distributed to a DAO Member. + +(m) “**Legal Order**” means any restraining order, preliminary or permanent injunction, stay or other order, writ, injunction, judgment or decree that either: (i) is issued by a court of competent jurisdiction, or (ii) arises by operation of applicable law as if issued by a court of competent jurisdiction, including, in the case of clause “(ii)” an automatic stay imposed by applicable law upon the filing of a petition for bankruptcy. + +(n) “**Legal Proceeding**” means any private or governmental action, suit, litigation, arbitration, claim, proceeding (including any civil, criminal, administrative, investigative or appellate proceeding), hearing, inquiry, audit, examination or investigation commenced, brought, conducted or heard by or before, or otherwise involving, any court or other governmental entity or any arbitrator or arbitration panel. + +(o) “**Liability**” means any debt, obligation, duty or liability of any nature (including any unknown, undisclosed, unmatured, unaccrued, unasserted, contingent, indirect, conditional, implied, vicarious, inchoate derivative, joint, several or secondary liability), regardless of whether such debt, obligation, duty or liability would be required to be disclosed on a balance sheet prepared in accordance with generally accepted accounting principles and regardless of whether such debt, obligation, duty or liability is immediately due and payable. To be “**Liable**” means to have, suffer, incur, be obligated for or be subject to a Liability. + +(p) “**Lien**” means any lien, pledge, hypothecation, charge, mortgage, security interest, encumbrance, other possessory interest, conditional sale or other title retention agreement, intangible property right, claim, infringement, option, right of first refusal, preemptive right, exclusive license of intellectual property, community property interest or restriction of any nature including any restriction on the voting of any security or restriction on the transfer, use or ownership of any security or other asset. + +(q) “**Material Adverse Exception Event**” means that one or more of the following has occurred, is occurring or would reasonably be expected to occur: + +(i) a Consensus Attack adversely affecting the results or operations of the Designated Smart Contract; + +(ii) the Designated Smart Contract having become inoperable, inaccessible or unusable, including as the result of any code library or repository incorporated by reference into the Designated Smart Contract or any other smart contract or oracle on which the Designated Smart Contract depends having become inoperable, inaccessible or unusable or having itself suffered a Material Adverse Exception Event, mutatis mutandis; + +(iii) a material and adverse effect on the use, functionality or performance of the Designated Smart Contract as the result of any bug, defect or error in the Designated Smart Contract or the triggering, use or exploitation (whether intentional or unintentional) thereof (it being understood that for purposes of this clause “(iii)”, a bug, defect or error will be deemed material only if it results in a loss to a DAO Member or the DAO of at least ___ percent of such DAO Memvber's distributable interest in the DAO Property and/or __ percent of the DAO Property); + +(iv) any unauthorized use of an administrative function or privilege of the Designated Smart Contract, including: (A) any use of any administrative credential, key, password, account or address by a Person who has misappropriated or gained unauthorized access to such administrative credential, key, password, account or address or (B) any unauthorized use of an administrative function or privilege by a DAO Member or a representative of a DAO Member; or + +(v) the Designated Smart Contract, any of the DAO Members or the DAO Property is subject to a Legal Order that prohibits the Designated Smart Contract (or that, if the Designated Smart Contract were a Person, would prohibit the Designated Smart Contract) from executing any function or operation it would otherwise reasonably be expected to execute. + +(r) “**Person**” means any human, robot, bot, artificial intelligence, corporation, partnership, association or other individual or entity recognized as having the status of a person under the law. + +(s) “**Token**” means a digital unit that is recognized by the Designated Client on the Designated Blockchain Network as capable of: (i) being uniquely associated with or “owned” by a particular public-key address on the Designated Blockchain Network at each particular block height; and (ii) having Transfers of such digital unit recorded on the Designated Blockchain. + +(t) “**Transfer**” of a Token to a given address (the “***Receiving Address***”) on the Designated Blockchain Network will be deemed to have occurred if and only if it is recognized by the Designated Client on the Designated Blockchain Network that: (i) there has been duly transmitted to the Designated Blockchain Network a new transfer function transaction that:(A) provides for the reassociation of the Designated Token with the Receiving Address; and (B) is signed by a private key that is (or a group of private keys that together are) sufficient to authorize the execution of such transfer function; and (ii) such transaction has been Confirmed. + +### VII. Miscellaneous + +(a) *Amendments.* Any provision of this Charter may be amended, waived or modified only upon a vote in favor of such amendment, waiver or modification by the DAO Members through the Designated Smart Contract. + +(d) *Severability.* In the event any one or more of the provisions of this Charter is for any reason held to be invalid, illegal or unenforceable, in whole or in part or in any respect, or in the event that any one or more of the provisions of this Charter operate or would prospectively operate to invalidate this Charter, then and in any such event, such provisions) only will be deemed null and void and will not affect any other provision of this Charter and the remaining provisions of this Charter will remain operative and in full force and effect and will not be affected, prejudiced, or disturbed thereby. + +(e) *Construction.* Any rule of construction to the effect that ambiguities are to be resolved against the drafter shall not be applied in the construction or interpretation of this Charter. This Charter constitutes the entire agreement among the DAO Members with respect to the subject matter hereof and supersedes all prior agreements and understandings, both written and oral, among the DAO Members with respect to the subject matter hereof. + +(f) *Disputes; Mandatory Arbitration.* Any Legal Proceeding, Claim or other dispute or controversy arising out of or relating to this Charter, its enforcement, or the breach thereof shall be finally resolved by binding arbitration in accordance with the Arbitration Procedures; *provided, however*, that any DAO Member may seek injunctive relief in aid of arbitration in order to prevent irreparable harm or preserve the status quo. EACH DAO MEMBER HEREBY IRREVOCABLY WAIVES ALL RIGHT TO TRIAL BY JURY IN ANY ACTION, PROCEEDING OR COUNTERCLAIM WHETHER BASED ON CONTRACT, TORT OR OTHERWISE) ARISING OUT OF OR RELATING TO THIS CHARTER, THE DESIGNATED SMART CONTRACT, THE DAO MATTERS OR THE ACTIONS OF THE DAO MEMBERS IN THE NEGOTIATION, ADMINISTRATION, PERFORMANCE AND ENFORCEMENT OF THIS CHARTER. + +(g) *Governing Law.* All rights and obligations hereunder will be governed by the laws of _____________ /*INSERT DESCRIPTION OF LEGAL JURISDICTION--E.G. "the State of Delaware"*/, without regard to the conflicts of law provisions thereof. diff --git a/docs/papers & research/Audit-Report-for-SFT-aka-ZAP.pdf b/docs/papers & research/Audit-Report-for-SFT-aka-ZAP.pdf new file mode 100644 index 0000000..802c9df Binary files /dev/null and b/docs/papers & research/Audit-Report-for-SFT-aka-ZAP.pdf differ diff --git a/docs/SFT-Protocol-Yellowpaper.pdf b/docs/papers & research/SFT-Protocol-Yellowpaper-deprecated.pdf similarity index 100% rename from docs/SFT-Protocol-Yellowpaper.pdf rename to docs/papers & research/SFT-Protocol-Yellowpaper-deprecated.pdf diff --git a/docs/papers & research/ZAP-Whitepaper.md b/docs/papers & research/ZAP-Whitepaper.md new file mode 100644 index 0000000..62f17f1 --- /dev/null +++ b/docs/papers & research/ZAP-Whitepaper.md @@ -0,0 +1,378 @@ +# ⌁⌁ZAP⌁⌁ +## THE ZEROLAW org-AUGMENTATION PROTOCOL + +### 1. Introduction + +The ZeroLaw org-Augmentation Protocol (ZAP) is a general-purpose tech/law stack for augmenting any business entity or organization through the use of smart contracts and tokens deployed to Ethereum or any other EVM-based blockchain. It is non-rent-seeking, fully free and open source and is neither funded by nor requires the use of any protocol token. It is intended to be compatible with a range of legal compliance strategies or applicable legal regimes by providing tunable compliance parameters; it is even compatible with antilaw positions. ZAP’s compliance parameters may be tuned 'all the way up,' 'all the way down' or anywhere in between; thus, ZAP is suitable for any entity or organization, ranging from traditional corporations to anarchic, pseudonymous collectives. ZAP merges the vision of a borderless, decentralized future with the power to comply with existing legal requirements & best practices for doing business. ZAP has been developed by ZeroLaw, an independent law/technology team working to make technology and legal agreements interoperable. Anyone may contribute to the protocol. + +ZAP's highly modular architecture is divided into Components, with each Component being a tech/law dyad consisting of: + +* on the law side: legal agreements, statutes and/or rules expressed in natural language +* on the tech side: a system of interlinked smart contracts coded in Solidity + + + ZAP Orgs may differ significantly from one another depending on the type of entity or organization being augmented through the protocol. This paper aims to explain a prototypical ZAP implementation, with notes regarding how parameter settings might differ among Org types. + +###Important Disclaimer - Please Read! + +ZAP, this paper, the ZAP source code and the other ideas, documents and materials referenced herein or included in any ZeroLaw or ZAP software repository (the “**_ZeroLaw Materials_**”) are not intended to be, or to serve the purposes of, legal, accounting, tax, investment, or other advice or services. There is no attorney-client or other representational or fiduciary relationship between ZeroLaw or any person affiliated or otherwise connected with or representing ZeroLaw or who has or will contribute to the ZeroLaw Materials (each, a “**_ZeroLaw Participant_**”), on the one hand, and any reader, recipient or user of the ZeroLaw Materials (each, a “**_ZeroLaw User_**”), on the other hand. The ZeroLaw Materials are being provided on an as-is basis and for informational purposes only, and should be considered highly experimental and unreliable. Any use of the ZeroLaw Materials should be vetted with an attorney and other applicable professional advisors. No ZeroLaw Participant is making any statement, representation, warranty, guarantee, or assurance that any of the ZeroLaw Materials is suitable for any purpose or complies with any applicable law. No ZeroLaw Participant has promised or is undertaking to provide any assistance, service or guidance to any ZeroLaw User. + +## 2. The Org Component + +### OrgLaw + +The law of the Org is its spirit. The OrgLaw comprises the Org's constitutional or charter principles (whether or not expressed in a written document), and, if it is a state-chartered Org, the applicable authorizing legal regime. For example, if the Org is a Delaware corporation, its OrgLaw will be its certificate of incorporation and bylaws, together with the Delaware General Corporation Law. If the Org is a DAO*, then the OrgLaw may be an informal, mutable social contract or community understanding based on the members’ shared values along with any rules relating to partnerships or unincorporated associations that apply in relevant jurisdictions. + +The relationship between the OrgLaw and the OrgCode is complex, nuanced, and potentially bidirectional. The OrgLaw may define the rules, regulations and agreements that are to be implemented in the OrgCode. Alternatively, OrgLaw may consist of rules, regulations and/or agreements specifying a “code deference” approach to governance. Code deference approaches may be absolute or qualified and complete or partial. + +|||| +|--- |--- |--- | +|Code Deference Approach|Complete|Partial| +|Absolute|"Code Is Law" For All Org Governance|"Code Is Law" For Governance of Some Aspects of Org| +|Qualified|All Org Governance Defers to Code, Except in Limited Cases Like Consensus Attack, Court Orders, Etc.|Some Aspects of Org Governance Defer to Code, Except in Limited Cases Like Consensus Attack, Court Orders, Etc.| + + +For an example of qualified partial code deference, see [The Model DAO Charter](https://). + +**A Word On “DAOs”** The term “DAO” is probably one of the most ambiguous and widely misused in the blockchain/DeFi community. In this paper we use the term “DAO” to refer to a type of Org—meaning that a DAO is a code/law dyad, just like any other Org. The OrgLaw for a DAO may be anarchic, but that is still a form of social agreement which we regard as ultimately legalistic (and potentially binding) in nature. DAOs may also be subject to default laws included in their OrgLaw, even if the DAO members are unaware of such default laws—for examples, in common law jurisdictions DAOs may be general partnerships by default. Unless otherwise expressly stated, we do **not** use the term “DAO” to refer solely to a smart contract that automates treasury, voting and liquidation functions for an Org—rather, we refer to such a smart contract as the OrgCode for a DAO, or as the 'DAO smart contract'. + +We also adopt the following DAO typology: + +* 'GrantDAOs' -> grant-giving (MolochDAO) +* 'VentureDAOs' -> venture capital (TheDAO by slock.it) +* 'GovDAOs' -> protocol/DAPP governance (MakerDAO) +* 'PACDAOs' -> political (YangDAOofficial) +* 'ShadowDAOs' -> hacktivist/anon (?) + +### B. OrgCode + +If the OrgLaw is the soul or mind of the Org, then the OrgCode is the Org’s CNS. The OrgCode consists of a smart contract deployed to the blockchain as an instance of [`OrgCode.sol`](https://github.com/zerolawtech/ZAP-Tech/master/contracts/OrgCode.sol). Other smart contracts become part of the OrgCode by becoming connected to the OrgCode via the applicable [association method](https://sft-protocol.readthedocs.io/en/latest/issuing-entity.html#associating-contracts), either through an owner- or administrator-controlled association process or through a more open process, depending on the configuration of the Org in question. The OrgCode then either implements or extends the OrgLaw by administering these ancillary smart contracts. For example: + + +* ShareCode contracts (i.e., instances of `BookShare.sol` or `CertShare.sol`) must be associated to the OrgCode before OrgShares can be transferred, so that the OrgCode can accurately track holder addresses + +* IDcode contracts (i.e., instances of `OrgIDVerifier.sol` or `RegistrarIDVerifier.sol`) must be associated to the OrgCode to provide any identity confirmation data that may be required by the ShareLaw before new addresses/persons can receive or send OrgShares + +* Custodian contracts (i.e., contracts inheriting from `iBaseCustodian.sol`) must be associated to the OrgCode in order to send or receive OrgShares, and the OrgCode is also where any applicable restrictions will be set on a custodian contract + + +The OrgCode is administered by a standard multi-sig permissioning scheme inherited from [`MultiSig.sol`](https://sft-protocol.readthedocs.io/en/latest/multisig.html#multisig). The owner(s) of the OrgCode (one or more blockchain addresses declared as owners in the OrgCode constructor) may access any administrative function of the OrgCode. Owners may also delegate administrative function access to one or more additional authorities (one or more blockchain addresses declared as authorities through the `.addAuthority` method). Authorities are approved by owners on an administrative-function-by-administrative-function basis via the function `_signatures` parameter of `.addAuthority`; such `_signatures` may include any administrative function other than the `.addAuthority` method itself, which can only be called by owners. Both owner and authority rights to can be tied to a multisig threshold via the `_threshold` parameter. Authority permissioning may additionally be time-limited via the `_approvedUntil` parameter. The parameters for existing owners and authorities can be modified later via various specialized methods. The same permissioning scheme can be extended to the Org's custom modules (see Section 5 below). + +This scheme is very powerful and flexible, accommodating a wide array of potential use cases and compliance techniques. For example, an Org that is a corporation could configure each issuance of an OrgShare token to be authorized by two addresses respectively controlled by the President and Secretary of the corporation. This would mirror the two-officer signature requirement for stock certificates imposed by most states’ corporation statutes. + +## 3. The Shares Component & IDVerifier Component + +### A. ShareLaw + +#### i. Intro to ShareLaw + +On the social/legal layer, OrgShares are transferable legal rights pertaining to the Org. You can think of OrgShares as the reification of the rights conferred upon particular Org participants by the OrgShare. + +Below are some illustrative examples, for various Org types, of how the ShareLaw of those Org types could be/often would be configured: + +|||| +|--- |--- |--- | +|Org Type|OrgShare Type|ShareLaw| +|Corporation (DE)|Capital Stock|DGCL, Certificate of Incorporation, Bylaws, U.S. Federal Securities Laws, Ordinary Income Tax (mostly)| +|LLC (DE)|Membership Interests|DLLCA, Operating Agreement. U.S. federal securities laws, Partnership Income Tax (mostly)| +|GrantDAO (e.g.—MolochDAO)|membership interest|Quorum-less majority voting, Ragequit, Rough social norms & floating delegations communicated through member-only channels| +|VentureDAO (e.g. TheDAO)|investment contract interest in decentralized venture fund|misc. governance arrangements, Securities Laws, Unclear taxation—likely partnership| +|Other DAOs|Misc.|Misc.| + + +#### ii. Share Instruments + +In the immediately preceding section, we discussed how the ShareLaw divides determines the type of OrgShares—for example, whether the OrgShares are capital stock, club memberships, investment contracts, or something else. However, those types of categories are essentially classifications of types of rights—they are very abstract. The ShareLaw does not stop there—it also classifies types of OrgShare _instruments_. + +Instruments are methods of representing, and evidencing ownership over, OrgShares. Although the distinctions among types of instruments may appear dry and technical, they are critical from a legal perspective. Many other security token protocols ignore this issue and do not clearly and consistently treat tokens as belonging to a defined category of legal instruments. Under corporate and commercial law, the type of instrument by which an OrgShare is transferred will determine what formalities need to be followed with respect to transactions such as transferring ownership of the OrgShare or pledging the OrgShare as collateral for a loan. + +Under the Uniform Commercial Code, there are three types of securities instruments: + +* certificated +* uncertificated (aka “book-entry”) +* account-based/entitlement-based + + +It is critical that the instrument type for each OrgShare be explicit so that each person transacting in the OrgShare knows what type of instrument he or she is dealing with. For example, if a lender is extending credit to a shareholder and taking a security interest in the OrgShare as collateral, the lender cannot know how to perfect its rights to foreclose on the OrgShare in an event of default unless it knows the instrument type of the corresponding token: if the token is a securities certificate, then the lender can take possession of the token and be assured of having a first-priority security interest; on the other hand, if the token is a book-entry representation of the OrgShare, then the lender must notify the Org to ensure that the Org notes the encumbrance on the Org’s books and does not make alternative transfers. + +As further discussed below under “ShareCode,” ZAP accommodates blockchain equivalents to all three types of instrument. Although each instrument type has pros and cons, and such pros and cons may differ depending on the relevant type of Org in question, in general ZeroLaw believes tokens functioning as securities certificates are work better on a public permissionless blockchain because they create the opportunity for finer (and potentially more liberal) transferability tuning and chain-of-title analysis, which can be vitally important in securities transactions. The lending example above leads to one illustration of how the certificated model is a far more natural fit for blockchain, as people will naturally wish to view possession of a token representing an OrgShare or the locking up of that token in a multisig smart contract as a form of possession of a securities certificate in token form that ought to create a senior, perfected security interest in the OrgShare as collateral. For a very in-depth discussion of this topic, _see_ “_[Representation of Corporate Capital Stock via Cryptographically Secured Blockchain Tokens: Motivations and Potential Implementations](https://gabrielshapiro.wordpress.com/2018/10/28/2/)”_ by Gabriel Shapiro. + +### iii. Transfer Restrictions + +An Org may desire to (or, depending on the applicable law, may be required to), limit the transferability of OrgShares. OrgShare transfer restrictions constitute part of the ShareLaw, and such aspects of the ShareLaw may in many cases be programmatically enforced in the ShareCode. + +There are three main types of transfer restrictions: + +* identity-based +* transaction-based +* vesting-based (may be time-based, service-based or milestone-based vesting); + + +Transfer restrictions typically arise from four main sources of law (or a combination thereof): + + +* securities laws (if the OrgShares are securities) +* general regulatory requirements such as export/sanctions controls, money transmitter laws, etc. +* legal contract or other private agreement +* misc. commercial laws and property laws + + +Transfer restrictions will typically apply at one of the following levels of granularity (or a combination thereof): + + +* all OrgShares; +* all OrgShares of a given class or series; +* specific OrgShares +* any/all OrgShares held by or on behalf of a specific individual or entity (or a single address associated to a given individual/entity) or smart contract + + +Transfer restrictions will typically apply in one or both of the following markets: + + +* primary market (Org → shareholder) +* secondary market (shareholder-->shareholder or shareholder-->Org) + + +Below are some illustrative examples, for various Org types, of common transferability restrictions + + +|||||| +|--- |--- |--- |--- |--- | +|Transfer Restriction|Type(s)|Law Source|Granularity|Market| +|not owned/transferable until time T|vesting|contract law|specific OrgShares|primary & secondary| +|not transferable if post-transfer Org would have more than 499 unaccredited shareholders or more than 1,999 total shareholders|transaction-based & identity-based|SEC Rule 12g-1|all equity securities OrgShares|secondary| +|not transferable to an unaccredited investor in a private placement where issuer is relying on Rule 506(c)|Identity-based & transaction-based|SEC Rule 506(c)|specific OrgShares or all OrgShares of a class/series|primary| +|if a “restricted security,” not transferable during first 12 months after issuance, except to qualified institutional buyer (QIB)|transaction-based w/ identity-based exception|SEC Regulation D & Rule 144, Rule 144A|specific securities OrgShares|secondary| +|no transfer by an affiliate of the issuer unless disclosure requirements, volume limitations, and manner of sale conditions have been met, except to QIBs|identity-based w/ identity-based exception|SEC Regulation D, Rule 144|any/all securities OrgShares held by or on behalf of a specific holder|secondary| +|not transferable except in compliance with ROFR and co-sale procedures|transaction-based|ROFR and Co-Sale Agreement|typically all OrgShares or all OrgShares of a given class/series; sometimes further limited to large holders only|secondary| +|not transferable to individuals/entities appearing on OFAC’s specially designated and blocked persons (SDN) list|identity-based|misc sanctions regulations and executive orders|all OrgShares|primary and secondary| +|not transferable in a manner utilizing OrgShares as a convertible virtual currency|transaction-based|money services business regulations|all OrgShares|secondary| +|not transferable to a known DEX or other exchange address, or third party custodian, that is not a registered securities exchange or ATS or registered broker/dealer|identity-based|securities laws|all securities OrgShares|primary and secondary| +|no transfer by a holder subject to an injunction not to make the transfer (could be bankruptcy-related, divorce-related, etc.)|identity-based|misc. laws|any/all OrgShares held by or on behalf of a specific holder|secondary| +|no transfer of a share encumbered by a perfected first-priority lien, except to the lienholder|transaction-based w/ identity-based exception|private agreement, misc. property laws|specific OrgShares|secondary| + +An Org may not wish to or be required to implement all types of transfer restrictions. Nevertheless, a robust general-purpose Org augmentation protocol must be **able to** accommodate all such transfer restrictions and more. Otherwise, a protocol will effectively be requiring Orgs to choose between taking advantage of the efficiencies of the protocol and non-compliance (or high risk of non-compliance) with applicable law. On the other hand, the protocol should not assume that every Org will need to comply with all such transfer restrictions and should recognize that, consistent with the politics and ideals of decentralization, Org administrators should minimize their power to censor transactions to the greatest extent possible without violating the law. Therefore, while transfer restrictions & associated permissioning schemes must be possible, they must also be optional and tunable. This is the approach embodied in ZAP. + +#### iv. Identity-Based Restrictions + +As noted above, many potential transfer restrictions are identity-based. Complying with such transfer restrictions will require an off-chain identity documentation process capable of verifying that a particular prospective Shareholder is a certain person in the real world, the blockchain addresses belonging to that person, the legal jurisdictions relevant to that person and that the person satisfies any applicable “accreditation requirements” and does not appear on (or reside in a country that appears on) any applicable sanctions lists. Many ID verification services exist, including ones that verify the “accredited investor” status of investors under U.S. federal securities law. We anticipate that, over time, vendors who provide such services will supplement them with blockchain-specific subservices, such as maintaining lists of blockchain addresses associated with DEXs or centralized exchanges which an Org may desire to prevent from receiving OrgShares. + +The Org’s chosen off-chain verification processes provide the content for whitelists and blacklists. + +Whitelists are essential when OrgShares should only be issued and/or transferred to certain types of person. Let us consider an example relating to both primary market and secondary market transactions: the restriction of transfers on OrgShares that are securities sold in a SEC Rule 506(c) private placement. To qualify for Rule 506(c), the issuer must verify that all of the primary purchasers of the OrgShares are “accredited investors.” When those OrgShares are sold, they will initially be “restricted securities”—meaning that the purchasers cannot resell the OrgShares until 12 months from the date of the initial sale. However, the 12-month restriction, in turn, has an identity-based exception: the OrgShares may be resold to persons who are verified to be “qualified institutional buyers” (QIBs). Thus, the Org’s whitelist should include both verified “accredited investors” and verified “QIBs”. These whitelists could either be compiled by the Org itself (or a service provider acting on behalf of the Org), and thus essentially be private, Org-specific whitelists, or they could be master lists directly or indirectly licensed to the Org by vendors who specialize in compiling and maintaining such lists. + +Blacklists are perhaps even more important. While it is theoretically possible for OrgShares to be freely tradeable in general (for example, if the OrgShares are not securities, or if they are SEC-registered securities), it will nevertheless nearly always be true that at least certain types of persons should be excluded from owning OrgShares. Consider some examples: Orgs subject to U.S. jurisdiction will be prohibited from transacting business with persons listed on OFAC’s [specially designated and blocked persons (SDN) list](https://www.treasury.gov/ofac/downloads/sdnlist.pdf), and would be well advised to comply with those prohibitions; similar lists exist in most other jurisdictions. + +Other reasons for blacklisting may be more Org-specific. For example, a commercial Org may wish to prevent its competitors from acquiring its OrgShares. An Org whose OrgShares are securities may wish to take reasonable precautions to reduce the likelihood that the OrgShares will be transferred to known custodial cryptocurrency exchanges or cryptocurrency DEXs that are not legally permitted to facilitate trading of securities. If the OrgShare is a non-security under EU law but would be a security under U.S. law, then the Org may wish to blacklist any person known to be a U.S. citizen or resident. If the OrgShare is a security issued by a U.S. issuer under a Regulation S exemption, then the Org may wish to blacklist all U.S citizens and residents for a period of 12 months to prevent flowback and remain eligible for the exemption. + +So far, we have mainly discussed commercial and regulatory reasons why identity verification, whitelisting and blacklisting can matter. However, even ShadowDAOs might require the power to whitelist and blacklist persons as part of practicing good OpSec and maintaining cultural consistency. For example, a hacktivist cooperative may wish to restrict transfers of its Shares to nation-state actors or ideologically opposed groups. The “rating” process for such a ShadowDAO may be binary—you’re either in or you’re out—but a form of minimal ID-verification may be needed to confirm that the person in control of a particular forum handle is also in control of a particular blockchain address. + +Similarly, a DAO organized around local politics may wish to ensure that Shares can only be held by residents of the applicable municipality. If a group of developers is selling a token intended not to be a security, then that group may wish to only allow transfers of that token to individuals who pass a series of Q&As and tests proving that they are not buying for investment purposes, as contemplated by the Brooklyn Project’s [Consumer Token Framework](https://collaborate.thebkp.com/project/BKP/document/1/version/2). Alternatively, if a DAO or similar association wishes to allow free transferability, then that principle may be enshrined in its ShareLaw, and there will be no whitelists or blacklists. Thus, the ShareLaw Component, including the identity verification aspects thereof, augments, rather than limits, Orgs’ autonomy. + +### B. SharesCode + +#### i. OrgShare Instruments as Tokens + +On the tech layer, OrgShares are represented as tokens on the blockchain, with each token having programmatically tunable levels of transferability. The tokens are thus transferable instruments representing OrgShares, and can be classified as certificates, book entries or entitlements. + +ZAP represents certificated shares as non-fungible tokens (NFTs) issued by an instance of [`CertShare.sol`](https://github.com/zerolawtech/ZAP-Tech/master/contracts/CertShare.sol). Just as paper stock certificates issued by a corporation have unique identifying numbers, each ‘token-cert’ is uniquely identifiable by ID#. This enables powerful and useful functionality: for example, imposing share-specific transfer restrictions, or tracing the provenance of particular shares in a mixed account. + +Although token-certs are instruments representing OrgShares, there is a layer of separation between them and the Org. Just as paper stock certificates can change hands without the corporation that issued them either being on notice of, approving or recognizing, the transfer, so, too, token certs can be transferred independently from the Org (assuming the absence of on-chain transfer restrictions) without the Org needing to know the identity of the transferee or approve such transfer in advance. Just as a paper stock certificate can be stolen or destroyed without the true owner of the stock losing his or her legal ownership rights in the stock, so too, if a token certificate is transferred accidentally, or the owner loses the key or has it stolen, this does not entail a change in ownership rights over the corresponding OrgShares. + +This layer of separation between the Org and the token certificates representing OrgShares has many implications. On the one hand, it allows OrgShareholders greater immediate property rights over their OrgShares, since they can be transferred quite freely. On the other hand, transferees run a greater degree of risk in such transactions than they do in purchases of book-entry shares. Whereas a book-entry share transfer inherently requires the Org's approval, a transfer of a token certificate does not. In theory, this means that the transfer could be prohibited by the Org without the would-be transferee knowing it, in which case the would-be transferee might have paid for the OrgShares but not be entitled to exercise ownership rights with respect to the OrgShares. + +Even when the transfer of OrgShares is legal, the Org will likely take the position that if a token certificate representing an OrgShare has been transferred to a new address, the holder of that OrgShare will not be able to vote on Org issues or received Org dividends until completing the appropriate ID verification procedure. These issues can be mitigated to an extent by careful planning and coding, but never completely—unlike a cryptonative asset like BTC or ETH, the tokens are a representation of an OrgShare, not identical with an OrgShare, and thus it is possible in corner cases for the symbol to become detached from the legal rights it is supposed to symbolize. + +ZAP can also represent OrgShares in book-entry form. ZAP represents book-entry shares as fungible tokens issued by an instance of [`BookShare.sol`](https://github.com/zerolawtech/ZAP-Tech/master/contracts/BookShare.sol). Under that approach, the blockchain becomes the Org’s official share ledger and transfers of the tokens represent official changes to the OrgShare's ledger. If the Org is a corporation, this approach is explicitly permitted under the Wyoming and Delaware corporate statutes (with Wyoming’s version of the statute even allowing for transfers to be recorded as changes in owners represented as blockchain address rather owners represented as the legal names of persons). + +Since the blockchain is meant to be the Org’s official share ledger, the degree of separation between the Org and the secondary market that exists with token-certs does not really exist under the book-entry approach. The Org will be deemed to have approved or given official effect to any transfer of an OrgShare that gets recorded on the blockchain. Therefore, the Org will likely want to adopt the tightest possible transfer restrictions and institute manual review procedures to ensure that it is not officially recording a prohibited transfer of OrgShares. This is more cumbersome than the certificated system described above, but does offer an advantage to third parties who might be considering acquiring OrgShares—they can know from the state of the blockchain that the Org regards the history of transfers as valid. + +Although in general we believe the main benefit to deploying an Org on the blockchain is the resulting disintermediation, and thus anticipate that few Orgs will tend to represent their OrgShares through account-based/entitlement-based instruments, ZAP nevertheless has the capability of doing so. ZAP represents entitlement-based OrgShares as tokens held by a special type of custodial smart contract deployed as an instance of OwnedCustodian.sol or IBaseCustodian.sol. Such OrgShares may also be conceptualized as simply being token-certs that are held by a custodian or book entries that are marked as giving authority to custodians. For more on custodial smart contracts, see below. + +#### ii. Code-Enforced Share Transfer Restrictions + +Transfer restrictions can be encoded in the smart contract rules governing transfer of the tokens representing the OrgShares, and thus enforced programmatically. This reduces monitoring and enforcement costs and can thus facilitate freer transfer even of restricted securities than might otherwise be feasible. + +Direct transfer restrictions are set by the owner or another appropriately permissioned authority of the Org smart contract (an instance of OrgCode.sol). Such restrictions can be set at various levels of granularity: + +* identity-based transfer restrictions—i.e., restrictions on all OrgShares held by a particular shareholder or custodian—are set by calling OrgCode.setEntityRestriction with the unique HashID of the restricted holder (_see below_ under “ID Verification” for more on HashIDs) + +* restrictions on all of the OrgShares or all of the OrgShares of a given class or series—i.e., restrictions on particular OrgShares, regardless of who holds them—are set by calling OrgCode.setTokenRestriction + + +It is also possible to impose various other types of transfer restrictions indirectly. An Org may define a limit on the number of unique shareholders it will have. Such a limit may be defined on a per-Org, per-country and/or per-accreditation-type basis. + +For example, if the OrgShares are equity securities and the Org is a pre-IPO company that has or will be expected to have $10M+ in assets, the Org will want to prohibit any transfer of OrgShares that would result in the Org having more than 499 unaccredited shareholders or more than 1,999 overall to prevent itself from having to “go public” prematurely under SEC Rule 12g-1 / Section 12(g)(1) of the Securities Exchange Act of 1934. Such investor limits have the same effect as transfer restrictions because programmatically prevent transfers that would cause the Org to violate the applicable condition. An example of a situation in which restrictions by country would be important would be where an Org wishes to take advantage of Regulation S so that a particular issuance of OrgShares is not covered by U.S. law and thus programmatically prohibits all transfers of OrgShares to U.S. citizens and U.S permanent residents, either indefinitely or for a period of time (e.g., the 12-month anti-U.S.-flowback period for equity securities sold by a non-reporting issuer in a Category 3, Regulation S offering). + +Shareholder counts and limits are stored in `uint32[8]` arrays. The first entry in each array is the sum of all the remaining entries. The remaining entries correspond to the count or limit for each accreditation level. Setting an investor limit to 0 means no limit is imposed. The issuer must explicitly approve each country from which investors are allowed to purchase tokens. It is possible for an issuer to set a limit that is lower than the current investor count. When a limit is met or exceeded existing investors are still able to receive tokens, but new investors are blocked. + +Investor limits are configured with setter functions called on the OrgCode (the Org’s instance of OrgCode.sol). + +The setter method OrgCode.setCountry approves or prohibits a country’s citizens or permanent residents from being shareholders and sets investor limits within that country. Its parameters are as follows: + +* `_country`: the code of the country to modify +* `_permitted`: permission bool +* `_minRating`: the minimum rating required for an investor in this country to hold tokens. Cannot be zero. +* `_limits`: a `uint32[8]` array of investor limits for this country which essentially supplies investor limits in a destructured variable assignment. The seven positions in the array correspond to the seven possible shareholder accreditation types. If there are fewer than seven possible accreditation types, the remainder will be set to “0”. For example, for U.S. issuers, there are likely to be three accreditation types—unaccredited, accredited and QIB—and thus four of the array elements would typically be 0 + +`OrgCode.setCountries` is a similar setter method that enables approving many countries (with corresponding per-country investor limits) at once without per-country differences in limitations that vary based on the shareholder’s accreditation level. + +The setter method `OrgCode.setInvestorLimits` sets total shareholder limits for the Org by accreditation type, irrespective of country. This is likely to be the most common setter method used by early, pre-public ZAP orgs. For example, a U.S.-based Org whose OrgShares are equity securities would call issuer.setInvestorLimits with argument `[1999, 499, 0, 0, 0, 0, 0, 0]`—meaning that OrgShare transfers which would result in the Org having more than 1,999 shareholders overall (inclusive of accredited shareholders) or more than 499 unaccredited shareholders will be programmatically blocked. Thus, the Org would prevent itself from prematurely becoming an Exchange-Act-reporting company under SEC Rule 12g-1/Section 12(g)(1) of the Exchange Act. + +An important caveat: In configuring its transfer restrictions, an Org will be relying upon various assumptions that tie into its off-chain identity verification procedures—for example, it will assume that the representations made by prospective shareholders during the identity verification process (e.g. that they are buying shares for their own account and have sole control over an blockchain address) are accurate. While these process-backed assumptions are not perfect, they are ultimately no more risky or uncertain than the working assumptions adopted by ordinary off-chain companies today. Indeed, one can argue that the risks for on-chain Orgs are lower, since ordinary companies cannot programmatically enforce their investor limits but must rely solely on contractual covenants to avoid gaining more investors than they intended. + +Such assumptions may be more or less conservative, depending on the Org’s preferences. For example, a conservative Org may wish to assume that it reach $10M in assets at any time, and thus always set shareholder limits below the Rule 12g-1 thresholds. Another Org could might be willing to grow its shareholder base beyond those limits on the assumption that it will not reach $10M in assets. As a general purpose Org augmentation protocol, ZAP is designed to accommodate a wide array of risk preference choices. + +#### iii. ID Verification + +The technology-based components of the ID verification process will typically consist of three tools: + +* an encrypted off-chain database of personally identifiable information (PII) regarding current and prospective Org members, which may include each such person’s: + * full legal name + * country and region (encoded under the [ISO 3166 standard](https://sft-protocol.readthedocs.io/en/latest/data-standards.html) for storage in `OrgIDVerifier.sol` or `RegistrarIDVerifier.sol`) + * rating (non-accredited, accredited, QIB, etc.—varies by issuer & jurisdiction—will be represented by an arbitrary uint8 in `OrgIDVerifier.sol` or `RegistrarIDVerifier.sol`) + * tax ID # + * one or more public blockchain addresses + * a required renewal date (will be represented in epoch time in `OrgIDVerifier.sol` or `RegistrarIDVerifier.sol`) + * the `KECCAK256` hash of a subset of the foregoing PII (the IDHash) + +* an Org-specific smart contract (deployed as an instance of `OrgIDVerifier.sol`) which, for each Org member, stores a mapping of that Org member’s IDHash to the Org member’s country code, region code, rating code (reflecting “accredited” status or lack thereof), required renewal date and blockchain address(es) (RegistryData) + +* an inter-Org smart contract (deployed as an instance of `RegistrarIDVerifier.sol`) which stores the RegistryData of current and prospective members of many Orgs—such inter-Org registrars would likely be deployed and maintained by independent third parties running businesses related to securities tokens; for example, professional transfer agents or investor-accreditation-check services + + + +`OrgIDVerifier.sol` and `RegistrarIDVerifier.sol` essentially function as on-chain whitelists, but they only store IDHashes. Without access to the information contained in the private off-chain database of personally identifiable information, it would be impossible to correlate a particular IDHash with a particular person. Nonetheless, it is possible that the on-chain registrar smart contracts will be subject to GDPR or other privacy regulations, and the public nature and practical irreversibility of the blockchain may thus place the ZAP protocol at risk of being non-compliant, depending on the details of the Org. We anticipate that zero-knowledge proof and other techniques will eventually be added to address these issues. + +`IDBase.getID` is a public function of `OrgIDVerifier.sol` and `RegistrarIDVerifier.sol` which accepts an IDHash as an argument. Thus, anyone can call `IDBase.getID()` to determine the blockchain address(es) and legal jurisdictions associated with an IDHash in the applicable smart contract registry. + +`OrgIDVerifier.sol` and `RegistrarIDVerifier.sol` are both “owned” smart contracts, with “owner” being an administrative role assignable to one or more blockchain addresses at the time of deployment. In the case of `OrgIDVerifier.sol`, the owner will be the OrgCode (the smart contract deployed as an instance of OrgCode.sol for the applicable Org). The owner of `RegistrarIDVerifier.sol` will be an arbitrary blockchain address, which is likely to be controlled by a third party maintaining both an off-chain database and the registrar smart contract as a paid service. + +Additional authorities (beyond “owner”) can be permissioned to call one or more administrative functions of the ID smart contract, either generally or solely with respect to persons located in one or more countries covered by that authority. In the case of `OrgIDVerifier.sol`, such permissioning will piggyback on the authority scheme of `OrgCode.sol`; in the case of `RegistrarIDVerifier.sol`, authorities will be added directly. This granularity would enable a ZAP Org to appoint different transfer agents in different countries, each with the authority to perform administrative functions pertaining to and only to investors subject to the transfer agent’s jurisdictions. Although such functionality may not be important for the smaller, privately controlled Orgs that are likely to be the initial users of ZAP, they will be critical when ZAP Orgs are global public entities with shareholders in many jurisdictions, each with its own ever-shifting laws, rules and regulations. + +The ownership and authority schemes in `OrgIDVerifier.sol` and `RegistrarIDVerifier.sol` can be combined with a standard MultiSig Implementation to impose M-of-N multisig rules regarding the combination of owners or authorities that is necessary to add new persons to the whitelist or add or remove restrictions from persons who are already on the whitelist. + +## 4. The Custodial Component + +### A. Custodial Law + +In the traditional financial world, custodians for securities and other assets are commonplace. Although blockchain offers the opportunity for more direct interactions between an Org and its shareholders than is typical for many public companies, we nevertheless recognize that custodial arrangements will continue to have a role even for blockchain-augmented Orgs. Therefore, ZAP seeks to trust-minimize custodial arrangements to the greatest extent possible. + +Custodial arrangements may be necessary or desirable in a number of contexts. For example, Section 17(f) of the Investment Company Act requires registered management companies to custody their securities with a securities custodian such as a qualified bank, national securities exchange or securities depository. We envision a future in which digital securities deployed to public blockchains are ubiquitous and Orgs enter into triparty agreements with the investment companies who own the OrgShares and the qualified securities custodians who hold the OrgShares on behalf of the investment companies. These agreements could provide that custody of the OrgShares is maintained in transparent, trust-reduced custodial smart contracts that give both the Org and the investment companies relevant administrative powers such as the ability to ensure that the custodian does not violate transfer restrictions applicable to specific OrgShares. Eventually, such smart contract arrangements could become so feature-rich and reliable that they might lead to changes in law--for example, Section 17(f) might be amended to eliminate the requirement for a third-party custodian if an appropriate smart contract is used to safeguard the investment companies' assets as well or better than trusted custodial intermediaries. + +### B. Custodial Code + +Custodial smart contracts are approved to hold tokens representing OrgShares on behalf of multiple investors. Each custodial contract must be individually approved by an Org’s owners or administrators (through an association of the custodial smart contract with the OrgCode) before receiving tokens. + +There are two broad categories of custodial smart contracts: + + +* *Owned* custodial smart contracts; they are controlled and maintained by a known legal entity such as a registered securities broker/dealer or a centralized securities exchange or cryptocurrency exchange. + +* *Autonomous* custodial smart contracts are autonomous in that once deployed there is no authority capable of exercising control over the contract. Autonomous custodial smart contracts will be useful for escrow arrangements, implementation of privacy protocols and the operation of decentralized exchanges. + + +As discussed above, an Org may need to carefully limit the number of investors it has in order to avoid opting into expensive regulatory regimes. For this reason, ZAP embodies conservative assumptions regarding how ownership of custodied OrgShares is counted. When an investor transfers a balance into a custodian it does not increase or decrease the overall investor count; instead the investor is now included in the list of beneficial owners represented by the custodian. Even if the investor now has a balance of 0 in their own wallet, they will still be included in the Org’s investor count. + +#### i. Custodial Token Transfers + +There are three types of token transfers related to Custodians. + + +* *Inbound*: transfers from an investor into the Custodian contract +* *Outbound*: transfers out of the Custodian contract to an investor’s wallet +* *Internal*: transfers involving a change of ownership within the Custodian contract. This is the only type of transfer that involves a change of ownership of the token, however no tokens actually move + +Importantly, internal transfers are subject to the same permissioning regime established by the OrgCode. + +Permissioning checks for custodial transfers are identical to those of normal transfers. `OrgShare.checkTransferCustodian` checks if a custodian internal transfer of tokens is permitted and returns `true` if the transfer is permitted. If the transfer is not permitted, the call will revert with the reason given in the error string. + + +`BookShare.transferCustodian` modifies investor counts and ownership records based on an internal transfer of ownership within the Custodian contract. + + +## 5. Misc. Additional Legal Considerations & Org Modules + +### A. Introduction to ZAP Modules + +ZAP supports custom modules. Modules can be dynamically attached and detached from the OrgCode via OrgCode.attachModule and OrgCode.detachModule. ZAP’s modularity is designed to maximize gas efficiency - modules may be detached as soon as they are no longer needed, and may even adjust their own hook points or detach themselves during the course of their lifecycle. + + There is no limit to the ways that OrgLaw can be encoded and programmatically enforced through such modules. For example, the current version of ZAP includes: + +* the Waterfall Module (`Waterfall.sol`), a venture-capital-style preferred stock module that will honor the liquidation preferences and conversion features of preferred stock in a dividend, merger or other distribution event + +* the Dividend Module (`Dividend.sol`), a module for automated distribution of dividends to OrgShare holders + +* the Options Module (`VestedOptions.sol`), a module for automated vesting and exercise of stock options + +* the Governance Module (`Governance.sol`), a minimal voting/governance module allowing for the supply of OrgShares to be throttled by a mandatory vote of current shareholders + + +Other possibilities including adding modules to handle crowdsales, country/time based token locks, automated right-of-first refusal procedures, complex shareholder votes, tender offer execution and bond redemption. + +### B. Venture Capital Considerations & Preferred Stock Liquidation Module + +Blockchain-based smart contracts, paired with tokenized OrgShares, create a powerful tool for venture-backed companies with complex preferred stock capital structures, partnerships with tiered distribution waterfalls and any Org with mezzanine debt. As envisioned by Vice Chancellor J. Travis Laster of the Delaware Court of Chancery: + + >By accurately programming different classes or series of preferred stock [to] carry different voting rights, conversion rights, payment rights, and other features…up front, a complex capital structure can be administered automatically, without human intervention. If, for example, the corporation wishes to issue additional shares, but a particular series of preferred stock has a blocking right, then the stock ledger could be coded to prevent the shares from being issued unless the requisite vote is received. Smart contracting technology also could be used to implement conversion provisions and would simplify the often difficult task of calculating conversion rates, particularly when anti-dilution formulas come into play. If the features were programmed accurately up front, then the calculations would take place automatically. + +ZAP is working toward realizing this vision in a number of ways. + +The experimental Waterfall Module, [`Waterfall.sol`](https://github.com/iamdefinitelyahuman/ZAP-Tech/blob/waterfall/contracts/modules/Waterfall.sol), encodes the distribution rules for a corporate-style Org's entire capital structure: common stock, common stock options, and any number of series of preferred stock. This enables automatic and trust-reduced distribution to all OrgShareholders of their respective portions of any and all dividends, merger consideration and liquidation proceeds that the Org might have occasion to pay out to OrgShareholders. + +Preferred stock will typically be convertible to common stock at some ratio and have a 'liquidation preference' that is hard-coded at the time of issuance and taken into account by the Waterfall Module in allocating distributions. Varieties of preferred stock recognized by the Waterfall Module include fully participating, partially participating and non-participating preferred stock; given a distribution amount, the Waterfall Module will determine whether the preferred stock should be treated on a preferred-stock basis or an as-converted-to-common-stock basis (i.e., which treatment will result in a greater payment to the preferred stock) and allocate the distribution amount accordingly. The Waterfall Module can also pay out stock options on a net-exercise basis by deducting the exercise price of the option from the otherwise applicable per-share merger consideration. + +For example, if the Org is a 'target' Org to be acquired by an 'acquirer' Org in a statutory merger pursuant to which the acquirer Org becomes the owner of all OrgShares, the acquirer Org would deposit the merger consideration in the form of ETH, DAI or another token on the applicable blockchain to the address of a smart contract escrow. The merger consideration would then automatically be divvied-up in accordance with the liquidation priorities of the different stockholders, with preferred stockholders at the top of the stack and common stockholders at the bottom--unless the preferred stock is getting paid on an as-converted-to-common-stock basis or is participating, in which case the preferred stock would be pari passu with the common stock for all or a portion of the merger consideration. The allocated amounts would be distributed to the addresses where the stockholders held the token-certificates representing the various issued and outstanding shares of capital stock or stock options. + +Today in regular M&A deal execution, these processes require a cadre of lawyers, transfer agents, escrow agents and payment agents. The roles of these intermediaries and trust holes, and the manual and error-prone processes they rely upon, could be dramatically reduced or, in certain cases, even completely eliminated with ZAP. Alternatively, the Waterfall Module can be used simply to calculate the relevant amounts in a transparent and trust-reduced manner, and distribution could then be handled on a more ad hoc basis--entirely on-chain, entirely off-chain, or partially on-chain & off-chain. This should be the future; it just makes sense. + +The Governance Module, [`Governance.sol`](https://github.com/zerolawtech/ZAP-Tech/master/contracts/modules/Governance.sol), is a minimal proof of concept that may be used as a starting point for enabling OrgShareholders to vote on governance issues. It can be combined with a checkpoint module to build whatever specific setup is required by an Org. Although the current version is modest in scope, it provides a critical function for corporate-style Orgs--namely, requiring OrgShareholder approval before increasing the number of shares of a given class or series of stock that the corporation is authorized to issue. This vote is also legally required in the case of corporations, and takes the form of stockholders voting on a proposed amendment to the corporation's certificate of incorporation. With ZAP, that vote can be held on chain. + +### C. Unique Challenges Posed by the Contractual Nature of OrgShares + +OrgShares are bundles of legal rights associated with a blockchain token that functions as a transferable instrument. Unlike with typical ERC20 tokens or other 'bearer instruments' such as protocol tokens, persons in markets for stock, membership interests or other types of shares, or even debt instruments like bonds, typically consider it important to ensure that buyers and sellers of the instrument understand that the instrument represents a bundle of legal rights and the nature and limitations of those legal rights. + +In traditional equity markets, purchasers of securities typically have sufficient information to evaluate their investment decision because: + +1. they are buying from a stock exchange or broker-dealer where all the assets available are typically shares of corporate common stock having very similar terms; +2. the shares in question are those of very well known public corporations who are registered with the SEC and all of whose governance documents (certificate of incorporation, bylaws, etc.) can be accessed by anyone on [https://www.sec.gov/edgar/](https://www.sec.gov/edgar/); and +3. they are piggybacking off of the due diligence and analysis conducted by a wide variety of market “gatekeepers” such as attorneys, underwriters, securities analysts, stock exchanges like NASDAQ and NYSE, broker/dealers, proxy advisory firms like ISS, institutional shareholders and the SEC, any or all of which would be apt to identify and publicize any particularly off-market features (like CEO voting control in the case of companies like Facebook). + +One might consider traditional securities markets, interfaces and intermediaries as providing a kind of custom UX which puts the buyer of a security on notice regarding the nature of the instrument and associated rights. As a result of this custom UX, it would be surprising if, for example, a person bought a share of Apple common stock but believed they were buying a bond or a cash credit for the Apple store. In the unlikely event such confusion were to occur, it would almost certainly be a result of 'user error' in the un-ironic sense--a kind of willful blindness to the information available. + +In contrast, blockchain tokens typically do not represent bundles of legal rights, and they trade freely through any blockchain wallet or blockchain software client rather than solely through broker-dealers with fiduciary and disclosure obligations. Transactions in ordinary ERC20 tokens may occur through a variety of interfaces and instrumentalities, whether on a p2p basis or by means of centralized cryptocurrency exchanges (e.g. Binance, Kraken and Coinbase) or decentralized exchange smart contracts (e.g., Uniswap and 0x). In general, a user transacting through such interfaces could reasonably believe the token they are buying is a cryptonative asset rather than a contractual right. + +Although user confusion is always undesirable, when it comes to transactions in securities instruments, it could be disastrous. No company should want to sell its shares to a person who thinks those shares are a utility token. This could lead to significant confusion--for example, a buyer might not be on notice that the token it holds could be converted into another token pursuant to a merger transaction under applicable law. A buyer might not know that it needs to contact the issuer and supply a Form W-9 in order to receive dividends on the share. A buyer might not understand that it has the right to vote on certain corporate transactions, or might not receive proxy statements explaining the proposals to be voted upon. + +Thus, along with blockchain’s tremendous potential for decentralizing transactions and opening new markets comes a resulting vacuum of infrastructure and best practices within those markets. If the OrgShares of pre-IPO Orgs become tokenized and freely transferable on a trust-reduced basis, the informational mechanisms that exist for traditional public equities will not be available to ensure that purchasers of these OrgShares are fully informed. + +The Org and its members should care about this issue, for several reasons. Most importantly, the Org and its members will not want to face lawsuits from individuals who believed they were acquiring a token that had different economic or legal features than the OrgShare does. The Org will also want to ensure that any limitations of legal liability, transfer restrictions or other contractual arrangements involved in membership in the Org are specifically consented to by each OrgShare holder; otherwise there is a risk they will not be legally enforceable against the OrgShare member—in the context where transfer restrictions and may be automatically enforced, this is arguably even more important, since the purchaser will literally be unable to perform certain kinds of transactions with the token. Finally, as discussed in more detail below, treating the tokens representing OrgShares consistently with their intended function of being contractual instruments will mitigate the risk of them being deemed convertible virtual currencies and the Org being regulated as a money services business. + +An additional concern is that money transmission is a highly regulated activity. Regulation of money transmission and regulation of securities instruments historically have been handled under completely separate and mutually exclusive statutory regimes. With blockchain, however, the distinctions between securities and money are eroding, creating the potential that a single token may be simultaneously regulated as both a security and a currency, and a single token issuer may be regulated both as a securities issuer and a financial institution. For example, the U.S. Financial Crimes Enforcement Network (FinCEN)'s recent guidance memorandum entitled ["Application of FinCEN’s Regulations to Certain Business Models Involving Convertible Virtual Currencies"](https://www.fincen.gov/sites/default/files/2019-05/FinCEN%20CVC%20Guidance%20FINAL.pdf) contains the following somewhat surprising guidance, which establishes how secondary trading of OrgShares may subject unwitting Orgs to all the same regulations as bonafide money transmitters like PayPal merely if the token certificates representing the OrgShares trade too freely and become used as general substitutes for value: + +>money transmission could involve...the issuance and subsequent acceptance and transmission of a digital token that evidenced ownership of a certain amount of a commodity, security, or futures contract...\[I]f assets that other regulatory frameworks define as commodities, securities, or futures contracts were to be specifically issued or later repurposed to serve as a currency substitute, then the asset itself could be a type of value that substitutes for currency, the transfer of which could constitute money transmission. Therefore...money transmission may occur when a person (or an agent, or a mechanical or software agency owned or operated by such person) not exempt from MSB status:...issues physical or digital tokens evidencing ownership of commodities, securities, or futures contracts that serve as value that substitutes for currency in money transmission transactions + +Idealistically, one might bemoan the fragmentary and myopic nature of these regulations, as well as their political motivations, but for practical purposes an Org would be well advised to seek to avoid being deemed a money transmitter and solely function as a partnership actively co-managed by all partners or as a securities issuer with a mix of active managers and passive investors. In doing so, Orgs will need to ensure that there are appropriate 'frictions' that put users on notice that they are buying an OrgShare, not a currency. + +Addressing these issues creates a unique challenge for blockchain-augmented Orgs: namely, how can the Org ensure that a person who has the UX of simply transacting with one token among many knows that the token they are transacting in is not a cryptonative asset, not a utility token, but rather is a very specific OrgShare with very specific legal rights and limitations attached? To achieve this in the context of public unpermissioned blockchains, new information channels and consent mechanisms will be required. However, these mechanisms should be designed in a way that preserves the peer-to-peer, trust-reducing virtues of blockchain by avoiding the reintroduction of gatekeepers and intermediaries; otherwise, what is the point of using a blockchain at all? + +In an ordinary client-server architecture, the solution would be simple—force users to buy through your app and present them with the appropriate contract to sign as part of the transaction flow. An Org may try to approximate something similar in the blockchain context by creating its own custom interface or wallet for reading from/writing to the blockchain and interacting with blockchain nodes, and such an interface could provide context-specific UX supplying current and prospective Org members with useful notices about the legal terms of the OrgShares, transfer restrictions applicable to OrgShares and other material information. An Org may also publicly encourage persons transacting in OrgShares to do so only through the Org's official wallet so that they understand the nature of the rights associated with the token they are transacting in. However, because of the permissionless, decentralized architecture of Ethereum and other similar EVM-based blockchains, an Org can never be certain that all OrgShare transactions will occur through the Org's official interface. Buyers or sellers of OrgShares may still use the clients, wallets, and other means of interacting with the applicable blockchain and network; in such cases, the Org will have no control over the user experience, and there will be a risk that persons buying the token will not understand that it is an OrgShare and carries certain rights as well as certain limitations such as transfer restrictions. + +ZAP thus addresses this issue in at least two ways: + + +* ZAP trust-minimizes the authentication of legal documents pertaining to the Org. The Org admins can record the hash of a legal document (e.g., the Org’s certificate of incorporation, or a Shareholders’ Agreement) to the blockchain via the OrgCode (the Org’s instance of OrgCode.sol). Current or prospective shareholders who receive the document through potentially compromised or secondhand sources can then verify that the hash of the document matches the recorded hash available from the OrgCode. This process can also assist with version control, since Org governance documents may frequently be amended and shareholder will want to ensure they are working from the most current version. + +* In a future version of ZAP, we intend to add a module that enables Orgs to gate sales/purchases of OrgShares in the secondary market with an automated escrow process. This would enable issuers to ensure that the contractual terms of OrgShares are agreed upon by future buyers, without representatives of the Org needing to manually permission each OrgShare transaction. Each OrgShare purchase/sale could be required to be effected through a smart contract escrow. The OrgShare tokens and the purchase price (any tokens on the applicable blockchain) would be deposited into the escrow smart contract. The would-be purchaser would be directed to a website to e-sign an acknowledgement of having received disclosures regarding the nature of the OrgShares. The hash of that acknowledgement and the purchaser's blockchain address could then be recorded to the smart contract escrow, evidencing that the information had been received and the acknowledgement signed, whereupon the OrgShare tokens would be automatically transferred to the address of the purchaser and the token-denominated purchase price would be automatically transferred to the address of the seller out of the smart contract escrow. The smart contract escrow could also be configured to permit termination by the would-be seller if the required documents are not proffered by the would-be purchaser within some specified period--e.g. 48 hours. Upon a termination, the OrgShare tokens and purchase price tokens would revert to the original owners, minus a penalty to be paid by the would-be purchaser for failure to deliver the documents within the required time. In effect, this arrangement would simulate a traditional share purchase agreement which is signed by the parties on one date and then provides for a later 'closing date' triggered when various conditions precedent--such as the signing of additional documents by one or more parties--have been satisfied. This is a 'smart contract' along the lines originally proposed by Nick Szabo--i.e., a mechanism for automated and trust-reducing the performance-or-breach structure of a share purchase agreement. + +### 6. Conclusion + +Thus concludes the ZAP Whitepaper. + +We welcome all contributors to ZAP, both legal and technical. If you are interested in contributing, please email g.shapiro@zerolaw.tech (legal) and/or b.hauser@zerolaw.tech and a.firmani@zerolaw.tech (code). + +If you are interested in engaging the ZeroLaw team to implement ZAP for your organization, please contact g.shapiro@zerolaw.tech, b.hauser@zerolaw.tech and a.firmani@zerolaw.tech. + +Please keep in mind the disclaimers provided at the beginning of this whitepaper, and use ZAP responsibly. + +Hack on! \ No newline at end of file