Blockchain Protocol Developers are not Fiduciaries: An Analysis of the Cryptoeconomics of Open Source Networks and the Role of Protocol Developers in Public Blockchain Network Governance

Abstract

This paper analyzes the role of protocol developers in the governance of open source public blockchain networks such as Bitcoin and Ethereum. It addresses whether certain developers should be considered legal fiduciaries given their influence over changes in a public blockchain’s software client. We argue that — in the context of open source production systems — protocol developers play a radically different structural role than that played by fiduciaries and do not create the type of risks that require the imposition of fiduciary duties. We therefore conclude that fiduciary duties do not and should not apply to protocol developers under current law, and further, that given protocol developers’ structural capabilities and incentives, it would not be beneficial nor practical for fiduciary duties to be imposed as such. Relatedly, this paper hopes to add to the growing literature analyzing the potential of blockchain as an institutional technology which enables decentralized communities to come to consensus about a version of the truth and thus the creation of new open economies that are governed through a multi-level political process.

Introduction

Technological development challenges regulation. By enabling new modes of human interaction, technological advancements can turn existing regulatory frameworks obsolete and force governments to reassess their regulatory tools and approaches. The development of blockchain[1] exemplifies the regulatory challenge of technology. By enabling a wide array of never-before possible peer-to-peer interactions, blockchain technology threatens to disintermediate many of the traditional gatekeepers of certain highly regulated activities, such as early stage venture financing and cross-border money transmission, and has therefore put regulators on their heels.[2]

In this environment, financial and prudential regulators are called on to perform a tough balancing act. On the one hand, they must remain vigilant and guard against potential fraud, consumer harm and systemic risk. On the other, they must ensure that their stakeholders are able to benefit from the value created by new technological developments and that the markets they oversee remain competitive. To achieve this task, it is critical that regulators apply a legal framework that reflects the way the new economy works, and the economic incentives[3] and structural roles of the agents involved.[4] Academics who have studied technological revolutions have noted that a critical step in devising the social and regulatory paradigm that will allow a society to benefit from the full potential of a new technology is to fight the reflex to force age-old legal concepts from prior technoeconomic paradigms onto new economic models.[5]

The increased interest in open source public blockchain networks such as Bitcoin or Ethereum (“public blockchains”) is in large part due to technological breakthroughs in consensus algorithms. Leveraging these collective consensus mechanisms, “decentralized”[6] networks of individual computers are able to coordinate through a multi-level political process on a version of the truth and create new economic systems and communities. In this sense, we can understand public blockchains “as an institutional or social technology for coordinating people.”[7] The role that software developers play in the governance of public blockchains has rightly been the subject of intense interest on the part of regulators, academia and other commentators.[8] As part of this discourse, Angela Walch has suggested that developers who propose or advocate for changes to the code base of public blockchain software clients[9] (whom we refer to as “protocol developers”)[10] exercise power over users of public blockchains in a manner that “looks like” the power a fiduciary has over a beneficiary, and therefore, Walch argues, protocol developers should be subject to fiduciary duties, potentially towards the public at large.[11]

For the reasons laid out below, we disagree with the proposition that protocol developers are similar to fiduciaries or should be legally treated as such.[12] We recognize that public blockchain networks have governance structures and that, from time to time, certain individual protocol developers may exercise significant influence over the evolution of a certain software client. However, we argue that — viewed through the appropriate conceptual framework — the role played by protocol developers in the governance of public blockchain networks does not exhibit the structural dynamics, nor pose the risks of abuse, that uniformly characterize traditional legal fiduciaries and are the raison d’être for the imposition of fiduciary duties.

Our argument follows the following structure: (I) first we define the legal term “fiduciary” under current U.S. law by asking a series of simple questions; (II) after, we analyze the evolution of open source production, focusing on its inherent drivers and surprising track-record of rapid innovation; (III) in the third section, we argue that developers of open source public blockchain protocols do not play the role of legal fiduciaries, nor do they present the risks fiduciary law is intended to address; (IV) we then analyze the practical disadvantages that labeling protocol developers as fiduciaries would have on the legal system and the open source production framework; and (V) finally, we conclude by highlighting that there are several alternative avenues for influencing the behavior of protocol developers and other participants in the governance of public blockchain networks — including certain experimental “on-chain” governance technologies — which assuage any need to regulate developers through the amorphous and age-old concept of fiduciary obligations that was developed in response to a much different technoeconomic paradigm.

I. What are “fiduciaries”?

A first step to understanding whether protocol developers should be treated as legal fiduciaries under current law is to analyze the nature and function of fiduciary duties. To do so, it is helpful to guide our inquiry by asking the following questions:

a. In what types of relationships do fiduciary duties normally arise?

While the concept of a “fiduciary” traces its roots to the common law of trusts, courts in the United States have exhibited a tendency to expansively apply fiduciary duties to a growing number of relationships (both categorically and ad hoc), including to those found in corporate law and a host of other contexts. However, all “fiduciary relationships” share certain fundamental structural similarities.

Tamar Frankel, a noted academic of fiduciary law, explains that fiduciary obligations traditionally arise in relationships that exhibit two central characteristics:

(i) one party — the fiduciary — serves as a substitute for another party — the entrustor — in order to provide specialized services that are socially important and usually costly to acquire; and

(ii) in order for the fiduciary to achieve her stated goal, the entrustor must delegate either property or power to the fiduciary.[13]

Law and economics academics also provide an insightful framework for understanding fiduciary law, arguing that fiduciary obligations are applied by courts to relationships where principal–agent or agency problems frequently arise. Principal-agent problems occur whenever one party — the principal — must rely on another — the agent — to act on her behalf in an unobservable and discretionary manner, and by virtue of entering into such relationship, the principal exposes herself to potential harm from the agent’s actions.[14]

b. What are the inherent and structural risks posed to entrustors?

Frankel notes that “[e]ntrustment poses for entrustors the risk that fiduciaries will use the entrusted property and power for purposes other than in the service of the entrustor… [and] will not possess the expertise they purport to possess, or, even if they do, that the fiduciaries will not exercise their expertise well, or fail to exercise their expertise at all.”[15]

Arguing from a law and economics point of view, Robert Sitkoff states that “[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.”[16]

Therefore, we may say that fiduciary obligations are applied to relationships where one party (the “beneficiary”) is inherently and structurally vulnerable to abuses of power and agency problems due to their reliance on a second party (the “fiduciary”) to act on their behalf in an unobservable and discretionary manner. It has long been recognized that the structural disadvantages that characterize fiduciary relationships are endemic of systems that require participants to trust a centralized party and therefore allow that central party to exploit this trust and engage in self-serving and rent-seeking behavior.[17]

Importantly, fiduciary obligations are standards that enable courts to provide a remedy when “the protective mechanisms outside of fiduciary law cannot adequately eliminate the risk.”[18] Therefore, if one party (the potential beneficiary) can protect herself from abuse of power through alternative methods, such as observing the other party (the potential fiduciary) or by recourse to other legal regimes, there is no need for the application of fiduciary law.[19]

c. What is the purpose of fiduciary obligations?

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.[20] Sitkoff explains that 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.” [21]

Therefore, fiduciary obligations are a judicial deterrence tool meant to allow for socially beneficial services to be provided by experts, while regulating potential abuses of the structurally dominant position held by those experts. They are 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).

d. How do courts analyze whether a fiduciary meets her obligations?

To embody fiduciary obligations, courts have developed extensive jurisprudence on the duties of loyalty and the duty of care, which are legal standards applied by courts to judge whether prior actions of a fiduciary were legally adequate,[22] as well as other duties applicable to specific types of fiduciary relationships.[23]

The duty of loyalty addresses potential conflicts of interest by requiring a fiduciary to act in the “best” interests of the beneficiary and not favor her own interest or the interests of third parties. The aim of the duty of loyalty is to induce the fiduciary to avoid conflicts of interest entirely or to disclose them to the beneficiary, enabling the later to make an informed decision whether to consent to the conflict.[24]

The duty of care provides the standard by which the relative skill of the fiduciary’s performance is judged. Given the expert status of fiduciaries, courts analyze whether a fiduciary met her duty of care by applying a “reasonableness” standard that is informed by industry norms and practices. In other words, courts ask whether the fiduciary in question acted in a manner consistent with the way a reasonable fiduciary in her position would act (imputing to such fiduciary specialized knowledge reasonably held by such persons).[25]

Using the duty of loyalty and duty of care as standards, courts are able to evaluate whether a certain fiduciary acted adequately in her representation of the beneficiary. In the event a court finds that the fiduciary’s actions fell short of either standard (say, because the fiduciary favored herself over the beneficiary, or because the fiduciary acted carelessly in her representation of the beneficiary), the court may award a range of remedies, including compensatory damages to offset any losses suffered by the beneficiary, disgorgement of any of the ill-received profits of the fiduciary, and also punitive damages to punish egregious violations of the law by the fiduciary.[26]

e. What are some examples of fiduciary relationships?

In considering whether protocol developers should be treated as fiduciaries, it is helpful to keep in mind several examples of traditional fiduciary relationships and the risks that beneficiaries are exposed to in each circumstance. It is also important to note that neither the list below, nor the set of established categorical fiduciary relationships, exhaust the universe of potential scenarios where courts may apply fiduciary duties. As Sitkoff points out, courts may impose fiduciary duties ad hoc to any relationships of “trust and confidence” that present agency problems.[27] For example, in Burdett v Miller, Judge Posner noted “the relation between an investment advisor and the people he advises is not” a per se fiduciary relationship, but decided to impose fiduciary duties on the defendant investment adviser nonetheless based on the specific characteristics of the relationship at issue.[28] However, by comparing the role of protocol developers to the fiduciaries described below, we can begin to differentiate their functions and the range of risks they pose.

i. Trustee

The archetypal fiduciary relationship is that of a trustee and the trust’s beneficiaries. Trusts allow settlors to determine how their property will be distributed over time and are considered valuable estate planning devices. However, by being delegated control and legal ownership over the settlor’s property, the trustee is empowered to distribute it with certain discretion and potentially act in self-serving manners. For example, a trustee could misappropriate certain of the trust’s property for her own gain or distribute it against the wishes of the settlor, and in the process harm the trust’s beneficiaries. To prevent this type of abuse, trustees are subject to fiduciary duties, including a duty of loyalty that requires, among other things, that they distribute the property in accordance with the settlor’s intent.

ii. Director of a public company

A director of a public company owes fiduciary duties to the shareholders of her corporation. Directors are thought to contribute a valuable service to society: by deploying their business expertise to take risks and make decisions on behalf of their shareholders and other investors, directors contribute to the growth of their company and the economy. However, directors are also structurally enabled to act selfishly and against the interests of their stockholders and therefore are subject to limitations imposed by fiduciary duties. For example, there is ample case law interpreting the requirement of a director’s fiduciary duties to stockholders in the face of a hostile corporate takeover bid that would result in the ouster of the director, but a premium paid to stockholders.[29]

iii. Lawyer

A lawyer also owes fiduciary duties to her clients. Lawyers are thought to contribute valuable expert services to society that ensure — through the vigorous representation of their clients — that the justice system functions fairly. Yet, the practice of law can also be rife with potential conflicts and opportunities for self-dealing which has led to the application of fiduciary duties to lawyers. For example, a lawyer who fails to disclose that she is concurrently working for clients with opposing interests in a certain matter (or fails to get the required conflict waivers) would be in violation of her duty of loyalty.[30]

iv. Doctor

Doctors also owe fiduciary duties to their patients, often phrased in terms of the “Hippocratic Oath.”[31] Doctors are acknowledged to provide critical services to society by relying on their medical expertise to take care of our sick and elderly. Due, among other things, on patient’s reliance on doctor’s expertise, the doctor-patient relationship has been repeatedly characterized by courts as a fiduciary relationship.[32] Therefore, in the case that a doctor acts thoughtlessly (by operating on the wrong leg for example) she may be liable to the patient on grounds that she breached her duty of care.

II. The Evolution of Open Source Production:

The first section analyzed the types of relationships to which courts traditionally apply fiduciary obligations and the risks which fiduciary duties are intended to ameliorate. This section shifts our attention to the historical development and the inherent dynamics of what we refer to as “open source production” systems. As we shall see, an understanding of open source production and “commons” economics (as opposed to closed/private economies) is critical in being able to distinguish the role of protocol developers from that of legal fiduciaries.

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.[33] The term “open source”[34] refers to software that is freely distributed in source code form and evolves through a process that “involves software developers at many different locations and organizations sharing code to develop and refine software programs…”[35] In contrast, “proprietary” code refers to code that is distributed in object code form only and where the source code is protected as a trade secret.

As we shall explore more in depth in Section III.c, anyone is free to suggest a change to the code of a particular software client, but only those developers with “commit access” to the code repository have the power to incorporate a change into the code repository. While commit access may seem to grant the protocol developers who wield it with the coercive power to force code changes on other network participants, our analysis of the multi-level political process through which changes are adopted reveals this is not the case.

b. Production through voluntary contributions of decentralized actors

A main principle of open source production is that development work is undertaken by a decentralized group of volunteers who decide on their own account to collaborate with others in an iterative fashion. As compared to a traditional technology firm where software development is undertaken by employees who are instructed by managers to work on specific parts of a project, protocol developers contributing to open source production systems work on a piece of code when and if it interests them. While protocol developers in open source production systems do organize into communities, often around specific projects, interests or ideologies, these structures generally lack any formal hierarchy or coercive power that characterize traditional centralized institution.[36]

c. Open access to code and ability to “fork”

A corollary to the principle of allowing open collaboration as the driver of production is the commitment to making any iteration of the code freely available to the public for future use or modification. In other words, in an open source production system, anyone is allowed to suggest a code change to the community, and is also allowed to modify the existing code and try to build their 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 III.c below).

To accomplish the goal of free and public availability, open source projects publish their source code in an online repository and license it under a spectrum of FOSS licenses[37] that range from (i) the “strong copyleft” General Public License (GPL) family of licenses;[38] (ii) others such as the Mozilla Public Licenses, Apache Public Licenses, the Eclipse Public Licenses, etc. which take a moderate approach to the requirement to share code and (iii) the Berkeley Software Distribution and MIT Licenses, which are less restrictive on the obligations to share code. For example, the Bitcoin Core[39] software client is licensed under the permissive MIT License[40] and the Ethereum Client is licensed under the more restrictive GPLv3.[41]

d. Building cryptoeconomic institutions with tokens

Bitcoin’s most significant contribution may stem from the Bitcoin network’s ability to solve the “double spend problem”[42] which had hampered all previous attempts to launch a virtual currency. Satoshi Nakamoto’s elegant solution was to design an architecturally and politically decentralized state machine that is updated through a Proof of Work consensus mechanism.[43] The result was the ability of the Bitcoin network to support freely-tradable cryptographic tokens (“tokens”) that were unable to be copied, or inimitable, and limited in number. Stated differently, Satoshi’s innovation allowed for the newfound ability to transfer value over a peer-to-peer network.

Importantly, Bitcoin’s introduction of tokens provides a new “mechanism design” [44] tool to develop more complex incentive systems on top of open source networks. Using tokens, networks can now be designed in a way that economically incentivizes participants with different preferences and information to act collaboratively in order to optimize for a common goal. Tokens work as an incentive for network participants by motivating holders to grow the network and drive demand for the tokens, therefore leading to an appreciation in the tokens’ price.[45] As described by Chris Dixon, “[c]ryptonetworks provide economic incentives to developers, maintainers, and other network participants in the form of tokens.”[46]

In this sense, tokens enable the transformational aspect of public blockchain networks, which is their ability to create and execute rule-systems that result in new organizational and institutional forms of economic governance and enable bespoke socio-economic coordination. “A blockchain is in this sense a new species of rule-system for economic coordination: so, alongside firms, markets, clubs, commons, and governments we now also have blockchains.”[47]

e. Open source production track record of technological innovation

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. Speaking 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 free and open source software (FOSS) project.”[48]

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. In addition to Apache, open source production has created Linux (the preferred operating system for programmers), Wikipedia (the killer of Encarta), as well as today’s public blockchain networks.[49]

To understand why open source production seems to be so inimical to traditional economic models we can consider the role of copyright laws, which are intended to foster innovation by granting inventors property rights over their inventions and thus the ability to exclude others from benefiting from their use. Copyright laws are traditionally defended on the grounds that they promote innovation by preventing free-riders and ensuring that inventors are compensated for the sunk cost expended to discover their invention.

Open source production offers an almost diametrically opposed paradigm. Here, innovation is encouraged through a system where individuals contribute to a project without intention or ability to exercise any property rights over their contributions and knowing those contributions will be available for the free use by the community.[50] Yet by employing publicly observable reputational mechanisms and, after Bitcoin, cryptoeconomic incentive frameworks based on cryptographic tokens, open source production systems are able to overcome the free-rider problem and “generate cooperation in the production and maintenance of quasi-public goods.”[51]

III. Protocol developers do not function as fiduciaries nor do they create the risks commonly associated with fiduciaries

In the first section we discussed the structure exhibited by traditional fiduciary relationships and the risks that fiduciary duties are intended to ameliorate and in the second section we uncovered some of the underlying dynamics present in open source production and public blockchain development. This section examines whether, by exercising influence over changes to certain public blockchain software clients, protocol developers are functioning as legal fiduciaries and raising the risk of abuse meant to be deterred by the imposition of fiduciary duties.

Our analysis is structured as follows: (a) first we recognize that public blockchain networks, like any form of human organization, develop governance structures; (b) then we clarify whom “protocol developers” refers to and analyze the general role and motivation of the different types of protocol developers; © using the Bitcoin network as an example, we later provide an overview of how changes to the Bitcoin Core software client are implemented in practice and (d) finish by directly comparing the role of public blockchain protocol developers to fiduciaries, finding that protocol developers do not (i) play similar structural roles as fiduciaries, nor (ii) do they pose the risks traditionally posed by fiduciaries.

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” they are anarchic systems. 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.”[52] Therefore, we do not claim that protocol developers should not be regulated as legal fiduciaries on the basis that public blockchain networks lack a governance structure, nor because developers lack influence over those governance structures. Rather, we argue that the dynamic role played by protocol developers in the development and governance of public blockchain networks is not of the nature, nor does it present the risk associated with, a legal fiduciary relationship.

b. The function and incentives of protocol developers in public blockchain networks

i. What do we really mean by “protocol developer”?

In the context of open source software production generally, the term “developer” may refer to various unrelated individuals who play fundamentally different roles over time. When talking about public blockchain networks, it is first important to distinguish between developers contributing to the software client supporting the network (to whom we have been referring to as “protocol developers”) from those developers building decentralized applications by coding and deploying application-specific code known as “smart contracts” onto public blockchain networks (to whom we shall refer to as “smart contract developers”). Of course, the same individual may from time to time perform both roles.

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 particular software client. One role is the “catalyst” developer, who provides the impetus for the launch of a decentralized open source project and as we shall see subsequently recedes. The other role is played by the developers who voluntarily contribute their efforts collaboratively and iteratively 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,” allowing them to incorporate changes into the public repository. Further, while traditionally open source developers are unpaid volunteers, certain protocol developers are employed by businesses or foundations associated with the open source project to which they are contributing.[53]

ii. Catalyst developers and network effects

While public blockchain networks can exhibit decentralizing tendencies over time,[54] out of necessity, they begin with a sponsor which (at least until now) tends to be a centralized group or even a single individual. In fact, open source projects often share similar genesis stories associated with an individual who becomes frustrated by a particular circumstance, takes it upon herself to address the issue, and invites others to help along the way.

In The Starfish and the Spider, Brafman and Beckstrom study the agents responsible for beginning decentralized organizations (including open source projects such as Linux, Apache, Wikipedia and also Craigslist and even Alcoholics Anonymous) whom they refer to as “catalysts.” They find that the fundamental characteristic catalysts share is that they play a dynamic role in the development of decentralized organizations, being critically important at the beginning, but incrementally stepping back and allowing others to make decisions as the project grows and matures. “We see the same pattern with every decentralized organization,” Brafman and Beckstrom argue, “a catalyst gets a decentralized organization going and then cedes control to the members.”[55]

In their seminal study of open source economics, Jean Tirole and Josh Lerner provide a similar account of the development of open source software projects noting that, “although the leader is often at the origin a user who attempts to solve a particular program, the leader over time performs less and less programming.”[56]

Looking at the example of the launch of the Bitcoin network, the role of a catalyst is evident. With the background of the world financial crisis, “Satoshi Nakamoto” famously published the Bitcoin whitepaper in October 31, 2008 and soon after coded the very first Bitcoin client, releasing it in January 2009. She/he/they interacted on web forums for a short time thereafter, before disappearing into oblivion, without ever after being successfully identified. Satoshi’s ability to define the general architecture of the Bitcoin project, coalesce a community around Bitcoin and later disappear, makes Satoshi an archetypal catalyst developer.[57]

One potential explanation for the dynamic role that catalysts play in the open source projects are network effects.[58] Decentralized open source projects and public blockchain networks such as Bitcoin exhibit strong positive network effects, which means that the more users who flock to the network, the more the value of the network increases for other users. Therefore, in order for a public blockchain or other open source project to be successful and exhibit the value creation associated with network effects, the catalyst who launched the project will need to attract more participants to join the network and contribute their efforts for free. Incentivizing contributions from other developers is not an easy task and requires, at a minimum, that the catalyst developer (i) establish trust in the fundamentals of the project and her role in its governance; and (ii) provide opportunities for developers to build something that is seen as valuable and interesting by them and others in the community.[59]

iii. The incentives of developers contributing to open source projects

Analyzing the issue from a different point of view, we may ask: what motivates skilled developers to contribute to an existing open source project? Developers are highly technical workers who have the potential to be lucratively compensated for their work by modern firms. Yet, by contributing to open source projects such as Linux or Apache, developers are generally not remunerated and unlikely to get anything of direct value[60] from their contributions unless the project ends up a success.[61]

But developers contribute to open source projects in droves. We noted earlier that Linux has amassed many thousands of contributions over its history. In a more recent example, since Bitcoin was launched in 2009, a decentralized group of developers has maintained the “Bitcoin Core” software client,[62] which as of September 2018 had over 18,000 revisions (or “commits”) implemented by over 570 individual contributors.[63] How can we explain this phenomenon?

1. Social and psychological incentives

The academic literature finds that the contributors to earliest open source software projects were motivated by the medium- to long-term social and psychological impact of their work, as opposed to by a short-term economic payoff. After studying the open source economies that evolved with the invention of the internet, Jean Tirole and Josh Lerner described developers’ motivations as “career concerns” and “ego gratification,” which is essentially reputational value they gained from being seen as a significant contributor to a successful open source project.[64] Tirole and Lerner argued that, as compared to closed/private economic systems, open source economies exhibited stronger “signaling incentives” which motivated developers to provide value to their community in hopes of being able to accrue reputational benefits from successful contributions down the line.[65]

In addition, contributors to open source projects are often animated by a particular ideology which influences their decision-making over particular design and architectural choices. For example, the open source software movement was closely associated with the free and open source software (“FOSS”) ideology. Similarly, the emergence of Bitcoin and other public blockchain networks is associated with the “cypherpunk” ideology, which was in part a reaction to the perceived shortcomings of the international financial system and a lack of privacy in modern societies.[66]

2. Economic incentives through tokens

While the developers contributing to the earliest open source software projects were mostly motivated by social and psychological factors, Bitcoin inaugurated a new paradigm of open source production by introducing tokens into open source economies. As noted in Section II.e , tokens provide a new mechanism design tool that could be used to influence the actions of network participants. For example, catalyst developers can come to acquire the tokens by means of a pre-mined allocation and contributing developers can be directly remunerated with tokens for their contributions. By holding the token, these developers will be directly economically incentivized, through the appreciation of the token, to attract more users to the network and drive demand for the tokens. Taken together with the long-term social and psychological drivers (including reputational gains and ideological motives) tokens can be used to align the incentives of developers with other network participants towards a common goal.

c. How are changes to software clients made and what is the role of developers in implementing those changes in the network?

How can we understand the process through which changes to a particular software client of a public blockchain network are made? More importantly for our purposes: what is the role of protocol developers in the process of updating a software client and implementing it on the netowork, and do developers act as legal fiduciaries during this process?

i. Changes to a public blockchain’s software client come from the political consensus of network participants

Public blockchain networks do not function in reliance of one single “code base,” but rather can support a range of software clients so long as they all agree on the consensus rules of the network.[67] In this sense, while Bitcoin Core is the original and most important software client on the Bitcoin network, it does not represent the totality of the network, nor does it have a monopoly over the consensus rules or the direction of development of the network.[68] As we shall argue, the consensus rules and development direction of public blockchain networks are defined by the choice made by the economically significant network participants of which software client to run.[69]

Public blockchain networks vary significantly in their architecture and design. Using the Bitcoin protocol as an example, the direct participants of the network (the “formal participants”) are (1) the network users (e.g., token holders) and (2) the network nodes (both miners and other full nodes that run the software client). In addition, 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).[70] In addition to the formal and indirect participants outlined above, public blockchain networks develop large communities composed of a diverse ecosystem that includes many additional participants, including unaffiliated individuals willing to trade valuable service or assets for tokens.

ii. A multi-level coordination model of public blockchain governance

Changes to a public blockchain network that affect the basic rules (or “consensus rules”) of the protocol are extremely 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.[71]

Vitalik Buterin 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.” At a fundamental — layer 1 — level, every formal participant has the ability to “run whatever software [client] they want in their capacity as a user, miner, participant, validator or whatever other kind of agent a blockchain protocol allows them to be.”[72] While the bottom layer provides formal participants with ultimate decision-making authority regarding what software client to run, due to the strong positive network effects experienced by public blockchain networks, the decision of each of the formal participants is influenced by their perception of other formal participants’ likely choices and coordinated by other informal participants’ actions.

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.”[73] These coordinating institutions use their structural ability to signal preferences and steer the formal participants of network to towards consensus.[74]

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 client,[75] and (2) play the role of coordinating institution in advocating for a particular change. Critically, protocol developers are not formal participants of a public blockchain network and, as such, lack the ability to “cram down” changes on other network participants.

iii. Lifecycle of a Bitcoin Core update

Updates to a public blockchain’s software client (including Bitcoin Core) can be proposed by anyone.[76] In the case of Bitcoin Core, small code enhancements or patches (which don’t require standardization between projects) can be suggested by opening an “issue” or responding to one of the open “pull requests” on GitHub page.[77]

Major changes to the Bitcoin Core software client are suggested through Bitcoin Improvement Proposals (“BIPs”).[78] Each BIP is proposed by an individual — referred to as a “champion” — who drafts the proposal in the required style and format[79] and initiates discussions in the appropriate forums. Most importantly, once the BIP has been drafted, the champion must leverage her prestige and persuade others to support her idea.

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.[80] This public draft of the BIP will be intensely studied, debated, tested and refined by the community, enabling the BIP’s champion to flesh out the draft and address any initial concerns.

Once a BIP has been “socialized” with the community and properly formatted, it may be submitted to the Bitcoin GitHub repository as a “pull request.”[81] At this point, an editor (the “BIP Editor”)[82] will decide whether to merge the pull request to the Bitcoin Core BIP repository. While the BIP Editor has the nominal power to reject a BIP at this stage, the risk of censorship is ameliorated in practice. To begin with, Bitcoin Core’s policy calls for a liberal standard of BIP acceptance that focuses on formatting and technical requirements over a normative judgment of the BIP.[83] Moreover, a developer who has their BIP censored by the Bitcoin Core BIP Editor can always implement their desired change by soft forking the Bitcoin Core code and launching their own software client on the Bitcoin network or resorting to a hard fork that splits the network as described in Section III.c.iii.2 below.

Once a BIP has been accepted and merged into the Bitcoin Core repository, the BIP Editor will assign the BIP a number,[84] label it according to its formal type[85] and give the BIP the status of “Draft.” From Draft status, the BIP can progress according to the flowchart laid out below, with “Active” referring to a BIP that has been implemented:

[86]

A champion has the ability to 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”[87] amongst active developers on the mailing list.” [88]

In order for a BIP to get from Draft status to Final status (meaning implemented on the Bitcoin network) it has to be approved 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 client. 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 client in order to maintain consensus in the network (given that full nodes running the old, non-implementing software client will still be able to accept new blocks generated by the miners running the new implementing software client). As such, implementing a soft fork BIP requires only adoption of the miners, usually through a supermajority “vote” of 95% of active hashpower.[89]

In order 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.”[90]

Miners truly “vote” on whether to implement a particular BIP by choosing whether to apply their hashpower and mine new blocks running an implementing or non-implementing software client. Given the positive network effects of public blockchain networks, when deciding whether to mine running implementing or non-implementing software client, miners must anticipate which version of the software client the broader community will coalesce around. Academics 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.”[91]

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 hashing power in relation to the value of the token being mined. Therefore, a key factor in a miner’s decision framework (i.e., which version of the software client to run) is the effect that a certain proposed code change will have on the value of the token. The value of the token is in turn determined by those willing to offer things of value in exchange for the underlying token (be it goods, services or other currencies). 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.

In addition, 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.[92] As implemented in connection with BIP 16, the USAF entitled full nodes and other informal participants to signal support for a “flag day” upon which all participating full nodes would be committed to upgrade to a new software client and reject blocks produced by miners running the old non-implementing software client. In connection with BIP 148, the contentious SegWit update which was the centerpiece of Bitcoin Core’s scaling roadmap, the UASF only required a certain threshold of users to signal for approval given that a substantial percentage of the network had already upgraded to the implementing software client. While miners are still required to implement a “User Activated” Soft Fork, the mechanism works as a signaling / commitment strategy meant to influence miners’ decisions to implement a BIP out of fear of losing the block rewards by building on a minority chain. [93]

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 client (or simply implement a software client with different consensus rules and create a new chain) will not accept blocks created by miners running the upgraded software client. While soft forks can be implemented by miners only, the implementation of hard forks requires every formal participant to upgrade to the new implementing software client. Hard forks therefore represent a “permanent divergence from the previous version of the Blockchain.”[94]

Critically, a “hard fork” serves as the ever-present escape valve accessible to any network user or informal participant who finds available software clients disagreeable. [95] They effectively allow any individual to copy the current source code of a certain public blockchain’s software client, modify it to reflect a new ruleset, re-release it to the public and coalesce a community around the revised protocol. [96] In this way, hard forks ensure “the community as a whole can never be forced to adopt undesirable changes to Bitcoin.”[97] For example, should a bad actor or group take the Bitcoin Core client in a poor direction, the broader community would have the ability to reverse the undesired change or make a new modifications and launch a new project.[98]

While copying publicly available software client might seem simple in theory, hard forks have limitations and are costly in practice.[99] By potentially splitting a community in two, hard forks threaten the value creation and efficiencies derived from network effects. Further, hard forks can result in contentious disputes over which of the post-fork chains gets to use the pre-fork marketing name.[100] However costly, hard forks provide an “exit” option to formal participants of a public blockchain that ensures they will not be “crammed down” a version of the code they do not support and thus provide a viable avenue to minimize risks of undue influence on the code by third parties.[101]

d. Role of protocol developers compared to fiduciaries

Having previously analyzed the structural role and incentives of protocol developers in public blockchain network governance and, as an example, outlined how changes to the Bitcoin Core software client are implemented in practice, we now turn to directly comparing the role of protocol developers in public blockchain network governance to the role of traditional legal fiduciaries. As laid out below, we find that protocol developers (i) play radically different structural roles than fiduciaries, and (ii) do not pose the risks that fiduciary duties are meant to address.

i. Developers play radically different structural roles than fiduciaries

The role that protocol developers play vis-a-vis token holders and other public blockchain network participants bears little similarity to the role of fiduciaries as specified by Frankel’s and Sitkoff’s frameworks outlined in Section I. Protocol developers are not agents of another party, nor are they delegated with power or authority by other participants in public blockchain networks, neither are they compensated by them. Further, the need to impose fiduciary duties is negated due to the various viable alternatives available to regulate protocol developers, including other network participants’ ability to act in their self-interest.

1. Protocol developers are not agents

While courts have found that fiduciary duties apply to a variety of different categorical relationships, we have noted in Section I.a how all such relationships are characterized by an agreed-upon agency relation that is structurally vulnerable to abuse.[102] In describing how an ad hoc fiduciary relationship may arise, Judge Posner notes the need for a preexisting agency agreement noting that “If a person solicits another to trust him in matters in which he represents himself to be expert as well as trustworthy and the other is not expert and accepts the offer and reposes complete trust in him, a fiduciary relationship is established.”[103]

When analyzing whether protocol developers are acting as legal fiduciaries, it is therefore insightful to focus on whether they are functioning as the legal agent of any of the other participants in a public blockchain network. As we shall see, no agency relationship exists between protocol developers and token holders, nor with any other network participant for that matter.

Agency is legally defined as a relationship in which one party (the agent) can affect the other party’s (the principal) legal status vis-à-vis third parties when acting with actual or apparent authority.[104] Given agents’ ability to bind their principals, very principal is afforded the power to control the agent’s actions by providing them with instructions which the agent must reasonably interpret and abide by.[105]

The lawyer, for example, enters into an agreement with her client that lays out the scope and terms of the representation. While a lawyer is required to consult with the client before making certain types of determinations, she is also afforded the power to bind her client in dealing with third parties. Should the lawyer’s actions come under scrutiny, the courts will decide whether her behavior met the standards imposed by her fiduciary duties, as informed by the agreement of representation she had with her client.

By way of another example, a trustee is appointed pursuant to a trust agreement entered into with the settlor, which spells out the trustee’s power and responsibilities over the assets held in trust. The trustee must voluntarily assent to her position for the trust to be formed. The trust agreement then empowers the trustee to act on behalf of the settlor and delineates her ability to exert control over the trust’s assets and can therefore also be the basis of a challenge when the settlor or the beneficiaries find the trustee’s actions disagreeable.

In contrast, protocol developers cannot be said to act as the 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 inherently different from the actions undertaken by a fiduciary during her representation of the beneficiary, and as delineated by an agreed-upon and pre-existing agency relationship. To begin with, there is no appointment (direct or indirect) or acceptance of any agency role.[106] At no time do protocol developers consent to enter into any kind of agreement establishing an agency relationship with predetermined responsibilities and a term. Neither are other network participants agreeing to being bound by such designation nor do they have an ability to control the actions of protocol developers. Further, no parties can be said to have a reasonable expectation that an agency relation will be imputed, and are thus prevented from acting in anticipation of the potential consequences.

Critically, protocol developers lack the ability to bind any other network participants and, further, 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 client 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 whatever version of the software client as well as hard fork the Bitcoin Core client (or any other software client of a public blockchain network). These actors have the ability to independently audit the proposed revisions and evaluate their choices. A protocol developers’ ability to influence the welfare of the token holder (i.e., the value of the token) is therefore limited to proposing and advocating for a solution that is subsequently adopted by the community.

In claiming that protocol developers act as fiduciaries, Walch points to the perceived influence that certain catalyst protocol developers and other prestigious contributing protocol developers can exert by way of being able to “speak for the community” in public appearances and in meetings with public officials.[107] It is undeniable that certain protocol developers[108] have significant influence — through a combination of their structural power (i.e., commit access to Bitcoin Core client) and reputation (established through prior contributions) — over the Bitcoin community and the Bitcoin Core git repository (or the software clients of other public blockchain networks).[109] However, protocol developers — no matter how influential — do not have the ability to speak authoritatively for the community as a whole (or for anyone other than themselves) in the same way that a lawyer may be empowered to speak for their client, or a public company officer may be delegated by the board to speak for their company.

2. No delegation of power or property

Under Tamar Frankel’s framework, a fundamental characteristic of fiduciary relationships is the entrustor’s delegation of power or property to the fiduciary, which is necessary for the later to achieve their goal. For example, a settlor must cede ownership and control over the assets she places in trust, and without such asset transfer the whole arrangement becomes pointless. Similarly, a client legally empowers their lawyer to act as their representative allowing the legal system to function more efficiently.[110]

In contrast, there is no action that take places between a protocol developer and a token holder or any other network participant that could be adequately characterized as a delegation of property or power. We have already noted 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 the protocol developers. Further, the ability of protocol developers to act is not dependent or enabled by a specific action taken by any particular token holders.

The attenuated relationship between a public blockchain protocol developer and a token holder is established on the basis of two separate actions: (a) a protocol developer’s decision to contribute code to a particular software client and (b) another’s decision to participate in the public blockchain network by acquiring tokens or operating a node. Neither of these actions alone, nor their combination, can be said to constitute a delegation of power or property by a token holder or the acceptance of such power or authority of the token holder by a given protocol developer.

For the avoidance of doubt, it is worth noting that the decision of an individual to acquire a token cannot be interpreted as a delegation of property or power to a protocol developer given that, as a result of that action, protocol developers are neither directly gaining control over property nor gaining the ability to bind the token holder to any decision. Critically, the purchase of tokens should not be confused with the purchase of public company equity securities, given that public company directors have the ability to legally bind the shareholder’s 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. In contrast, protocol developers have no such ability to bind other network participants.

One may argue that the potential effect that updates to a certain software client proposed by protocol developers may have on the value of tokens demonstrates a delegation of property from the token holders to the protocol developer, which could be the basis of a fiduciary relationship. However, the token’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.

3. No compensation for services

Legal fiduciaries are traditionally compensated handsomely for both their expert services and for the risk of liability associated with their fiduciary obligations.[111] In contrast, while some protocol developers are compensated by foundations or other entities associated with projects they contribute to and could potentially stand to benefit from the appreciation in value of tokens they may hold, they are traditionally not directly compensated for their services or the risk of liability potential claims relating to breaches of fiduciary duties.[112]

4. 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.”[113] 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 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.

ii. Protocol developers do not pose the 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.

We have noted that the key risk in fiduciary relationships are addressed by imposing the (1) a duty of loyalty which is intended to prevent the fiduciary from acting selfishly and against the interests of the beneficiary, and (2) a duty of care which is intended to prevent the fiduciary from acting carelessly and causing harm to the beneficiary.

1. Developers are not empowered to act selfishly to the detriment of other network participants

Fiduciaries are usually empowered to act with discretion in unobservable ways and bind the beneficiary, resulting in the risk that they will act in self-serving ways to the detriment of the beneficiary. We have noted earlier how any revisions to software clients suggested by protocol developers must be implemented by other formal participants of the network through a multi-level process and as a result, protocol developers do not have the structural ability to act with discretion and bind other network participants.

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. In some cases, such as when a patient is under anesthesia and is being operated on by the doctor, the ability for the beneficiary to monitor the fiduciary at work is impossible. In others, such as the shareholder who is entitled to only certain information about the actions of the board, the beneficiary has the ability to monitor the fiduciary, but this monitoring is limited in order to achieve a public policy goal.[114] In either case, the fiduciary duties are applied to ameliorate the information asymmetries arising from the beneficiary’s limited ability to monitor the fiduciary from being exploited by the fiduciary to her advantage.

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 client is by definition readily accessible to the public through an online git repository. Moreover, updates made to a certain software client, through BIPs and similar processes, 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.”[115] Given that a significant part of the impetus for protocol developer contributions to public blockchain networkss is the reputational value gained from being associated to important contributions to the project, these projects also make contributions highly visible and attributable to specific protocol developers.[116]

While most token holders are not knowledgeable enough to understand the technical details of particular projects or revisions, a vibrant ecosystem of participants has developed which have the technical knowledge and economic incentives to take a “deep dive” into the technicalities of particular projects and signal their preferences to formal network participants and the market generally. We explored in Section III.c.ii how certain institutions played a coordinating role with formal participant to the network and by the same process provide synthesized information to the broader market through their statements and actions.

2. Developers are not incentivized to act selfishly to the detriment of other network participants

We have noted that protocol developers contributing to a certain software client 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 tokens they may hold. Given that protocol developers are incentivized by their reputational gains from contributing to a successful project and economic gains from the value appreciation of tokens associated with network effects, a protocol developer’s ability to benefit from their contribution to a certain software client is directly linked to the success and growth of the related network. Since the incentive alignment between protocol developers and other network participants, the need to impose fiduciary duties is ameliorated.[117] This context is radically different from that of traditional fiduciary relationships that provide the fiduciary with the ability and incentive to act selfishly to extract short-term value to the detriment of the beneficiary.

3. 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 highly experimental. As a result, errors in the code of software clients occur and can be expected to continue.[118] However, given the motivations of protocol developers and the multi-party political process governing changes to the network, the risks that protocol developers will act carelessly and harm other network participants is much lower than in the context of traditional fiduciaries. Protocol developers are directly incentivized to produce the highest quality code given that they are staking their reputations on it and are economically incentivized to do so. Further, public blockchain networks have developed processes and standards for auditing code, such as BIPs, which exert a level of quality control that arguably beats any alternative centralized process. Not only is each update scrutinized by arguably the most capable protocol developers in the particular system, but they are also analyzed and tested by other network participants who have significant economic interest and technical capabilities to audit the code before implementing it.[119] Open source’s track record of innovation in highly technical areas is a testament itself to the quality of work produced by this system.

IV. Effects of imputing fiduciary duties on protocol developers

For the arguments laid out above, we believe that it would be inconsistent with settled judiciary precedents for a court in the United States to extend fiduciary obligations to any public blockchain protocol developer. However, 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 standard for courts to interpret

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. How would courts asses 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.

However, 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 terminology[120] or relying on conclusory definitions.[121]

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 client 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 being burdened with fiduciary obligations. Importantly, without the ability to delineate which developers in particular 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 client 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 client, such as Bitcoin Core, does not entail control over a network which we have noted can support different software clients. 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. How would courts define who is a “beneficiary”?

According to Justice Felix Frankfurter “to say that a man is a fiduciary only begins analysis; it gives direction to further inquiry. To whom is he a fiduciary? What obligations does he owe as a fiduciary?”[122] However, Walch admits that she is “somewhat vague about who, precisely are the parties to whom key developers would act as fiduciaries.”[123] While some may dismiss the inability to define fiduciary and beneficiary as a mere complexity to be worked out down the line, we argue that it represents a fundamental structural flaw with the fiduciary framework as applied to protocol developers which would render it impossible to impractical in practice.

When discussing who protocol developers owe fiduciary duties to, Walch initially focuses on token holders and other network participants. For the reasons laid out above, we disagree with this characterization. In addition, Walch states that “[u]sers of the applicable cryptocurrency appear to have the most reliance on the blockchain, but there are arguments that the other businesses within the ecosystem do as well. Ultimately, the fact that the public could be impacted if public blockchains become infrastructure, or if cryptocurrencies become systematically important to the financial system, may mean that these fiduciary duties run to the public at large…”[124]

The position that certain protocol developers owe fiduciary obligations to the public at large is as untenable as the position that all protocol developers (even those only reviewing code) are de facto fiduciaries. Walch support her position by analogizing to arguments that politicians or judges are fiduciaries to the public.[125] However, these arguments are distinguishable from the case of protocol developers on the grounds that politicians and judges are voluntarily elected or appointed to their positions. In any event, to our knowledge, no court has held that politicians or judges owe such fiduciary duties to the public. Holding that protocol developers owe fiduciary duties to the public would thus seem to be a radical and inadequate expansion of the concept.

Further, fiduciary obligations are a deterrence mechanism that provide legal recourse to parties who are structurally susceptible to abuses or power. The imposition of fiduciary obligations on public blockchain protocol developers would allow, under Walch’s most extreme position, any member of the public at large to file a lawsuit in their local court and have a judge determine whether, in proposing a certain code update to a software client, a protocol developer owed a duty of loyalty or duty of care to the allegedly aggrieved party and whether either duty was violated. Granting the public at large, or even a subset of blockchain network participants, the ability to file a suit against protocol developers would therefore create the potential for an avalanche of litigation that would be piled on to an already overwhelmed court system.

b. Ineffective

From the view point of institutional design, it is also clear that local courts are not the best arbiter of whether a particular code update was done selfishly or with lack of care. Consider, for example, the ability of a district court judge or jury to determine whether a particular line of code implemented into a complex functioning protocol was “negligently” written. Assessing the potential damages stemming from the introduction of the code would also be highly complex, on a different scale than the calculations required by today’s mass torts and other highly technical litigation. We posit that blockchain communities themselves, given their technical expertise, review processes and lively discourse, would be better suited to determining the quality and desirability of updates to a particular software client.

c. Deter or kill open source

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. We noted in Section 2.e how 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 world’s information. 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 on the basis of 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 netowrks, open source production risks grinding to a halt.

V. Conclusion: Towards a better understanding of public blockchain network governance

We have argued that public blockchain protocol developers do not function as, or present the risks traditionally associated with, legal 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 from time-to-time certain individual protocol developers can exercise an influential role in the implementation of changes to certain software clients. 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.[126] In addition, we acknowledge the critical role of regulators in protecting the public and policing the markets, including by holding accountable developers who willfully design and launch malicious smart contracts and other software.[127] However, for the reasons stated above, we find the argument for extending fiduciary duties to protocol developers to be both untenable and undesirable.

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, such as the ones proposed by the Tezos and Decred projects. By means of these on-chain consensus mechanisms, formal participants of a network will be able to decide which code updates are implemented according to a pre-existing ruleset. As we have argued, blockchains are at their core a “foundational technology for new forms of governance for making rule-governed economic orders.”[128] Therefore, the technology itself can provide the means to regulate the actions of the relevant participants. In contrast, the imposition of fiduciary duties on protocol developers risks the “corporate capture” of blockchain governance whereby experimentation with new human institutional arrangements is foregone in place of adopting a corporate governance structure which becomes the sole source of legitimacy for blockchain governance. [129]

This paper is the product of ongoing conversations with the DLx Law team and deeply indebted to the guidance provided by Lewis Cohen, Gabriel Shapiro, Greg Strong and other colleagues. In addition, I wanted to thank Jenny Leung, Noah Batist and Lewis McCorkle for their comments and encouragement.

[1] A blockchain is a type of distributed ledger maintained and updated by a number of network participants through a consensus mechanism, as compared to a traditional database that is stored in a central, permissioned, server.

[2] In a recent speech, CFTC Commissioner Brian Quintenz phrased the resulting issue succinctly: “How can our regulatory apparatus, built to register and oversee intermediaries, adequately police our markets and set standards for a disintermediated market?” See Remarks of Commissioner Brian Quintenz at the 38th Annual GITEX Technology Week Conference, October 16, 2018, (the “Quintenz Speech”) available at: https://www.cftc.gov/PressRoom/SpeechesTestimony/opaquintenz16.

[3] An incentive is something that makes people act in a particular way. As we shall explore in the context of public blockchain networks, incentives may be used to achieve common gains by aligning parties with different motivations and degrees of knowledge.

[4] As recently stated in a blog post by Bill Gates, “lawmakers need to adjust their economic policymaking to reflect these new realities.” https://www.gatesnotes.com/Books/Capitalism-Without-Capital.

[5] See, Carlota Perez, Technological Revolutions and Financial Capital: The Dynamics of Bubbles and Golden Ages, 2002, Edward Elgar Publishing, Inc.; pg. 145 (arguing that “An adequate set of institutions is needed to complement, shape and guide the transformations that take place in the economic sphere [due to technological revolutions]. Yet, it cannot be a blissful return to what worked in the previous paradigm; it must be the complex design of what will work with the new one.”)

[6] “Decentralization” is an often-used term in the discourse surrounding public blockchain networks, which suffers from a lack of precision. Vitalik Buterin provides a useful framework for understanding the meaning of “decentralization,” noting that, in the context of open source software, the term may actually refer to three separate axes of (de)centralization:

Ø architectural (de)centralization (how many physical computers make up a system?);

Ø political (de)centralization (how many individuals or organizations ultimately control the computers in the system?); and

Ø logical (de)centralization (are the interface and data structures that the system presents and maintains coherent or disparate?)

See Vitalik Buterin, The Meaning of Decentralization, February 6, 2017, available at: https://medium.com/@VitalikButerin/the-meaning-of-decentralization-a0c92b76a274.

As used in this paper, the term “decentralized” refers to the second of Vitalik’s categories — political (de)centralization. In their book The Starfish and the Spider, Ori Brafman and Rod A. Beckstrom provide more context to political (de)centralization, or what they call “decentralized organizations,” describing them as organizations where “there’s no clear leader, no hierarchy, and no headquarters. If and when a leader does emerge, that person has little power over others. The best that person can do to influence people is to lead by example.” In these organizations, “There are rules and norms, but these aren’t enforced by any one person. Rather the power is distributed among all the people and across geographic regions”; pg. 20 (“The Starfish and the Spider”).

[7] Other academics have argued that while blockchain technology “at first appears to be part of the [Information and Communication Technologies] revolution [it] is actually better understood as a revolution (or evolution) in institutions, organization and governance.” Sinclair Davidson, Primavera De Filippi, Jason Potts, Economics of Blockchain, available at: https://papers.ssrn.com/sol3/papers.cfm?abstract_id=2744751, pg. 1 (“Economics of Blockchain”). See also, Jeffrey Atik and George Gerro, Hard Forks on the Bitcoin Blockchain: Reversible Exit, Continuing Voice 1. Stanford J. of Blockchain Law & Policy 1 (2018) (arguing that “The Bitcoin blockchain marks a novel form of social organization”) (“Hard Forks on the Bitcoin Blockchain: Reversible Exit, Continuing Voice”).

[8] See, e.g., Howard Marks, Should Satoshi Nakamoto Go to Jail?, October 24, 2018, available at: https://hackernoon.com/should-satoshi-nakamoto-go-to-jail-12ccb679e49d; Tim Swanson, Bitcoin Is No Just a Ticker Symbol and Stopped Being Permissionless Years Ago, November 13, 2017, available at: https://www.ofnumbers.com/2017/11/13/bitcoin-is-now-just-a-ticker-symbol-and-stopped-being-permissionless-years-ago/; and Ciaran Murray, Are Public Blockchain Systems Money Services Businesses in Disguise?, October 12, 2017, available at: http://rulesofthegame.blog/2017/10/12/are-public-blockchain-systems-money-services-businesses-in-disguise/.

[9] A “software client” refers to open source code designed to facilitate transactions and consensus on public blockchain networks. The Bitcoin Core teams described software clients as “the end-user software that facilitates private key generation and security, payment sending on behalf of a private key, and optionally provides: (i) useful information about the state of the network and transactions; (ii) information related to the private keys under its management; and (iii) syndication of network events to other peer clients.” See https://en.bitcoin.it/wiki/Clients.

As discussed further in Section III.c, it is critical to note that individuals can interact with public blockchain networks by running a range of software clients as long as each client recognizes the general or “consensus” rules of the public blockchain. In other words, there is not one “code base” for public blockchain networks such as Bitcoin and Ethereum, which currently support dozens of software clients each. In addition to the Bitcoin Core client, there are also 22 versions of the software client that can run on the Bitcoin network. In fact, commentators have argued that “diversity of [software] clients users run is…a key strength” of a public blockchain network. Bitmex Research, Competing with Bitcoin Core, October 15, 2018, available at: https://blog.bitmex.com/bitcoin-cores-competition/ (“Competing with Bitcoin Core”).

[10] See Section III.b.i for an attempt at a more precise definition of “protocol developers”.

[11] See Angela Walch, In Code(rs) we trust: Software developers as fiduciaries in public blockchains, June 27, 2018, available at: https://papers.ssrn.com/sol3/papers.cfm?abstract_id=3203198 (“In Code(rs) we trust: Software developers as fiduciaries in public blockchains”) (arguing in a section titled “If it looks like a fiduciary…” that “[w]hen using a general definition of ‘fiduciary,’ certain developers of public blockchains show a strong resemblance.” Pg. 9.

[12] While our analysis below focuses specifically on the application of U.S. law, we believe it would be persuasive in other common law jurisdictions with a similar concept of legal fiduciary.

[13] See, Tamar Frankel, Fiduciary Law, 71 Cal. L. Rev. 795 (1983) available at: https://scholarship.law.berkeley.edu/cgi/viewcontent.cgi?article=2137&context=californialawreview (“Fiduciary Law”); pg. 808; Tamar Frankel, Fiduciary Law in the Twenty-First Century, Boston University Law Review, Vol. 91; available at: https://www.bu.edu/law/journals-archive/bulr/documents/frankel.pdf (“Fiduciary Law in the Twenty-First Century”); pg. 1293.

[14] See, e.g., Robert H. Sitkoff, An Economic Theory of Fiduciary Law (July 18, 2014) Philosophical Foundations of Fiduciary Law, Andrew Gold & Paul Miller eds., Oxford University Press, 2014, Available at https://ssrn.com/abstract=2367006 (“An Economic Theory of Fiduciary Law”); pg. 199.

[15] Fiduciary Law in the Twenty-First Century; pg. 1293–4.

[16] An Economic Theory of Fiduciary Law; pg. 199.

[17] See, e.g., Tullock, G. (1967) “The Welfare Costs of Tariffs, Monopolies and Theft.” Western Economic Journal 5: 224–232.

[18] Fiduciary Law; pg. 808.

[19] Id.; pg. 811.

[20] An Economic Theory of Fiduciary Law; pg. 201.

[21] Id.

[22] According to Sitkoff, “[t]he duties of loyalty and care are standards that allow the court to decide whether, in view of all the circumstances, the fiduciary acted in accord with what the parties would have agreed if they had been able to anticipate those circumstances. In effect, the loyalty and care standards empower the court to complete the parties’ contract after the fact.” Id.; pg. 211.

[23] According to Sitkoff, “we also find specific subsidiary fiduciary duties, often phrased as rules, that elaborate on the application of loyalty and care to commonly recurring circumstances in the particular form of fiduciary relationship.” Id.; pg. 198.

[24] Id.; pg. 201.

[25] Id.; pg. 202.

[26] Frankel points out that “[w]hile a breach of contract entitles the harmed party mainly to damages, a breach of fiduciary relationship entitles the damaged entrustor to punitive damages, sometimes in the absence of any injury.” Fiduciary Law in the Twenty-First Century; pg. 1295.

[27] An Economic Theory of Fiduciary Law; pg. 200 (citing Wiener v Lazard Freres & Co 672 NYS2d 8, 14 (App Div 1998) (noting that fiduciary obligation may arise if “a party reposed confidence in another and reasonably relied on the other’s superior expertise or knowledge”); Restatement (Third) of Agency § 8.01 cmt c (noting imposition of fiduciary obligation “on the basis that one party to the relationship has in fact reposed trust and confidence in the other and has done so consistently with the other’s invitation.”))

[28] 957 F2d 1375 (7th Cir 1992) at 1381 (noting that the plaintiff had “reposed trust and confidence” in the defendant, who had held himself out “to be expert as well as trustworthy.” The defendant had gained “influence and superiority over” the plaintiff by virtue of his claimed “expert knowledge the deployment of which the [plaintiff could not] monitor.”)

[29] See Revlon, Inc. v. MacAndrews & Forbes Holdings, Inc., 506, A.2d 173 (Del. 1986) and its progeny.

[30] Owen v. Pringle, 621 So.2d 668, 671 (1993) (“Each lawyer owes each client a second duty, not wholly separable from the duty of care but sufficiently distinct that we afford it its own label, viz. the duty of loyalty, or, sometimes, fidelity. We speak here of the fiduciary nature of the lawyer’s duties to his client, of confidentiality and of candor and disclosure.”).

[31] “I will use treatment to help the sick according to my ability and judgment, but never with a view to injury and wrong-doing. Neither will I administer a poison to anybody when asked to do so, nor will I suggest such a course… Into whatsoever houses I enter, I will enter to help the sick, and I will abstain from all intentional wrong-doing and harm, especially from abusing the bodies of man or woman, bond or free. And whatsoever I shall see or hear in the course of my profession, as well as outside my profession in my intercourse with men, if it be what should not be published abroad, I will never divulge, holding such things to be holy secrets.” The Hippocratic Oath.

[32] See, e.g., Zeigler v. Illinois Trust & Savings Bank (1910), 245 Ill. 180; Witherell v. Weimer (1981) 421 NE2d 869; Fure v. Sherman Hospital (1978), 64 Ill. App.3d 259; Stafford v. Shultz (1954), 42 Cal. 2d 767, 270 P.2d 1; Bowman v. McPheeters (1947), 77 Cal. App. 2d 795, 176 P.2d 745; Adams v. Ison (Ky. 1952), 249 S.W.2d 791.

[33] For example, the code of the main clients of Bitcoin, Ethereum and Hyperledger, as well as portions of the clients of Enterprise Ethereum and Corda all consist of open source code. Further, according to Chris Dixon, “the cryptocurrency movement is the spiritual heir to previous open computing movements, including the open source software movement led most visibly by Linux, and the open information movement led most visibly by Wikipedia.” Chris Dixon, Crypto tokens: A breakthrough in open network design, June 1, 2017, available at: https://medium.com/@cdixon/crypto-tokens-a-breakthrough-in-open-network-design-e600975be2ef (“Crypto tokens: A breakthrough in open network design”).

[34] The Open Source Initiative manages a comprehensive definition of open source software that may be found at http://opensource.org/docs/osd.

[35] See Tirole, Jean and Lerner, Josh, The Simple Economics of Open Source (October 2000). HBS Finance Working Paper №00–059. Available at: https://ssrn.com/abstract=224008 (“The Simple Economics of Open Source”); pg. 1.

The archetypal example of open source software development is Linux, the first version of which was released by Linus Torvalds in 1991 and eventually grew to amass many thousands of contributions and went on to become the operating system of choice for many of the world’s leading tech companies today.

In recounting the early days of the internet, Tirole and Lerner further argue that “many of the key aspects of the computer operating systems and the Internet were developed in academic setting such as Berkeley and MIT during the 1960s and 1970s, as well as in central corporate research facilities where researches had a great deal of autonomy (such as Bell Labs and Xerox’s Palo Alto Research Center). In these years, the sharing by programmers in different organizations of basic operating code of computer programs — the source code — was commonplace.” The Simple Economics of Open Source; pg. 4.

[36] See Section III.c below for a further discussion of the governance structures of public blockchain networks.

[37] See, e.g., Joshua Krumholz, Ieuan G. Mahony & Brian J. Colandreo, Blockchain and intellectual property: A case study, in Blockchain & Cryptocurrency Regulation 2019, Global Legal Insights (“Blockchain and intellectual property”).

[38] GPL licenses are considered “viral licenses” because they require that any work that is derived from GPL-licensed code must also be licensed under GPL.

[39] As noted above in FN 8, software clients are the consensus building protocols that run blockchain networks. The Bitcoin Network is ran by nodes implementing 22 different software clients. The original software client and the most influential is Bitcoin Core. The relevance of the Bitcoin Core software client has been disputed by sponsors of other software clients. See, Competing with Bitcoin Core.

[40] Available at: https://opensource.org/licenses/MIT.

[41] Available at: https://www.gnu.org/licenses/gpl-3.0.en.html.

[42] Referred to as the “Byzantine General’s problem” in computer science.

[43] Satoshi Nakamoto, Bitcoin: A Peer-to-Peer Electronic Cash System, October 2008, available at: https://bitcoin.org/bitcoin.pdf.

[44] “Mechanism design is the sub-field of microeconomics and game theory that considers how to implement good system-wide solutions to problems that involve multiple self-interested agents, each with private information about their preferences.” http://www.eecs.harvard.edu/~parkes/pubs/ch2.pdf.

In other words, ““Mechanism design is the art of designing the rules of a game to achieve a specific desired outcome. While game theory takes the rules of a game as given and helps us determine outcomes based on them and the strategic interaction of players, mechanism design uses the framework of game theory with incomplete information and asks about the consequences of different rules and chooses the game structure rather than inheriting one.” Outlier Ventures, Token Ecosystem Creation, October, 2018, available at: https://outlierventures.io/research/why-crypto-assets-need-effective-token-ecosystems/ (“Token Ecosystem Creation”).

[45] While the run up in the “ICO” market in 2017 showed how tokens may also be used as part of malicious schemes such as pump-and-dump schemes and other frauds, the actions of bad actors should not be imputed on the technology itself. Blockchain represents a new paradigm of institutional design that is in its nascent stages, with experimentation happening across a wide spectrum of industries by a range of actors and, critically, in the context of inadequate regulations. The attraction of fraudsters to blockchain, similar to their attraction to previous technological developments like the internet, should not be surprising.

[46] Chris Dixon highlights how tokens are also effective tools to finance the launch of networks and enable network participants to overcome the ‘bootstrap problem’ by introducing a tradable asset with that “add financial utility when application utility is low.” Crypto tokens: A breakthrough in open network design.

This novel financing model raises interesting securities laws issues which are outside of the scope of this article.

[47] Economics of Blockchain; pg. 6.

[48] Yochai Benkler, Peer Production, the Commons, and the Future of the Firm, 15 Strategic Org. 264 (2017), available at: http://nrs.harvard.edu/urn-3:HUL.InstRepos:37078633.

[49] “{P]roponents of open source software state that the structure fosters the creation of vibrant — and valuable — developer communities, and leads to a common set of well tested, transparent, interoperable software modules upon which the developer community can standardize.” Blockchain and Intellectual Property.

[50] As we discussed in Section II.c above, these contributions are generally licensed by specialized permissive open source licenses.

[51] Economics of Blockchain; pg. 13.

[52] Jo Freeman, The Tyranny of the Structureless, 1970, available at: https://www.jofreeman.com/joreen/tyranny.htm.

[53] For example, several of the Bitcoin Core developers are employed by the company called Blockstream.

[54] SEC Director of Corporation Finance William Hinman acknowledged this potential in his description of the Ethereum network, leading him to conclude that current sales of Ether are not sales of securities. William Hinman, When Howey Met Gary (Plastics), June 14, 2018, available at: https://www.sec.gov/news/speech/speech-hinman-061418.

[55] Brafman and Beckstrom provide additional context describing catalysts arguing that “[i]n open organizations, a catalyst is the person who initiates a circle (a decentralized group with norms) and then fades away into the background… In letting go of the leadership role, the catalyst transfers ownership and responsibility to the circle… Once the catalyst leaves, however, his or her presence is still felt. The catalyst is an inspirational figure who spurs other to actions.” The Starfish and the Spider; pg. 92–93.

[56] The Simple Economics of Open Source; pg 21.

[57] One could argue that Vitalik Buterin, one of the co-founders of Ethereum, is a catalyst even though he remains perhaps the most influential developer in the Ethereum community. Not only has Vitalik contributed to making the Ethereum community more open and inclusive, but he has even recently stated that “its time for him to start fading into the background as a necessary part of the growth of the community.” Mike Orcutt, Ethereum founder Vitalik Buterin says his creation can’t succeed unless he takes a step back, November 1, 2018, available at: https://www.technologyreview.com/s/612372/ethereums-founder-vitalik-buterin-says-his-creation-cant-succeed-unless-he-takes-a-step/amp/.

[58] The archetypal example used to explain network effects is the invention of the telephone systems. At the point where there was one telephone in the world, the telephone network as a whole did not provide a very valuable service. However, each additional telephone that is connected to the network would add to the overall value.

[59] 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, © attract other programmers, and last but not least, (d) ‘keep the project together’ (prevent it from forking of being abandoned).” The Simple Economics of Open Source; pg. 21.

[60] As noted earlier in Section II.d above and discussed further in Section III.b.iii.2 below, this dynamic changes with Bitcoin’s introduction of tokens.

[61] Developers’ contributions to an open source project are sunk cost in the sense that, if the project is not successful, there is little the developer will be able to take away from their contributions that has immediate value.

[62] In addition to the Bitcoin Core software client, there are also 22 other software clients that can run on the Bitcoin network.

[63] https://github.com/bitcoin/bitcoin.

[64] The Simple Economics of Open Source; pg. 14.

[65] Tirole and Lerner argued that signaling incentives were relatively stronger (i) the more visible the performance to the relevant audience; (ii) the higher the impact of effort on performance, and (iii) the more informative the performance about talent. They noted how open source projects publicized the contributions of developers, increasing the signaling power of such efforts, by going through considerable efforts to make the nature of their decision-making process transparent (Id., pg. 24), and giving credit to the authors is essential in the open source context. Id., pg. 19.

[66] “Therefore, privacy in an open society requires anonymous transaction systems.” Eric Hughes, A Cypherpunk’s Manifesto, March 9, 1993, available at: https://www.activism.net/cypherpunk/manifesto.html

[67] Networks maintain a set of consensus rules that they require of all blocks for compatibility. When users disagree about the sets of consensus rules to enforce, it results in a chain split.

[68] “The Bitcoin Core software project cannot change what software users are running and the users are a lot more independent minded that many people think, in our view.” Competing with Bitcoin Core.

[69] “[Consensus] rules are defined by the clients economically significant users currently run.” Id.

[70] Hard Forks on the Bitcoin Blockchain: Reversible Exit, Continuing Voice; pg 2.

[71] “Blockchains are governed, and blockchain governance outcomes will be driven by the politics of participants in the public blockchain space.” Vlad Zamfir, Blockchain Governance 101, September 29, 2018, available at: https://medium.com/@Vlad_Zamfir/blockchain-governance-101-eea5201d7992 (“Blockchain Governance 101”)

[72] Vitalik Buterin, Notes on Blockchain Governance, December 17, 2017, available at: https://vitalik.ca/general/2017/12/17/voting.html (“Notes on Blockchain Governance”).

[73] Notes on Blockchain Governance. For example, BIP 9 was introduced to serve as a signaling mechanism for the Bitcoin protocol, enabling miners to indicate that they are prepared to implement a change by including information in the header of each block they mine.

[74] Vitalik provides a useful illustration describing coordination institutions “as putting up green or red flags in the air saying ‘go’ or ‘stop,’ with an established culture that everyone watches these flags and (usually) does what they say.” Notes on Blockchain Governance.

[75] “Most node operators don’t want to write much software, and it’s a technical challenge for anyone to independently write compatible implementations of any consensus protocol even if they have a specification. As a result, node operators rely on software repositories (usually hosted on Microsoft/Github servers) to provide them with the software they choose to run.” Blockchain Governance 101.

[76] “Bitcoin is free software and any developer can contribute to the project.” https://bitcoin.org/en/development#code-review.

[77] Available at: https://github.com/bitcoin/bitcoin.

[78] Amir Taaki submitted the first-ever BIP, BIP 1, in August 19, 2011, where he laid out the original BIP workflow. BIP 1 was subsequently replaced by BIP 2 submitted by Luke Dashjr in February 3, 2016. According to BIP 2 “A BIP is a design document providing information to the Bitcoin community, or describing a new feature for Bitcoin or its processes or environment. The BIP should provide a concise technical specification of the feature and a rationale for the feature.” BIP 1 is available at: https://github.com/bitcoin/bips/blob/master/bip-0001.mediawiki; and BIP 2 is available at: https://github.com/bitcoin/bips/blob/master/bip-0002.mediawiki.

[79] BIP 2 requires that all BIPs contain the following parts: (i) Preamble — Headers containing metadata about the BIP; (ii) Abstract — A short (~200 word) description of the technical issue being addressed; (iii) Copyright — The BIP must be explicitly licensed under acceptable FOSS license; (iv) Specification — Description of the syntax and semantics of any new features; (v) Motivation — Explanation of why the existing protocol is inadequate to address the problem that the BIP solves; (vi) Rationale — Description of what motivated the design; (vii) Backwards compatibility — Description of any backwards incompatibilities; and (viii) Reference implementation — Test code.

[80] bitcoin-dev@lists.linuxfoundation.org

[81] https://github.com/bitcoin/bips.

[82] The current BIP Editor is Luke Dashjr who can be contacted at luke_bipeditor@dashjr.org.

[83] See BIP 2 stating “The BIP editor will not unreasonably reject a BIP. Reasons for rejecting BIPs include duplication of effort, disregard for formatting rules, being too unfocused or too broad, being technically unsound, not providing proper motivation or addressing backwards compatibility, or not in keeping with the Bitcoin philosophy.” (emphasis added).

See also instructions in Bitcion Core’s GitHub page stating that “People wishing to submit BIPs, first should propose their idea or document to the bitcoin-dev@lists.linuxfoundation.org mailing list. After discussion, please open a PR. After copy-editing and acceptance, it will be published here. We are fairly liberal with approving BIPs, and try not to be too involved in decision making on behalf of the community. The exception is in very rare cases of dispute resolution when a decision is contentious and cannot be agreed upon. In those cases, the conservative option will always be preferred. Having a BIP here does not make it a formally accepted standard until its status becomes Final or Active.” Available at https://github.com/bitcoin/bips/ (emphasis added).

[84] Champions do not number the BIPs they propose when submitting them to the git repository, but instead give the BIP a descriptive name. The BIP Editor assigns each BIP a number based on a predetermined classification system based on the layer of the Bitcoin protocol which the BIP modifies, with lower-number layers involving more intricate interoperability requirements. See BIP 123, available at: https://github.com/bitcoin/bips/blob/master/bip-0123.mediawiki.

[85] There are three kinds of BIPs: (i) “Standard Track BIPs” which describe any change than affects most or all Bitcoin implementations, such as s change to the network protocol and are the type of BIP with which we are concerned in this paper; (ii) “Informational BIPs” which describe a Bitcoin design issue, or provide general guidelines or information to the community; and (iii) “Process BIPs” which describe a process surrounding Bitcoin, or proposes a change to a process. See BIP 2.

[86] Id.

[87] A “rough consensus” is reached when a proposed BIP has been “open to discussion on the development mailing list for at least one month, and no person maintains any unaddressed substantiated objections to it. Addressed or obstructive objections may be ignored / overruled by general agreement that they have been sufficiently addressed, but clear reasoning much be given in such circumstances.” Id.

[88] Id.

[89] See, e.g., Jimmy Song, Why the UASF Segwit Scenario is Hopelessly Naïve, April 18, 2017, available at: https://medium.com/@jimmysong/why-the-uasf-segwit-scenario-is-hopelessly-naive-70338711bc3c (arguing that “Short of a switch to proof-of-stake or something similar, there really isn’t a way for any sort of fork to be triggered by anyone but a miner”).

[90] Hard Forks on the Bitcoin Blockchain: Reversible Exit, Continuing Voice; pg. 6–7 (noting that MASFs have been used to successfully activate multiple soft forks in the past, including BIP 65 and BIP 112. However, it led to issues with BIP 66 when hashpower indicated most miners had upgraded when in fact they had not).

[91] Hard Forks on the Bitcoin Blockchain: Reversible Exit, Continuing Voice; pg. 3.

[92] See BIP 148 implementing SegWit and BIP 16 implementing Pay-to-Script-Hash.

[93] See, e.g., Jimmy Song, Bitcoin, UASF and Skin in the Game, May 29, 2017, available at: https://medium.com/@jimmysong/bitcoin-uasf-and-skin-in-the-game-7695031c5689 (arguing that “the hope is that by giving the USAF chain more value, they can create incentives for miners to mine more on their chain and eventually overtake the other chain in length”).

[94] Andrew Tar, UASF vs. UAHF, Explained, CoinTelegraph, July 19, 2017, available at: https://cointelegraph.com/explained/uasf-vs-uahf-explained.

[95] See Alphonse Pace, Chain Splits and Resolutions, March 7, 2017, available at https://medium.com/@alpalpalp/chain-splits-and-resolutions-d3398bddf4ab.

[96] “[A] portion of the community that questions the legitimacy of a governance decision can make a copy of the blockchain network (and corresponding software repositories) and maintain a “fork” of the blockchain outside of the governance of the original chain.” Blockchain Governance 101. For example, Nakamoto’s original code has now been forked over 21 thousand times. See, https://github.com/bitcoin/bitcoin.

[97] Alex Galea, Bitcoin development: who can change the core protocol?, March 30, 2018, available at https://medium.com/@galea/bitcoin-development-who-can-change-the-core-protocol-478b8ac5fe43.

[98] “Therefore, concerns about the Bitcoin Core software repository becoming deleted, hacked or hijacked should be far less of an issue than many people think. If this happens it will not affect clients users are already running and if further upgrades or improvements are needed, one can simply switch to a different repository or many different repositories, without worrying about any coordination problem or other risks.” Competing with Bitcoin Core.

[99] A recent study noted “that forked assets consistently underperform their parents [which] runs contrary to the commonly articulated belief that value can easily be forked as users readily switch between networks.” BlockChannel, A Brief Study of Cryptonetwork Forks, September 24, 2018, available at: https://medium.com/blockchannel/a-brief-study-of-cryptonetwork-forks-1377791d0354.

Vlad Zamfir described this as the “power law rule [which] means that even though it is very possible to fork, there will only ever be a small number of forks that are ultimately successful enough to be considered a ‘major blockchain.’ As a result, the blockchain governance regimes of a small number of major blockchains will determine governance outcomes for the entire blockchain space.” Blockchain Governance 101.

[100] See Ciaran Murray, Are Public Blockchain Systems Money Services Business In Disguise, October 12, 2017, available at: http://rulesofthegame.blog/2017/10/12/are-public-blockchain-systems-money-services-businesses-in-disguise/ and also Blockchain Governance 101.

[101] Walch dismisses the significance of hard forks by analogizing them to the ability of a public shareholder to exit their investment by selling her shares, arguing that this ability to “exit” does not negate the fiduciary duties owed to the holder by public company directors. In Code(rs) we trust: Software developers as fiduciaries in public blockchains; pg. 12 (“Much is made of token-holders ‘right to exit’ via the forking process or selling the token, but the ability to exit should not be relevant to the fiduciary analysis; shareholders of publicly-registered stock can always exit by selling the stock, yet are still owed fiduciary duties by officers and directors of the company.”)

As we argue in Section III.d.i.2 the analogy of token holders to shareholders does not hold up given that public company directors are — critically — able to bind shareholders, while protocol developers cannot bind token holders.

[102] As stated by Sitkoff, “[a]gency problems are the defining hallmark of categorical fiduciary relationships, such as those between the trustee and the beneficiary, guardian and ward, principal and agent (in law), director and corporation, and lawyer and client.” An Economic Theory of Fiduciary Law; pg. 200.

[103] Patricia Burdett vs. Robert S Miller 957 F.2d 1375 (1992).

[104] Black’s Law Dictionary defines “Agency” as “A relation, created either by express or implied contract or by law, whereby one party (called the principal or constituent) delegates the transaction of some lawful business or the authority to do certain acts for him or in relation to his rights or property, with more or less discretionary power, to another person (called the agent, attorney, proxy, or delegate) who undertakes to manage the affair and render him an account thereof.” Black’s Law Dictionary, available at: https://thelawdictionary.org/agency/

[105] Deborah A. DeMott, Defining Agency and its Costs, Comparative Contract Law: A Tale of Two Legal Systems (Martin Hogg & Larry A. DiMatteo eds., Oxford Univ. Press 2015), available at: https://scholarship.law.duke.edu/cgi/viewcontent.cgi?article=6101&context=faculty_scholarship.

[106] Frankel highlights the need for the “fiduciary” to accept their position and responsibilities by noting that “[t]he fiduciary is free to enter or refrain from entering the relation, and cannot be forced to serve without his consent,” and arguing further that “[a] person may agree or refuse to serve as a fiduciary out of purely selfish reasons. On this point, fiduciary law is as individualistic as contract.” Fiduciary Law; pg. 820; 830.

[107] According to Walch, “[p]rominent developers also shape how the public blockchains are viewed by regulators and the public at large, as certain developers have met privately with various international regulators or leaders and often comment publicly on what should happen with the particular blockchain they represent and the technology as a whole.” Walch support her position by noting that Gavin Andresen met with the Central Intelligence Agency in the US when he served as the lead developer of Bitcoin in 2011, and Vitalik Buterin met with Russian president Vladimir Putin in 2017. In Code(rs) we trust: Software developers as fiduciaries in public blockchains; pg. 6.

[108] For example, Wladimir J. van der Laan, Pieter Wuille, Gavin Andreesen and Luke Dashjr are acknowledged to be influential members of Bitcoin Core.

[109] In the Ethereum community, Vitalik Buterin stands out as a catalyst protocol developer, along with key contributing protocol developers such as Vlad Zamfir.

[110] One may even argue that when a patient undergoes surgery, she cedes power over her body to a doctor, a requirement for the latter to be able to operate.

[111] Fiduciaries are not entitled by common law to compensation. See, e.g., Uniform Partnership Act §18(f) (absent an agreement, partner not entitled to compensation for acting on partnership business); Restatement of Agency §378 (Agent has no right to compensation absent an agreement). However, given their expertise, in practice they are able to command significant compensation.

[112] To the extent that a certain developer is employed by a company or other business or entity, she may owe certain obligations towards that particular agent which are outside of the scope of this paper, which focuses on claims that protocol developers are fiduciaries in relation to other blockchain network participants and potentially the public at large.

[113] Fiduciary Law; pg. 811.

[114] A fundamental principle in corporate law known as the business judgment rule, allows public company director with the discretion to take certain actions without soliciting input from their shareholders. This is done in the belief that the directors are in the best position to make the decisions for the company.

[115] Hard Forks on the Bitcoin Blockchain: Reversible Exit, Continuing Voice; pg: 5.

[116] The list of all contributors to the Bitcoin Core software client is accessible here: https://bitcoin.org/en/development#bitcoin-core-contributors.

[117] Frankel argues that “[w]hen the fiduciary’s interests coincide with those of the entrustor, the entrustor is partially protected because as the fiduciary acts in his own interest he will automatically act in the interest of the entrustor.” Fiduciary Law; pg. 811.

[118] For example, in September 2018, a new bug was discovered in the Bitcoin Core software client 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, September 27, 2018, available at: https://hackernoon.com/bitcoin-core-bug-cve-2018-17144-an-analysis-f80d9d373362.

[119] Academics studying open source production systems have commented on the efficiencies of the “parallel debugging” enabled when code is freely accessible to the public.

[120] Walch references variations of the term “developers,” including “core developers,” (e.g., pg. 6) “prominent developers” (pg. 6), “software developers” (pg. 7 in context of BTC fork), “key developers” (pg. 7 in context of BTC fork), “Ethereum developers” (pg. 8 in context of ETH fork), “dominant developers” (pg. 8 in context of ETH fork), “small number of developers” (pg. 8 in context of ETH fork) and “certain developers.” In Code(rs) we trust: Software developers as fiduciaries in public blockchains.

[121] Walch defines “developers” as “those making decisions about the policy choices to be embedded in the code, how to best technically manifest those choices, and then actually crafting and reviewing the code to achieve those policy and technical choices,” noting that [w]ithin this group of contributors, importantly, not all participants are equal. For instance, in open-source software projects like public blockchains, a team of “core developers” or “maintainers” generally leads the software development process. This means that although this group of people may not be united under the roof of an entity structure, they function as leaders and decision-makers for the code.” Id. pg. 5.

However, we have seen how no developer has the power to make decision about the consensus rules and development of a network, but rather how those decisions are made by the formal network participants and economic majority.

[122] SEC v. Chenery Corp., 318 US 80, 85–86 (1943)

[123] In Code(rs) we trust: Software developers as fiduciaries in public blockchains; pg. 19.

[124] Id.; pg. 20 (emphasis added).

[125] Id.; pg. 9.

[126] For example, the Bitcoin Core developers should consider clarifying who in particular has commit access to the Bitcoin Core repository.

[127] For example, CFTC Commissioner Quintenz argued that while neither public blockchain developers contributing protocol-level changes, nor miners, nor users should be generally held responsible for unlawful activity on potentially occurring on public blockchain networks, developers working on specific smart contracts (“Smart Contract Developers”) may be held legally responsible if they can “reasonably foresee” that their smart contracts will be used illegally. See Quintenz Speech.

Recent enforcement actions against smart contract developers include the cease and desist settlement announced by the SEC on November 8, 2018 against the operator on a digital asset exchange on the basis of operating an unregistered securities exchange, available at: https://www.sec.gov/news/press-release/2018-258. In addition, an Arkansas court recently sentenced a software developer to 33 months in prison for aiding and abetting computer intrusions by selling malware, to individuals who used the malware to steal sensitive information. Available at: https://www.justice.gov/opa/pr/arkansas-man-sentenced-prison-developing-and-distributing-prolific-malware

[128] Sinclair Davidson, Primavera De Filippi, Jason Potts, Disrupting governance: The new institutional economics of distributed ledger technology, available at http://ssrn.com/abstract=2811995, pg. 3.

[129] Blockchain Governance 101.