The legal duty of blockchain developers

As blockchain technology becomes increasingly relied upon, it becomes critical that the law extends its well-established protections to this new context. Today, people rely on a variety of blockchains and the products built upon them, be it because they have chosen to invest their money in something like Bitcoin, because their business is built upon the blockchain or any number of other realistic scenarios.

The law imposes different kinds of duties on individuals or other legal entities. For example, a claim of negligence under English law requires that the plaintiff establish that the defendant owed them a duty of care, and that they had been negligent in discharging that duty. Another example is fiduciary duties, which typically attach more onerous obligations, which exist in situations where one person has placed trust in another to act in their interests. An example would be the relationship that exists between a doctor and their patient, but fiduciary duties have been established in a wide range of contexts.

The creation, development and maintenance of blockchains may be seen as a novel circumstance but it is inevitable that the courts will be called upon to determine how existing laws—and in particular the law of fiduciaries and similar duties—are to apply.

Finally, this question is going to be put before the courts in the United Kingdom: Dr. Craig Wright, victim of a multi-billion dollar hack resulting in the loss of 111,000 BTC and associated unsplit coins, is suing the developers of BTC, BCH, BCH ABC and BSV arguing that as those in charge of the blockchain, they owe him legal duties to ensure that the theft cannot be effected. He argues that these duties compel the developers to enable him to regain access to the stolen coins.

To some, this seems like a radical and outrageous step. However, those familiar with the kinds of duties that the law is interested in imposing would be left unsurprised. Actors within a blockchain ecosystem may hold titles or be dealing with technology that the law has yet to contemplate, but the roles they play arguably fit within the law as it already exists. The policy reasons for imposing a duty on those who are relied upon to act properly and in good faith are no less pressing—if anything, they are even more important—in this scenario.

Fiduciary duties

At the heart of the law of fiduciaries is the concept of trust, giving legal recognition to the fact that many individuals or other legal entities occupy such a position that they are relied on to act competently, in good faith and in the best interests of the beneficiary.

The definition of fiduciary was described in the leading fiduciary case of Mothew v Bristol & West Building Society as ‘someone who has undertaken to act for and on behalf of another in a particular matter in circumstances which give rise to a relationship of trust and confidence.’

The easiest cases are the likes of doctors and lawyers, but fiduciary relationships can be found in a range of contexts and the process for determining them is complex and often holistic. These relationships are often recognized in contract, but critically, the fiduciary duty is not founded in contract and no contract is necessary.

The U.K. Supreme Court recently embarked on this analysis in Lethimaki v Cooper on appeal in 2020. They accepted the prior court’s application of a test set out in the Australian case of Grimaldi v Chameleon Mining NL (No 2):

“A person will be in a fiduciary relationship with another when and in so far as that person has undertaken to perform such a function for, or has assumed such a responsibility to, another as would thereby reasonably entitle that other to expect that he or she will act in that other’s interest to the exclusion of his or her own or a third party’s interest.”

Though the law of fiduciaries has developed somewhat differently in the United States, the foundational concerns and applications remain similar. Fiduciaries typically have four attributes, as described by leading law professor Tamar Frankel:

  1. Fiduciaries offer mainly services which are usually socially desirable and often require expertise
  2. They must be entrusted with property or power in order for them to perform these services effectively
  3. The entrustment poses to the entrustors the risk that the fiduciary will not be trustworthy
  4. There is a likelihood that the entrustor will fail to protect itself from the risks involved in fiduciary relationships, the markets might fail to protect the entrustors from these risks, and the costs for fiduciaries of establishing their trustworthiness might be higher than their benefits from the relationship

The subject matter is much the same, but expressed somewhat differently. The last point is concerned with establishing that the entrustor is vulnerable to fiduciaries and that this vulnerability is not likely to be protected by either the fiduciary or the market.

Further, it is important to remember that a finding that a person or other entity is acting as a fiduciary is merely the first step. Frankfurter J in the United States case of Securities & Exchange Commission v Chenery Corpn (and subsequently favourably cited by U.K. courts) said this:

“To say that a man is a fiduciary only begins the analysis; it gives direction to further inquiry. To whom is he a fiduciary? What obligations does he owe as a fiduciary?”

Position of blockchains

Though exact approaches differ across jurisdictions, the thrust of fiduciaries law and the policy reasons behind it are similar. With that in mind, should blockchain developers be considered fiduciaries? To whom should they owe this duty?

Part of the reason that it is sometimes assumed that public blockchain developers owe no duties to anybody is that the myth of decentralization has become so intertwined with the story of blockchain that many take it as a given. In reality, by standards of both common sense and the approach of courts in similar circumstances, public blockchains are not decentralized.

This misconception understandable: blockchain technology is such that it can be misleadingly described quite easily. For example, it is true to say that public blockchains operate on a peer-to-peer basis, with the software being run by a network of computers. Development is done on an ‘open source’ basis, which may in some contexts suggest decentralization though not in the case of most public blockchains.

Of course, none if this is helped by a concerted effort by those who do know better to push decentralization as a key narrative pillar of blockchain and Bitcoin generally. However, if you cut away the overwhelming narratives that have taken hold within the industry and apply law to fact—as the Court will do in Dr. Wright’s pending litigation—it would appear that blockchain developers fit within the ambit of fiduciaries law quite comfortably.

Application of law to fact

To focus on the language used in Grimaldi and accepted in Lethmaki, developers have clearly undertaken to perform a function for others (the development and maintenance of the blockchain). The users of the blockchain would reasonably be entitled to expect that the developer(s) to act in their interest. The users do not as a rule possess the expertise that would be held by the developers, so the asymmetry is real, and there is no real mechanism in the market which might otherwise protect them from developers acting improperly or in bad faith.

The exact analysis would depend on the blockchain in question, but to take BTC as an example. If BTC were truly decentralized, then it would be hard to impose fiduciary obligations in this context. There is no “developer” in which trust could be said to have been placed, because anyone can propose changes to the code.

However, in spite of its reputation as an open-source project, there is a central body of developers who lead development. Again, the notion of decentralization as it might pertain to the question of trust falls apart when one asks why it is users of the blockchain could readily provide an answer if asked: “who are BTC’s developers?” The answer would not be “everyone,” the answer would be any or all of a narrow list of people depending on when the question is asked. In 2014, the answer might have been Gavin Andresen. Today, the answer might be Wladimir van der Laan or any number of associated developers. These are the gatekeepers and decision-makers. The governance of the blockchain is happening by identifiable people whose decisions obviously change the course of the project and thus change the fortunes of the people using it.

Those who have bought BTC or who have set about building applications on its blockchain are relying on those decision-makers to, for example, not act in a manner which would destroy the adoptability of the technology, or deplete the value of the BTC. No issue arises out of the fact that the developers may not know the specific individuals who are placing their trust: duties can be owed to a class of people (arguably the users of the blockchain, though a more granular class of those entrusting the developers to act properly will likely emerge via litigation) and, in other contexts, even the public at large.

For public blockchains, the case almost makes itself when you consider the many high-profile disasters which have been associated with developer actions.

Take Ethereum’s DAO debacle, for example. When the DAO was built and released on the Ethereum blockchain, it was hacked within a month leading to the theft of $60 million worth of ether. Naturally, this demanded action: what should be done about the theft? Should it be accepted as a mistake and simply ignored? Or should direct action be taken to prohibit the use of the stolen ether?

The response was not led by the community, as a decentralized narrative might have you believe. The response was led by the people we most closely associate with Ethereum—the founders and developers like Vitalik Buterin.

Further, there can be no argument that “code is law” and as such those who wrote and released that code are absolved of their duties. Legal attitudes toward this point are nicely encapsulated by the comments of Judge Alfred P. Murrah in State Farm Mutual Automobile Insurance Company v Bockhurst, a U.S. case which considered the impact of computer processing on human liability (though not in the context of duties):

“A computer operates only in accordance with the information and directions supplied by its human programmers. If the computer does not think like a man, it is man’s fault.”

If it means anything to be able to refer to “BTC developers” as a class of people, as regularly done, then it is self-evident that there are people who are acting in control of the blockchain. If, as would be correctly implied by open source, any person could make and commit changes to the protocol with no gatekeeping, then it means nothing to refer to “BTC developers” as a class of people. As it is, anyone can easily identify those who are in charge of BTC (and ETH and so on).

Tortious duty of care

This is to say nothing of the additional duties which may apply here. An important feature of fiduciary law is that these duties do not exclude the imposition of other kinds of duties. A fiduciary is likely to also owe other common law duties. The Law Commission of England and Wales examined the topic in assessing the duties owed by investment intermediaries, making the following general point:

“In the past, the term ‘fiduciary duty’ has been used in a broad sense to cover all the various duties a fiduciary owes. However, the courts have now issued stern warnings against using the term in this way. It has now been recognised that fiduciaries will owe both fiduciary duties and non-fiduciary duties.”

To use Dr. Wright’s stolen coins as an example: in addition to the fiduciary duties discussed above, he is arguing that he is owed a duty of care in tort by the blockchain developers which obliges them to act with reasonable care. Presumably any lawsuit action which flows from this assertion will be focused on the developer’s failure to act in relation to coins which they know (thanks to Dr. Wright’s recent legal letters) to be stolen and owned by Dr. Wright.

Typically, courts are reluctant to impose a duty in relation omissions save for in specific circumstances—for example, where a defendant is found to have voluntarily accepted responsibility. This again returns to similar questions considered in the fiduciary context—what role are the core developers playing in this chain—but duties have been found in somewhat analogous contexts which will be influential on any court reviewing Dr. Wright’s case. For example, in Stansbie v Troman in the U.K., the court imposed a duty on a decorator toward a homeowner whose house he had failed to properly secure, leading to a burglary. The decorator’s failure to lock the door to the house was found to be a breach of that duty and as a result of the breach, the items were stolen.

Implications

The implications of these duties are significant. To stick with the case of stolen coins (likely the example relevant to the largest number of people), once a duty is established, it is a small step for the courts to take to assert that in not acting upon the knowledge that coins on their network have been stolen from their rightful owners, they are in breach of this duty. Duties of care—both arising from the fiduciary relationship and arising at tort—are likely most relevant. The question would broadly become whether a failure to take steps to remedy such a theft (or even failure to maintain a system that would enable them to do so) constituted a breach of that duty.

In this case, it seems to follow naturally that once a fiduciary relationship is established between developer and user, the developer will not be saved from acting to protect stolen coins purely because their blockchain protocol does not allow for it. Courts have been willing to prohibit the continued operation of software that is found to be non-compliant with the law: in i4i v Microsoft, Microsoft was forced to remove, via patch, functionality from its Word program that was held to be in violation of a patent held by i4i. The court barred Microsoft from selling Word products which contained the infringing functionality until the patch was implemented. Even if a court will not order the specific implementation of software to allow the return of stolen coins, it might grant an injunction disallowing those governing the blockchain from giving effect to transactions involving stolen coins; this would have the same practical effect.

The law already applies here

If there is any gap in the law regarding the application of the law on duties to the public blockchain context, it exists only because no plaintiff has brought the matter before the Courts or at the very least, because legislators have not yet legislated for it. That has changed this year with the emergence of Dr. Wright’s hack and subsequent legal action against specific blockchain developers.

There are good policy reasons to apply traditional understandings of duties to blockchain governance, as evidenced by the countless other people who have found themselves in Wright’s shoes: the victims of a theft, left with no obvious recourse despite the stolen property remaining in full view.

Critically, the good governance of these blockchains is in the public interest: should they fail, the people relying on them can lose their data, money and even their businesses. It would be highly inconsistent with the law’s approach to relationships if it were to ignore the easily identifiable figures whose work is indispensable in ensuring the continuance of the system.

New to Bitcoin? Check out CoinGeek’s Bitcoin for Beginners section, the ultimate resource guide to learn more about Bitcoin—as originally envisioned by Satoshi Nakamoto—and blockchain.

[10]
[10]
[id^="_form"]
[id^="_form"]
[id$="_submit"]
[id$="_submit"]
[^;]
[^;]
['on' + event]
['on' + event]
[?&]
[?&]
[^&#]
[^&#]
[(d+)]
[(d+)]
[i]
[i]
[results[1]]
[results[1]]
[elem.name]
[elem.name]
[+_a-z0-9-'&=]
[+_a-z0-9-'&=]
[+_a-z0-9-']
[+_a-z0-9-']
[a-z0-9-]
[a-z0-9-]
[a-z]
[a-z]
[el.name]
[el.name]
[10]
[10]
[id^="_form"]
[id^="_form"]
[id$="_submit"]
[id$="_submit"]
[^;]
[^;]
['on' + event]
['on' + event]
[?&]
[?&]
[^&#]
[^&#]
[(d+)]
[(d+)]
[i]
[i]
[results[1]]
[results[1]]
[elem.name]
[elem.name]
[+_a-z0-9-'&=]
[+_a-z0-9-'&=]
[+_a-z0-9-']
[+_a-z0-9-']
[a-z0-9-]
[a-z0-9-]
[a-z]
[a-z]
[el.name]
[el.name]