Crypto Legal Risk Checklist
By Fatemeh Fannizadeh, Silke Noa
Crypto projects involve various areas of legal risks, which are difficult to identify and quantify. This is due to the fact that legacy legal systems, their laws, processes and their jurisprudence are regularly ill-suited to the intricacies of decentralised, permissionless, and perhaps autonomous open-source technology.
Innovation in the space often means that projects or products have a strong financial and tokenized component potentially running afoul with legacy system’s financial regulations, tax laws or consumer laws, to just name a few. Being investigated by (sometimes several) financial or tax authorities for allegedly failing to comply with laws and regulations can have serious undesirable consequences. However, it is also undesirable to be radically risk averse and therefore overcomply, i.e. to go beyond one’s obligations, which slows down innovation, prevents potentially positive disruption and sets a negative precedent for the crypto space.
We therefore find it crucial for any crypto project to conduct a thorough and honest assessment of its legal risks early on. Identifying legal risks early on in the design process may allow projects to find (often simple) technological solutions that reduce the project’s regulatory burden long-term. Mapping the likely legal implications of a product/project is a demanding task and the availability of lawyers who understand the technological and regulatory nuances across multiple jurisdictions is currently low.
This draft checklist, first prepared for a talk at EthCC[4] in July 2021, aims to help projects, their stakeholders and lawyers to better understand and navigate crypto legal risks. It draws on our experience advising blockchain projects over several years. The checklist is not exhaustive, and should not be interpreted as implying any form of risks or favoring any type of behaviour. It simply acts as a starting point to initiate a broader discussion around legal risks mitigation for decentralised permissionless crypto projects. Let’s all share our research and thoughts to better tackle these sensitive questions!
COLLABORATION
We invite everyone to suggest corrections, additions or any other type of modification to this doc and warmly thank those who provided feedback. Please contribute your knowledge and let’s open source all things legal, to drive innovation and better coordination across our crypto ecosystem.
Feel free to propose an edit to this resource or write to the original authors at oscryptolaw@gmail.com with any other comments. We are looking forward to your input!
The Checklist
Please consider the following areas of concerns and questions about the current and future situation of your product and project. Answer each question, and include actions to be taken, if any, and the timeframe. It could be useful to highlight how and when you think the answers to these questions will change in your specific case.
Date of assessment:
A. POTENTIAL HARM AND BENEFIT
A.0. Identify the stakeholders of your product/project. Who can affect or be affected (whether positively, negatively or in a neutral manner) by your product/project?
A.1. How does your project benefit the world? Explain its positive impact and in which way it brings positive innovation to your space and to whom exactly. Why should it exist?
A.2. Can your product or its use cause harm, and if so, to whom? (e.g. hack, bugs, exploits, direct and indirect harm, intentional and unintentional etc.)
A.3. Does or could the product’s code have bugs that may cause users to lose funds? What mitigation measures have been/will be put in place to avoid hacks, exploits, bugs and by whom? (e.g. formal verification, audits, bounties etc.)
A.4. Do you have a process to monitor the occurrence of potential exploits, hacks, or bugs? Is there a process in place to deal with the consequences of exploits, hacks, or bugs?
B. REGULATORY PRODUCT DESIGN
B.1. Does your product/project as envisaged or implemented comply with the laws of the jurisdiction(s) of incorporation (if any); the domiciles of the shareholder/management/members/core contributors; the users/target markets; and other notable stakeholders?
This assessment is not black and white. Identify what laws and regulations could be applicable, which ones could be used against the product and particularly the particular aspects of the product. Also identify which regulations are in your favour (e.g. data privacy laws), enable you or could provide a defence.
B.2. In your role with regard to the product/project, would your team or anyone thereof qualify as a financial service provider or a similarly regulated role in relevant/chosen jurisdictions?
B.3. In your role with regard to the product/project, would your team or anyone thereof qualify as a virtual asset service provider or a similarly regulated role in relevant jurisdictions?
B.4. What are the data protection requirements that could be applicable to you in relevant jurisdictions? Can you comply with them, and if so, how?
B.5. Are there any new laws or regulations that may enter into force that could change the assessments above? Try to identify the risk thereof.
C. (DE)CENTRALISATION
C.1. Has the core team ceased control over the product/project? Has the team control over certain functions or over de facto necessary components for the product to function or to be used?
List all centralised points, such as relayer services, centralised websites, backend services maintained or those functions where manual signatures/input are required.
C.2. Are there many contributions from third-parties (devs, community, marketing, design, or any other field)? If the product/project (or part thereof) is permissionless, do third parties in fact contribute and take over functions (execution, deployment, liquidity provision, market creation) or does the core team maintain the permissionless system (e.g. is liquidity only provided by you even though third parties could do so but don’t)?
C.3. Are the communication channels (twitter, discord, telegram, etc.) community run or run by some third party? If so, who finances that? If not, do you plan for this in the future, and if so, when and how?
C.4. Is the project’s token a governance token? Describe why and how.
C.5. Does the token have a utility? Does the token serve a purpose for your product/project, and if so, which one(s)? Is there a payment use case?
C.6. What rights do the token give to holders, if any? What are the tokenomics?
C.7. How is the token being originally distributed? Is it an ICO, token sale, IDO, or TGE, or a similar event where the user pays to receive the tokens? Is it an airdrop or merkledrop (which requires persons to actively claim the tokens)? Why this choice over another?
How can one acquire the token after the initial launch and distribution? (primary or secondary markets, centralised or decentralised markets, mining, yield farming etc.)
C.8. If the issuance is a token sale, are any know-your-customer and AML checks conducted? Is the sale restricted to only qualified/accredited investors?
C.9. If the issuance is a token drop, are there any strings attached to qualifying for the token drop (eg. writing a blog post, tweeting, etc.) and how do those strings benefit the product/project?
C.10. If the issuance is a token drop, is it a “fair launch” with no tokens to the team or investors? If you aim for a “fair launch”, define what this means in your context.
C.11. How is the token supply allocated? What are the distribution percentages? What percentage of the supply does the team hold? In the case of a governance token, can the team force a decision? Is the team’s token holding crucial to form a quorum to pass a proposal? Do you have whales, such as pre-launch investors?
C.12. Was the token transferable from its creation or did it gain transferability through a community proposal and vote?
If it was non-transferable at the beginning, for how long did it stay non-transferable? Who decided on the deployment and transferability of the token?
C.13. Does the token give meaningful power to the token holders over the product/project? Explain and define it yourself.
C.14. If the project is a DAO or is in any way governed by the community, do third parties submit proposals? If so, are those proposals successfully passed?
C.15. How many frontends/GUIs are there? Are there centralised frontends? If so, who deployed and maintains them?
C.16. Are there any centralised frontends provided or deployed by third party entities? Is there a programme to incentivise the provision of frontends? If so, who incentivises the frontends?
C.17. If you provide centralised frontend(s), for example on AWS, where are those servers located? Is your product legally compliant in those jurisdiction(s)? What percentage of traffic or trading volume is generated through your frontend? To use your product, must everyone, even a technologically savvy person, interface with your frontend or data on your frontend? Conversely, can a person avoid reliance on your frontend by transacting directly on the blockchain? Does anyone do this?
C.18. Are the frontends hosted serverlessly, such as on IPFS, Arweave, Swarm etc.?
C.19. Do you have a DAO? If so, describe its structure and how it is governed.
C.20. Does your product require resorting to an oracle or other off-chain data input? Who is the oracle/provider of data input? Is the data decentrally procured? Who resolves disputes in relation to the oracle/provider or data? Do you resort to decentralised/third party dispute resolution? Who is the arbiter over the validity of off-chain data?
C.21. Do you require a person to open an account with you to interact with your product (e.g. by providing email address and other data)?
D. (UN)SECURITY RELATED
D.1. Are the tokens being sold directly by the project or by the issuer? If so, do you require regulatory approval in a jurisdiction where token recipients are located?
D.2. Will your product be ready, and if so to what extent, when the tokens are distributed?
D.3. Does the token have a use case other than fundraising and speculation?
D.4. Is there a general expectation on your core team to further develop the product/project? If the core team stops working, how will it impact the project?
D.5. Is there a reference price at the time of issuing the token (for instance if you had private or pre-sales)?
D.6. Do you have a convincing argument (and informed the public to that effect) that: the tokens are to govern the product; the tokens have no monetary value; and are not for investment and speculative purposes?
D.7. Are you planning to approach and/or discuss with market makers, exchanges, etc. prior to launch of the product and/or distribution of the token?
D.8. What are the safeguards you put in place? (e.g. geoblocks, terms and conditions, disclaimers, banners, information material, KYC, AML checks)
D.9. Do you charge a fee for usage of your product? Is the fee charged on a frontend or on protocol level? To whom does that fee get paid out?
D.10. If there is a fee, do you require users to use a certain token (e.g. a USD-pegged stablecoin)?
D.11. Do you or can you have control (even indirectly) over the smart contracts that enable token transfer?
E. CORPORATE SET UP
E.1. Should one or several legal entity(ies) be set up for your product/project? If so, why and where? How will they interact with each other, with the core team and stakeholders? Please also consider transfer pricing concerns.
E.2. How will your setup help mitigate legal risks for you and your stakeholders?
What impact will your setup have on other stakeholders and the crypto space in general, if any? (e.g. Does your setup restrict certain persons from becoming members of your community, shareholders, employees or contractors?)
E.3. Where are team members located and how does this provide substance for taxation purposes within the chosen corporate structure? May this draw your project/product unintentionally into a jurisdiction?
E.4. Are there investors or potential investors, stakeholders or regulators that require you to have a certain entity form in a specific jurisdiction?
E.5. Does the product/project need to have legal personality to interact with legacy systems (be able to sign contracts and have standing to sue/be sued)?
Could an unregistered DAO be fine for this purpose?
E.6. In the case of unregistered DAOs, who should be the contractual counterpart to third parties? Do you have volunteers within the team or the community? If so, how will you structure their exposure to liabilities?
E.7. Does the team consider limited liability (having a corporate veil) important or are members comfortable with being exposed to potential unlimited and/or joint and several liability? Can you assess the risks? If not, why?
E.8. In case of an unregistered DAO, could the DAO have any (contractual or quasi-contractual) agreements in place to limit the liability of agents and owners (Participation Agreement, Operating Agreement, Constitution, Bylaws, etc)? What risks are covered by the agreement and which ones are not?
E.9. Are you dealing with off-chain assets (trademarks, copyright, etc)? What are those assets?
E.10. How are those off-chain assets managed?
E.11. Do you want to hire staff as employees (as opposed to consultants or contractors) and if so, where and why?
E.12. Are team members and other persons with whom you interact comfortable to freelance with (1) a legal entity and/or (2) unincorporated entity?
E.13. How are consultancy fees/salaries paid?
E.14. If you plan to compensate team members in tokens, are there any restrictions on token payments in the jurisdictions of those team members? Should it matter to you (e.g. if the obligation lies with you as an employer)?
F. TAX RELATED
F.1. Where, if anywhere, do you intend for the project to be tax liable? Does your tax advisor agree the project will be tax liable there (and only there)? May it be tax liable elsewhere, where and why?
F.2. If you wish to be taxed on an entity level, do you have sufficient substance in the jurisdiction of incorporation to have your tax liability accrue there?
F.3. In which jurisdictions do you have collaborators (employees, contractors etc)? What are the risks of the entity/project becoming tax liable there?
F.4. If you have a centralised management, where is it primarily located? Are you OK with the entity being taxed there?
F.5. If you conducted a token sale, what are your tax obligations arising out of it and where?
F.6. Did you procure tax advice (several) in the relevant jurisdictions?
G. GENERAL
G.1. Do you document your legal and regulatory efforts and narrative (i.e. curate a trail)?
G.2. How can you build, ship and decentralise fast(er)?!
G.3. Did you inform your users of the risk to which they expose themselves using your product, the ways they can protect themselves and the absence of any recourse towards you should a risk materialise (e.g. through terms and disclaimers)? This is particularly important in unaudited alpha/beta versions.
How do you test your products? Any tests in production?
G.4. Are your terms or disclaimers binding on the users? Do users have to actively consent? Do they have to sign a consent which is timestamped?
G.5. Do you have an effective dispute resolution framework in place to avoid a formal dispute resolution such as lawsuits/binding arbitrations?
G.6. Do you get your legal advice in written form?
G.7. Did you enter into a D&O insurance for your key or generally exposed personnel and/or do you have a segregated defence fund (a pool of money purposed for future legal defence needs)?
DISCLAIMER
The checklist is provided as an informal tool persons may wish to consult when setting out on structuring a new product or project in the blockchain space. While oftentimes regulation is jurisdiction specific, the checklist is not focused on any one jurisdiction, but aims to address some common themes. The blockchain regulatory climate is constantly evolving and regulatory considerations may change at short notice. We make no representations as to the checklist’s quality, accuracy, completeness or suitability, and disclaim any duty to keep this information current or accurate.
The checklist is provided on an “as is” and “as available” basis. The checklist does not constitute legal advice. In no event shall the authors and contributors be liable for any claim, damages or other liability or regulatory action, whether in an action of contract, tort or otherwise, arising from, out of or in connection with the provision of this Checklist.
Do your own research and thank you!