On smart and not-so-smart contracts

I had the honour of chairing the table on smart contracts at yesterday’s Unconference organised by David Birch (thanks David! great event!) and I wanted to take the opportunity to write up some of our conclusions here.

We first tried to get some of our definitions and semantics straight to ensure we were all talking about the same thing: a contract is driven by the intent of two business people to agree on a certain set of actions (‘outputs’) depending on the uncertain states of the world.

Traditionally this contract is first formulated in essence by business people — eg orally, or more formally in documents like ‘Heads of Terms’.

Traditionally, in the second step, lawyers would be brought into the picture to create the contract which really is meant to be a codification of the intent of the two contracting business party. The word codification is chosen deliberately here because it is semantically similar to the word code, and to some extent this is what a contract is: it is some kind of formal code that is written in a specific programming language (we might call it ‘legalese’) that — like other programming languages — is similar to but distinctive from the English that is spoken in everyday use. This programming language is operating on a runtime, which is the extended legal system of the country under whose law the contract was written.

Given this build-up, it is clear what is coming next: a “smart contract” is mutatis mutandis the same thing, just that is is created by bona fide programmers instead of lawyers, and that it is executed on some smart contract runtime, for example a blockchain.

However, this is not complete picture: whilst in some edge case (anonymous participants, executed on some distributed runtime with no clear jurisdiction) the ‘smart contract’ is all there is, in the cases that are interesting for business, the smart contract is executed within the regular legal framework of the environment in which they are operating.

This brings us to a well known issue in the legal world where contract documents are written in two languages. Of course the idea is that the documents in all languages are the same, but to the extent this is not the case the tie is broken that one document is declared the master document that prevails in case the a discrepancy occurs.

I want to take a short break here to relay a story I have heard at the “99.9% Club” INSEAD event I attended a few years back (99.9% refers to the loss of value a ‘club-member’ company experienced). The company in question was a German (?) company that ended up building a very profitable business in Poland (in fact, at the point of that story almost all — 99.9% — of the company value was in Poland). At one point German senior management came over to Poland to sign some contracts with local management. Because it was regarding the Polish entity, the contracts were under Polish law and the Polish language version prevailed. To cut a long story short, after the contract were signed the German senior management found out that (a) the contracts differed substantially and (b) they had just signed over the entire local operations to local management.

What did we learn from that? The less the business people understand the language in which the contract is written, the more they rely on trusted intermediaries that translate their intentions into the code to be executed on the chosen runtime.

Arguably fraud is not the main issue here however: the issue is more that mistakes creep in, and the programmers around the table agreed that depending on the level of complexity it will be exceedingly difficult to write code that performs well under all possible edge scenarios. As an example we discussed securitisations (and in particular the master trust structures favoured by many UK banks pre-crisis) that were of a mind-boggling complexity which made it impossible to understand all edge cases.

An interesting idea emerged there, triggered by one participant remembering that the SEC apparently had at one point asked for securitisation waterfall in Python rather than in legalese. The idea is that indeed in some instances the code should be the contract. To make this a bit more precise: of course the legal contract prevails (there is no way around this within the legal system) but the contract could simply stipulate that the payments are whatever the attached model says they are. There are a few issues to consider: for example, the code execution could fail and lead to runtime errors, or the outputs could contradict existing law (eg, in many jurisdictions entities are no longer authorised to make payments when bankruptcy is probable). Also it is probably a good idea to specify a runtime on which the code is to be executed, lest one side say creates a runtime that say exchanges ‘+’ with ‘-’ and bases its claim on this.

The conclusions that could be drawn from the ensuing discussions were as follows

  • Smart contracts are not contracts (some people also suggested they are not smart), and they generally need to be embedded within a wider governing contract that is “running on the legal runtime”, and that in case of discrepancy prevails
  • In some very specific cases (auto-execution, anonymous or out-of-reach participants, …), smart-runtime-only contracts are possible, but not necessarily desirable, because if things go wrong there is no recourse through the usual (‘legal’) means (there are no runtime-errors that would lead to uncertain outputs in the legal runtime: everything gets resolved, albeit possibly at a very high cost, and not in line with the expectations of all participants at contracting time)
  • Verifying that a smart contract does what it is meant to do can be extremely complicated; also it is generally outside the capabilities of the business person for whom this contract has been created, so it is crucial to have trusted programmers that can do the translation (a proper SDK/IDE and testing environment, as well as a very tight deployment procedure, also helps)
  • Despite of the above, there is a wide range of possible use cases that are simple enough for the smart contract algorithms to be verified with certainty (the example was a team deciding upon their bonus distribution using a voting mechanism related to a smart contract)
  • In some cases, the ‘smart’ form of the contract might be more easily verified than the ‘legalese’ form, an example being the exact definition of the payments waterfall in a complex securitisation transaction. Also — as experienced recently in the securitisation — legal contracts can contain contradictory clauses making the output undefined (or rather, to be inferred by the ‘legal runtime’ which is a costly exercise). Whilst runtime errors can occur in smart contract code as well, with the right tools they are easier to prevent in smart contracts than in legal contracts
  • If external data is pulled in (eg, closing price of SPX) this adds additional complexity when compared to the ‘endogenous’ case where all data is produced by the contracting parties (see the previous ‘team bonus’ case)

In conclusion: smart contracts are an exciting area of development, provided they are properly integrated into the applicable legal framework. However, depending on complexity, creating smart contracts that perform as the business people intended can be a challenged. This challenge is mitigated when there is a well designed recourse to an overarching “legal runtime”.