In Code(rs) We Trust: Software Developers as Fiduciaries in Public Blockchains
Cryptocurrencies and public blockchains are often celebrated as eliminating the need for trust in a central party, due to their decentralized nature. Unfortunately, this mainstream view of these systems is incomplete and misleading, suggesting that no humans are making decisions on behalf of others, and that these systems operate autonomously through the running of software code.
In my forthcoming chapter, In Code(rs) We Trust: Software Developers as Fiduciaries in Public Blockchains, I attempt to debunk the myth that users of public blockchain systems don’t have to trust in a central party. By contrast, I argue that users of blockchain systems (e.g., holders of cryptocurrencies, those running businesses atop them, or those tying other assets or recordkeeping systems to them) place extreme reliance on both the skill and ethics of a small set of software developers. In fact, the trust placed is so significant that I argue these software developers function as fiduciaries of those who depend on the ongoing operation and success of the relevant blockchain.
Using Professor Tamar Frankel’s theory of the attributes of a fiduciary, I analyze the actions taken by software developers in the creation and ongoing operation of public blockchains, finding that there are strong arguments that key software developers fulfill all of Frankel’s identifiers of fiduciaries. In public blockchains, software developers provide socially desirable services (from the perspective of those using the system) that require significant expertise. Enabling the developers to perform these services requires entrusting them with property (the cryptoasset) or power (to shape the code constituting the cryptoasset). Those using public blockchains are at risk if the developers are incompetent (bad code or planning causes the collapse of the system) or self-dealing (perhaps by planting a bug that will drive a cryptocurrency’s price down upon its discovery or by taking money from an undisclosed third party to shape the code a particular way). Finally, it is likely that neither users nor the market will adequately protect users from developer actions, and it may be more expensive for the software developers to demonstrate their trustworthiness than what they can charge for their services (remembering that software development of core protocols like Bitcoin and Ethereum is chronically underfunded).
The chapter then analyzes the pros and cons of treating software developers of public blockchains as fiduciaries, and provides an initial analysis of questions to be answered for policy makers considering this question. These questions include how to identify which software developers of a given blockchain act as fiduciaries, which parties within a public blockchain’s ecosystem should be treated as ‘entrustors’ (or beneficiaries) of the fiduciary relationship, how the law might find a basis to recognize such a categorization, what duties are owed, how to identify a breach of the duty, and what types of remedies may be appropriate.
The chapter concludes by considering broader questions raised by the analysis, such as the accountability of software developers of other open source software projects that provide important services (like money) or infrastructure (e.g., of the internet). With an existing liability paradigm that quite securely protects software developers from responsibility for harms caused by their software, it may be time for a shift, given the critical role that software developers play in our societies, and in public blockchains in particular.
Angela Walch, St. Mary's University School of Law; University College London - Centre for Blockchain Technologies