Blockchain Development and Fiduciary Duty
In 2018, Bitcoin’s value dropped a walloping 70%.1 The number of crypto-related litigation proceedings tripled by the end of the year,2 leading to the birth of crypto litigation as a practice area. An alphabet soup of federal agencies—IRS, SEC, CFTC, CFPB, FinCen, CFPB, and FTC—created groups to research and investigate blockchain3 and cryptoasset-based ventures (“cryptoventures”).4 Charges of fraud and criminality resulted from the spate of state and federal government investigations launched since 2017.5
By enabling new modes of human interaction, technological advancements catalyze the evolution of existing regulatory frameworks and spur the reassessment of regulatory tools and approaches. The rapidity at which computer technology evolves outpaces the rate at which much legislation, rulemaking, and law can be codified. Our economy is increasingly structured not only by traditional fiduciary actors, but also by software systems.6 Through software systems, assets are able to permeate markets rapidly and at a greater scale.7 Rightfully, scholars and regulatory officials reexamine liability frameworks for software developers.8 The advent of blockchain technologies dramatically demonstrates the challenge of scrutinizing an interconnected software system. Blockchain technologies emerged extra-institutionally.9 These technologies enable a wide array of never-before possible peer-to-peer interactions. Blockchain-based transactions bypass regulatory control.10
We have explored the governance role of blockchain developers for the two most prominent11 public12 blockchain communities and networks. With respect to the incentives and operations of prominent public blockchains, the role played by core developers in the governance of these networks does not exhibit the structural dynamics that warrant the imposition of fiduciary obligations for the benefit of cryptoasset holders. These developers are structurally unable to make decisions to foist changes upon the participants of a network.
The evolution of software systems outpaces the rate at which legal scholarship can timely examine the operational dynamics of software development. Such dynamics should be integral to an analysis of the appropriate liability framework for software developers.13 Blockchain technologies use state-of-the-art encryption technology for automated validation of transaction data.14 Many blockchain networks that are open to the public use a gamified incentive scheme to further validate the history of transactions and maintain conformity in the data recorded across the distributed ledgers.15 Despite its uncanny birth,16 or maybe even because of it, blockchain technology has been adopted world-wide.17
Many of the traditional gatekeepers of certain highly regulated activities, such as early stage venture financing and cross-border money transmission, have called for regulation and scrutiny of blockchain ecosystems.18 Financial and prudential regulators are called on to perform a tough balancing act. To begin with, they must sift through the explosion of information and misinformation on the Internet to gain baseline knowledge about the technology. They must then, on the one hand, remain vigilant and guard against potential fraud, consumer harm, and systemic risk. On the other hand, 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.
Determining where this innovative technology fits into legal frameworks is more than a hypothetical exercise for courts, regulators, and legislatures. Since the Bitcoin network launched in 2009, there have been a variety of cases that have grappled with the advent of blockchain technologies enabling disintermediated transactions that are pseudonymous and cross-jurisdictional.19
Cryptocurrency’s use as a tool for money laundering schemes is one such regulatory concern. As an example, US v. Ulbricht concerned the arrest and eventual conviction of Ross Ulbricht for, among other things, maintaining an auction website where individuals could purchase illegal items with bitcoin.20 Ulbricht was charged with money laundering in connection with the sales of items on his website “The Silk Road.”21 His counsel argued that he could not be charged with money laundering because transactions in bitcoin were not financial transactions as defined by 18 U.S.C. § 1956.22
Whether or not cryptocurrency is within the purview of money transmitter laws is an issue for every state. For example, US v. Faiella examined whether facilitating bitcoin transactions on behalf of customers constituted operating a money service business necessitating a money transmission license.23 Defendants Robert Faiella and Charlie Shrem were charged with operating an unlicensed money transmission business.24 The defendants argued that they were improperly charged, because bitcoin did not qualify as money under 18 U.S.C. § 1960.25
Even well-settled securities laws have been reexamined due to the advent of blockchain technologies and the cryptographic tokens they enable. In 2017, the Securities and Exchange Commission issued what is colloquially known as “The DAO Report.”26 In the report, the SEC discussed the results of their investigation into “whether The DAO, an unincorporated organization; Slock.it UG (“Slock.it”), a German corporation; Slock.it’s co-founders; and intermediaries may have violated the federal securities laws” by issuing cryptographic tokens.27 As explained in the report, the DAO “is one example of a Decentralized Autonomous Organization, which is a term used to describe a ‘virtual’ organization embodied in computer code and executed on a distributed ledger or blockchain.”28 The DAO sold tokens, “TheDAO tokens,” to investors who would then vote on projects to allocate funds to.29 As such, in The DAO Report the SEC analyzed whether this initial coin offering, or “ICO,” of TheDAO tokens constituted an illegal securities offering.30
One ICO offering typical of the wild west nature of this technology space included two high-profile celebrity endorsements from a rapper and a boxer, respectively.31 In SEC v. Sharma, the SEC charged the two cofounders of a company, CentraTech, Inc., that claimed to offer a “crypto debit card,” and touted non-existent relationships with Visa and MasterCard, with securities fraud.32
In addition to the attention from regulators, state legislatures issue legislation dictating the treatment of public blockchain networks.33 For example, on September 28, 2018, the California State Assembly approved an update to their laws to include a definition of “blockchain,” as “a mathematically secured, chronological, and decentralized ledger or database”; whereas, the State of Vermont defines blockchain as “a cryptographically secured, chronological, and decentralized consensus ledger or consensus database maintained via Internet, peer-to-peer network, or other interaction.”34 In 2018 alone, there were thirty-six different blockchain-related pieces of legislation introduced in state legislatures around the country.35 These competing, and sometimes conflicting, approaches to this new technology speak to the interest in these platforms, and the need for clarity on how these new platforms should be treated by the law.
It may be tempting, when facing a wildfire of developments resulting from this emerging technology, to advocate for a fiduciary obligation on all blockchain developers. Subsequent to a major exploitation of the token-transferring code used by The DAO, which split the prominent Ethereum blockchain community into two and resulted in token value volatility, some scholarship36 promoted views one scholar summarized by the title of her article—“Call Blockchain Developers What they Are: Fiduciaries.”37 In the Twitter universe, there was a related attempt to create a hashtag movement: #codersasfiduciaries.38 The thrust of the argument presented is that public blockchain developers have open-ended control of cryptoassets that belong to others.39
These calls for the imposition of the fiduciary standard to be applied to “coders”40 lack discernment of the many distinct operational roles and structural incentives of public blockchain developers. There is a long-held doctrine that careful deliberation is needed before a finding of fiduciary duty41—we agree. It is critical that regulators apply a legal framework that reflects the way an economy works, and the economic incentives42 and structural roles of the agents involved.43 Scholars 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.44
This article addresses the forgoing issue in four parts. In Part I, we discuss the operations of open source, decentralized development to better understand these developers’ functions and how cryptocurrencies are used to build blockchain networks. In Part II, we discuss the different developers involved in creating blockchain and blockchain-based systems and the governance structure under which they operate. We examine moments of crisis in blockchain communities that illustrate this governance in Part III. In Part IV, we emphasize the distinction between blockchain protocol developers and directors and officers of a corporation. We conclude our analysis by briefly exposing the effects of imputing fiduciary obligations on protocol developers.
I. The General Operations and Incentives of Open Source Production
To understand blockchain development operations, an understanding of open source production is critical.
a. Blockchain traces its roots to open source software development
Bitcoin and the public blockchain networks that followed from it have several innovative features, but their process of development, the method through which they came into being and are evolving, traces its roots to the open source production system that grew out of the early days of the Internet and the free software movement.45 The term “open source”46 refers to software that is freely distributed in source code47 form and evolves through a process that “involves software developers at many different locations and organizations sharing code to develop and refine software applications.”48 In contrast, “proprietary” code refers to code that is distributed in object code49 form only and where the source code is protected as a trade secret.
As we shall explore more in depth in Section II (c), anyone is free to suggest a change to the code of an open source software application,50 but only those developers with “commit access”51 to the code repository have the power to incorporate a change into the code repository. Commit access does not enable the protocol developers who wield it the power to force code changes on other network participants; network participants must act to download code changes.52
b. Production through voluntary contributions of independent actors
A main principle of open source production is that development work is undertaken by independent volunteers who decide on their own account to collaborate with others in an iterative fashion.53 As compared to software development in a traditional technology firm, which is undertaken by employees who are instructed by managers to work on specific parts of a project, developers contributing to open source production systems work on projects that interest them if and when they want to contribute.54 While 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 power parity that characterizes software development firms.55
c. Open access to code and ability to “fork”
In an open source production system, anyone can suggest a code change to the community. Anyone is also allowed to modify the existing code and try to build her own community to support a revised version of the code (a concept generally referred to as “forking,” which is discussed in more detail in Section II (c) below).
To accomplish the goal of being free and public available, open source projects publish their source code in online repositories and license it under a spectrum of free and open source (“FOSS”) licenses.56 These licenses recognize open collaboration as the driver of production and require the commitment to making any iteration of the code freely available to the public for future use or modification.57
d. Building cryptoeconomic institutions with cryptocurrencies
The Bitcoin project allowed for the newfound ability to transfer value over a peer-to-peer network and validate such transfers using a gamified incentive scheme that uses bitcoin, a cryptocurrency.58 Bitcoin’s most significant contribution to open source development may stem from the Bitcoin network’s ability to solve the “double spend problem,”59 which had hampered all previous attempts to launch a peer-to-peer virtual currency system.60 Satoshi’s solution was to design an architecturally and politically decentralized payment transfer system that relies on a gamified verification scheme to be tamper-evident.61 By running the appropriate hardware and software and connecting to the Internet, anyone can participate in this system to transact with anyone else.62 Furthermore, anyone can use her computer to participate in the system’s protocol for validating the record of transfer.63 This protocol is known as a Proof-of-Work (“PoW”) consensus mechanism, and participants in it are known as “miners.”64
It is the PoW consensus mechanism that gamifies participation in the validation scheme.65 Miners who are successful at proposing a batch of validated transactions that other network participants accept as valid are awarded in bitcoin.66 This is the only way in which bitcoin can be generated.67 The protocol for mining purposefully includes an energy-expensive routine; this routine deters malicious miners from tampering with the blockchain’s history, making it computationally expensive to do so.68 A miner has to pay (in energy) to play, so to speak.
The result is the ability of a network of computers, known as nodes, to support bitcoin transfers.69 These nodes can be owned and operated by any entity, thus the network is decentralized.70 Because of the protocol that runs the software applications on these nodes and governs the gamified validation scheme, Bitcoin is unable to be copied and is limited in number.71 Each of these nodes has a localized copy of the Bitcoin blockchain.72
The Bitcoin network’s introduction of bitcoin, or a blockchain network’s native cryptocurrency73 generally, provides a new “mechanism design” 74 tool to develop more complex incentive systems on top of open source networks. Using cryptocurrency, networks can now be designed in a way that economically incentivizes participants with different preferences and information to act collaboratively to maintain the value of the network.75 Native cryptocurrencies work as an incentive for network participants by motivating holders to grow the network and drive demand for the cryptocurrency, therefore leading to an appreciation in the cryptocurrency’s market price.76 Ownership of cryptocurrency is the economic incentive that keeps developers, miners, and other network participants to work to maintain the integrity of a blockchain network that uses the PoW consensus mechanism.77
In this sense, cryptocurrencies enable the transformational aspect of public blockchain networks—the ability to create and execute rule-systems that result in new organizational and institutional forms of economic governance and “enable bespoke socio-economic coordination.”78 The stability of public blockchain networks, a subspecies of distributed ledger systems, is a result of gamification.79 “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.”80
II. Blockchain Governance and Protocol Development
In the first section we uncovered some of the underlying dynamics present in open source production and public blockchain development. This section examines the influence protocol developers have on changes to public blockchain software applications. We do this by: (a) recognizing that public blockchain networks, like any organization, necessarily develop governance structures; (b) clarifying whom “protocol developers” refers to and analyzing the general role and motivation of the different types of protocol developers; and (c) providing an overview of how changes to the Bitcoin Core and Ethereum software applications are implemented in practice.
a. “Decentralized” does not mean “structureless”
When we refer to open source production and public blockchain networks, and in particular their governance, we do not assume that by virtue of being “decentralized”81 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.”82 Therefore, a study of dynamics necessitates the differentiation of participants in a network.
b. The function and incentives of protocol developers in public blockchain networks
i. Defining “protocol developer”
In the context of open source software production, the term “developer” may generally refer to various unrelated individuals who play fundamentally different roles over time.83 When talking about public blockchain networks, it is first important to distinguish between developers contributing to the software application supporting the network (whom we have been referring to as “protocol developers”) from the developers building decentralized applications by coding and deploying program specific code known as “smart contracts”84 onto public blockchain networks (whom we shall refer to as “smart contract developers”).
Our use of the term “protocol developer” is admittedly a loose one, given that it refers to individuals playing a range of roles, all of whom contribute in some fashion to maintaining a software application. One role is the “catalyst” developer, who provides the impetus for the launch of a decentralized open source project,85 and as we shall see, subsequently recedes from the networks’ governance.86 Another role is played by the developers who voluntarily contribute their efforts collaboratively and iteratively to an existing open source project.87 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,” such access allowing them to incorporate changes into the public repository.88 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.89
ii. Catalyst developers and network effects
While public blockchain networks can exhibit decentralizing tendencies90 over time,91 out of necessity they begin with a sponsor, which 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 circumstance, takes it upon herself to address the issue, and invites others to help along the way.
Agents responsible for beginning decentralized organizations (including open source projects such as Linux, Apache, Wikipedia, Craigslist, and even Alcoholics Anonymous) are referred to as “catalysts.”92 Catalysts 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, eventually ceding control.93
The role of a catalyst developers is evident when looking at the Bitcoin and Ethereum networks. With the backdrop of the world financial crisis, “Satoshi Nakamoto” famously published the Bitcoin whitepaper in October 31, 2008 and soon after coded the very first Bitcoin software application,94 releasing it in January 2009. She/he/they95 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. 96
Catalyst developers create the anchor point for network effects.97 Decentralized open source projects and public blockchain networks, such as the Bitcoin and Ethereum networks, 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.98 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. 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.99
iii. The incentives of developers contributing to open source projects
Analyzing the issue from a different point of view, one may ask: what motivates skilled protocol developers to contribute to an existing open source project? Developers are generally highly technical workers who have the potential to be lucratively compensated for their work by modern technology firms.100 Yet, by contributing to open source projects such as the Bitcoin or Ethereum project, developers are generally not directly remunerated and unlikely to get anything of direct value101 from their contributions unless the project ends up a success.102
Nonetheless, developers contribute to open source projects in droves. Bitcoin was launched in 2009, and a decentralized group of developers has maintained the “Bitcoin Core” software application,103 which as of February 2019 had over 18,000 revisions (or “commits”) implemented by over 570 individual contributors.104 The Go-Ethereum software application has over 10,500 implemented by almost 400 contributors.105 Let us examine this phenomenon.
1. Social and psychological incentives
The academic literature finds that contributors to the earliest open source software projects were motivated by the medium- to long-term social and psychological impact of their work, as opposed to motivation through short-term economic payoff.106 Studies that focus on the open source economies that evolved with the invention of the Internet 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.107 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.108
In addition, contributors to open source projects are often animated by an ideology which influences their decision-making over design and architectural choices. For example, the open source software movement was closely associated with the free and open source software (“FOSS”) ideology.109 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.110
2. Economic incentives through native cryptocurrencies
While the developers contributing to the earliest open source software projects were mostly motivated by social and psychological factors,111 the Bitcoin project inaugurated a new paradigm of open source production by introducing cryptocurrencies and gamification into open source economies. As noted in Section I (d), native cryptocurrencies 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 cryptocurrencies by means of a pre-mined allocation. Contributing developers can also now be directly remunerated for their contributions with the native cryptocurrency. By owning the native cryptocurrency, these developers will be directly economically incentivized to attract more users to the network and drive demand for the native cryptocurrency, thereby leading to the appreciation of cryptocurrency’s value. Taken together with the long-term social and psychological drivers, including reputational gains and ideological motives, native cryptocurrency can be used to align the incentives of developers with other network participants towards a common goal.
c. How changes to software applications are made and the role of developers in implementing those changes in the network
This section seeks to describe the process through which changes to a software application of a public blockchain network are made. More importantly, it examines the role of protocol developers in the process of updating a software application and implementing it on the network.
i. Changes to a public blockchain’s software application come from the political consensus of network participants
Public blockchain networks do not function in reliance on one single “code base,” but rather can support a range of software applications so long as they all conform to the consensus rules112 of the network.113 In this sense, while Bitcoin Core is the original and most important software application 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.114 Similarly, Go-Ethereum is a popular software application for interacting with the Ethereum network,115 but it is not the only one. As we argue, the consensus rules and development direction of public blockchain networks are defined by the choices made by the economically significant116 network participants as to which software application to run.117
Public blockchain networks vary significantly in their architecture and design. Using the Bitcoin and Ethereum protocols as examples, the direct participants of the network (the “formal participants”) are (1) the network users (e.g., cryptocurrency holders) and (2) the network nodes (both miners and other nodes that run the software application). There are multiple other interested parties with influence over public blockchain governance (the “indirect participants”), including (3) developers (both protocol developers and others such as smart contract developers) and also (4) businesses that service the blockchain network and provide the related infrastructure (including equipment manufacturers and exchanges).118 In addition to the formal and indirect participants outlined above, public blockchain networks develop large communities composed of a diverse ecosystem. These ecosystems include many additional participants, including unaffiliated individuals willing to trade valuable services or assets for the native cryptocurrencies of the blockchain network or cryptographic tokens resulting from smart contracts that run on the network.
ii. A multi-level coordination model of public blockchain governance
Changes to a public blockchain network that affect the fundamental consensus rules of the protocol are rare, and when they do happen they occur as the result of informal coordination between the various participants through a complex multi-level political process.119
Vitalik Buterin, the catalyst for the Ethereum Network, provides a helpful framework for understanding public blockchain network governance and the role of developers in it. He describes blockchain network governance using a multi-layered “coordination model.”120 At a fundamental—“Layer 1”—level, every formal participant has the ability to “run whatever software [application] they want in their capacity as a user, miner, participant, validator or whatever other kind of agent a blockchain protocol allows them to be.”121 As mentioned before, the bottom layer provides formal network participants with ultimate decision-making authority regarding what software application to run or whether to update the software application with new versions that exist. 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 network participants’ likely choices. The informal participants coordinate the formal participants’ decision making. The native cryptocurrency of the network aligns the incentives of the network participants; participants all have a stake in maintaining or increasing the value of the native cryptocurrency.
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.”122 These coordinating institutions use their structural ability to signal preferences and steer the formal participants of a network towards collective decision-making.123
In this context, protocol developers play a dual role in that they both (1) provide the “choices” for every formal participant to act on by maintaining and revising versions of a software application,124 and (2) play the role of a coordinating institution in advocating for a change. Critically, protocol developers lack the ability to force software changes and updates on other network participants.
There are thus recursive value dependencies that bind the network participants: the value of the cryptocurrency is dependent upon the volume of transactions that use it, the volume of transactions is dependent upon the stability and reputation of the network, the stability of the network is dependent upon the miners that participate in the validation scheme, the validation schemes are provided by the protocol developers, the protocol developers are incentivized by the value of the native cryptocurrency they may hold (and the social and psychological factors discussed above), the miners are incentivized by the value of the cryptocurrency they may gain by participating in the validation scheme. Thus, native cryptocurrency is an integral driver in the PoW mechanism design.125
iii. Lifecycle of a Bitcoin software application update
Updates to a public blockchain’s software application (including Bitcoin Core) can be proposed by anyone.126 In the case of Bitcoin Core, small code enhancements or patches (which neither require standardization between projects nor relation to the network’s consensus rules) can be suggested by opening an “issue” or responding to one of the open “pull requests” on the GitHub page, available publicly at https://github.com/bitcoin/bitcoin.127
Major changes to the Bitcoin Core software application are suggested through Bitcoin Improvement Proposals (“BIPs”).128 Each BIP is proposed by an individual—referred to as a “champion”—who drafts the proposal in the required style and format129 and initiates discussions on Internet forums. Most importantly, once the BIP has been drafted, the champion must leverage her prestige and persuade others to support her idea.130
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.131 This public draft of the BIP is 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 is properly formatted, it may be submitted to the publicly available Bitcoin GitHub repository as a “pull request,” which is analogous to a request for change.132 At this point, an editor (the “BIP Editor”)133 will decide whether to accept 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 because all GitHub pull requests are publicly available online.134 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.135 Moreover, a developer who has her BIP censored by the Bitcoin Core BIP Editor may implement her desired change by “soft forking” the Bitcoin Core code and launching her own software application on the Bitcoin network or resorting to a “hard fork” that splits the network. “Forking” is described in Section II (c) below.
Once a BIP has been accepted and merged into the Bitcoin Core repository, the BIP Editor will assign the BIP a number,136 label it according to its formal type,137 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 implemented138:
A champion can change the status of a BIP from Draft → Withdrawn or Deferred. However, a BIP’s path from Draft → Proposed → Active (but not yet Final or implemented on the Bitcoin network) requires buy-in from the Bitcoin Core developer “technocracy.” This entails the BIP achieving a “rough consensus”139 amongst active developers on the mailing list.140
For a BIP to get from Draft status to Final status (meaning implemented on the Bitcoin network) it must be adopted by the formal participants of the Bitcoin network, which we have seen play a separate role from that of the protocol developers. This is a key point. Protocol developers do not formally “touch” the blockchain; they can only propose changes to a certain software application. Implementation of any changes to a public blockchain network, such as a BIP, requires the consensus of the formal participants, which are influenced by the indirect participants in a multi-layered coordination-model.
There are two paths that a BIP can take to go from Final → Final status and be implemented on the Bitcoin network.
1. Soft forks
Certain BIPs propose a “tightening” of the consensus rules of the Bitcoin protocol (i.e., the ruleset is narrowed, disallowing new blocks that previously would have been valid) and thus require only a “soft fork” to be implemented. These types of modifications are said to be “backwards compatible” because full nodes (other than miners) are not required to upgrade to the implementing software application to maintain consensus in the network (given that full nodes running the old, non-implementing software application will still be able to accept new blocks generated by the miners running the new implementing software application). As such, implementing a soft fork BIP requires only adoption of the miners, usually through a supermajority “vote” of 95% of active hashpower.141
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.”142
Miners truly “vote” on whether to implement a BIP by choosing whether to apply their computational power to mine on the network that implements the software application. Given the positive network effects of public blockchain networks, when deciding whether to mine to validate the implementing or non-implementing software application, miners must anticipate which version of the software application the broader community will coalesce around. Scholars have therefore argued that “[a] miner’s ‘vote’ is better understood as its prediction of the collective stance of the broader miner community than as an expression of the voting miner’s individual preference.”143
The “economic majority,” a term referring to a combination of network users and other indirect participants such as wallets and exchanges, exerts indirect influence over the adoption of soft forks. Mining is a for-profit industry in which profits are determined in large part by the cost of computational power to mine in relation to the value of the cryptocurrency being mined. Therefore, a key factor in a miner’s decision framework (i.e., which version of the software application to run and which history to adopt) is the effect that a certain proposed code change will have on the value of the cryptocurrency. The value of the cryptocurrency is in turn determined by those willing to offer things of value in exchange for the underlying cryptocurrency (be it goods, services, fiat currencies, or other cryptoassets). Therefore, while soft forks can be normatively implemented without direct user participation, given the profit-motive of miners, the economic majority’s preferences are ultimately reflected in a miners’ decision-making framework.
As an example, the economic majority can employ coordination procedures, such as a User Activated Soft Fork (a “UASF”), to exert leverage over the miners in the context of a potential soft fork.144 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 application and reject blocks produced by miners running the old non-implementing software application. In connection with BIP 148, the contentious SegWit update which was the centerpiece of Bitcoin Core’s project to enable increase the volume of transactions batched, 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 application. While miners are still required to implement a “User Activated” Soft Fork, the mechanism works as a signaling strategy to influence miners’ decisions to implement a BIP out of fear of losing the block rewards by building on a minority chain.145
2. Hard forks
Network participants can also exert influence over a public blockchain’s governance through “hard forks.” As opposed to soft forks, hard forks implement code changes that “loosen” the consensus rules of a blockchain’s protocol (i.e., the ruleset becomes broader, allowing for previously disallowed blocks to be treated as valid). Hard forks are therefore not backwards compatible, in the sense that full nodes which do not upgrade to the new implementing software application (or simply implement a software application with different consensus rules and create a new chain) will not accept blocks created by miners running the upgraded software application. While soft forks can be implemented by miners only, the implementation of hard forks requires every formal participant to choose to upgrade to the new implementing software application. Hard forks therefore represent a “permanent divergence from the previous version of the Blockchain.”146
Critically, a “hard fork” serves as the ever-present escape valve accessible to any network user or informal participant who finds available software applications disagreeable.147 It effectively allows any individual to copy the current publicly-available source code of a certain public blockchain’s software application, modify it to reflect a new ruleset, re-release it to the public and coalesce a community around the revised protocol.148 In this way, hard forks ensure “the community as a whole can never be forced to adopt undesirable changes to Bitcoin.”149 For example, should a bad actor or group take the Bitcoin Core software application in a poor direction, the broader community would have the ability to reverse the undesired change or make new modifications and launch a new project.150
While copying a publicly available software application might seem simple in theory, hard forks have limitations and are costly in practice.151 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 get to use the pre-fork trademark.152 However costly in terms of compromising network effects, hard forks provide an “exit” option to formal participants of a public blockchain that ensures they will not have “crammed down” a version of the code they do not support.
Hard forks thus provide a viable avenue to minimize risks of undue influence on the code by third parties.153 Formal participants are able to “vote with their feet.”154
d. Lifecycle of an Ethereum Update
Similar to Bitcoin, the Ethereum community employs an improvement process. That process involves the creation of an Ethereum Improvement Proposal (“EIP”) that is a “design document providing information to the Ethereum community, describing a proposed new feature or its processes or environment.”155 More specifically, as detailed on the Ethereum GitHub website, EIPs “describe standards for the Ethereum platform, including core protocol specifications, client APIs, and contract standards.”156 As with Bitcoin, anyone can submit EIPs that may or may not be accepted by the community.157
There is an inherent distinction between Ethereum and Bitcoin that should be understood; this distinction informs the identification of different types of blockchain developers.158 Bitcoin’s protocol supports few payment-transfer functions; its protocol would have to change to support more complex functionality that is associated with general computing.159 The Ethereum blockchain supports the development of general computing programs (called smart contracts, as discussed previously) by anyone,160 and the creation and accessibility of such programs do not require an EIP; any smart contract developer can create such accessible programs on the Ethereum blockchain without any action or oversight by a protocol developer.161 In this way, Ethereum can be thought of as a platform that enables programming projects orchestrated by organizations other than the Enterprise Ethereum Alliance, Ethereum’s catalyst sponsor. Among these projects were those that created tokens for the purposes of raising capital for ventures (called initial coin offerings [“ICOs”] or token sales).162 Protocol developers’ commits do not generate or destroy the cryptoasset tokens that are the center of ICO litigation. Smart contract developers create those tokens through the creation of smart contracts that they deploy on the network directly.163
III. Protocol Developers in Moments of Crisis
The capitalization of blockchain cryptoassets was over twelve billion USD164 and has increased by billions since.165 Along with the rise of cryptoassets having real market value is an increase in crises resulting from hacks and exploits of token exchanges and smart contracts, leading to losses of over one billion USD to date.166 These hacks and exploits are often the result of bugs in the software code.
a. The Ethereum Hard Fork
The decision to fork or not fork is one taken by network participants during moments of crisis.167 At least two major exploits have touched the history of the Ethereum network. These compromises provide a lens into the operations of developers and whether the actions taken by protocol developers warrant the safeguards provided by the corporate fiduciary duty.
As mentioned in the introduction, The DAO, an unincorporated organization run by the founders of Slock.it UG,168 is a German corporation that works on IoT infrastructure.169 Theda project ran on the Ethereum blockchain through the actions of smart contract developers. The project had the “objective of operating as a for-profit entity that would create and hold a corpus of assets through the sale of DAO tokens to investors, which assets would then be used to fund ‘projects.’”170 After $150 million worth of tokens were sold, a flaw in the smart contract code was exploited, resulting in the theft171 of about $50 million worth of tokens in the summer months of 2016.172
Arguably, participants in The DAO network were put on notice that the smart contract code superseded any representations or warranties. The purchasers of The DAO token were put on notice of this Term on The DAO website:
The terms of The DAO Creation are set forth in the smart contract code existing on the Ethereum blockchain at 0xbb9bc244d798123fde783fcc1c72d3bb8c1894. Nothing in this explanation of terms or in any other document or communication may modify or add any additional obligations or guarantees beyond those set forth in The DAO’s code. Any and all explanatory terms or descriptions are merely offered for educational purposes and do not supersede or modify the express terms of The DAO’s code set forth on the blockchain; to the extent you believe there to be any conflict or discrepancy between the descriptions offered here and the functionality of The DAO’s code at 0xbb9bc244d798123fde783fcc1c72d3bb8c1894, The DAO’s code controls and sets forth all terms of The DAO Creation.173
This is only one of many disclosures that the DAO put out. Another statement published by The DAO reads:
The DAO’s smart contract code governs the Creation of DAO tokens and supersede any public statements about The DAO's Creation made by third parties or individuals associated with The DAO, past, present and future. The software code currently available at https://github.com/slockit/dao is the sole source for the terms under which DAO tokens may be created.174
The Creation of DAO tokens carries with it significant risk. Prior to Creating DAO tokens, carefully consider the exemplary and non-exhaustive list of risks set forth below and, to the extent necessary, consult a lawyer, accountant, and/or tax professionals prior to Creating DAO tokens.
1. Risk of Security Weaknesses in The DAO's Software
The DAO concept is both experimental in nature and unproven. There is a risk that, as an open source project, any contributor to The DAO's software could introduce weaknesses or bugs into the DAO software, causing the loss of DAO tokens or ETH in one or more or even all of the DAO Token Holder’s accounts.
2. Risk of Weakness in the DAO underlying blockchain, and/or Ethereum Network
The DAO software is itself based on an unproven platform: the Ethereum blockchain. There is a risk that, as an open source project, any contributor to the Ethereum blockchain could introduce weaknesses or bugs into the Ethereum software, causing the loss of DAO tokens or ETH in one or more or even all of the DAO Token Holder's accounts.
3. Risk of unforeseen attack vectors
The field of Digital Cryptography is very new and for this reason, there is a risk of unforeseen attack both in terms of the underlying cryptographic protocol that back the functioning of the DAO as well as ‘game theory’ related vectors which have not been documented to date. Both these vectors represent a risk that could lead the loss of DAO tokens or ETH in one or more or even all of the DAO Token Holder’s accounts.175
The DAO appeared to admit that its platform was in an experimental state and explained risks. In so doing, it can be inferred that The DAO wanted to shift liability away from itself and its smart contract developers through, in so many words, caveat emptor.
This preemptive shift in liability does not mean that the smart contract developers were totally careless programmers; among the several safeguards smart contract developers built into The DAO smart contract was a withdrawal latency of twenty-eight days.176 This window of time proved to be critical; it was used by the Ethereum protocol developers to organize the Ethereum community to decide what to do while the attacker could not exchange stolen DAO tokens for ether, the native cryptocurrency of the Ethereum ecosystem.177
A soft fork of the system was considered by Ethereum protocol developers and nearly reached execution stage,178 but ultimately the soft fork plans were abandoned because there was a denial of service exploit in the soft fork.179 The Ethereum developers had about twenty-two days left before the attacker would be able to convert DAO tokens into ether.180 The Ethereum protocol developers, facing a closing window in which to fully resolve the effects of the theft, concluded that a hard fork would be the best option.181
Even then, with this conclusion that a hard fork was the best option, the protocol developers decided to create a software application allowing network participants (Layer 1 of Buterin’s conceptual model) to decide whether or not to enable the fork.182 Whether or not the default should be for a client to opt-in (for the hard fork) or opt-out (against the hard fork) was debated.183 Ultimately, a vote was opened on carbonvote.com,184 where users could vote based on their ether supply. Of the 80% of the ether supply that voted,185 80% voted for opting-out to be the default. Thus, the decision to have the opt-out of the fork as the default was finalized.186 Five days later, Ethereum implemented a hard fork that resulted in two Ethereum networks: one with a state change that essentially returned the value of DAO tokens, which is the modern day Ethereum; and the other that continued with the effects of the attack in its blockchain history, Ethereum Classic.187
The present-day Ethereum gained a majority of the mining power, but Ethereum Classic had a sizeable community of 10% of the mining power and value.188 All Ethereum users who held ether at the time of the fork had funds on both blockchains (ETH for Ethereum and ETC for Ethereum Classic), and soon the exchange Poloniex listed ETC.189
This incident illustrates a number of different aspects about the Ethereum protocol developers. Assuming arguendo that the protocol developers had an agenda to cram down a hard fork so that history of The DAO exploit was universally erased, it was not successful; the Ethereum Classic community retained the history of the exploit, and that blockchain and community exist to this day.190 Second, even when committing the code to hard-fork, the hard fork was effectuated by Layer 1 formal participants adopting the software update of the hard fork.191
In January 2019, recent to the time of this writing, the Ethereum Classic blockchain network detected a 51% attack on the network, in which one entity controlled the majority (at least 50%) of the mining computational power and altered the transaction history of that blockchain.192 As discussed above, the Ethereum Classic blockchain network is the result of the minority mining community that chose to not adopt a hard fork to mitigate the effects of The DAO exploit.193 It is possible that this network’s vulnerability is a result of the mining power that left it for the present-day Ethereum network.194 The hard fork resulted in a near reset of network effects for the Ethereum Classic community.195 This illustrates that hard forking can impair the robustness, and therefore security, of the resulting blockchain networks. However, the miners did vote with their feet,196 and the protocol developers did not and could not force the fork on anyone.197
There are notably poor blockchain smart contract development practices,198 like the lack of adequate testing to prevent The DAO smart contract code exploit,199 and there are compelling reasons why a disclaimer attempting to negate representations should not shield public smart contract development organizations from any culpability or liability.200 However, these failures should not and need not be imputed to all blockchain developers alike; as The DAO hard fork events show, the protocol developers helped remedy the situation caused by the exploitation of the smart contract developer’s code. The protocol developers helped to coordinate and execute the will of the cryptocurrency holders with utmost consideration and under the constraints of little time. They also did not cram down changes on the community, but rather created the remedy-implementing software option for members who wanted to support a blockchain history that did not recognize the theft.201
b. The Bitcoin Core secret update
Developing, maintaining, and understanding blockchain systems are complex tasks that run the risk of errors being made and bugs being introduced into the codebase for the blockchain systems.202 Recently, a secret update was applied to the most popular Bitcoin client software, Bitcoin Core, to fix a bug that would have allowed a miner to artificially inflate the supply of bitcoin.203
Through the Bitcoin Core bug reporting system, an anonymous individual reported a bug which enabled a distributed denial of service attack on the Bitcoin Core client.204 In analyzing the reported bug, a second bug was discovered that would have enabled a miner to artificially inflate the supply of Bitcoin.205 This second bug was kept secret by the Bitcoin Core developers until a patch for both bugs was published to the community.206 Later, an individual independently discovered the second bug, and consequently the Bitcoin Core team published their recounting of the bug and the associated timeline.207
The Bitcoin Core developers keeping the bug secret raises the question of what safeguards should exist from developers exploiting that information to the detriment of network participants, and what recourse, if any, network participants should have against the developers. A user of the blockchain system could bring a claim of unfair trade practices alleging fraud against the developers that kept the bug secret, particularly, under Section 5 of the Federal Trade Commission Act.208 Additionally, or alternatively, a potential claim of insider trading could be brought against any developers trading on non-public information.209 Andrew Verstein notes that “crypto assets are subject to at least enough of the insider trading jurisprudence to allow federal prosecutors to bring successful criminal actions.”210
A framework similar to safe harbor provisions for data breach reporting may be the most appropriate model for a path forward. Under such a framework, developers may have a grace period to disclose the existence of bugs, and assuming they do not trade on the information to the detriment of network participants, they may not be held liable for keeping the bug secret.211
IV. The Improper Fit of Corporate Fiduciary
Scholarship on the law of fiduciary duties starts with an admission to the effect that the law is “messy,”212 and that the fiduciary concept itself is “elusive.”213 Courts use “ad hoc” approaches214 to “examine whether the relationship involved in the litigation is sufficiently like those in the paradigm cases to support an extension of the obligation to that relationship.”215 Critics state that this “jurisprudence of analogy”216 has led to applying the fiduciary principle “to disparate fact situations”217 that exacerbates the “confusion and uncertainty,”218 and that “analogies frequently do not result in appropriate rules.”219
We recognize the importance of fiduciary obligations as a tool to “give a judge a framework for crafting a hypothetical bargain.”220 We agree with the law and economics view that fiduciary duties are appropriate for “reducing agency costs associated with the separation of ownership and control.”221 We also acknowledge that, however problematic, the use of analogies is a logical starting point for understanding social changes. Yet for technologies that emerge extra-institutionally, we must be prepared to examine distinctions, however onerous the task of technical comprehension, before shoehorning a duty so high as a fiduciary duty.
At least one scholar suggests that because “developers look a lot like officers or directors of a corporation,” having analogous fiduciary duties is fitting.222 This line of reasoning follows from the view of “[cryptoassets] as shares of stock in a corporation.”223 The cumulative effect of reasoning based on a string of analogies underscores the risks of jurisprudence that is supported by analogizing a series of “disparate fact situations.”224
a. Corporate fiduciary duty
We put aside the growing body of scholarship that decries the corporate fiduciary obligation as a “myth,”225 and begin to deconstruct the succession of analogies by studying fiduciary duty generally. Arguing from a law and economics point of view, Robert Sitkoff states:
[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.226
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.”227 “When market forces can or do adequately constrain agency costs,” however, “the relationship in question is no longer properly regarded as a fiduciary.”228
Fiduciary obligations are applied to relationships where one party (the “beneficiary”) is structurally vulnerable to abuses of power and agency problems due to its reliance on a second party (the “fiduciary”) to act on its behalf in an unobservable and discretionary manner. 229 Fiduciary obligations are standards that enable courts to provide a remedy when “the protective mechanisms outside of fiduciary law cannot adequately eliminate the risk.”230 Therefore, if one party (the potential beneficiary) can protect itself 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.231
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.232
Therefore, fiduciary obligations are a judicial deterrence tool designed to work by influencing the fiduciary’s internal cost-benefit analysis of engaging in self-serving behavior through the threat of litigation (e.g., a corporate director is less likely to engage in a self-dealing transaction if under a model of rational self-interest, she believes that as a result of such self-dealing behavior she will face a lawsuit for breach of fiduciary duties that will cost her more than what she is able to gain through her actions).
Traditionally, corporate fiduciary duty arises from the view that corporate officers and directors owe fiduciary duties because they are managing the assets of the owner-shareholders in a trustee-like manner.233 Under applicable state corporate law, the stockholders of a corporation have the sole power to elect directors.234 Generally, shareholders select specific directors to serve on a company’s board due to their expertise in a particular area or connections in a certain industry, which the shareholders hope will benefit them by resulting in improved prospects for their company.235 Upon being elected by the stockholders of a corporation, directors are empowered to be the ultimate managers of the “business and affairs of the corporation.”236 This power is codified in Section 141(a) of the DGCL237 and by similar statutes in other states.238
When stockholders invest in a certain company, they entrust their capital to the corporation’s directors, who function as the shareholder’s agents. Given the deference directors receive under the business judgment rule, directors are legally empowered to make decisions on behalf of stockholders, and in certain circumstances can do so even against the express wishes of the latter.239 Courts therefore impose fiduciary duties on directors requiring them to protect the interests of the corporation and to act in the stockholders’ best interests.240
b. Where the analogy between protocol developers and corporate directors fails
Protocol developers are distinct from corporate directors in several ways. Protocol developers cannot be said to act as the legal agent of any other network participant, individually or collectively. Protocol developers’ voluntary, collaborative and iterative contributions take place in the context of open source production, making their contributions inherently different from the actions undertaken by a fiduciary during her representation of the beneficiary as delineated by an agreed-upon and pre-existing agency relationship. To begin with, there is no expectation between the cryptocurrency holder and the protocol developers of the latter having a legal agent role.241 Protocol developers do not make representations of a trustee-like fiduciary position.
Protocol developers lack the ability to bind any other network participants to software application changes, and no other network participant has the power to direct or control the voluntary actions of protocol developers. We have seen how implementation of any change to a particular software application takes place through a multi-level political process and requires consent of formal participants to a public blockchain network. The actions of protocol developers do not deprive any other network participant of their ability to act in their own self-interest, since every participant is free to run whichever version of the software application for the public blockchains. These actors can independently audit the proposed revisions and evaluate their choices. A protocol developers’ ability to influence the welfare of the cryptocurrency holder (i.e., the value of the cryptocurrency) is therefore limited to proposing and advocating for a solution that may or may not be subsequently adopted by the community.
A fundamental characteristic of fiduciary relationships is the entrustor’s delegation of power or property to the fiduciary, which is necessary for the latter to achieve her goal. For example, we have discussed how shareholders cede ownership and control over the assets of a corporation to the directors and corporate officers.242
In contrast, there is no action that take places between a protocol developer and a cryptoasset holder or any other network participant that could be adequately characterized as a delegation of property or power. There is no agency agreement delegating power between protocol developers and other network participants, nor means for the network participants to exercise formal power or control over the protocol developers. Further, the ability of protocol developers to act is not dependent or enabled by a specific action taken by any cryptocurrency holder.
The attenuated relationship between a public blockchain protocol developer and a cryptocurrency holder is established on the basis of two separate actions: (a) a protocol developer’s decision to contribute code to a particular software application and (b) another’s decision to participate in the public blockchain network by acquiring cryptoassets or operating a node. Neither of these actions alone, nor their combination, constitute a delegation of power or property by a cryptocurrency holder or the acceptance of such power or authority of the cryptocurrency holder by a given protocol developer.
The decision of an individual to acquire cryptocurrency cannot be interpreted as a delegation of property or power to a protocol developer given that, because of that action, protocol developers are neither directly gaining control over property nor gaining the ability to bind the cryptoasset holder to any decision. Critically, the purchase of cryptocurrencies should not be confused with the purchase of public company equity securities, given that public company directors can legally bind the shareholders’ rights and interests, even against their will. For example, the board of directors of a public company may rebuff a merger offer that would result in a shareholder receiving a significant premium for her shares.243 In contrast, protocol developers have no such ability to bind other network participants.
One may argue the potential effect that updates to a certain software application proposed by protocol developers may have on the value of the cryptocurrency demonstrates a delegation of property from the cryptoasset holders to the protocol developer, which could be the basis of a fiduciary relationship. However, the cryptocurrency’s potential diminution does not reflect the existence of a fiduciary relationship because it is due to the reaction of the economic majority to a development adopted through a multi-level political process.
c. Protocol developers do not pose the same risks of traditional fiduciaries
We have shown in the prior section how the relationship between protocol developers and other participants in public blockchain networks does not share structural similarities to the relationship between a fiduciary and beneficiary. In this sub-section, we show that protocol developers do not pose the dangers that fiduciary obligations are meant to deter, namely abuse of power or agency costs.
i. Protocol developers’ motivations align with those of the network participants
Fiduciaries are usually empowered to act with discretion and bind the beneficiary, resulting in the risk that they will act in self-serving ways to the detriment of the beneficiary. In addition, the risks posed by fiduciary relationships are often heightened by the inherent inability of the beneficiary to monitor the fiduciary’s performance of her services. For example, shareholders are entitled to only certain information about the actions of the board, and while the beneficiary can monitor the fiduciary, this monitoring is limited to achieve a public policy goal.244 Fiduciary duties are therefore applied to ameliorate the information asymmetries arising from the beneficiary’s limited ability to monitor a fiduciary who could possibly exploit her.
In contrast, a protocol developer’s actions are radically more transparent and do not exhibit the same information asymmetries as traditional fiduciary relationships. An open source software application is, by definition, readily accessible to the public through an online repository. Moreover, updates made to a certain software application, through BIPs and EIPs, are heavily discussed and analyzed by the community both in technical and general terms. “Anyone who stumbles upon the thick Twitter, Reddit and Medium chatter addressing Bitcoin reform or reads the Bitcoin-related GitHub postings can readily monitor activity in the Bitcoin developer community.”245 Given that a significant part of the impetus for protocol developer contributions to public blockchain networks 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.246
While many cryptocurrency holders are not sufficiently knowledgeable to understand the technical details of projects or revisions, a vibrant ecosystem of participants has developed with the technical knowledge and economic incentives to take a “deep dive” into the technicalities of projects and signal preferences to formal network participants and the market generally. We explored in Section II (c) how certain institutions play a coordinating role with formal participants in the network and by the same process provide synthesized information to the broader market through their statements and actions.
ii. Protocol developers are structurally unable to act selfishly to the detriment of other network participants
We have noted that protocol developers contributing to a certain software application are traditionally not directly remunerated for their efforts by other participants in the network, and as such, the impetus for their contributions can be attributed to (a) long-term reputational value from contributing to important projects and (b) economic value from the potential price appreciation of cryptocurrencies they may hold. Given that protocol developers are incentivized by reputational gains from their contributions to a successful project and by economic gains from the value appreciation of cryptocurrency due to network effects, a protocol developer’s ability to benefit from her contribution to a certain software application is directly linked to the success and growth of the related network. Given the incentive alignment between protocol developers and other network participants, the need to impose fiduciary duties is obviated.247 This context is disparate 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.
The DAO exploit exemplifies the above point. As discussed earlier, the Ethereum protocol developers took care to poll holders of Ether to determine if they preferred a default in the software application of forking or not forking; these developers were under no obligation to conduct such a poll to direct the design the hard fork software. However, the protocol developers’ interests are to increase the value of the network, and the value of the network is reflected by a community’s willingness to transact on it and participate in its validation scheme. Thus, the protocol developers wanted to know the wishes of the community to design the software application in accordance with those wishes; doing so salvaged the network’s value for what is the modern-day Ethereum network.
The community that did not want the hard fork did not vanish were free to keep on to the blockchain history and protocol that they wanted. That Ethereum Classic community continues to this day. Assuming arguendo that protocol developers wanted all network participants to “convert” to adopt the hard fork, the protocol developers failed; they were unable to foist their decisions onto this community.
Corporate boards and directors have much more coercive power—for example, they are able to bind the corporation against the will of shareholders. Protocol developers simply lack the authoritative power that warrant the imposition of fiduciary obligations.
iii. The structural dynamics and incentive structures of public blockchain network governance ameliorates the risks that protocol developers will act carelessly
Blockchain technology is still in its nascent stage and is highly experimental. As a result, errors in the code of software applications occur and can be expected to continue.248 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 and EIPs. Not only is each update scrutinized by arguably the most capable protocol developers in the 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.249 Open source production’s track record of innovation in highly technical areas is a testament itself to the quality of work produced by this development paradigm.250
c. There are alternative methods to regulate protocol developers which negate the need to extend fiduciary duties
Fiduciary obligations are imposed in the absence of other alternative means of redress. As noted by Frankel, “[i]f the entrustor can protect himself from abuse of power, there is no need for the intervention of fiduciary law.”251 The imposition of fiduciary duties on protocol developers is therefore inadequate given the existence of alternative mechanisms to control protocol developers and other participants in public blockchain networks.
There are existing legal frameworks that are much better suited for dealing with the risks potentially posed by protocol developers and other participants in public blockchain networks, including the imposition of commodity and securities laws at the federal and state level, money transmission and payments law at the federal and state level, as well as general consumer protection, anti-fraud and criminal regulations. While an in-depth discussion of the relative benefits of each regulatory framework is outside of the scope of this Article, courts and policymakers have a wide array of tools they can use to protect the interest of participants in public blockchain networks, several of which reflect the realities of the techno-economic paradigm more closely than would the imposition of fiduciary duties.
V. Effects of Imputing Fiduciary Duties on Protocol Developers
Imputing fiduciary obligations to public blockchain protocol developers ignores the design mechanisms in place that curb the risk of wanton decision making by the protocol developers. It is instructive to analyze how designating protocol developers as fiduciaries would affect the judicial process and open source production systems. Once we consider the potential implications of regulating protocol developers as fiduciaries, the impracticability and undesirability of adopting such a position becomes clear.
a. Impractical for courts
At its mildest, labeling protocol developers as fiduciaries would present courts with the challenge of forcing the static concepts of “fiduciary” and “beneficiary” onto a highly dynamic context of public blockchain network governance.
i. Assessing which protocol developers owe fiduciary duties
A protocol developer may contribute one minor line of code that is utterly essential to network functionality. Another may constantly contribute a high volume of lines over a long period of time, but still be a functionary whose work is wholly non-essential and could easily be replaced by others. Alternatively, a “contributor” may not even write actual code at all but instead make a conceptual suggestion that is critical, or simply review other’s code and discover an important bug. Given the different types of activities that individual protocol developers engage in, it would be untenable to suggest that every single protocol developer who makes any contribution, no matter how small or irrelevant, to a public blockchain network is a de facto fiduciary.
At the same time, given the highly dynamic, collaborative and iterative nature of public blockchain development, there is simply no alternative way to define which protocol developers rise to a status warranting the label of fiduciary. Those who argue that fiduciary duties should apply to developers are aware of this definitional issue and resort to either referring to a laundry list of different terminologies252 or relying on conclusory definitions.253
The temporary influence held by certain protocol developers is derived from the reputations they established through the quality and frequency of their contributions and from the value of the particular contribution at stake. Moreover, the fact that a particular protocol developer can wield influence over a software application at a certain moment does not mean that she will continue to exercise that influence, and critically it does not mean that she is able to bind any other participants in the network. Therefore, it would be functionally impossible for courts to provide a static definition that delineates with clarity which protocol developers are “influential enough” to warrant the imposition of fiduciary obligations. Importantly, without the ability to delineate which developers are fiduciaries, protocol developers themselves will be unable to take the necessary steps to protect themselves.
One might argue that those protocol developers with “commit access” to the code repository of a particular software application should be identified as fiduciaries. However, this would entail a misunderstanding of the power dynamics in public blockchain governance, given that protocol developers exhibit a range of influence not defined exclusively or even particularly by this access. Moreover, “commit access” to a specific software application, such as Bitcoin Core, does not entail control over a network which we have noted can support different software applications. Separately, applying fiduciary obligations to individuals with commit access is also likely to be an ineffective regulatory approach, given the potential for technological work-around that could provide developers with anonymity.
ii. The risk of strike suits
Fiduciary obligations are a deterrence mechanism that provide legal recourse to parties who are structurally susceptible to abuses of power.254 The imposition of fiduciary obligations on public blockchain protocol developers would allow, under the most extreme position, any member of the public holding cryptocurrencies 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 application, a protocol developer owed a duty of loyalty or duty of care to the allegedly aggrieved party and whether either duty was violated. Imposing the fiduciary standard on protocol developers for the benefit of cryptoasset holders would grant the public at large, or even a subset of blockchain network participants, the ability to file under a cause of action for breach of a heightened duty, creating the potential for strike suits that would be piled on to an already overwhelmed court system.255
b. Create motive for subverting the mechanism design of a public blockchain
Corporate fiduciaries are often paid handsomely for the risk they take on as fiduciaries, and these benefits incentivize them to keep corporate matters under their scrutiny and control. Protocol developers, as we have discussed, are not directly compensated and volunteer to create software applications that allow users to participate in the blockchain network—a network that relies upon decentralization of participation for its stability. Imputing fiduciary obligations to protocol developers may cause the protocol developers to take more authority over the network and subvert the purpose of public blockchains. The purpose of public blockchains is to allow for open transacting. For example, a protocol developer, knowing that she would be held to such a high standard for any cryptocurrency owner, may decide to create barriers for network participation entry so that she has less risk by swaying network participation. Under such a high standard, she may also design consensus rules that favor transactions and miners that she desires to lower her liability risk. Imputing fiduciary obligations would threaten the decentralized ecosystem of public blockchains.
c. Chill open source innovation
Importantly, the imposition of fiduciary duties on protocol developers and the risk of liability that determination entails could potentially end the viability of open source production. Open source production has emerged in recent decades as a startling paradigm of human interaction that has enabled innovative new models of social organization and is increasingly responsible for producing more of the world’s information.
Open source production has an impressive track record of technological innovation, made more remarkable by how modern economic theory is largely unable to explain its accomplishments. Writing in 2017 of the success of Apache, the open source web server software, Yochai Benkler stated, “[a]ny economist who would have predicted in 1996 that a group of developers working on webserver software, using no formal managerial hierarchy and relying on a copyright license that gave no one exclusive proprietary control over the products of the collaboration would beat Microsoft in a market that was core to Microsoft’s Internet strategy would have been laughed out of the room. And yet Apache beat Microsoft Server over the past twenty years, and its fastest growing competitor is Nginx, another FOSS project.”256
If we study its track record, we see how open source production—as a human coordination mechanism—has enabled remarkable technological innovations and is today responsible for an increasing amount of the information production in the world. Some of these technological innovations include: Apache, Linux (the preferred operating system for programmers), Wikipedia (the killer of Encarta), as well as today’s public blockchain networks.257
Contributions to open source production systems are voluntary and partially animated by social and psychological factors. In the event these contributors were made potentially liable to the public at large based on newly expanded and untested fiduciary standards, they would be likely to reconsider contributing to such projects, resulting in them ceasing to do so, or continuing in covert or non-public ways. If the risk of liability derived from the imposition of fiduciary obligations changes the incentive mechanism of public blockchain networks, open source production risks grinding to a halt.
Conclusion: Towards a Better Understanding of Public Blockchain Network Governance for Appropriate Liability Frameworks
We have argued that public blockchain protocol developers do not function as corporate fiduciaries, and further that labeling protocol developers as fiduciaries would be impractical and have other negative effects including potentially destroying the open source production model.
However, we have also readily acknowledged that public blockchain networks necessarily develop governance structures (however latent or dynamic) and that in some circumstances, protocol developers can exercise an influential role in the implementation of changes to certain software applications. As such, it is important to focus on better understanding the role that all participants in public blockchain networks play in their governance, and that the community of developers contributes to achieving this understanding.258 It is important to study the incentive mechanisms that guide those in these roles. In addition, we acknowledge the critical role of regulators in protecting the public and policing the markets, including by holding accountable developers who design and launch malicious and unsafe smart contracts and other software applications.259 However, for the reasons stated above, we find the argument for extending fiduciary duties to protocol developers for the prominent blockchain networks we have focused on to be both untenable and undesirable at this point.
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.260 By means of these blockchain-based consensus mechanisms, formal participants of a network may be able to decide which code updates are implemented according to a pre-existing ruleset. Blockchains are at their core a “foundational technology for new forms of governance for making rule-governed economic orders.261 Therefore, the technology itself may provide 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. 262