Smart Contracts: The Good, the Bad and the Ugly - Part 2: The Bad and the Ugly

In this two-part article Rachael Goss takes a fresh look at the perennial question of whether smart contracts can ever work under English contract law by looking at the good, the bad and the ugly aspects associated with them. In Part 2 she looks at the shortcomings.

The Bad

Despite their allure and promises, there are an archipelago of problems associated with smart contracts that would cause them to clash with contract law provisions or make them incredibly onerous to implement. These issues arise because of three distinct features of smart contracts - immutability, anonymity, and the public nature of blockchain.

Immutability

Immutability has the potential to be one of the most attractive features of smart contracts yet at present is arguably one of the most unattractive features. It gives rise to a series of problems because once a condition has been met the smart contract is set into motion and cannot be stopped – at least not easily. Although “certain parameters may be amendable, smart contracts operating within a blockchain network fundamentally do not – perhaps cannot – change.”1

Additionally, the transaction itself cannot be reversed meaning that it would take the creation of a new node and an additional transaction using the same assets transferred in first instance to reverse the effects of the initial smart contract. Several problems arise from this, including mistakes and coding errors made during the creation of the smart contract.

If a smart contract’s code contains a mistake, and subsequently executes in a way that was unintended, or it contains a bug, it is very hard for one to fix the problem without undertaking what is known as a hard fork. A hard fork is a drastic change to the protocol resulting in the existing code being altered thus creating an old and new version of the blockchain. Transactions made prior to the fork are rendered invalid. This is a radical measure and it is unlikely that it would be employed in every instance of a coding error. Immutability therefore impedes the ability to amend mistakes and, although “nobody can mess with your contract once it has been deployed…immunity to human interference is as serious a problem as transactions being irreversible.”2 Consequently, one would be left with a bugged program unless programmers were capable of writing bug free programs first time, every time.

Where a smart contract has been coded with mistakes and executes, immutability also makes it difficult for one to obtain a remedy. Remedies in contract law often seek to restore the parties to their original, pre-contractual position and amend any damages incurred as a result of the agreement. There are several remedies available including rescission, injunction and damages. None of these would be readily available for a smart contract. A rescission seeks to restore parties to their original positions. However, a smart contract transaction cannot be reversed without the addition of a second smart contract. This makes restoring their position incredibly difficult and could even bar the remedy entirely as it may be deemed too difficult to return the injured party to their pre-contractual position. Similarly, an injunction to, for example, prevent one party from enforcing or violating a term of a smart contract may not be effective because the immutability of the smart contract makes any change such as a command for non-execution, almost impossible. The primary issue with an injunction is that:

“The smart contract is autonomous and self-executing. Unlike a non-digital contract, a smart contract is not capable of simply being ‘stopped’ instantaneously upon notification to the affected party that it must cease whatever activity is being prohibited by the injunction.” 3 

Providing rescission and injunction remedies in cases involving smart contracts will therefore prove complex. The situation is just as complex for damages claims, though the obstacles are different. It is not the immutability that is in the way but the anonymous nature of online contracting which makes it hard to track down the individuals involved.

Anonymity

The use of pseudonym and other methods that render the contracting parties anonymous to one another, makes it hard to ascertain with whom you are contracting. This could give rise to cases involving mistaken identity or misrepresentation if “a party contracts with another party on the assumption that the other party is who they say they are, when in actual fact they are someone else.”4 Parties who do not know each other are unable to enforce their rights in court because they will not know whom they are enforcing these rights against. Furthermore, to make a claim, the injured party would need to know the real identity of the opposing party, not who they claim to be. Where they can obtain a default judgment, it is still rendered useless with limited practical effect unless the identity of the other party was discovered.5   

Another issue arising from anonymity is whether the person with whom one contracts has the legal capacity to enter into a contractual relationship. Owing to the fact that:

“parties to a smart contract may, and indeed often will, be unknown to one another, there is a very real risk that a party who has attained the age of majority may inadvertently contract with a minor cloaked by the anonymity of the Internet. This threatens the enforceability of the agreement.” 6

Those who are of sound mind are said to have full contractual capacity under UK law. However, “in the case of minors and the mentally incapacitated, contract law seeks to protect such persons from the consequences of their own inexperience or inability.”7 There is a general rule that a minor (person under 18) cannot be bound by a contract unless it is to supply them with “necessaries” or where it is for the benefit of the minor. Hence, several contracts involving minors can be voidable – this means that it is not automatically rendered void but the party who is not a minor may decide to void the contract or affirm it. 

It is unlikely that a smart contract would be made for “necessaries” such as food or clothing, and if they were they would likely be rendered unenforceable as per the UK law relating to the contractual capacity of minors. 

Public Ledger

Smart contracts that execute on a blockchain are publicly available ledgers which any individual can gain access to at any time. This means that a major concern when dealing with smart contract implementation is privacy. Since there is a degree of transparency available with blockchain smart contracts, the idea of using one to establish a contractual agreement may prove quite unappealing for parties. Likewise, because each transaction is broadcast across a peer-to-peer network, there are privacy risks involved with smart contracts. Although contracting is done on a pseudonymous basis, where the identity of one account becomes known, the individual could be at risk. Even where the identity has not become public knowledge, one may employ identification techniques to discern the identity of the party.8 This potential lack of privacy will no doubt be a limiting factor on the potential for smart contracts to replace traditional contracts as confidentiality is a key component of legal contractual relationships. Though there are emerging blockchain networks that seek to preserve privacy, currently they are unable to support smart contracts as they exist on Ethereum.

The Ugly

As a concept, smart contracts are nothing new. Yet as a working program, they are far from complete. They are capable of much but may be incapable of overcoming their inherent difficulties. Several grey areas remain where one cannot say with certainty that they will be advantageous or not. These grey areas are broadly: certainty of terms, jurisdiction, and regulation. 

Certainty of Terms

The strict, unambiguous language of code presents several advantages for contracting parties. Using smart contracts, “parties can memorialise their intent using code just as they can with paper”9 and in doing so, infuse their contractual terms with certainty. Like many computer programs, smart contracts are codified using Boolean logic meaning that there is no ambiguity: “something either does or does not happen, is or is not triggered, as a result of the code. This varies significantly with traditional contracts where the requirement for nuance and interpretation is often present.”10 While this can positively impact the agreement due to a defined and certain, the lack of ambiguity could put smart contracts at a disadvantage compared to their traditional counterparts. 

Lack of certainty in legal agreements can be an advantage because it “enables both parties to adapt to changing circumstances without having to redraft the agreement. Developers fail to realise that in contract law, ambiguity is a feature not a bug.”11 Several provisions are purposely written quite broadly to allow interpretation which a smart contract would be unable to do. Additionally, the more terms one includes within a smart contract ultimately increases the risk of a coding error:

“As the number of errors increases in proportion to the number of lines of code, longer smart contracts would contain more errors.” 12

Despite the increased certainty code may bring, if there is an error within said code this alleged benefit is undermined. Yet some may nonetheless prefer the risk of coding errors to the vagueness posed by traditional contract. Therefore, the issue of rigid certainty versus open-ended ambiguity remains a grey area of smart contracts. It is likely that for a simple agreement where the parties would benefit from a pre-determined outcome, such as with Fizzy, then a smart contract would prove ideal.  In a situation where the party’s circumstances are liable to change however, the ambiguity of a traditional contract is arguably the better choice. It is consequently unclear whether the certainty of terms a smart contract can offer would be hailed as an advantage or disadvantage.

Which Jurisdiction?

As with most cross-jurisdictional traditional contracts, a potential problem arising from the use of smart contracts could be which jurisdiction governs the contract. When a traditional contract is employed, the parties typically agree to have the contract governed by the laws of one party’s jurisdiction. The same method could be adopted for smart contracts – revealing to the other individual which jurisdiction you are from will not sacrifice anonymity. If, however, the parties do not agree which jurisdiction governs the smart contract then it will be almost impossible to assign a jurisdiction to the agreement due to anonymity. Unless a party readily reveals their location, one cannot know which jurisdiction they fall under thus assigning one to govern the smart contract will be almost impossible. Where a claimant comes forward with an issue concerning a smart contract however, it may be possible to either use their jurisdiction to govern the contract or apply the decision in Entores v Miles Far East Corporation13 which held that, because a contract was entered into when acceptance by the offeree was received by the offeror, the contract would be subject to the offerors legal system. The lack of jurisdictional certainty can thus be a hindrance to smart contracts as they could give rise to issues concerning which law governs them.

To some, a smart contract’s lack of jurisdiction may appear to be their greatest weakness; to others it is their greatest strength. A smart contract exists not in the narrow scope of a legal document but within the universal language of code. They are neither bound nor limited by jurisdiction which affords them a much larger scope than a traditional contract. Furthermore, one may argue that “blockchains create a parallel transactional universe, or even their own jurisdiction, where the parties can transact outside of the legal system”14 which would “obviate the need for legal rules and institutions.”15 This is anarchic and to some radical, yet it raises the point that the lack of jurisdiction may not be a hindrance to smart contracts after all as they perhaps will not require one to function effectively. If this were the case, they would operate without legal rules which would likely render them illegal and could put an abrupt end to any hope of their application and use in UK contract law. Nevertheless, it is important to note that provided the code is universally capable of being read, the contract is capable of being executed without the need for the law to step in.

Regulation

The notion that the law is not required for smart contracts to function is a prominent view held by many advocates of the new technology. Yet for them to acquire a place and use within legal transactions they must be made in compliance with the UK law of contracts. At present, though they meet the requirements to be a contract capable of being legally enforced, UK contract law is ill equipped to govern smart contracts because there is nothing outlining what shall be done in cases where something goes wrong, for example, where the transaction has executed yet one party seeks to reverse the transaction due to alleged misrepresentation. How would the transaction be reversed? Would it be reversed? How would the court hold accountable an anonymous online party to a contract who may prove difficult to track due to the decentralised nature of blockchain? Additionally, there are no UK wide guidelines for their creation or use, what they should or should not include and whether they can be used in a variety of situations or if their use will be limited to one area of law (such as insurance law). Governing smart contracts may seem complex, yet it could potentially be not far removed from the provisions and principles of the current e-commerce regulations.

The Electronic Commerce (EC Directive) Regulations 2002 encapsulates the EU Electronic Commerce Directive 2000/31/EC into UK law and applies to contracts that are concluded by electronic means alongside distributed storage such as the cloud. Online service providers must act in compliance with the Regulations when dealing with customers in the UK or any other member states of the EU. They are required to provide the information that the Regulations have outlined to the party entering into an online contract and failure to do so may amount to breach of statutory duty.  Similarly, the terms and conditions under which the contract is formed must be made available to a party to the contract and must be capable of being reproduced or stored.17 

These Regulations may prove to be a good starting point for governing smart contracts, but much like UK contract law they provide no guidance on remedies, claims or solutions to issues that arise following execution. The UK therefore requires updated legislation or perhaps a parliamentary act dedicated to the use, creation and governance of smart contracts. In doing so, the UK would be amongst the first to implement law that facilitates possible digital advancements within the legal world. States in America have already begun the process of bringing smart contracts under their current law through creation of new Bills of Rights. Arizona is one such state who, in 2017, passed a Bill that recognises electronic signatures on the blockchain, and stipulates that:

“Smart contracts may exist in commerce. A contract relating to a transaction may not be denied legal effect, validity or enforceability solely because that contract contains a smart contract term.” 18

Though this statute effectively grants smart contracts legal weight, it does little to determine how one would regulate them. Regulation therefore remains a grey area even where such legislation exists as it is unclear how legal controls could be placed upon computer code, especially when in a decentralised manner. The question that the law faces is, ultimately, who or what can be legislated against? 

One method of regulation may impose laws on ‘end-users’ or those who are seeking to use the smart contract in an analogous manner as the aforementioned Regulations. A statute could be passed that outlines what one can or cannot use a smart contract for and, where an individual has used it in a manner that is illegal or unsavoury, they could be held liable. However, the problem with this form of regulation rests on anonymity which would make it difficult to bring actions against individuals who act in breach. This is “likely to be exacerbated in the context of blockchains, because of the technologies heavy reliance on encryption and other data protection techniques.”19 It may be more effective to impose vicarious liability on those who interact with undesirable applications facilitating unlawful activities – knowing you could get caught is one thing, but knowing that if you are caught you may be responsible for the actions of others could act as an even stronger deterrent.20

Alternatively, the UK could instead regulate internet service providers (ISPs). A smart contract exists in a digital medium such as a blockchain that likely requires internet connectivity to function. There is potential here as:

“The inherent transparency of blockchains means that ISPs can discern which computers are connected to a blockchain based network and, in some cases, even analyse the data being recorded to a blockchain…Governments could require that ISPs operating within their borders block data coming from and directed to a particular blockchain”.21

This would enable regulators to see which individuals connected with certain smart contracts and if it was for a malicious purpose access could be blocked by restricted internet. However, some may argue that this is excessive and a breach of their privacy due to what may feel like routine monitoring by the government. 

Perhaps the most promising option would be the regulation of the code itself. Smart contracts are nothing more than a computer program and because they “rely on code to define their operation, governments could choose to regulate how developers create blockchain based applications and smart contracts to influence how these systems are used and how these systems develop.”22 It is important for regulators not to undermine or attempt to impose strict limitations on the execution of smart contracts – focus instead should be placed on the code to ensure that it is in compliance with the law which means that the execution will also be lawful. If “code is law”23 then govern the code. 

Conclusion

Of course, other advantages and disadvantages of smart contracts, and indeed other even greyer areas are still to be resolved but the issues covered in this article highlight that smart contracts, in their current form, can resolve several problems associated with contract law. They are well suited to one-off transactions and improving the efficiency and fluidity of the contracting process. Furthermore, through the trust mechanism they can enable parties to contract without fear of non-performance by placing their trust not in people but in code. Yet they are far from perfect and arguably create almost as many problems as they can allegedly solve. Their immutable nature is a recipe for disaster, whilst anonymity and the use of a public blockchain ledger are certain to do more harm than good. Similarly, there are grey areas of smart contracts that one cannot conclusively determine because at present, it is not clear based on the information available whether there will be a simple solution.  

As it stands my view is that smart contracts simply cannot operate with certainty under the current UK law of contract. Their use within the UK will be limited, therefore, until the problems have been dealt with sufficiently and the grey areas (specifically regulation) are no longer ugly but have fallen conclusively on the side of the good or the bad. 

 

Rachel Goss is a Masters student at Queen’s University Belfast where she is researching the potential impact that emerging developments may have on contract, corporate and copyright law.

Footnotes

1 Mark Giancaspro, ‘Is a ‘smart contract’ really a smart idea?’ (2017) Computer Law and Security Review 33, 825-835

David Gerard, Attack of the 50 Foot Blockchain (CreateSpace Independent Publishing Platform 2017) p105

3 Mark Giancaspro, ‘Is a ‘smart contract’ really a smart idea?’ (2017) Computer Law and Security Review 33, 825-835

4 ibid 

5 Primavera Di Filippi and Aaron Wright, Blockchain and the Law (HUP 2018) p85

6 Mark Giancaspro, ‘Is a ‘smart contract’ really a smart idea?’ (2017) Computer Law and Security Review 33, 825-835

7 Ewan McKendrick, Contract Law (11th Edition, Palgrave 2015) p287

8 See Primavera Di Filippi and Aaron Wright, Blockchain and the Law (HUP 2018) p83

9 ibid p79

10 Paul Catchlove, ‘Smart Contracts: A New Era of Contract Use’ (2017) Available at https://papers.ssrn.com/sol3/papers.cfm?abstract_id=3090226 Accessed 3/1/18

11 Eliza Mik, ‘Smart Contracts: Terminology, Technical Limitations and Real World Complexity’ (2017) Available at https://papers.ssrn.com/sol3/papers.cfm?abstract_id=3038406 Accessed 20/11/17

12 ibid 

13 [1955] 2 QB 327

14 Eliza Mik, ‘Smart Contracts: Terminology, Technical Limitations and Real World Complexity’ (2017) Available at https://papers.ssrn.com/sol3/papers.cfm?abstract_id=3038406 Accessed 20/11/17

15 ibid 

16 The Electronic Commerce (EC Directive) Regulations 2002, Regulation 9 (1): “Unless parties who are not consumers have agreed otherwise, where a contract is to be concluded by electronic means a service provider shall, prior to an order being placed by the recipient of a service, provide to that recipient in a clear, comprehensible and unambiguous manner the information set out in (a) to (d)”.

17 ibid at (3): “Where the service provider provides terms and conditions applicable to the contract to the recipient, the service provider shall make them available to him in a way that allows him to store and reproduce them.”

18 State of Arizona HB 2417

19 Primavera Di Filippi and Aaron Wright, Blockchain and the Law (HUP 2018) p176

20 ibid 

21 Primavera Di Filippi and Aaron Wright, Blockchain and the Law (HUP 2018) p177

22 ibid 

23 Lawrence Lessig, Code and Other Laws of Cyberspace (Basic Books 1999)

Published: 2019-08-01T14:00:00

    Please wait...