Jelena Madir is the Chief Counsel of the European Bank for Reconstruction and DevelopmentThe EBRD is a multilateral development bank, which invests in Central Asia, Central Europe, and the Baltic states, eastern Europe and the Caucus, shut-eastern Europe, the southern and eastern Mediterranean and Turkey In some ways, developing countries are more likely to employ new blockchain technologies, and smart contracts in particular, to advance their financial systems than their developed counterparts. Pragmatism is a driver: While in developed economies, the efficiency levels of the existing financial system are perceived to be acceptable and therefore massive overhauls are not seen as needed, by contrast, in developing countries, the perspective is that since there are high levels of inefficiency, a massive overhaul is the only way forward. In fact, the governments in many of EBRD’s countries of operations have shown willingness to experiment with solutions and undertake transformative initiatives. For example, both the National Public Registry of Georgia and the e-Governance Agency of Ukraine have been working on introducing blockchain-based smart contracts in real estate transactions, while the National Bank of Belarus is considering facilitating the use of smart contracts in banking transactions. Yet the term “smart contract” is not uniformly defined or, for that matter, well understood. The first thing many people think of when they hear the term “smart contract” is a contract that is somehow transposed into computer code and runs without any human intervention. This misses the mark by a wide margin. However, smart contracts are better thought of as “conditional transactions” because they refer to the logic written in code that has “IF this, THEN that” conditions. For example, it can easily be programmed in a smart contract that “IF on 1 October 2020, Bank A does not receive GBP 1,000 from Jack, transfer GBP 1,000 from Jack’s account to Bank A’s account.” In order to help lawmakers and regulators in EBRD’s region inform appropriate legal, policy, and strategic responses, the EBRD’s Legal Transition Team (LTT), together with Clifford Chance, published a report on Smart Contracts – Legal Framework and Proposed Guidelines for Lawmakers. In it, we show, among other things, that smart contracts may be particularly effective for sectors of the economy or in situations that operate using highly standardised contractual terms and agreements with clear conditions and repetitive transactions. For instance, a smart contract could entail a loan agreement encoded so that the software automatically triggers a monthly loan repayment when the software receives an input confirming that it is the last day of the calendar month (i.e., without the need for human intervention or instruction) or so that the software automatically changes the monthly repayment amount where it receives an input confirming that there has been a reduction in the relevant reference interest rate (e.g., a central bank interest rate) – in each case the conditions can be objectively determined. This is illustrated in Figure 1 below: Parties A and B enter into a smart loan contract. The software is programmed to receive inputs from trusted data sources via an oracle and to automatically generate payment instructions based on those inputs, in accordance with the terms of the smart contract. When the smart contract receives an input that it is the last day of the month, it uses the interest rate input to calculate the correct monthly repayment amount under the smart loan contract. Then, the software automatically sends an electronic instruction to Party A’s bank to transfer this amount from Party A’s bank account to Party B’s bank account. Party A’s bank acts on the automatically generated instruction and transfers the payment to Party B’s account.
Figure 1: Blockchain-based smart contract Source: EBRD and Clifford Chance: Smart Contracts – Legal Framework and Proposed Guidelines for Lawmakers Another example of a potentially smart deployment of smart contracts could entail real estate; Consider an hypothetical sale of a house on the blockchain: to facilitate the transaction after the buyer and the seller have executed the sale agreement, the buyer transfers the deposit amount to be held in escrow by the smart contract. In turn, and immediately prior to settlement, the lender can also send the loan amount to the smart contract escrow. After the total purchase price is sent to the smart contract escrow, the seller may finalise the transfer and trigger the smart contract to disburse the funds to its account and transfer the tokenised house to the buyer. The transfer is recorded on the blockchain and the state of title ownership is updated. There are a few key critical assumptions in this example: First, the house has been tokenised, which means that a blockchain token has been associated with the house. Despite media headlines about house sales on the blockchain, there are a number of legal and technical challenges that need to be overcome for this to happen. Second, the transaction does not involve anything more than a simple transfer of property, free from encumbrances, between two parties. This is rarely the case in practice. In contrast to the above examples, which include conditional “if this, then that” logic, with or without external inputs, conditional clauses requiring an assessment to be conducted “to the satisfaction” of a contracting party or to take action “in a commercially reasonable manner” are unlikely to be automated. These elements require a subjective assessment of the individual circumstances and it may be difficult to express the relevant circumstances in software language or to automate them. For instance, code could be used to represent the agreement that, if an event happened, the price will be adjusted by subtracting the product of x and y. However, it is unlikely that code can be used to represent that, if an event happened, the price is to be adjusted by the party in a commercially reasonable manner. Similarly, clauses that do not contain conditions, but merely determine arrangements (for example, clauses stipulating governing law or jurisdiction) can be encoded, but may not be automatable because they have no conditional logic. The spectrum of automatability of contractual clauses can be represented in the following schematic:
Figure 2: Spectrum of automatibility of contract clausesSource: EBRD and Clifford Chance: Smart Contracts – Legal Framework and Proposed Guidelines for Lawmakers Does a smart contract even constitute a valid, binding and enforceable contract? How do you ascertain that your counterparty is authorised to enter into a smart contract? If code performs in a way that the parties did not expect, what remedies will they have and against whom? If not addressed, these types of issues could prevent or slow down the widespread adoption of smart contracts. And they are not in themselves issues for seamless cross-border coding among developers. Indeed, the very determination of whether a smart contract constitutes a valid, binding and enforceable contract will depend on the elements that need to be present in the relevant jurisdiction for a contract to exist in the legal sense (e.g., (i) offer and acceptance, (ii) consideration, (iii) intention to create legal relations, and (iv) certainty of terms under English and US law; or (i) consent through an offer and acceptance; (ii) object of the obligation, which must be determined or determinable, and (iii) cause of the obligation (similar to consideration) under French law). So, for example, under English law, e-mail messages are considered to be capable of constituting offers and acceptances. And because smart contracts are typically initiated by messages sent using PKI over the internet, it would therefore be surprising if English courts were to draw conceptual distinctions between such messages and email communications. But under US law, “[a]n offer is an expression by one party of his assent to certain definite terms, provided that the other party involved in the bargaining transaction will likely express his assent to the identically same terms.” Smart contract code used on a distributed ledger is therefore likely to constitute an offer only if other participants on the ledger are entitled to interact with, and execute, the code. You would then proceed undertake a similar analysis of each of the constituent elements of a contract. Similarly, determining whether the counterparty signing on behalf of a company has the authority to enter into such contract will be possible only if the software deployed in the smart contract is sophisticated enough to parse the data contained in relevants documents to be able to establish whether a specific person is authorised to enter into a specific type of transaction on behalf of the company. This in turn would require coding sufficiently robust to scrub the relevant data sources (e.g., a company registry setting out the relevant information on the company and its authorised signatories, as well as other signature authorisation documents of the company). If sufficiently intelligent, the software might be able to access and parse a board resolution or a list of directors itself. Otherwise, the software may simply seek an input confirming that the resolution was duly passed or that the person “signing” the smart contract and purporting to have the authority to do so does in fact have such authority. While it is not possible to summarise the entirety of our legal analysis and recommendations as to the legislative framework for the use of smart contracts in any particular jurisdiction, our ultimate view is that lawmakers should assess whether their existing laws adequately accommodate the use of smart contracts and whether certain amendments might be desirable. This process should be one that begins with an evaluation of the robustness of a jurisdiction’s domestic laws in accommodating electronic identification more generally, and via cryptographic keys, more specifically, and then evaluates record and storage-keeping requirements and accompanying third-party (government) involvement. Fintechpolicy.org readers can access the full study and the accompanying animated videos at: www.ebrd.com/documents/pdf-smart-contracts-legal-framework-and-proposed-guidelines-for-lawmakers.pdf And https://www.ebrd.com/news/video/distributed-ledger-distributed-liability.html, respectively.