Blockchain Development and Fiduciary Duty
In 2018, Bitcoin’s value dropped a walloping 70%.
There are, in fact, many blockchains; we focus on two prominent ones in this Article. See Primavera De Filippi & Aaron Wright, Blockchain and the Law: The Rule of Code 21, 31 (2018).
See Stefan Stankovic, US Cryptocurrency Regulation: Policies, Regimes & More, Unblock (July 13, 2018), https://unblock.net/us-cryptocurrency-regulation/#h3.
See Jean Eaglesham et al., Crypto Craze Drew Them In; Fraud, in Many Cases, Emptied Their Pockets: SEC and State Regulators Have Brought More Than 90 Crypto Cases over the Past Two Years, but Tracing Funds Is Hard Because of the Elusive Nature of the Currency, Wall St. J. (Dec. 26, 2018), https://www.wsj.com/articles/crypto-craze-drew-them-in-fraud-in-many-cases-emptied-their-pockets-11545820200.
By enabling new modes of human interaction, technological advancements catalyze the evolution of existing regulatory frameworks and spur the reassessment of regulatory tools and approaches. The rapidity at which computer technology evolves outpaces the rate at which much legislation, rulemaking, and law can be codified. Our economy is increasingly structured not only by traditional fiduciary actors, but also by software systems.
We have explored the governance role of blockchain developers for the two most prominent
The evolution of software systems outpaces the rate at which legal scholarship can timely examine the operational dynamics of software development. Such dynamics should be integral to an analysis of the appropriate liability framework for software developers.
See Arjun Kharpal, Beyond Bitcoin: How the World Is Experimenting with the Blockchain, CNBC (Aug. 29, 2018), https://www.cnbc.com/2018/08/29/bitcoin-world-is-experimenting-with-blockchain.html.
Many of the traditional gatekeepers of certain highly regulated activities, such as early stage venture financing and cross-border money transmission, have called for regulation and scrutiny of blockchain ecosystems.
Determining where this innovative technology fits into legal frameworks is more than a hypothetical exercise for courts, regulators, and legislatures. Since the Bitcoin network launched in 2009, there have been a variety of cases that have grappled with the advent of blockchain technologies enabling disintermediated transactions that are pseudonymous and cross-jurisdictional.
Cryptocurrency’s use as a tool for money laundering schemes is one such regulatory concern. As an example, US v. Ulbricht concerned the arrest and eventual conviction of Ross Ulbricht for, among other things, maintaining an auction website where individuals could purchase illegal items with bitcoin.
Whether or not cryptocurrency is within the purview of money transmitter laws is an issue for every state. For example, US v. Faiella examined whether facilitating bitcoin transactions on behalf of customers constituted operating a money service business necessitating a money transmission license.
See United States v. Faiella, 39 F. Supp. 3d 544, 545-47 (S.D.N.Y. 2014).
See id. at 545.
Even well-settled securities laws have been reexamined due to the advent of blockchain technologies and the cryptographic tokens they enable. In 2017, the Securities and Exchange Commission issued what is colloquially known as “The DAO Report.”
One ICO offering typical of the wild west nature of this technology space included two high-profile celebrity endorsements from a rapper and a boxer, respectively.
In addition to the attention from regulators, state legislatures issue legislation dictating the treatment of public blockchain networks.
It may be tempting, when facing a wildfire of developments resulting from this emerging technology, to advocate for a fiduciary obligation on all blockchain developers. Subsequent to a major exploitation of the token-transferring code used by The DAO, which split the prominent Ethereum blockchain community into two and resulted in token value volatility, some scholarship
These calls for the imposition of the fiduciary standard to be applied to “coders”
This article addresses the forgoing issue in four parts. In Part I, we discuss the operations of open source, decentralized development to better understand these developers’ functions and how cryptocurrencies are used to build blockchain networks. In Part II, we discuss the different developers involved in creating blockchain and blockchain-based systems and the governance structure under which they operate. We examine moments of crisis in blockchain communities that illustrate this governance in Part III. In Part IV, we emphasize the distinction between blockchain protocol developers and directors and officers of a corporation. We conclude our analysis by briefly exposing the effects of imputing fiduciary obligations on protocol developers.
I. The General Operations and Incentives of Open Source Production
To understand blockchain development operations, an understanding of open source production is critical.
a. Blockchain traces its roots to open source software development
Bitcoin and the public blockchain networks that followed from it have several innovative features, but their process of development, the method through which they came into being and are evolving, traces its roots to the open source production system that grew out of the early days of the Internet and the free software movement.
As we shall explore more in depth in Section II (c), anyone is free to suggest a change to the code of an open source software application,
See Arvind Narayanan et al., Bitcoin and Cryptocurrency Technologies: A Comprehensive Introduction 171 (2016) (explaining that the protocol developers with commit access “can urge the community [the blockchain participants] on, but they don’t have formal power to force people to follow them if they take the system in a technical direction that the community doesn’t like.”).
b. Production through voluntary contributions of independent actors
A main principle of open source production is that development work is undertaken by independent volunteers who decide on their own account to collaborate with others in an iterative fashion.
See Section II below for a further discussion of the governance structures of public blockchain networks.
c. Open access to code and ability to “fork”
In an open source production system, anyone can suggest a code change to the community. Anyone is also allowed to modify the existing code and try to build her own community to support a revised version of the code (a concept generally referred to as “forking,” which is discussed in more detail in Section II (c) below).
To accomplish the goal of being free and public available, open source projects publish their source code in online repositories and license it under a spectrum of free and open source (“FOSS”) licenses.
d. Building cryptoeconomic institutions with cryptocurrencies
The Bitcoin project allowed for the newfound ability to transfer value over a peer-to-peer network and validate such transfers using a gamified incentive scheme that uses bitcoin, a cryptocurrency.
It is the PoW consensus mechanism that gamifies participation in the validation scheme.
The result is the ability of a network of computers, known as nodes, to support bitcoin transfers.
The Bitcoin network’s introduction of bitcoin, or a blockchain network’s native cryptocurrency
In this sense, cryptocurrencies enable the transformational aspect of public blockchain networks—the ability to create and execute rule-systems that result in new organizational and institutional forms of economic governance and “enable bespoke socio-economic coordination.”
Davidson et al., supra note 42, at 6-7.
II. Blockchain Governance and Protocol Development
In the first section we uncovered some of the underlying dynamics present in open source production and public blockchain development. This section examines the influence protocol developers have on changes to public blockchain software applications. We do this by: (a) recognizing that public blockchain networks, like any organization, necessarily develop governance structures; (b) clarifying whom “protocol developers” refers to and analyzing the general role and motivation of the different types of protocol developers; and (c) providing an overview of how changes to the Bitcoin Core and Ethereum software applications are implemented in practice.
a. “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”
Jo Freeman, The Tyranny of Structurelessness, JoFreeman.com, https://www.jofreeman.com/joreen/tyranny.htm (May 1970).
b. The function and incentives of protocol developers in public blockchain networks
i. Defining “protocol developer”
In the context of open source software production, the term “developer” may generally refer to various unrelated individuals who play fundamentally different roles over time.
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,
For example, several of the Bitcoin Core developers are employed by the company Blockstream.
ii. Catalyst developers and network effects
While public blockchain networks can exhibit decentralizing tendencies
Agents responsible for beginning decentralized organizations (including open source projects such as Linux, Apache, Wikipedia, Craigslist, and even Alcoholics Anonymous) are referred to as “catalysts.”
The role of a catalyst developers is evident when looking at the Bitcoin and Ethereum networks. With the backdrop of the world financial crisis, “Satoshi Nakamoto” famously published the Bitcoin whitepaper in October 31, 2008 and soon after coded the very first Bitcoin software application,
Catalyst developers create the anchor point for network effects.
According to Tirole and Lerner, the leader of an open source project “must (a) provide a vision, (b) make sure that the overall project is divided into much smaller and well-defined tasks (“modules”) that individuals can tackle independently from other tasks, (c) attract other programmers, and last but not least, (d) ‘keep the project together’ (prevent it from forking or being abandoned).” Josh Lerner & Jean Tirole, The Simple Economics of Open Source 21 (Nat’l Bureau of Econ. Research, Working Paper No. 7600, 2000).
iii. The incentives of developers contributing to open source projects
Analyzing the issue from a different point of view, one may ask: what motivates skilled protocol developers to contribute to an existing open source project? Developers are generally highly technical workers who have the potential to be lucratively compensated for their work by modern technology firms.
Nonetheless, developers contribute to open source projects in droves. Bitcoin was launched in 2009, and a decentralized group of developers has maintained the “Bitcoin Core” software application,
1. Social and psychological incentives
The academic literature finds that contributors to the earliest open source software projects were motivated by the medium- to long-term social and psychological impact of their work, as opposed to motivation through short-term economic payoff.
Id. at 14.
In addition, contributors to open source projects are often animated by an ideology which influences their decision-making over design and architectural choices. For example, the open source software movement was closely associated with the free and open source software (“FOSS”) ideology.
2. Economic incentives through native cryptocurrencies
While the developers contributing to the earliest open source software projects were mostly motivated by social and psychological factors,
c. How changes to software applications are made and the role of developers in implementing those changes in the network
This section seeks to describe the process through which changes to a software application of a public blockchain network are made. More importantly, it examines the role of protocol developers in the process of updating a software application and implementing it on the network.
i. Changes to a public blockchain’s software application come from the political consensus of network participants
Public blockchain networks do not function in reliance on one single “code base,” but rather can support a range of software applications so long as they all conform to the consensus rules
Public blockchain networks vary significantly in their architecture and design. Using the Bitcoin and Ethereum protocols as examples, the direct participants of the network (the “formal participants”) are (1) the network users (e.g., cryptocurrency holders) and (2) the network nodes (both miners and other nodes that run the software application). There are multiple other interested parties with influence over public blockchain governance (the “indirect participants”), including (3) developers (both protocol developers and others such as smart contract developers) and also (4) businesses that service the blockchain network and provide the related infrastructure (including equipment manufacturers and exchanges).
ii. A multi-level coordination model of public blockchain governance
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 between 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 multi-layered “coordination model.”
As Vitalik Buterin conceptualizes it, operating above layer 1 are “coordination institutions” which “create focal points around how and when individuals should act in order to better coordinate behavior.”
In this context, protocol developers play a dual role in that they both (1) provide the “choices” for every formal participant to act on by maintaining and revising versions of a software application,
There are thus recursive value dependencies that bind the network participants: the value of the cryptocurrency is dependent upon the volume of transactions that use it, the volume of transactions is dependent upon the stability and reputation of the network, the stability of the network is dependent upon the miners that participate in the validation scheme, the validation schemes are provided by the protocol developers, the protocol developers are incentivized by the value of the native cryptocurrency they may hold (and the social and psychological factors discussed above), the miners are incentivized by the value of the cryptocurrency they may gain by participating in the validation scheme. Thus, native cryptocurrency is an integral driver in the PoW mechanism design.
iii. Lifecycle of a Bitcoin software application update
Updates to a public blockchain’s software application (including Bitcoin Core) can be proposed by anyone.
Major changes to the Bitcoin Core software application are suggested through Bitcoin Improvement Proposals (“BIPs”).
The BIP submission process is broken up into several stages. During the first informal stage, a champion presents a BIP in draft form to the Bitcoin community, including by sharing the idea with the Bitcoin development mailing list.
Once a BIP has been “socialized” with the community and is properly formatted, it may be submitted to the publicly available Bitcoin GitHub repository as a “pull request,” which is analogous to a request for change.
Once a BIP has been accepted and merged into the Bitcoin Core repository, the BIP Editor will assign the BIP a number,
A champion can change the status of a BIP from Draft → Withdrawn or Deferred. However, a BIP’s path from Draft → Proposed → Active (but not yet Final or implemented on the Bitcoin network) requires buy-in from the Bitcoin Core developer “technocracy.” This entails the BIP achieving a “rough consensus”
For a BIP to get from Draft status to Final status (meaning implemented on the Bitcoin network) it must be adopted by the formal participants of the Bitcoin network, which we have seen play a separate role from that of the protocol developers. This is a key point. Protocol developers do not formally “touch” the blockchain; they can only propose changes to a certain software application. Implementation of any changes to a public blockchain network, such as a BIP, requires the consensus of the formal participants, which are influenced by the indirect participants in a multi-layered coordination-model.
There are two paths that a BIP can take to go from Final → Final status and be implemented on the Bitcoin network.
1. Soft forks
Certain BIPs propose a “tightening” of the consensus rules of the Bitcoin protocol (i.e., the ruleset is narrowed, disallowing new blocks that previously would have been valid) and thus require only a “soft fork” to be implemented. These types of modifications are said to be “backwards compatible” because full nodes (other than miners) are not required to upgrade to the implementing software application to maintain consensus in the network (given that full nodes running the old, non-implementing software application will still be able to accept new blocks generated by the miners running the new implementing software application). As such, implementing a soft fork BIP requires only adoption of the miners, usually through a supermajority “vote” of 95% of active hashpower.
To facilitate reaching consensus amongst miners, procedures such as a Miner Activated Soft Fork (“MASF”) have been devised that allow miners to signal their support for a particular BIP by including messages or “flags” in the headers of the blocks they successfully mine. As miners raise flags over time, a group position emerges. MASFs therefore function “as a kind of pre-election polling, gauging sentiment and promoting the formation of a common understanding of what will come to pass.”
Miners truly “vote” on whether to implement a BIP by choosing whether to apply their computational power to mine on the network that implements the software application. Given the positive network effects of public blockchain networks, when deciding whether to mine to validate the implementing or non-implementing software application, miners must anticipate which version of the software application the broader community will coalesce around. Scholars have therefore argued that “[a] miner’s ‘vote’ is better understood as its prediction of the collective stance of the broader miner community than as an expression of the voting miner’s individual preference.”
The “economic majority,” a term referring to a combination of network users and other indirect participants such as wallets and exchanges, exerts indirect influence over the adoption of soft forks. Mining is a for-profit industry in which profits are determined in large part by the cost of computational power to mine in relation to the value of the cryptocurrency being mined. Therefore, a key factor in a miner’s decision framework (i.e., which version of the software application to run and which history to adopt) is the effect that a certain proposed code change will have on the value of the cryptocurrency. The value of the cryptocurrency is in turn determined by those willing to offer things of value in exchange for the underlying cryptocurrency (be it goods, services, fiat currencies, or other cryptoassets). Therefore, while soft forks can be normatively implemented without direct user participation, given the profit-motive of miners, the economic majority’s preferences are ultimately reflected in a miners’ decision-making framework.
As an example, the economic majority can employ coordination procedures, such as a User Activated Soft Fork (a “UASF”), to exert leverage over the miners in the context of a potential soft fork.
See, e.g., Jimmy Song, Bitcoin, UASF and Skin in the Game, Medium
2. Hard forks
Network participants can also exert influence over a public blockchain’s governance through “hard forks.” As opposed to soft forks, hard forks implement code changes that “loosen” the consensus rules of a blockchain’s protocol (i.e., the ruleset becomes broader, allowing for previously disallowed blocks to be treated as valid). Hard forks are therefore not backwards compatible, in the sense that full nodes which 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.”
Critically, a “hard fork” serves as the ever-present escape valve accessible to any network user or informal participant who finds available software applications disagreeable.
While copying a publicly available software application might seem simple in theory, hard forks have limitations and are costly in practice.
Hard forks thus provide a viable avenue to minimize risks of undue influence on the code by third parties.
Verstein, supra note 125.
d. Lifecycle of an Ethereum Update
Similar to Bitcoin, the Ethereum community employs an improvement process. That process involves the creation of an Ethereum Improvement Proposal (“EIP”) that is a “design document providing information to the Ethereum community, describing a proposed new feature or its processes or environment.”
There is an inherent distinction between Ethereum and Bitcoin that should be understood; this distinction informs the identification of different types of blockchain developers.
III. Protocol Developers in Moments of Crisis
The capitalization of blockchain cryptoassets was over twelve billion USD
a. The Ethereum Hard Fork
The decision to fork or not fork is one taken by network participants during moments of crisis.
As mentioned in the introduction, The DAO, an unincorporated organization run by the founders of Slock.it UG,
Arguably, participants in The DAO network were put on notice that the smart contract code superseded any representations or warranties. The purchasers of The DAO token were put on notice of this Term on The DAO website:
The terms of The DAO Creation are set forth in the smart contract code existing on the Ethereum blockchain at 0xbb9bc244d798123fde783fcc1c72d3bb8c1894. Nothing in this explanation of terms or in any other document or communication may modify or add any additional obligations or guarantees beyond those set forth in The DAO’s code. Any and all explanatory terms or descriptions are merely offered for educational purposes and do not supersede or modify the express terms of The DAO’s code set forth on the blockchain; to the extent you believe there to be any conflict or discrepancy between the descriptions offered here and the functionality of The DAO’s code at 0xbb9bc244d798123fde783fcc1c72d3bb8c1894, The DAO’s code controls and sets forth all terms of The DAO Creation.173Adam J. Kolber, Not-So-Smart Blockchain Contracts and Artificial Responsibility, 21 Stan. Tech. L. Rev. 198, 200 (2018).
This is only one of many disclosures that the DAO put out. Another statement published by The DAO reads:
The DAO’s smart contract code governs the Creation of DAO tokens and supersede any public statements about The DAO's Creation made by third parties or individuals associated with The DAO, past, present and future. The software code currently available at https://github.com/slockit/dao is the sole source for the terms under which DAO tokens may be created.174Drew Hinkes, A Legal Analysis of the DAO Exploit and Possible Investor Rights, Nasdaq (June 21, 2016), https://www.nasdaq.com/article/a-legal-analysis-of-the-dao-exploit-and-possible-investor-rights-cm638561.
The Creation of DAO tokens carries with it significant risk. Prior to Creating DAO tokens, carefully consider the exemplary and non-exhaustive list of risks set forth below and, to the extent necessary, consult a lawyer, accountant, and/or tax professionals prior to Creating DAO tokens.
1. Risk of Security Weaknesses in The DAO's Software
The DAO concept is both experimental in nature and unproven. There is a risk that, as an open source project, any contributor to The DAO's software could introduce weaknesses or bugs into the DAO software, causing the loss of DAO tokens or ETH in one or more or even all of the DAO Token Holder’s accounts.
2. Risk of Weakness in the DAO underlying blockchain, and/or Ethereum Network
The DAO software is itself based on an unproven platform: the Ethereum blockchain. There is a risk that, as an open source project, any contributor to the Ethereum blockchain could introduce weaknesses or bugs into the Ethereum software, causing the loss of DAO tokens or ETH in one or more or even all of the DAO Token Holder's accounts.
3. Risk of unforeseen attack vectors
The field of Digital Cryptography is very new and for this reason, there is a risk of unforeseen attack both in terms of the underlying cryptographic protocol that back the functioning of the DAO as well as ‘game theory’ related vectors which have not been documented to date. Both these vectors represent a risk that could lead the loss of DAO tokens or ETH in one or more or even all of the DAO Token Holder’s accounts.175Id.
The DAO appeared to admit that its platform was in an experimental state and explained risks. In so doing, it can be inferred that The DAO wanted to shift liability away from itself and its smart contract developers through, in so many words, caveat emptor.
This preemptive shift in liability does not mean that the smart contract developers were totally careless programmers; among the several safeguards smart contract developers built into The DAO smart contract was a withdrawal latency of twenty-eight days.
A soft fork of the system was considered by Ethereum protocol developers and nearly reached execution stage,
Even then, with this conclusion that a hard fork was the best option, the protocol developers decided to create a software application allowing network participants (Layer 1 of Buterin’s conceptual model) to decide whether or not to enable the fork.
The present-day Ethereum gained a majority of the mining power, but Ethereum Classic had a sizeable community of 10% of the mining power and value.
This incident illustrates a number of different aspects about the Ethereum protocol developers. Assuming arguendo that the protocol developers had an agenda to cram down a hard fork so that history of The DAO exploit was universally erased, it was not successful; the Ethereum Classic community retained the history of the exploit, and that blockchain and community exist to this day.
In January 2019, recent to the time of this writing, the Ethereum Classic blockchain network detected a 51% attack on the network, in which one entity controlled the majority (at least 50%) of the mining computational power and altered the transaction history of that blockchain.
There are notably poor blockchain smart contract development practices,
Protocol developers can be smart contract developers as well, but they often are not. When creating liability frameworks to apply categorically, it makes sense to distinguish the hats involved, if/when the same person is wearing more than one.
b. The Bitcoin Core secret update
Developing, maintaining, and understanding blockchain systems are complex tasks that run the risk of errors being made and bugs being introduced into the codebase for the blockchain systems.
Through the Bitcoin Core bug reporting system, an anonymous individual reported a bug which enabled a distributed denial of service attack on the Bitcoin Core client.
The Bitcoin Core developers keeping the bug secret raises the question of what safeguards should exist from developers 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.
Section 5(a) of the Federal Trade Commission Act (FTC Act) (15 USC §45).
A framework similar to safe harbor provisions for data breach reporting may be the most appropriate model for a path forward. 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.
See, e.g., the recently passed Ohio statute concerning Safe Harbor at https://www.legislature.ohio.gov/legislation/legislation-summary?id=GA132-SB-220.a.
IV. The Improper Fit of Corporate Fiduciary
Scholarship on the law of fiduciary duties starts with an admission to the effect that the law is “messy,”
We recognize the importance of fiduciary obligations as a tool to “give a judge a framework for crafting a hypothetical bargain.”
At least one scholar suggests that because “developers look a lot like officers or directors of a corporation,” having analogous fiduciary duties is fitting.
Deborah A. DeMott, Beyond Metaphor: An Analysis of Fiduciary Obligation, 1988 Duke L. J. 879, 915 (1988).
a. Corporate fiduciary duty
We put aside the growing body of scholarship that decries the corporate fiduciary obligation as a “myth,”
[b]y delegating a task to an agent, the principal benefits from specialist service... But these benefits come at the cost of being made vulnerable to abuse if the agent is given discretion the exercise of which cannot easily be observed or verified. In such circumstances, the agent may be tempted to favor the agent’s interests when they diverge from those of the principal. The losses and other inefficiencies resulting from this misalignment of interests are called agency costs.226Robert H. Sitkoff, An Economic Theory of Fiduciary Law, in Philosophical Foundations of Fiduciary Law 199 (Andrew Gold & Paul Miller eds., 2014).
Through the imposition of fiduciary duties, “[t]he agent is induced to act in the best interests of the principal by the threat of after-the-fact liability for failure to have done so. Deterrence in this sense means ex post settling up with the principal for any breach of the agent’s ex ante fiduciary duties.”
Fiduciary obligations are applied to relationships where one party (the “beneficiary”) is structurally vulnerable to abuses of power and agency problems due to its reliance on a second party (the “fiduciary”) to act on its behalf in an unobservable and discretionary manner.
From the point of view of legal institutional design, fiduciary obligations are a deterrence tool to address the structural and inherent risk exhibited in certain types of relationships. Under this regulatory approach, the fiduciary is enabled to act on behalf of the beneficiary and exercise discretion in unobservable ways, but the beneficiary is subsequently provided with the means to scrutinize whether the fiduciary’s actions were undertaken in the beneficiary’s best interests and with adequate skill.
Therefore, fiduciary obligations are a judicial deterrence tool designed to work by influencing the fiduciary’s internal cost-benefit analysis of engaging in self-serving behavior through the threat of litigation (e.g., a corporate director is less likely to engage in a self-dealing transaction if under a model of rational self-interest, she believes that as a result of such self-dealing behavior she will face a lawsuit for breach of fiduciary duties that will cost her more than what she is able to gain through her actions).
Traditionally, corporate fiduciary duty arises from the view that corporate officers and directors owe fiduciary duties because they are managing the assets of the owner-shareholders in a trustee-like manner.
When stockholders invest in a certain company, they entrust their capital to the corporation’s directors, who function as the shareholder’s agents. Given the deference directors receive under the business judgment rule, directors are legally empowered to make decisions on behalf of stockholders, and in certain circumstances can do so even against the express wishes of the latter.
b. Where the analogy between protocol developers and corporate directors fails
Protocol developers are distinct from corporate directors in several ways. Protocol developers cannot be said to 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 their contributions inherently different from the actions undertaken by a fiduciary during her representation of the beneficiary as delineated by an agreed-upon and pre-existing 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 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. We have seen how 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 their ability to act in their own self-interest, since every participant is free to run whichever version of the software application for the public blockchains. These actors can independently audit the proposed revisions and evaluate their choices. A protocol developers’ 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 may or may not be subsequently adopted by the community.
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 her goal. For example, we have discussed how shareholders cede ownership and control over the assets of a corporation to the directors and corporate officers.
In contrast, there is no action that take places between a protocol developer and a cryptoasset holder or any other network participant that could be adequately 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 or enabled by a specific action taken by 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, nor their 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 bind 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 receiving a significant premium for her shares.
One may argue the potential effect that updates to a certain software application proposed by protocol developers may have on the value of the cryptocurrency demonstrates a delegation of property from the cryptoasset holders to the protocol developer, which could be the basis of a fiduciary relationship. However, the cryptocurrency’s potential diminution does not reflect the existence of a fiduciary relationship because it is due to the reaction of the economic majority to a development adopted through a multi-level political process.
c. Protocol developers do not pose the same risks of traditional fiduciaries
We have shown in the prior section how the relationship between protocol developers and other participants in public blockchain networks does not share structural similarities to the relationship between a fiduciary and beneficiary. In this sub-section, we show that protocol developers do not pose the dangers that fiduciary obligations are meant to deter, namely abuse of power or agency costs.
i. Protocol developers’ motivations align with those of the network participants
Fiduciaries are usually empowered to act with discretion and bind the beneficiary, resulting in the risk that they will act in self-serving ways to the detriment of the beneficiary. In addition, the risks posed by fiduciary relationships are often heightened by the inherent inability of the beneficiary to monitor the fiduciary’s performance of her services. For example, shareholders are entitled to only certain information about the actions of the board, and while the beneficiary can monitor the fiduciary, this monitoring is limited to achieve a public policy goal.
In contrast, a protocol developer’s actions are radically more transparent and do not exhibit the same information asymmetries as traditional fiduciary relationships. An open source software application is, by definition, readily accessible to the public through an online repository. Moreover, updates made to a certain software application, through BIPs and EIPs, are heavily discussed and analyzed by the community both in technical and general terms. “Anyone who stumbles upon the thick Twitter, Reddit and Medium chatter addressing Bitcoin reform or reads the Bitcoin-related GitHub postings can readily monitor activity in the Bitcoin developer community.”
While many cryptocurrency holders are not sufficiently knowledgeable to understand the technical details of projects or revisions, a vibrant ecosystem of participants has developed with the technical knowledge and economic incentives to take a “deep dive” into the technicalities of projects and signal preferences to formal network participants and the market generally. We explored in Section II (c) how certain institutions play a coordinating role with formal participants in the network and by the same process provide synthesized information to the broader market through their statements and actions.
ii. Protocol developers are structurally unable to act selfishly to the detriment of other network participants
We have noted that protocol developers contributing to a certain software application are traditionally not directly remunerated for their efforts by other participants in the network, and as such, the impetus for their contributions can be attributed to (a) long-term reputational value from contributing to important projects and (b) economic value from the potential price appreciation of cryptocurrencies they may hold. Given that protocol developers are incentivized by reputational gains from their contributions to a successful project and by economic gains from the value appreciation of cryptocurrency due to network effects, a protocol developer’s ability to benefit from her contribution to a certain software application is directly linked to the success and growth of the related network. Given the incentive alignment between protocol developers and other network participants, the need to impose fiduciary duties is obviated.
The DAO exploit exemplifies the above point. As discussed earlier, the Ethereum protocol developers took care to poll holders of Ether to determine if they preferred a default in the software application of forking or not forking; these developers were under no obligation to conduct such a poll to direct the design the hard fork software. However, the protocol developers’ interests are to increase the value of the network, and the value of the network is reflected by a community’s willingness to transact on it and participate in its validation scheme. Thus, the protocol developers wanted to know the wishes of the community to design the software application in accordance with those wishes; doing so salvaged the network’s value for what is the modern-day Ethereum network.
The community that did not want the hard fork did not vanish were free to keep on to the blockchain history and protocol that they wanted. That Ethereum Classic community continues to this day. Assuming arguendo that protocol developers wanted all network participants to “convert” to adopt the hard fork, the protocol developers failed; they were unable to foist their decisions onto this community.
Corporate boards and directors have much more coercive power—for example, they are able to bind the corporation against the will of shareholders. Protocol developers simply lack the authoritative power that warrant the imposition of fiduciary obligations.
iii. The structural dynamics and incentive structures of public blockchain network governance ameliorates the risks that protocol developers will act carelessly
Blockchain technology is still in its nascent stage and is highly experimental. As a result, errors in the code of software applications occur and can be expected to continue.
For example, in September 2018, a new bug was discovered in the Bitcoin Core software application that could have been potentially been exploited to shut down the network or create additional bitcoins. See Jimmy Song, Bitcoin Core Bug CVE-2018-17144: An Analysis, Medium (Sept. 27, 2018), https://hackernoon.com/bitcoin-core-bug-cve-2018-17144-an-analysis-f80d9d373362.
Those innovations are discussed in Section V (c).
c. There are alternative methods to regulate protocol developers which negate the need to extend fiduciary duties
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.”
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. While an in-depth discussion of the relative benefits of each regulatory framework is outside of the scope of this Article, courts and policymakers have a wide array of tools they can use to protect the interest of participants in public blockchain networks, several of which reflect the realities of the techno-economic paradigm more closely than would the imposition of fiduciary duties.
V. Effects of Imputing Fiduciary Duties on Protocol Developers
Imputing fiduciary obligations to public blockchain protocol developers ignores the design mechanisms in place that curb the risk of wanton decision making by the protocol developers. It is instructive to analyze how designating protocol developers as fiduciaries would affect the judicial process and open source production systems. Once we consider the potential implications of regulating protocol developers as fiduciaries, the impracticability and undesirability of adopting such a position becomes clear.
a. Impractical for courts
At its mildest, labeling protocol developers as fiduciaries would present courts with the challenge of forcing the static concepts of “fiduciary” and “beneficiary” onto a highly dynamic context of public blockchain network governance.
i. Assessing which protocol developers owe fiduciary duties
A protocol developer may contribute one minor line of code that is utterly essential to network functionality. Another may constantly contribute a high volume of lines over a long period of time, but still be a functionary whose work is wholly non-essential and could easily be replaced by others. Alternatively, a “contributor” may not even write actual code at all but instead make a conceptual suggestion that is critical, or simply review other’s code and discover an important bug. Given the different types of activities that individual protocol developers engage in, it would be untenable to suggest that every single protocol developer who makes any contribution, no matter how small or irrelevant, to a public blockchain network is a de facto fiduciary.
At the same time, given the highly dynamic, collaborative and iterative nature of public blockchain development, there is simply no alternative way to define which protocol developers rise to a status warranting the label of fiduciary. Those who argue that fiduciary duties should apply to developers are aware of this definitional issue and resort to either referring to a laundry list of different terminologies
The temporary influence held by certain protocol developers is derived from the reputations they established through the quality and frequency of their contributions and from the value of the particular contribution at stake. Moreover, the fact that a particular protocol developer can wield influence over a software application at a certain moment does not mean that she will continue to exercise that influence, and critically it does not mean that she is able to bind any other participants in the network. Therefore, it would be functionally impossible for courts to provide a static definition that delineates with clarity which protocol developers are “influential enough” to warrant the imposition of fiduciary obligations. Importantly, without the ability to delineate which developers are fiduciaries, protocol developers themselves will be unable to take the necessary steps to protect themselves.
One might argue that those protocol developers with “commit access” to the code repository of a particular software application should be identified as fiduciaries. However, this would entail a misunderstanding of the power dynamics in public blockchain governance, given that protocol developers exhibit a range of influence not defined exclusively or even particularly by this access. Moreover, “commit access” to a specific software application, such as Bitcoin Core, does not entail control over a network which we have noted can support different software applications. Separately, applying fiduciary obligations to individuals with commit access is also likely to be an ineffective regulatory approach, given the potential for technological work-around that could provide developers with anonymity.
ii. The risk of strike suits
Fiduciary obligations are a deterrence mechanism that provide legal recourse to parties who are structurally susceptible to abuses of power.
b. Create motive for subverting the mechanism design of a public blockchain
Corporate fiduciaries are often paid handsomely for the risk they take on as fiduciaries, and these benefits incentivize them to keep corporate matters under their scrutiny and control. Protocol developers, as we have discussed, are not directly compensated and volunteer to create software applications that allow users to participate in the blockchain network—a network that relies upon decentralization of participation for its stability. Imputing fiduciary obligations to protocol developers may cause the protocol developers to take more authority over the network and subvert the purpose of public blockchains. The purpose of public blockchains is to allow for open transacting. For example, a protocol developer, knowing that she would be held to such a high standard for any cryptocurrency owner, may decide to create barriers for network participation entry so that she has less risk by swaying network participation. Under such a high standard, she may also design consensus rules that favor transactions and miners that she desires to lower her liability risk. Imputing fiduciary obligations would threaten the decentralized ecosystem of public blockchains.
c. Chill open source innovation
Importantly, the imposition of fiduciary duties on protocol developers and the risk of liability that determination entails could potentially end the viability of open source production. Open source production has emerged in recent decades as a startling paradigm of human interaction that has enabled innovative new models of social organization and is increasingly responsible for producing more of the world’s information.
Open source production has an impressive track record of technological innovation, made more remarkable by how modern economic theory is largely unable to explain its accomplishments. Writing in 2017 of the success of Apache, the open source web server software, Yochai Benkler stated, “[a]ny economist who would have predicted in 1996 that a group of developers working on webserver software, using no formal managerial hierarchy and relying on a copyright license that gave no one exclusive proprietary control over the products of the collaboration would beat Microsoft in a market that was core to Microsoft’s Internet strategy would have been laughed out of the room. And yet Apache beat Microsoft Server over the past twenty years, and its fastest growing competitor is Nginx, another FOSS project.”
If we study its track record, we see how open source production—as a human coordination mechanism—has enabled remarkable technological innovations and is today responsible for an increasing amount of the information production in the world. Some of these technological innovations include: Apache, Linux (the preferred operating system for programmers), Wikipedia (the killer of Encarta), as well as today’s public blockchain networks.
Contributions to open source production systems are voluntary and partially animated by social and psychological factors. In the event these contributors were made potentially liable to the public at large based on newly expanded and untested fiduciary standards, they would be likely to reconsider contributing to such projects, resulting in them ceasing to do so, or continuing in covert or non-public ways. If the risk of liability derived from the imposition of fiduciary obligations changes the incentive mechanism of public blockchain networks, open source production risks grinding to a halt.
Conclusion: Towards a Better Understanding of Public Blockchain Network Governance for Appropriate Liability Frameworks
We have argued that public blockchain protocol developers do not function as corporate fiduciaries, and further that labeling protocol developers as fiduciaries would be impractical and have other negative effects including potentially destroying the open source production model.
However, we have also readily acknowledged that public blockchain networks necessarily develop governance structures (however latent or dynamic) and that in some circumstances, protocol developers can exercise an influential role in the implementation of changes to certain software applications. As such, it is important to focus on better understanding the role that all participants in public blockchain networks play in their governance, and that the community of developers contributes to achieving this understanding.
In addition to the various regulatory frameworks currently available and those that may be designed to specifically reflect this techno-economic paradigm, an alternative and promising method to regulate the behavior of protocol developers and other participants in public blockchain networks is through the imposition of “on-chain” governance protocols.