Blog Authors: Charles Maurice, Partner and Daniel Fournier, Paralegal – Stevens & Bolton LLP
Smart contracts – fruit of the nascent distributed ledger technology – are an emergent disruptor to the legal landscape, but what are they and how do they fit in with traditional contracts?
You might be forgiven for thinking that contract law in the UK is neither modern nor smart: after all at times we still rely on legal principles handed down in judgments from the Victorian era and earlier. However, the rise of distributed ledger technologies has been largely responsible for the introduction of a new phrase into the legal lexicon – the “smart contract” – “a legally binding contract in which some or all of the contractual obligations are defined in and/or performed automatically by a computer program.”[1] This definition has been provided by the Law Commission, in its paper on smart contracts published in November 2021, itself the culmination of research into whether the UK’s common law system is well-equipped to deal with smart contracts (more of which below).
Automated contract performance is not a new thing, at least conceptually. Plenty of contracts are conditional upon and/or are expressed automatically to come into force on certain outcomes or the performance of certain tasks. However, automated contract performance wholly or partially based on code takes this to a new level (a program actually doing something vs a piece of paper telling us it will happen), and raises interesting possibilities around efficiency, transparency and reliability.
So what do we mean by this? A smart contract written in machine executable code allows a given program to execute obligations within a contract automatically once the conditions to that contract have been fulfilled (i.e. to simplify: if “X” happens, then do “Y”). In practice, the parties to the agreement negotiate the terms, which are then transposed into code, and which can be (but are not always) accompanied by natural language clauses – it is perfectly possible to have a smart contract acting as an execution mechanism for a particular part of a wider natural language contract.
Due to their inherent transparency, smart contracts can reduce the importance of trust between parties. Generally the self-executing obligations in a smart contract are stored on distributed ledgers (such as a blockchain), which are designed to be difficult to alter without the consent of the other party. Therefore, once agreed and in force, the smart contract is designed to continue to do its thing without further intervention. Common applications for smart contracts include supply chain management, banking transactions, customer verification, peer-to-peer transacting and other repetitive tasks, although there is increasing potential for them to be used in more complex agreements. One practical example that we have implemented is to “hard bake” artist royalty payments into the onward sale of NFTs – particularly useful where the seller is not the artist itself. In that sort of application, the smart contract for the NFT might include a pre-defined royalty payment, automatically paying a percentage of any onward sale of the NFT by a third party into the artist’s crypto wallet. The idea too is that this type of arrangement requires little policing, particularly if the arrangements are accurately described and appropriate control is maintained over the marketplace and crypto wallets used to make a sale: once a sale happens and value is exchanged, the royalty is automatically paid without the need for buyer or seller to do anything (or any ability to stop it).
All good so far, but this does raise some challenging questions for the contract lawyer, including whether we are expected to be able to write code (an area to upskill, but we also work with people who can); how we can identify when a smart contract is appropriate (the list of use cases is ever-growing); whether we need to understand how the smart contract fits together (we do); and whether the code itself is binding (yes, it can be).
Turning back to our friends at the Law Commission, their view is that the UK’s common law system is well-equipped to deal with smart contracts. However, this view is accompanied by recommendations on how best to ensure that a smart contract forms a binding contract from a traditional contract law perspective, including that parties: (i) distinguish which definitions prevail in the event of a conflict, if expressed in both natural language and code; (ii) provide a jurisdiction and choice of law clause; (iii) allocate the extent of liability in the event of bugs or coding errors; and (iv) provide an explanation in natural language to accompany coding, while making clear that the explanation forms part of the contract.
An interesting point arises too with regard to interpretation of coded terms. The courts have developed principles of interpretation in relation to natural language; it is unclear whether they will easily apply to terms in code. The Commission has propounded a test whereby an expert coder could assist the court in ascertaining the meanings of coded terms – a “reasonable coder” test. Additional uncertainties will doubtless arise as the use of smart contracts continues to increase, particularly in relation to conflict of law issues. The government has asked the Commission to set out further guidance on conflict of laws and emerging technology, and this work is expected to begin in the first half of 2022.
As the digitisation of contracts continues, smart contracts may feature as part of that, particularly for certain applications where automated contract execution is relevant. The construction industry may pick up on the benefits of this in due course, particularly for example as Building Information Modelling (BIM) takes hold in larger construction projects, where it is possible that smart contracts will have a role to play as concept progress.
This article was originally published by Stevens & Boltons LLP on their website. To access the original please click here.
[1] Smart legal contracts, Advice to Government, CP 563, Law Com No 401, vii