SMART Contracts

Business Technology
Let’s talk about law and innovation, specifically legal contracts and what they could look like in the future. This post is inspired by, and partially based on, a research paper from Barclays and the University College London on Smart contract templates (link).
In the next few paragraphs, you’ll find my notes while I am trying to figure out what makes a legal contract Smart. I will take the perspective of how these concepts could be used in combination with some of the Virtual & Trust machine features of blockchain I introduced in previous posts.

Premise –  Traditional Contract:

If you think about it and strip down the components behind the intent of a contract, in its most simple form it is as follows:
  1. A legally bounding 
    “legally” –  in line with the laws that govern the behaviour in given circumstances
    “bounding” its content is enforced through social institutions 
  2. Agreement
    The intent over which the parties are coming together to agree on (usually assigning rights and/or duties)
  3. Between two or more competent parties
> In short, what a contract does is to (re)assign rights and duties under a recognised framework, so that everybody (that is part of the same framework) can acknowledge that this specific “rights & duties transaction” actually happen within a give set of common rules, and take the new state of the world as a given for the next iteration of transactions.

Next step towards Computer Science – Ricardian Contract:

Ricardian Contract is essentially a design pattern that aims at upgrading legal contracts to something more efficient (“digitalizable”) while maintaining its initial intent of readability for the parties involved and validity under the law in which it operates.
It is not easy to design a meaningful interface that is both easily readable for unsophisticated parties, comprehensive enough to be enforceable and useful, and compliant with the governing law.
Challenge: Machine/Human readability tradeoff
The most challenging aspect in making a Ricardian Contract is the machine/human readability tradeoff aspect because it seems like this is adding another variable to a problem that has already no closed form solution (at least in they way is currently framed).
We need to juggle the following considerations:
  • It should be easily readable for the contracting parties to ensure that their intended agreement is captured accurately;
  • It should be easily readable by an intermediary of the law (lawyer) who can ensure its validity in light of the governing laws under which it is written, but also regulators, standards bodies and policy makers.
And add on top these new considerations:
  • It should be machine readable so that it can be easily extracted for computational purposes and can easily be linked back to the original plain English intent for “code auditing” purposes;
  • It should be signed digitally and uniquely identifiable;
  • Ideally, the operational parameters that make up the intent of the agreement should be digital so that the logics captured by the contract can be self-enforced between the two (or more) parties.

Smart legal contracts:

Definition of a Smart Legal Contract:
“ An agreement whose execution is both automatable and enforceable.” (as defined in the paper by C. Clack, V.Bakshi, & L.Braine.)
  1. Automatable by a computer, although some parts may require human input and control.
    • Examples of how to achieve automation: Ricardian Contract Triple
      A [1] Prose (is linked via) [2] Parameters (to) [3] Code (that provides execution)
    • In “plain English”, a Smart Legal Contract could be:
      • a collection of business logics,
      • instantiated on a shared ledger and,
      • once executed, will proceed to undertake various transfers of value
      • in accordance with the legal prose.
    • Obviously, where the logic cannot be captured by parameters observed on the distributed ledger or by a business logic, this might require human input and control.
  2. Enforceable by either legal enforcement or rights and obligations
    • WHAT:
      • Right and obligations often expressed in complex, context-sensitive, legal prose
        • May cover not just individual actions but also time-dependent or sequence-dependent sets of actions
        • May also have overriding obligations such that a lack of action could be deemed to be a wrong performance or non-performance.
    • HOW
      • Two methods, well-known traditional (e.g. still using courts) and non-traditional method.
      • The second one is the most promising, as it entails the possibility of enforcing the execution of smart contract code at a network level without the need for dispute resolution.
        • To achieve that, we need essentially an unstoppable contract that covers all possible scenarios and has a pre-agreed answer for all of those, without requiring court resolution to reach an agreement for each scenario that might appear after the initiation.
        • Obviously, this would work initially only with very standardised contracts where the above-mentioned concept can be achievable in the design of the contract, not all current contracts can achieve that but thinking about the financial industry there are few that might work.

Conclusion: Approaches for the intersection between contracts & computer science

  1. Augmented Reality: link reality (legal prose) to code
    • As described above, this “augments” the traditional prose of a contract by linking via parameters to the code that captures the intent of the language (Ricardian Contract). However, why should we replicate 1:1 what we do offline in a digital system when we could potentially do better? See point 2.
  2. Hybrid: writing legal agreements the way programmers develop software (open-source Legalese project – link)
    • This approach is based on the principle that we could keep the important qualities of a well-designed programming language instead of the traditional legal language:
      • such as lack of ambiguity,
      • or a compositional approach where any clause can be clearly deduced without reading the rest of the document.
  3. Virtual Reality: code a “virtual reality” look through of the code
    • if, as described above, we have an unstoppable contract that has already all the potential dispute scenario and outcomes then we could walk our way back to a “virtual reality” –  the code could generate a document version of the contract understandable by all parties. A contract, as traditionally intended, might be more like an outline of scenario analysis of the digital contract you are signing up to rather than a list of complex, context-sensitive legal prose.

Next Steps – Legal Virtual Reality:

The third approach seems to be the most interesting to me, specifically for autonomous blockchain vehicles to further disintermediate their distribution in the traditional marketplace. We often fall back on trying to mimic what we currently do with a new technology but I believe we should aim at doing something more, using the tools this new technology gives us.
For example:
  1. We have an autonomous and self-enforced contract where all scenarios (parameters) possible are already covered by an answer by the code.
  2. We want it to be understandable by someone without any programming skills.
  3. Is legal prose the best way to capture a scenario based simulation, isn’t there a better way?
These type of contracts would require a new breed of computer science auditing and will be heavily helped by standardisation.
Can we do it? I think so. We are progressing substantially in “machine learning” to allow computer algorithms to interpret the world, we should now think about how can we understand computer algorithms more intuitively, for “human applications”.

Comments are closed.