Blockchain: Future Legal Issues

50 %
50 %
Information about Blockchain: Future Legal Issues

Published on June 15, 2019

Author: markradcliffe

Source: slideshare.net

1. Mark Radcliffe DLA Piper Future Legal Issues PLI

2. www.dlapiper.com • Regulatory Issues • Liability for developers • Lex cryptographica 2 Overview

3. www.dlapiper.com • Who regulates what? • SEC • CFTC • Money transmitter • State laws • Wyoming: exemption for “utility tokens” • International regulatory regimes 3 Regulatory Issues

4. www.dlapiper.com • Performance Liability for Software • Are developers of blockchain technologies fiduciaries to other network participants (reasoning easily extended to all software)? • Tort liability: what are the rules? • Regulatory Compliance Liability for Software Developers 4 What about Liability for Developers and their Decisions?

5. www.dlapiper.com 5 Potential Effect on Blockchain Ecosystem Bad Theories Make Bad Law

6. www.dlapiper.com • Professor Walch: IN CODE(RS) WE TRUST: SOFTWARE DEVELOPERS AS FIDUCIARIES IN PUBLIC BLOCKCHAINS • Public blockchains are critical infrastructure • Governance is based on decisions relating to software development and implementation of the consensus protocol • Critical issues • Who is responsible for coding decisions in a decentralized ecosystem • Possible application of fiduciary duty (similar to officer and directors in corporations as well as lawyers and doctors) • Focuses on developers of “blockchain clients” not developers of “smart contracts” which depend on the blockchain clients 6 New Theory: Coders of Public Blockchain Protocols as Fiduciaries

7. www.dlapiper.com • Professor Tamar Frankel summary • Offer mainly services (not products) that are socially desirable • To perform effectively, fiduciaries need to be entrusted with power or property • This “entrustment” poses the risk to the “entrustors” that the fiduciary will not be trustworthy and misappropriate the power or authority • Likelihood that entrustors will: • Fail to protect themselves from the risks from violations of duty by fiduciary • Markets may also fail to protect entrustors from violations of duty by fiduciary • Costs for establishing trustworthiness higher than benefits of the relationship 7 What is a Fiduciary?

8. www.dlapiper.com • Encouraging developers to perform their duties with deliberation and care • Reduce harm by developers to others by acting without care or exploiting their role • Increase efficiency and economic activity due to reduction in investigation and due diligence needed • Creation of an accountability standard to match seriousness of their responsibilities 8 Advantages according to Walch

9. www.dlapiper.com • Potential inhibition of innovation • Blockchains are platform technologies and legal intervention should be at the application layer • Too extreme and too high a duty to place on the individuals • Impossible to determine whether fiduciary duty standards are met because of diverse interests of “entrustors” (or beneficiaries) • Deter programmers from participation in blockchain project • Users should do their due diligence and this approach is paternalistic • Unfair since developers do not expect this liability • Developers are not compensated as fiduciaries 9 Disadvantages according to Walch

10. www.dlapiper.com • Which developers are responsible and are fiduciaries? • Walch is unclear using the following formulations (see footnote 244 in Haque et al article) • “core developers” (pg 6) • “prominent developers” (pg 7) • “software developers” (pg 7 discussing the BTC fork) • “key developers” (pg 7 discussing the BTC fork) • “dominant developers” (pg 8 discussing the ETH fork) • “small number of developers” (pg 8 discussing the ETH fork) • Walch also notes that those who shape the code/functions but do not write code • Who are the “entrustors” to whom a fiduciary duty is owed? • What is the nature and scope of the fiduciary duty? 10 Open Issues in Walch Proposal

11. www.dlapiper.com • Developers are not “agents” of network participants (blockchain technology is implemented through clients running a particular protocol: the Bitcoin network is implemented through 22 different “clients” other that Bitcoin Core) • No authority to bind other network participants • Influence (speaking for the community is not enough) • No delegation of power or authority by network participants • Effect of changes to software on network participants is very attenuated 11 Industry Response: Haque/Plummer/Rosario I Blockchain Development and Fiduciary Duty

12. www.dlapiper.com • Other alternatives make “fiduciary duty” application unnecessary (Tamara Franklin limits fiduciary duty to relationships where the “entrustor” cannot otherwise protect himself from abuse of power) • Developers not incentivized to “act” improperly • Other problems: • Impractical to interpret: • Which “developer” owes a fiduciary duty? • Who is the beneficiary of the fiduciary duty? • Risk of developers abandoning projects 12 Industry Response: Haque/Plummer/Rosario II Blockchain Development and Fiduciary Duty

13. www.dlapiper.com • “Broadly speaking, a tort is a civil wrong, other than a breach of contract, for which the court will provide a remedy in the form of an action for damages.” • Tort Theories (US) • Negligence • Strict liability • Limits: Economic loss doctrine, limited to personal damages and property damages (no lost profits without other harm) 13 Tort Liability for Software Errors

14. www.dlapiper.com • State law with some special federal laws • American Law Institute has developed influential “Restatements” of the law, but the Restatement may be adopted by the relevant state courts • Status of Restatements • Restatement (Second) of Torts (1963/1979) • Restatement (Third) of Torts (2000) • Tort law in many states reflects principles found in the Restatement (Second) of Torts and over time, increasingly from the Restatement (Third) of Torts. However, state laws vary widely 14 Tort Law in the US

15. www.dlapiper.com • § 282. Negligence Defined • In the Restatement of this Subject, negligence is conduct which falls below the standard established by law for the protection of others against unreasonable risk of harm. It does not include conduct recklessly disregardful of an interest of others. • § 285. How Standard of Conduct is Determined. • The standard of conduct of a reasonable man may be established by a legislative enactment or administrative regulation which so provides, or adopted by the court from a legislative enactment or an administrative regulation which does not so provide, or established by judicial decision, or applied to the facts of the case by the trial judge or the jury, if there is no such enactment, regulation, or decision. 15 Negligence Theory: Restatement (Second) of Torts

16. www.dlapiper.com • § 402A. Special Liability of a Seller of Product for Physical Harm to User or Consumer. • A product is defective when, at the time of sale or distribution, it contains a manufacturing defect, is defective in design, or is defective because of inadequate instructions or warnings. A Product: • contains a manufacturing defect when the product departs from its intended design even though all possible care was exercised in the preparation and marketing of the product; • is defective in design when the foreseeable risks of harm posed by the product could have been reduced or avoided by the adoption of a reasonable alternative design by the seller or other distributor, or a predecessor in the commercial chain of distribution, and the omission of the alternative design renders the product not reasonably safe; • is defective because of inadequate instructions or warnings when the foreseeable risks of harm posed by the product could have been reduced or avoided by the provision of reasonable instructions or warnings by the seller or other distributor, or a predecessor in the commercial chain of distribution, and the omission of the instructions or warnings renders the product not reasonably safe. 16 Strict Liability in Tort: Restatement (Second) of Torts

17. www.dlapiper.com • One engaged in the business of selling or otherwise distributing products who sells or distributes a defective product is subject to liability for harm to persons or property caused by the defect. • A product is defective when, at the time of sale or distribution, it contains a manufacturing defect, is defective in design, or is defective because of inadequate instructions or warnings. A product: • (a) contains a manufacturing defect when the product departs from its intended design even though all possible care was exercised in the preparation and marketing of the product; • (b) is defective in design when the foreseeable risks of harm posed by the product could have been reduced or avoided by the adoption of a reasonable alternative design by the seller or other distributor, or a predecessor in the commercial chain of distribution, and the omission of the alternative design renders the product not reasonably safe; • (c) is defective because of inadequate instructions or warnings when the foreseeable risks of harm posed by the product could have been reduced or avoided by the provision of reasonable instructions or warnings by the seller or other distributor, or a predecessor in the commercial chain of distribution, and the omission of the instructions or warnings renders the product not reasonably safe. 17 Product Liability: Restatement (Third) of Torts

18. www.dlapiper.com • One engaged in the business of selling or otherwise distributing product components who sells or distributes a component is subject to liability for harm to persons or property caused by a product into which the component is integrated if: • (a) the component is defective in itself, as defined in this Chapter, and the defect causes the harm; or • (b) • (1) the seller or distributor of the component substantially participates in the integration of the component into the design of the product; and • (2) the integration of the component causes the product to be defective, as defined in this Chapter; and • (3) the defect in the product causes the harm. 18 Product Liability: Restatement (Third) of Torts (Components)

19. www.dlapiper.com • Negligence • Lack of reasonable man • Proof of causation • Substantial factor • Strict Liability in Tort • Limited to certain types of products • Policy decision by courts 19 Challenges of Applying Tort Theory to SW Development

20. www.dlapiper.com • Strict liability in tort should be applied to IoT devices, including software • Focus on “design” defects (other theories are defects during manufacturing and inadequate warnings) • CDT is most concerned about cybersecurity • Open issues • When is a digital product deemed defective? • Who is responsible for a defect? • Who is responsible for the damage caused by the failures of digital technologies? • Difficult issues • What is a digital defect? • How to allocate liability in supply chain? • Will software failure standards develop? 20 CDT Proposal: Strict Liability in Tort for IoT Devices (including software)

21. www.dlapiper.com • It may be necessary to treat open source software differently than closed source software. Often one cannot examine the codebase for closed source software due to technical protection measures and/or clauses forbidding such practices in End User Licensing Agreements. This means that bugs in that closed source software can persist, and place the safety of users of that software in jeopardy. Open source software, on the other hand, can be audited by users (or professional auditors) so as to identify and patch software bugs. If the concept of strict products liability is applied to incidents involving software failure, it may be necessary to establish whether closed source software should be treated differently. • However, open source software cannot be considered facially superior because it can be written in a way that is complex and thus difficult to understand. This would preclude users or experts from being able to adequately audit the software. To absolve those who write open source software entirely from liability may end up encouraging the opening up of existing closed source codebases but, at the same time, could encourage the unnecessary development of overly complex codebases. This would have the consequence of increasing the risk of software failure, a counterproductive outcome for user safety. Finally, open source software is commonly developed by communities of people. It may not be clear if and to whom liability could or should be allocated in the event that bugs in open source software contribute to incidents, which in turn cause physical harm or property damage. 21 CDT: Special Case of FOSS

22. www.dlapiper.com • Commodity Futures Trading Commission (“CFTC”) • Commissioner suggested that “smart contract” developers (not blockchain protocol developers) are liable for software which violates CFTC regulations • Is foreseeability part of the analysis • Securities and Exchange Commission (“SEC”) • EtherDelta decision 22 Liability for Regulatory Violations in SW Development

23. www.dlapiper.com • That leaves us with the developers of the smart contract code that underlies these event contracts, as well as the individual users who then use that code to create and wager on their own event contracts. The developers of the code could claim that they merely created the protocol and therefore have no control over whether and how users choose to use it once it is part of the public domain. They would place the liability on the individual users, who are the actual creators and counterparties of the event contracts. • In my view, this analysis misses the mark. Instead, I think the appropriate question is whether these code developers could reasonably foresee, at the time they created the code, that it would likely be used by U.S. persons in a manner violative of CFTC regulations. In this particular hypothetical, the code was specifically designed to enable the precise type of activity regulated by the CFTC, and no effort was made to preclude its availability to U.S. persons. Under these facts, I think a strong case could be made that the code developers aided and abetted violations of CFTC regulations. As such, the CFTC could prosecute those individuals for wrongdoing 23 Liability for Regulatory Compliance (Prediction Markets): CFTC Commissioner Brian Quintenz

24. www.dlapiper.com • After criticism by Coin Center, he expressed a willingness to review in a blog post on Coin Center: • The key determination in every matter concerns the developers’ intent. Questions that should be considered include whether the developers: 1) made modifications to the code that enhanced the unlawful activity; 2) promoted the unlawful activity through a website or marketing materials; or 3) had a financial stake in the unlawful activity. Another factor to consider is whether the code is narrowly designed to enable an unlawful purpose rather than broadly designed for legal activities. The more a code is narrowly tailored to achieve a particular end, the more it appears as if it was intentionally designed to achieve that end. Take for example, a computer code that is specifically programmed only to trade heavily on one side of the market during a future’s contract settlement period to purposefully distort the final settlement price either higher or lower, otherwise known as “banging the close.” If developers were aware that traders would use the program in this manner, the developers’ conduct begins to look a lot like classic aiding and abetting • https://coincenter.org/entry/how-the-cftc-can-take-a-pro-innovation-posture-while-maintaining- orderly-markets 24 Quintez Response to Coin Center Criticism

25. www.dlapiper.com • Coburn founded and ran EtherDelta which was a “decentralized exchange” for trading EC20 tokens • He wrote the code for EtherDelta • He did not register as an ATS as required for exchanges trading securities as required by the Securities and Exchange Act of 1934 • SEC investigated and reached a settlement with the following finding: • During the relevant period, Coburn founded EtherDelta, wrote and deployed the EtherDelta smart contract to the Ethereum Blockchain, and exercised complete and sole control over EtherDelta’s operations, including over the operations constituting the violations described above. Coburn should have known that his actions would contribute to EtherDelta’s violations and thus, under Exchange Act Section 21C(a), caused EtherDelta to violate Section 5 of the Exchange Act. 25 Liability for Regulatory Violations: EtherDelta

26. www.dlapiper.com • "When smart people hear the term ‘smart contracts’, their imaginations tend to run wild" • Definition: A self-executing contract written in computer programs that automatically execute the transaction if certain conditions under the programs are met • Can be used for many kinds of contracts: escrow, capital markets trading, real property and IP transfers, insurance claim processing, supply chain management and so on • A classic analogy to “smart contract”: vending machine (if coin is inserted, then automatically provides soda) • Issue: many contracts are not so simple 26 Smart Contracts: A New Potential Source of Liability

27. www.dlapiper.com • Smart contracts are software: all software has bugs • McConnell, Code Complete: Industry Average: "about 15 - 50 errors per 1000 lines of delivered code." He further says this is usually representative of code that has some level of structured programming behind it • The National University of Singapore (NUS) uncovered several severe smart- contract bugs: out of the 19,366 Ethereum smart contracts they analyzed, 8,833 of them had bugs! • Smart contract errors • TheDAO raised $165M in ether to fund Ethereum based projects (alternative to venture capital) • Hacker discovered flaw in the code and “diverted” $50M in ether • Community forked the Ethereum blockchain to recover the funds but significant minority view: Code is Law and did not fork • Parity Wallet: bug caused $30M in ether to be locked up in July 2017 27 Smart Contracts: Not so Smart

28. www.dlapiper.com • Proposed by Aaron Wright and Primavera De Filippi • Rules administered through self-executing smart contracts and decentralized (autonomous) organizations. As blockchain technology becomes widely adopted, centralized authorities, such as governmental agencies and large multinational corporations, could lose the ability to control and shape the activities of disparate people through existing means. As a result, there will be an increasing need to focus on how to regulate blockchain technology and how to shape the creation and deployment of these emerging decentralized organizations in ways that have yet to be explored under current legal theory. 28 Next Steps: Lex Cryptographica

29. www.dlapiper.com • Lex Cryptographica operates independently of governments • Is Lex Cryptographica superior to the rule of law? • Lawrence Lessig: “When government disappears, its not as if paradise will take its place. When governments are gone, other interests will take their place” • Risk of code is “law”: Rule by Autonomous Code • New issues • Establishing liability and responsibility in decentralized systems • What will replace regulation of “intermediaries” under traditional law • Intersection of Lex Cryptogaphica with traditional law 29 Rule of Law vs. Rule of Code

30. www.dlapiper.com • Walch In Code(rs) We Trust: Software Developers as Fiduciaries in Public Blockchains https://papers.ssrn.com/sol3/papers.cfm?abstract_id=3203198 • Haque, Seira, Plummer & Rosario Blockchain Development and Fiduciary Duty https://papers.ssrn.com/sol3/papers.cfm?abstract_id=3338270 • CDT Strict Products Liability and the Internet of Things https://cdt.org/blog/when-iot-kills- preparing-for-digital-products-liability/ • Quintez Response: https://coincenter.org/entry/how-the-cftc-can-take-a-pro-innovation-posture- while-maintaining-orderly-markets • Wright, Aaron and De Filippi, Primavera, Decentralized Blockchain Technology and the Rise of Lex Cryptographia (March 10, 2015). Available at SSRN: https://ssrn.com/abstract=2580664 or http://dx.doi.org/10.2139/ssrn.2580664 • Wright, Aaron and De Filippi, Primavera, Blockchain and the Law: The Rule of Code 30 References

31. Mark Radcliffe is a partner of DLA Piper USA, LLP, an international law firm with lawyers in over 30 countries and 80 cities. He earned a B.S. in Chemistry magna cum laude from the University of Michigan and a J.D. from Harvard Law School. Mr. Radcliffe’s practice focuses on representing corporations in their intellectual property and finance matters. In his thirty years practicing law in Silicon Valley, he has worked with a wide variety of companies from emerging growth companies such as Netratings, Cryptowerks, Propy, Slync, Doc.ai and Bulletproof360 Inc. to larger companies such as Sony Corporation, Siemens Corporation, Munich Re and AIG. He is the Chair of DLA’s Corporate Venture Practice Group and Open Source Practice Group. He has been advising on blockchain matter since early 2017 and open source licensing matters for over 15 years. He assisted Sun in open sourcing the Solaris operating system. He also chaired one of the four committees which drafted the new version of the GPL in 2007. He drafted the corporate formation documents for the OpenStack Foundation (with ATT, HP, Rackspace, Intel and IBM working on the drafting). He is outside general counsel for OSI (on a pro bono basis) and the Apache Software Foundation (on a pro bono basis) and works with the Linux Foundation on certain corporate matters Mark F. Radcliffe Mark F. Radcliffe Partner T: +1 650 833 2266 F: +1 650 687 1222 mark.radcliffe@dlapiper.com Education Harvard University (1981) J.D. 1998 Distinguished Alumni Award University of Michigan (1974) B.S., magna cum laude, Chemistry Université Paris Panthéon-Sorbonne I (1972) Admissions California Silicon Valley Office 2000 University Avenue, East Palo Alto, California, 94303-2214

32. Global Locations Australia Austria Bahrain Belgium Brazil Canada China Czech Republic Denmark Finland France Germany Hungary Italy Japan Kuwait Luxembourg Mexico Morocco Netherlands New Zealand Norway Oman Poland Portugal Qatar Romania Russia Saudi Arabia Singapore Slovak Republic South Africa South Korea Spain Sweden Thailand Ukraine United Arab Emirates United Kingdom United States Angola Botswana Burundi Colombia Chile Croatia Egypt Ethiopia Ghana Kenya Mauritius Mozambique Namibia Nigeria Peru Rwanda Senegal Tanzania Tunisia Uganda Zambia RELATIONSHIP FIRMSDLA PIPER OFFICES

33. www.dlapiper.com Thank you 33

Add a comment