Logical Contracts — Want less lawyers?

John Craig
9 min readMay 7, 2021

1. Background

I’ve written many contracts, mainly due to a lack of other volunteers and because we needed a contract to progress our work. Though maybe not fully qualified to do this, Product Management often understood what was required from other parties and could judge any delivery. I would start by writing the substance of the contract, the part that actually varies between contracts. But then ended up having to complete the contract myself for some legal review and would just cut-and-paste standard text from previous ones. After doing this for a while (a period measured in decades) it seemed that the cut-and-paste material contributed little of use, other than to make contracts bigger. Which begged the question of why contracts had to be so large and complex.

A few years ago, I started helping out some people who were working with Smart Contracts using blockchain, with the goal of making the benefits of blockchain and related technologies (Ethereum, Solidity, Tokens, Decentralised Apps, Natural Language Processing) available to everyone. Understanding better how these smart contracts worked, and having written so many contracts myself, I caught a glimpse of an easier life in future — much shorter logical contracts stripped to their essentials and executed without humans.

I should say that some of my best colleagues have been the lawyers. Neither as pedantic nor as dull as any stereotypes suggest, they were often interesting characters. But let’s consider a world where knowledge of the law, human elements around contracts, and the jurisdiction of courts, have all been digitised, and the benefits this could bring.

2. Introduction

In the mania to digitise everything that moves these days, to save money and demonstrate progress, it was only a matter of time before all things legal were considered. A key step could be the digitisation of the contract process by first creating self-running logical contracts.

I’ll call these logical contracts, as smart contracts as a term has been hijacked by a specific technology (blockchain) that I’m not sure has to underpin all logical contracts. Blockchain can reduce the need for trusted parties and enforce the irreversibility (immutability) required for contracts. But there is value in separating logical contracts from blockchain-based smart contracts. Once contracts are made logical, and depending on their nature, different possibilities for their execution can appear.

The current basis for non-smart contracts is subjective, involving 2 groups of people agreeing to their interpretation of something beaten/negotiated into a specific form and relying on jurisdictions and courts to intervene when things go wrong. A very human format, cleverly worded, and open to interpretation, even if this was not the intention. If we could have an objective contract, where ambiguity and human factors are replaced by logic and driven by digital inputs, we may not need as many lawyers. This would also empower new experts in creating these logical agreements — Programmers.

3. Simple Case — Deposit on an Apartment module

Usually part of a broader rental contract, we will consider it as a separate module. Breaking complex contracts into modules is a key aspect of logical contracts, as these modules can be independently worked on and optimised. Or even traded.

The renter pays a $2000 deposit to the landlord prior to their tenancy commencing. After the term of the agreement the money is returned, minus any damages outside of usual wear-and-tear. The main issue for a logical contract is that the renter and landlord will disagree on the amount to be deducted for damages. There is not usually a digital output, or an objective view, on the amount for damages. So, the contract uses a Trusted 3rd Party assessor, who has the objectivity to quantify the damages.

This contract module takes shape as follows: -

  1. The Contract, a software program, begins execution on its commencement date and has a fixed duration.
  2. The Contract invokes a trusted service (e.g. a bank) to transfer $2000 from the Renters bank account and put it into an independent bank Account (escrow), owned by the Contract.
  3. At end of the rental period the Contract requests an independent assessor to check the property. This could be done via chatbot, Email, or other digital means.
  4. This trusted party creates a transaction which writes the value of the damages as a % of the deposit (0–100%) into the contract.
  5. This assessor is then paid a pre-agreed amount by the Contract.
  6. The damages are deducted from the deposit by the contract and paid to the landlord, and the renters are paid the remaining sum back into their account, all in a similar manner.

This is a largely logical contract module, with the exception of the assessor’s role, which can be made independent and objective. There is no rocket science involved, and few lawyers either. The contract executes like a computer program, so to create it would need someone with logical skills, as opposed to deep knowledge of the law. Perhaps a trivial example, so let’s consider something else.

4. Simple B2B Case — A Data Processing job

Let’s say Company A pays Company B to process some data and receives back the transformed data for subsequent use. It is assumed the rights to perform this data processing have been secured, and data privacy and data protection are present.

A logical contract created to manage this process, could operate as follows: -

  1. The contract extracts the data from its repository in company A, and transfers it to company B, who check it and confirm back to the contract that they have received the data as it was described, and it is present and in a correct format.
  2. Company B then processes and transforms the data as instructed by the contract, making the result available to the contract after a period of time. The contract delivers the data to company A.
  3. Before doing so the contract could call for an independent assessment of the results by a Trusted 3rd Party should Company A not accept or agree with the work done. In the advertising world and certain cases involving Personal Data and attribution we already use Trusted 3rd Parties to ensure the 2 sets of personal data are handled appropriately.
  4. Company A checks and accepts the data and informs the contract, which pays Company B and ensures they delete the data, and this is verified within a defined period.

This is a bit simple, as B2B contracts involving digital entities and data can be.

5. The Internet of Things (IoT) Case

It may be useful to consider the logical contract as simply a Thing, like the ones made famous in the Internet of Things (IoT). Something that is a virtual machine and connected to the world. Consider a contract for the supply of raw goods. Whether these are tomatoes from a farm, or copper from a mine, is not too important. Both involve a producer and a buyer, and the contract specifically requires that the goods must be grown or extracted in a sustainable and ethical manner.

The contract could begin by inspecting generic certifications of the farm or mine, that indicate the operating company is committed to sustainable and ethical practises. If unsure the contract could invoke a trusted 3rd party to do a spot inspection to verify this. When the produce is ready it is containerised and a verification tag applied to it, providing a unique ID, details of the contents, and registering it with the contract. It can now be traced through the supply chain.

Such tracing gives transparency and illuminates the sequence of product custody, helping to address issues of counterfeit goods, compliance violations, theft, wastage and delays. The container with the tomatoes/copper is tracked as well as traced, using location data communicated over cellular networks, and sent to the contract.

The contract will be updated by the goods themselves, and other parties can query the contract to check status and see when goods will arrive. The contract will not get tired of people ringing it up and asking when their delivery arrives. Any deviations, inconsistencies, or unusual movements are electronically sensed and registered with the contract. There will be little ambiguity on whether this is authentic produce, or on its current location. The contract would perform re-routing or goods transfers should it discover that certain flights or shipping have been cancelled.

The container would be transferred between companies and vehicles along its journey, all performing both a physical and electronic handover and registering with the contract to ensure appropriate division of payment for the work undertaken. On reaching the destination, whether a supermarket (tomatoes) or a factory (copper) a verification process is undertaken by the buyer to determine these are the right goods, and they have correctly arrived from the producer. The result, such as goods accepted, goods rejected, or a need for adjudication by a trusted 3rd party, is written to the contract and acted upon to ensure all payments are done correctly. Such complete processes could conceivably involve no humans.

6. Challenges and Conclusions

It seems most contracts can be distilled into a logical basis. I did some experiments with some old contracts of mine and was able to reduce 20 pages down to less than 2 pages without any significant loss of sense. Try it. However logical contracts are not in widespread use today, and recent interest and developments in smart contracts using blockchain have not resulted in an avalanche of solutions propagating through industries and verticals.

There can be many reasons for this lack of progress, including, but certainly not limited to: -

  1. The need in company business agreements for sign-off, where every single department involved (however tenuously) must comment, change, review and approve their respective parts of any contract.
  2. The human tendency to embellish, complicate, demonstrate knowledge, and emphasize our own indispensability, resulting in too long and too complex contracts.
  3. The contract authors may not actually want them to be understood. For example, many consumer contracts are deliberately over-complex and obscure, to avoid them being fully understood. Check out App terms and conditions for use of your personal data, for examples of this.
  4. Standard business practises along the lines of ‘we’ve always done it this way’ or ‘Legal insists this standard text needs to be in every contract’.
  5. Lack of understanding and suspicion around Blockchain as the base for smart contracts. Blockchain is one of the few technologies where you need to explain its operation from first principles, just to sell an application based on it. It’s like describing how TCP/IP works when selling an eCommerce site. Furthermore, the need for trust as a cornerstone of contracts creates a slight tension due to the over-indexing of cowboys and get-rich-quick merchants found in the blockchain and related cryptocurrency space. It is becoming more respectable and accepted, but legacies remain.
  6. The need to consider all kind of eventualities and scenarios, however unlikely or extreme they may be.
  7. Recognition of the various laws, jurisdictions and court systems, as the only solution today.
  8. Why would turkeys embrace Xmas? You will need the help of lawyers, and legal departments, and their management, to introduce a new system that will reduce significantly their own power and influence.

Despite these practical issues, I believe logical contracts can be created that are short, easy to understand and capture the essentials of an agreement without lots of unnecessary human stuff. When we can create and execute these logical contracts, a significant element of work and costs around contracts is reduced. We create new stars of the logical contract creators (programmers) and establish robust execution environments and tools to optimise and trade generic contract modules. And, without judging whether this is a good thing or bad thing, another company function can be effectively one step closer to being automated.

About the Author

John Craig is a Product and Tech veteran, with no real qualifications to write such an article, other than having created and managed loads of contracts and having worked for a blockchain smart contract start-up. He did seek legal advice before publishing, but was simply told to stick to subjects that he knows something about ;-) He may not always be right, but he thinks this topic will be important in the future, and is therefore well worth a proper debate. You can find him on LinkedIn.

--

--

John Craig

Veteran Product Management guy based in Munich, starting to use medium to get some random thoughts written down, related mainly to my work.