Hosted by Barclays and blockchain technology company R3CEV LLC, which leads a consortium of more than 40 global financial services companies, the event, held simultaneously in London and New York, was attended by 35 experienced attendees including, investment banks, ISDA, FIA, UCL’s computer science unit, amongst others.
Smart contracts, which were defined at the summit as being agreements whose execution is automatable and enforceable, present great opportunities for increased efficiency and security in legal and financial transactions. With these opportunities, comes an array of challenges, which were discussed by the roundtable participants. Below, we summarise the key themes arising from the summit.
Interoperability – standardisation of language, templates and underlying technology
There was a strong emphasis on the importance of interoperability between smart contracts and their supporting technologies. A key challenge that was recognised was the development of a ‘domain-specific’ language, which would be both capable of legal expression whilst also carrying code to be electronically executable. The challenge here is to address the multiple separate ledgers and systems being developed by the different financial institutions, which will breed inefficiency through duplication and incompatibility. To address this challenge, there was general agreement that increased communication and cooperation through shared ledgers would be required. The general benefits identified were reductions in cost and risk, as well as an improvement in efficiency.
A proposal to remedy this problem was through a uniform approach, which could be achieved through common terminology and standardised template documentation. This could, for example, be started by leveraging the ISDA library which could provide a suite of templates, designed in FpML (Financial products Markup Language), increasing efficiency and promoting consistency.
This could potentially tie in with the idea of setting parameters within coded smart-contracts; values which are negotiated before being populated into the contracts 'terms', and a hypothetic future where prose and code can 'bind' together, and coexist (something that is already being progressed through the Common Language for Augmented Contract Knowledge). All in the context of Ricardian Contracts, which seek to bridge this gap between the prose and code – through these was general acknowledgment around the difficulties faced in attempting to simplify legal prose to be reduced to bytes that can be used electronically, especially under existing legal principles across introductions.
Legal interpretation, formalities and practicalities
There was some discussion of the spectrum of a smart contract’s definition, from a ‘code is contract’ model that fully encodes contractual agreements, to the automation of the performance of aspects of traditional contracts, and challenges were identified with each of these.
- Interpretation of terms – In addition to the construct of the language used in smart contracts, and the transposition between legal prose and its electronic code (as discussed above), the language of a contract, in terms of its meaning and interpretation, also poses a challenge to smart contracts. A key issue which challenges the ‘code is contract’ model, is that the nuances of a contract's obligations cannot currently be contained entirely by code; the contract is ultimately what the law says it is, and there will invariably be terms implied into the agreement, not by code, but by legal statute, or through the conduct of the parties. Even in less comprehensive agreements, where certain elements are automated, there is the issue of ambiguity around the triggers and conditions of performance of contractual obligations. Phrases such as ‘best endeavours’ or 'as soon as practicable’ were highlighted as key pitfalls in this respect. A key risk that was noted was that of unintended consequences – this is more prevalent in a code is contract model where full automation (without a kill switch operated, for example, by private parties and/or a regulator or government could have significant financial stability implications.
- Formalities – A further challenge in the adoption of a contract, set out entirely in code, might arise from the formalities of a jurisdiction’s contract law – for example, the principle of offer and acceptance, consideration and certainty of terms, which determine the existence of a legal contract in the first instance under English law, might be less easily satisfied. Another problem may lie in the signing of certain documents, for example the electronic equivalent of executing documents by way of a deed.
- Practicalities – Automatically processed contractual provisions are not only reliant on predetermined values of set parameters, but also on reference points provided by external data sources. Such information might be determinative of a clause in a contract being triggered, for example a stock reaching a certain price, or the passing of a certain date. In this instance, smart contracts become less smart as time passes. Long-term or irrevocable smart contracts would be susceptible to issues due to a determinative data source (e.g. a pricing index) ceasing to exist. Alternatively, laws or sanctions critical to the contract's provisions, or affecting its performance, might change. These exemplify clauses of contracts which would demand greater agility in the technology that underpins them.
Accordingly, it was agreed that at present we are at the smart processing end of the spectrum, where parts of a contract or process could be automated. Such a "split contract” model, would allow identifiers within a natural language contract to be coded with smart-contract parameters to permit a certain degree of automation. This would be supported by wrappers within automated contracts as fall-backs in the case of the primary code construct failing.
Enforceability and regulation
Matters of enforceability extend beyond the construct of smart contracts satisfying the formalities of a jurisdiction's contract law principles. Automation and encoding of contractual terms will not make them immune to litigation or scrutiny by the courts; this poses jurisdictional challenges, requiring agreement over the relevant governing law and the courts responsible for settling disputes arising out of the smart contract. This could be particularly difficult where the contract is silent on such issues, and this could present particular difficulty to existing agreements which become “on-boarded" to smart-contract templates in the future.
A further concern is that of the regulators’ approval. Though the UK’s Financial Conduct Authority has been proactive in its engagement and encouragement of innovation in the financial services sector, (see our articles on the Regulatory Sandbox, RegTech Roundtables and RegTech: FCA Call for Input Findings) the implementation of smart contract technology is still very much in its infancy, as is the acceptance of an accredited standard of technological solution. Aside from financial regulation, a meaningful adoption of smart contracts by the legal industry may be reliant on similar engagement, or at least acceptance, by each jurisdiction’ regulator’s (for example, the UK’s Solicitors Regulation Authority), who have to date remained silent on the issue.