A key concept underlying many uses of blockchain is that of the smart contract. It is often said — not without some justification — that smart contracts are neither smart nor contracts. Nevertheless, we have chosen to put them at the start of our discussion of blockchain and law rather than at the end of our discussion of blockchain as a technology.
Smart contracts
Smart contracts are generally said to have been first defined by Nick Szabo in 1994 as “a computerized transaction protocol that executes the terms of a contract,” that would aim to “satisfy common contractual conditions … minimize exceptions both malicious and accidental, and minimize the need for trusted intermediaries” as well as “lowering fraud loss, arbitration and enforcement costs, and other transaction costs.” It is worth pointing out that smart contracts were thought of some time before blockchain (as can be seen from the date of Szabo’s definition), and that they can exist entirely independently of blockchain. But they are perceived as a good fit for each other: proposals for the use of smart contracts have multiplied considerably in the context of efforts to reinvent various forms of business activity around blockchain-based processes.
A traditional contract records the arrangement between parties in written legal form. A smart contract replaces the traditional written agreement using executable computer code both to record that agreement and to automate its own execution to some extent, for example by transferring payment or property. It can be thought of as a high-tech version of the principle behind a vending machine (if the correct coins are inserted into the slot, tip the bottle of water into the trough; if the bottle will not tip, or if there are no bottles, return the coins) but, it is to be hoped, with more consistent results than such machines sometimes produce without recourse to physical violence by the customer. Some smart contracts use blockchain technologies for payment and audit trail functions. Ethereum, which describes itself as a “global, open-source platform for decentralized applications” is particularly associated with the running of smart contracts.
How smart is smart?
In theory, a smart contract should require no management, will monitor its own performance and can create whatever audit trail is required. In practice, we are only at the start of the process of automating contractual relationships in this way, and most “smart contract” systems are likely to involve a significant traditional legal drafting / human intervention element for some time to come.
In the long run, the possibilities for streamlining back and middle office processes in terms of cost, speed and availability are potentially enormous. One area of particular interest is where the performance of a contract takes place over a period of time and involves the collection of data, and there is a value in the parties having a shared record of that data because it has a direct impact on what happens next between the parties under the contract. This aspect of smart contract functionality is well captured in an introductory video produced by legal tech developer Clause, in which Dentons’ legal tech accelerator, Nextlaw Labs, has invested.
However, in practice, a number of factors may limit where and how smart contracts may be deployed.
- One potential limiting factor is whether an agreement that is both legally binding and practically useful can be formed and/or operated without intentional human intervention. English contract law, for example, starts from the assumption that a contract embodies the intentions of two or more parties, and many contracts are designed to deal with a range of possible situations in which the parties may find themselves by allowing one or other of them to choose between different options. Smart contracts, as generally conceived, are not actually very “smart”. They are not artificially intelligent or examples of machine learning: they are designed to bring about a particular outcome every time a specific condition is exactly fulfilled (“if X, then Y”), and will not necessarily readily accommodate reference back to the human decision-makers involved at critical junctures (“if X in form reasonably acceptable to the Seller, then Y”). To the extent that they involve such reference, much of the point of automating the contract may be lost. At the very least, parties may wish to agree in a conventional contractual framework how the automated system will operate. Such a framework may be as important for identifying the parties with whom each participant is prepared to enter into smart contracts as for supplementing their terms. Legislation governing the form or terms of particular types of agreement may also be a barrier to the deployment of smart contracts, particularly those involving individual consumers.
- Another set of limitations relates to the extent to which coding can do the job of conventional legal drafting. For example, while there are already smart contracts that can automate a transfer of title when a particular condition is met (such as payment), the coding would be unable to address the richer context and subjectivity that might be included in or underpin many traditional contractual provisions. It is difficult to address issues such as “satisfactory quality” or “reasonable endeavors” and nearly impossible to deal with issues relating to the broader context of the transaction such as frustration. Work commissioned by ISDA in this area points to non-operational provisions in a contract (such as those on governing law and jurisdiction) as areas where the conditional logic on which computer programs run is less likely to work.
- Automatic execution and the immutability of blockchain mean that, if a result that the parties do not want has occurred, they may have no alternative but to unwind it by a separate conventional contract — always assuming that they share the same view of what the “correct” result should have been. The combination of immutability and the need to achieve consensus across a large network of participants can also create difficulties in addressing bugs in a smart contract program. In at least one well-publicized case (The DAO ), this seems to have contributed to a situation in which a hacker was able to steal US$50 million.
- Although some smart contracts will be self-sufficient in the sense that all the data that they need to operate will come from within the blockchain, many will require external data inputs—information about what is happening in “the real world”—to trigger their operation. The software agent program that provides such external data is known as an “oracle”. However secure a blockchain and its associated smart contracts may be in themselves, because an oracle by definition interfaces with external data, separate steps will need to be taken to ensure that the data concerned is accurate and that the oracle is not being manipulated. To put it another way, the “trustless” automated system of smart contracts will still often require users to trust humans when it relates to the physical world.
- A related point is that, where sale and purchase are concerned, a smart contract will be better placed to self-execute when execution essentially only involves the transfer of title by making an entry in a register or—to the extent that physical delivery is involved— movement of goods through a more or less automated network such as an electricity grid.
There is much work still to be done before smart contracts become a generic or commoditized product. It seems unlikely that we are about to enter a world in which machines form and perform legally binding agreements without human intervention or the existence of an underlying conventional contractual framework. Overall, it seems unlikely that significant commercial blockchain applications of smart contracts will arise unless they are underpinned by a conventional contractual framework that deals with those aspects of the legal relations between participants that are less apt to be coded and automated and embodies the agreement of the human (or corporate) participants to abide by the rules of the smart contract game for those that are suitable for coding and automation. But the partial automation of some aspects of existing contractual relationships could become commonplace in areas of commercial activity where there are no regulatory barriers and the subject matter lends itself to standardized treatment, such as certain types of commodity trading.
Blockchain, cryptocurrencies and smart contracts: the legislative and regulatory agenda
There has so far been relatively little done in any jurisdiction by way of systematic legislative or judicial consideration of blockchain, cryptocurrencies or smart contracts. There are some notable exceptions to this, but these are often fairly limited in scope.
In the US, the Report of the Joint Economic Committee of Congress on the 2018 Economic Report of the President devotes an entire chapter to the implications of blockchain in a number of policy areas, with some particularly interesting comments on taxation and money transmission.
At state level, measures have been enacted or proposed with a view to facilitating the use of blockchain and/or smart contracts in Delaware, Arizona, Nebraska, Tennessee, Wyoming, Illinois and California.
In the UK, the UK Jurisdiction Taskforce of the LawTech Delivery Panel issued a Legal Statement on Cryptoassets and Smart Contracts in November 2019. The Taskforce was chaired by Sir Geoffrey Vos, Chancellor of the High Court, and its statement offers authoritative (although not judicial) commentary on a number of key questions about the application of English law to the world of smart contracts.
The application of laws regulating the public offering of securities as it applies to ICOs and token sales is a topic that has received some attention but, although most White Papers and announcements of ICOs do their best (with varying degrees of finesse) to put themselves outside the scope of any applicable securities regulation, the issue remains live.
- The SEC’s report of an investigation into The DAO is a good example of a regulator more or less successfully applying existing statutory provisions that were drafted long before anyone had dreamt of blockchain to consider the lawfulness or otherwise of the activities of one of a supposedly completely new category of Decentralized Autonomous Organizations.
- Also noteworthy in this context are the ICO Guidelines promulgated by the Ministry of Finance in Lithuania. The guidelines suggest that tokens that grant rights such as participation in company management, receiving a share of profits, income or interest on funds invested, or the ability to recover such funds and receive additional income through redemption of the tokens, are likely to be considered as securities. As such, they may be subject to a range of regulations, including laws on securities, crowdfunding, money-laundering, collective investments and markets in financial instruments. Many of these are governed by EU-wide regimes and so are of relevance beyond the vibrant Lithuanian blockchain scene. The guidelines also make some important points about the tax and accounting treatment of tokens.
- A survey published in 2018 highlighted a number of jurisdictions where ICOs were prohibited or significantly restricted. China was prominent among jurisdictions that took action to curb ICOs in 2017.
The relatively limited amount of legislative provision or regulatory action specifically applicable to blockchain to date means that to work out how to use any of these technologies to support any particular commercial model from a legal point of view one needs to go back to basics to try to analyze how existing legal concepts and rules can be applied to them. We sketch out some starting points for such analysis below. Such analysis is both the necessary precursor to any serious legislative or regulatory intervention and an essential step in the commercialization of any significant blockchain project that is not supported by a comprehensive regulatory framework.
Blockchain and contracts: an energy sector perspective
By way of example, we set out below a non-exhaustive list of ways in which blockchain and smart contracts could be deployed by parties in energy transactions (taking separately steps such as contract formation, record of contract, performance, validation of performance and settlement).
- Two parties enter into a transaction in a conventional way, and record the transaction using blockchain. The parties will then still perform the transaction in whatever is the relevant way.
- Two parties (by their actions at the time) enter into the transaction using blockchain as a platform on which one of them offers the transaction and the other accepts the offer.
- The transaction is made using blockchain, without any action at the time by the parties, based on the fact that pre-specified conditions are satisfied at the time. Contractually, this could be characterized either as the implementation (upon satisfaction of the conditions) of a contract already entered into or as the creation of a contract on the basis that the occurrence of conditions amounts to acceptance by one party of a standing offer by the other.
- A transaction is made, between two or more parties, as part of a wider scheduling or system management function using blockchain, for example optimizing power flows on an electricity distribution network on behalf of (or even instead of) a distribution system operator. This implies a multiparty contract, with complex and potentially layered or sequenced “trigger” conditions; it will raise questions of interdependency of transactions, and transparency and validation of the conditions (which of course may also be solved in the blockchain).
- The transaction is not only entered into, but is also performed, by an operation using blockchain (where performance is “dematerialized”). An example would be giving notification to a market operator of an energy transfer within a balancing regime (such as an “energy volume contract notification” or “NBP trade” within the British power and gas markets). As well as the issues of contract formation, there is an inherent agency relationship to be created here (with the relevant market operator).
- Alternatively, the transaction is physically performed on an automated basis, for example by the technology remotely directing the operation of valves or switching equipment to implement a contracted energy flow.
- Performance of the transaction is assessed / verified by blockchain, for example on the basis of meter readings / allocation statements / other performance data being directly fed in. This could extend to the implementation of financial adjustments / remedies where performance deviates from what was contracted for.
- The transaction is financially settled using blockchain, i.e. payment by one transaction party to another is made automatically upon the transaction being created, or upon its being performed. This may be done using either fiat or cryptocurrency; and credit risk may be managed by prepayment arrangements (a sufficient credit balance for the paying party being one of the conditions to transaction formation).
- The transaction is made and performed (or performance assessed) simultaneously using blockchain—in effect a combination of some of the above points. An example would be where the trigger for a transaction is a meter reading, so that the energy flow which the transaction concerns has already occurred and been measured at the time the contract is formed. This could be seen as effectively an option, which is exercised by the outturn result of its subject-matter.
No doubt there are other possibilities and in many cases a combination of the above will apply. Aside from the basic question of what contract framework is required to underpin or enable these blockchain-based transactions, they raise other contract law issues in areas such as how they interface / interact with other “external” contracts; cross-default; the timing of transaction formation and insolvency issues; the basis on which parties can withdraw from or modify contingent commitments; nature and definition of contract breach; suitable force majeure definitions; and remedies, penalties and mitigation where contract outcomes for breach are “automated.”
The above is only an outline sketch of issues, but it suggests that, when establishing a new blockchain venture, the participants, as well as having to think hard about the kinds of issues that always take up a fair amount of negotiating time in any complex commercial project, may have to spend some time re-thinking some quite basic contractual concepts in order to embody their business model in a robust legal framework.
Blockchain: other legal considerations
Contract law is, of course, not the only area of law where careful thought is required when considering a blockchain project.
Blockchain began as a system for supporting the issue of, and transactions in, a new form of currency which exists within the blockchain itself. If blockchain is to be used as evidence of or a means of transferring the ownership of or entitlement to things that exist in the “real” world outside the blockchain, a supporting framework of law is required to mesh with the code. Up to a point, a group of businesses that are operating in a jurisdiction that generally allows parties freedom as regards the substantive provisions of contracts can agree “rules of the game” that may form a self-sufficient system—in which, for example, it is agreed that digital transfer of a token confers ownership of a specific physical asset on the transferee. However, even in that case, participants would need to consider whether there are circumstances in which, in order for their project to be fully effective, they will need third parties, who have not agreed to their rules, to take notice of, and modify their own behavior in accordance with, for example, property or other rights as recorded in a blockchain.
Any new project will obviously need to be carefully analyzed against applicable intellectual property and data / privacy law. For example, under the EU’s General Data Protection Regulation (GDPR), businesses can face heavy penalties for non-compliance with rules on the processing of (broadly defined) “personal data.” Blockchain applications that fall within the scope of the GDPR—perhaps particularly those based in the EU or aimed at individual EU consumers—will have to grapple with the fact that GDPR was designed with centralized rather than decentralized networks in mind. Suggestions have been made as to how the GDPR could be interpreted so as not to stifle blockchain-based business models involving individual consumers and how projects could be designed so as to comply with it. But, as the regime is still fairly new, it is likely to be some time before there is any authoritative ruling on how it applies to the handling of personal data in a blockchain context.
Competition law is another area to watch in the development of blockchain projects. One of the potential attractions of many blockchain business models is greater market liquidity and transparency, but participants and antitrust authorities alike will need very robust assurance that such transparency does not include commercially sensitive information about prices, for example, being visible to others in a way that could dampen competition. At the same time, in any sector where blockchain platforms come to account for a substantial part of the market, there will be either a single dominant platform or a number of competing ones. Any platform or group of platforms that occupies a dominant position will need to ensure that there is nothing in its structure or behavior that tends towards abuse of its market power in relation to either customers or competitors. On the other hand, where a number of different platforms provide similar functionality, care will need to be taken to ensure that participants are neither prevented from participating in more than one platform nor unfairly disadvantaged if they do so (questions of interoperability, for instance, will need to be considered in this context). Principles of antitrust analysis developed in cases relating to credit card providers and other “two-sided markets” may be relevant. The OECD has produced an issues paper on blockchain and competition policy identifying a number of possible areas of concern.
The idea of being in a position to raise antitrust concerns might seem like no more than a “nice problem to have” for many of today’s blockchain startups. But it may be better to address potential competition law issues from the outset, rather than be forced to modify a business model by a competition authority, or legislative action, at a later stage when there could be much more at stake. After all, if blockchain fulfils its promise, some platforms are likely to grow very quickly, and they will do so in an environment in which competition authorities have become more sensitive to the potential downsides of a variety of online and technology based business models.
