By enabling new modes of human interaction, technological advancements catalyze the evolution of regulatory frameworks, tools, and approaches. The rate at which computer technology evolves outpaces that of legislation and rule-making. Our economy is increasingly structured not only by traditional fiduciary actors, but also by software systems, which allow assets to permeate markets rapidly and at a greater scale. Rightfully, scholars and regulatory officials are examining the liability frameworks for software developers, and blockchain technologies dramatically demonstrate the challenge of scrutinizing an interconnected software system. Blockchain technologies emerged outside of institutions, and blockchain-based transactions bypass regulatory control.
We have explored the governance role of blockchain developers for the two most prominent public blockchain communities and networks. When examining the incentives and operations of prominent public blockchains, the role played by core developers in the governance of these networks does not exhibit the structural dynamics that warrant the imposition of fiduciary obligations for the benefit of cryptoasset holders. These developers are structurally unable to make decisions to impose changes on participants in a network.
The Bitcoin project allowed for the transfer of value over a peer-to-peer network and the validating of such transfers through incentives that uses bitcoin, a cryptocurrency. Bitcoin’s most significant contribution to open source development may stem from the Bitcoin network’s ability to solve the “double spend problem,” which hampered all previous attempts to launch a peer-to-peer virtual currency system. Bitcoin founder Satoshi’s solution was to design an architecturally and politically decentralized payment transfer system that relies on a verification scheme that exposes tampering. By running the appropriate hardware and software and connecting to the internet, anyone can participate in this system to transact with anyone else. Furthermore, anyone can use her computer to participate in the system’s protocol for validating the record of transfer. This protocol is known as a Proof-of-Work (“PoW”) consensus mechanism, and participants in it are known as “miners.”
“Decentralized” Does Not Mean “Structureless”
When we refer to open source production and public blockchain networks, and in particular their governance, we do not assume that by virtue of being decentralized they are anarchic. We subscribe to the view that “[s]tructurelessness is organizationally impossible” and that “[a]ny group of people of whatever nature that comes together for any length of time for any purpose will inevitably structure itself in some fashion.” Therefore, it is useful to distinguish among participants in a network.
In the context of open source software production, the term “developer” may generally refer to unrelated individuals who play fundamentally different roles. When talking about public blockchain networks, it is first important to distinguish between developers contributing to the software application supporting the network (whom we refer to as “protocol developers”) from the developers building decentralized applications by coding and deploying program specific code known as “smart contracts” onto public blockchain networks (whom we refer to as “smart contract developers”).
Our use of the term “protocol developer” is admittedly a loose one, given that it refers to individuals playing a range of roles, all of whom contribute in some fashion to maintaining a software application. One role is the “catalyst” developer, who provides the impetus for the launch of a decentralized open source project and subsequently recedes from the networks’ governance. Another role is played by the developers who voluntarily contribute their efforts collaboratively to an existing open source project. Before analyzing these two roles more in depth, we should note that open source projects are often structured so that certain protocol developers have “commit access,” which allows them to incorporate changes into the public repository. Further, while open source developers are traditionally unpaid, certain protocol developers are employed by businesses or foundations associated with the open source project to which they are contributing.
Changes to a public blockchain network that affect the fundamental consensus rules of the protocol are rare, and when they do happen they occur as the result of informal coordination among the various participants through a complex multi-level political process.
Vitalik Buterin, the catalyst for the Ethereum network, provides a helpful framework for understanding public blockchain network governance and the role of developers in it. He describes blockchain network governance using a multilayered “coordination model.” At a fundamental – “Layer 1” – level, every formal participant has the ability to “run whatever software [application] they want in their capacity as a user, miner, participant, validator or whatever other kind of agent a blockchain protocol allows them to be.” The bottom layer provides formal network participants with ultimate decision-making authority regarding what software application to run or whether to update the software application with new versions. Due to the strong positive network effects of public blockchain networks, the decision of the formal participants is influenced by their perception of other formal network participants’ likely choices. The informal participants coordinate the formal participants’ decisions. The native cryptocurrency of the network aligns the incentives of the network participants; participants all have a stake in maintaining or increasing the value of the native cryptocurrency.
Network participants can also exert influence over a public blockchain’s governance through “hard forks,” which implement code changes that “loosen” the consensus rules of a blockchain’s protocol (i.e., the rules become broader, allowing for previously disallowed blocks to be treated as valid). Hard forks are therefore not “backwards compatible,” meaning that full nodes that do not upgrade to the new implementing software application (or simply implement a software application with different consensus rules and create a new chain) will not accept blocks created by miners running the upgraded software application. While soft forks can be implemented by miners only, the implementation of hard forks requires every formal participant to choose to upgrade to the new implementing software application. Hard forks therefore represent a permanent divergence from the previous version of the Blockchain.
The Improper Fit of Corporate Fiduciary
Scholarship on the law of fiduciary duties suggests that the law is messy, and that the concept of fiduciary itself is elusive. Fiduciary law scholar Deborah Demott notes that courts use ad hoc approaches to “examine whether the relationship involved in the litigation is sufficiently like those in the paradigm cases to support an extension of the obligation to that relationship.” Critics of existing jurisprudence like Reed McBride state that this jurisprudence of analogy has led to applying the fiduciary principle “to disparate fact situations,” which exacerbates confusion and uncertainty. J. C. Shepard, author of the The Law of Fiduciaries, state that the use of “analogies frequently do[es] not result in appropriate rules.”
We are in agreement with Kelli Alces’ observation that fiduciary obligations are a tool to “give a judge a framework for crafting a hypothetical bargain.” We agree with the law and economics view that appropriate fiduciary duties aid in reducing agency costs related to the separation of ownership and control. We also acknowledge that, however problematic, the use of analogies is a logical starting point for understanding social changes. For technologies that emerge outside of institutions, however, we must be prepared to examine distinctions, however onerous the task of technical comprehension, before creating a duty as high as a fiduciary duty.
Protocol developers are distinct from corporate directors in several ways. They do not act as the legal agent of any other network participant, individually or collectively. Protocol developers’ voluntary, collaborative, and iterative contributions take place in the context of open source production, making them different from the actions of a fiduciary during her representation of the beneficiary, and as delineated by an agreed-upon and preexisting agency relationship. To begin with, there is no expectation between the cryptocurrency holder and the protocol developers of the latter having a legal agent role. Protocol developers do not make representations of a trustee-like fiduciary.
Protocol developers lack the ability to bind any other network participants to software application changes and no other network participant has the power to direct or control the voluntary actions of protocol developers. Implementation of any change to a particular software application takes place through a multi-level political process and requires consent of formal participants to a public blockchain network. The actions of protocol developers do not deprive any other network participant of his ability to act in his own self-interest, since every participant is free to run whatever version of the software application for the public blockchains. These actors can independently audit the proposed revisions and evaluate their choices. A protocol developers’s ability to influence the welfare of the cryptocurrency holder (i.e., the value of the cryptocurrency) is therefore limited to proposing and advocating for a solution that the community may or may not adopt.
A fundamental characteristic of fiduciary relationships is the entrustor’s delegation of power or property to the fiduciary, which is necessary for the latter to achieve their goal. For example, shareholders cede ownership and control over the assets of a corporation to its directors and corporate officers.
In contrast, there is no action between a protocol developer and a cryptoasset holder or any other network participant that could be characterized as a delegation of property or power. There is no agency agreement delegating power between protocol developers and other network participants, nor means for the network participants to exercise formal power or control over the protocol developers. Further, the ability of protocol developers to act is not dependent on or enabled by a specific action of any cryptocurrency holder.
The attenuated relationship between a public blockchain protocol developer and a cryptocurrency holder is established on the basis of two separate actions: (a) a protocol developer’s decision to contribute code to a particular software application and (b) another’s decision to participate in the public blockchain network by acquiring cryptoassets or operating a node. Neither of these actions alone or in combination constitute a delegation of power or property by a cryptocurrency holder or the acceptance of such power or authority of the cryptocurrency holder by a given protocol developer.
The decision of an individual to acquire cryptocurrency cannot be interpreted as a delegation of property or power to a protocol developer given that, because of that action, protocol developers are neither directly gaining control over property nor gaining the ability to bind the cryptoasset holder to any decision. Critically, the purchase of cryptocurrencies should not be confused with the purchase of public company equity securities, given that public company directors can legally establish the shareholders’ rights and interests, even against their will. For example, the board of directors of a public company may rebuff a merger offer that would result in a shareholder’s receiving a significant premium for her shares. In contrast, protocol developers have no such ability to bind other network participants.
Fiduciary obligations are imposed in the absence of other alternative means of redress. As noted by Frankel, “[i]f the entrustor can protect himself from abuse of power, there is no need for the intervention of fiduciary law.” The imposition of fiduciary duties on protocol developers is therefore inadequate given the existence of alternative mechanisms to control protocol developers and other participants in public blockchain networks.
There are existing legal frameworks that are much better suited for dealing with the risks potentially posed by protocol developers and other participants in public blockchain networks, including the imposition of commodity and securities laws at the federal and state level, money transmission and payments law at the federal and state level, as well as general consumer protection, anti-fraud and criminal regulations.
Developing, maintaining, and understanding blockchain systems are complex tasks that run the risk of errors being made and bugs being introduced into the code base for the blockchain systems. Recently, a secret update was applied to the most popular Bitcoin client software, Bitcoin Core, to fix a bug that would have allowed a miner to artificially inflate the supply of bitcoin.
Keeping the bug secret raises the question of what safeguards should stop developers from exploiting that information to the detriment of network participants, and what recourse, if any, network participants should have against the developers. A user of the blockchain system could bring a claim of unfair trade practices alleging fraud against the developers that kept the bug secret, particularly, under Section 5 of the Federal Trade Commission Act. Additionally, or alternatively, a potential claim of insider trading could be brought against any developers trading on non-public information. Andrew Verstein notes that “crypto assets are subject to at least enough of the insider trading jurisprudence to allow federal prosecutors to bring successful criminal actions.”
A framework similar to safe harbor provisions for data breach reporting may be the most appropriate model. Under such a framework, developers may have a grace period to disclose the existence of bugs, and assuming they do not trade on the information to the detriment of network participants, they may not be held liable for keeping the bug secret.
This post comes to us from Professor Raina S. Haque at Wake Forest University School of Law; Rodrigo Seira Silva-Herzog, an associate at Cooley LLP; Brent A. Plummer, a recent graduate of Wake Forest University School of Law who will be joining Bank of America; and Nelson M. Rosario, an adjunct professor at Chicago-Kent School of Law. It is based on their recent article, “Blockchain Development and Fiduciary Duty,” available here.