Smart legal contracts

Can enterprise smart contracts be legally-enforceable? In this post we explore relations between real-world legal contracts and so-called smart contracts. We then define and talk about digital contracts, a powerful construct that can automate inter-organizational processes while staying within the legal context. Finally, we describe how digital contracts can be deployed and managed across industries and show the value potential of their proliferation.

Photo by Marius Masalar on Unsplash

Relationships of any subjects willing to transact (exchange value) with each other are typically regulated by the contracts (or agreements), a legally-binding documents that are subjects to common law (in case of English law, or its corresponding equivalent, depending on the jurisdiction). Definition of a contract may vary, but a majority of jurisdictions require that they have the following essential parts:

  • Offer,
  • Acceptance,
  • Intention to create legal relationships, and
  • Consideration (or price)

The notion of a contract and its history goes back to 1750 [1]. Since that time, humankind has witnessed tremendous progress in science and technology, however evolution of the contract has been quite modest, at least until very recently. Most important developments to the contracts have been:

  • Using of electronic document format (e.g. PDF),
  • Using of electronic and digital signatures,
  • Contract and process automation based on global standards and/or information systems (GS1 standard [2] in supply chain/logistics).

However, in the vast majority of the cases contracts themselves, or more generally — contracts or legal operations — are disconnected from the main business processes and operations of an organization, creating inefficiencies, slowing the pace of business, introducing costly errors.

One cause to this problem is that legal contracts are typically expressed in plain human language (prose) with specific legal jargon (legalese), which makes it impossible to analyze and automate directly. Over the past several decades there have been many efforts and proposals to structure legal contracts and create systems to reason about them, laying the groundwork for automated contract checking (static and dynamic) and even automating of contract negotiation.

The second cause has to do with the possibility of automation: contracts typically involve two or more parties — independent, mutually- distrusting organizations. When it comes to automation, e.g. changing some commonly used data in the context of the contract, the question arises: who can be entrusted to change such data in a correct way, so that all parties agree?

Contracts become smart?

Back in the 1990’s, a brilliant computer scientist Nick Szabo came up with a concept of smart contract [3] — a self executing piece of code that can be deployed in a decentralized computer system. Recently, with the proliferation of the so called Distributed Ledger Technologies (DLT), commonly known as blockchains, the smart contract concept finally got the necessary conditions to come alive.

Essentially, a smart contract is just a piece of computer code, encapsulating some logic that should be performed when the smart contract is called, or used as a part of transaction recorded in a distributed ledger (blockchain). Existing application of smart contracts deployed on the most popular blockchains such as Bitcoin [4] and Ethereum [5] are:

  • Keeping registers of token holders (of a digital asset or of a digital representation of a physical asset), and transfer of token ownership from between holders,
  • Conditional crypto-currency transfers, such as in an escrow arrangement.

Concepts of DLT/blockchain and smart contracts are parts of the bigger trend, a paradigm shift called ‘Web 3.0’, which promises to solve problems of current society and internet with hyper-centralized institutions and industries and bring power back to people via decentralization of data, business processes and governance.

In Web 3.0 paradigm people shall re-gain control of their data and shall be able to capture its value, and centralized industries shall become decentralized with the help of DLT/blockchain. By extension, smart contracts started to be seen as a universal mechanism to encode and manage rules and relationships between independent and mutually-untrusting people and organizations. Inevitably, the question arose: can smart contracts replace legal ones?

The choice of term ‘smart contract’ has contributed a lot to confusion around the main question: are smart contracts in fact contracts? There’s a long and detailed exploration of this topic found in [6]; fast forwarding to the answer we get the following: no, smart contracts cannot be regarded as analogue of the contracts within meaning of the law, rather, they are orthogonal concepts.

Legal contracts have 2 or more parties. They contain obligatory parts: an offer and its acceptance for certain consideration, subject to certain terms and conditions. Legal contracts state the intentions of the parties and provide remedies to each party in case one (or more) of their counterparts fail to fulfill their obligations. Legal contracts do not provide means to fulfill obligations. In case something goes wrong, legal contracts can be enforced in courts of law.

Smart contracts have very few of those. By design, each contract is instantiated by a single party. There’s no way to confirm that what is written in the code is in fact the intention of parties. There cannot be anything that can represent judgmental clauses of legal contracts (such as ‘best endeavors’). There’s also no remedy for wrongful (or erroneous) actions, since the code is self-executing and the blockchain state is immutable.

In fact, smart contracts provide exactly what’s lacking in the legal contracts — the means to fulfill parties’ obligations automatically. This leads to an interesting conclusion that a combination of legal contract and smart contract could be a powerful construct with far reaching capabilities.

Ricardian Contract

The idea of linking together of a legal agreement (or ‘legal prose’) and its digital representation was brought up by Ian Grigg, who coined the term Ricardian Contract [7].

Essentially, in its current form, a Ricardian Contract is a set of the following elements:

  • Data parameters, expressed as primitive types (numbers, strings) or complex types,
  • Legal prose (legally-enforceable contract language), the stipulation of parties’ intents, referencing data parameters,
  • Contract code, collection of procedures for data transformation under conditions of the parties’ agreement

All three elements are bound to each other by cryptographic functions (hashes) and digital signatures.

The concept of Ricardian Contract is rather well-known and is implemented in several blockchains, such as EOS [8] and R3 Corda [9].

While this concept is already quite powerful, it doesn’t deeply connect the legal and the automation part:

  • legal prose remains intact, it cannot be automatically structured and analyzed,
  • because of the above, we cannot establish logical equivalence between parties’ intents and the code.

In order to achieve true combination of legal enforceability and automation, it’s necessary to go deep into the structure of the legal contract.

Defining digital contract

Real-world contracts are written using natural language heavily augmented with specific legal dialect (legalese) and typically have the following structure:

  • parties references, including legal names, addresses, contact details, banking details, etc.
  • legal boilerplate, i.e. specific customary phrases and statements that are standard for the majority of the contracts (‘This agreement has been made by and between…’, ‘whereas …, now therefore…’, ‘headings…’, ‘entire agreement…’),
  • a set of definitions and references, describing specific terms in more general ones and/or referring to some external definitions (‘business day is …, USD/EUR rate is determined from …’),
  • a set of statements about the facts that form the legal basis of the contract (‘whereas Seller owns …’, ‘whereas Buyer is willing to purchase …’), that can be expressed as RDF [10] triples,
  • a set of deontic (‘shall’, ‘can’, ‘shall not’) statements, representing parties’ mutual bindings that form the contract (‘Buyer shall pay the Seller the sum …’, ‘in case of … Seller shall not be obliged to …’). Such statements are typically bound to parties’ actions and / or external events,
  • a set of contract parameters, typically if the contract body is a standard offering, or if the contract is within the context of some larger frame agreement (‘price per item = $…’, ‘revenue share %% is calculated as: …’)
  • a set of document templates, data formats, protocols, etc., especially if the contract presumes some form of digital communications.

In order for a contract to become formally described and / or automated while staying legally-enforceable, each part of contract needs to be transformed into some machine-comprehendible format:

When the existing legal contract is being transformed its of paramount importance that this transformation is fully-reversible, i.e. at any point it’s possible and computationally easy to come up with the human understandable legal prose. However, once we establish the fully reversible 1:1 correspondence between legal prose and digital contract representation, we can start working with digital-first contracts that have formal representation as legal prose.

We’ll call the construct described above a digital contract. In the following sections we discuss the useful properties of digital contracts and describe how they can be used to automate inter-organizational business processes on a mass scale.

Automating digital contract

Once we have a digital contract framework, there is a lot of useful stuff we can do with it:

  • Use the rules of formal logic to check the contract for inconsistencies, conflicts and errors [11],
  • Use the rules of formal logic to check the contract against other digital contracts for mutual inconsistencies and conflicts,
  • Map formal logic statements to definitions of actions and events and augment them with data/message formats
  • Map actions and events to smart contract interface specification,
  • Map terms and timings to business process rules,
  • Map data formats to smart contract messaging formats,
  • Define digital contract lifecycle and it’s integration into the enterprise information architecture

Essentially, this gives us all required components to deploy the digital contract into the enterprise context:

  • Map objects to enterprise objects,
  • Map contract interfaces to existing interfaces, message brokers or service buses,
  • Export business rules to enterprise business process automation system,
  • Develop smart contract code.

Digital contract in a process context

Contracts do not appear out of the blue for no reason, they are simply capturing the desire to conduct business manifested by their parties, and they represent formalized legal agreement to engage in a certain business transaction or transactions. Business transaction is an exchange of value, being a product, a service, or a combination of both. Suppliers are willing to sell something they produce; consumers are willing to buy something they need. Therefore, contracts can be seen as a reciprocal extension of business processes of each of the parties towards another party (counterpart).

When looking at a contract from the process standpoint, there’s always a happy path (i.e. a sequence of events when both parties operate within agreement) and escalation branches (when one or both parties deviate from the agreement). To account for this, for each contract we define a contract protocol and an exception protocol.

Large and medium-sized enterprises employ some form of automation and manage their processes through various solutions as a part of enterprise architecture. Typically they employ some kind of a mediation system, in a form of service bus [12], message broker [13] or just a set of defined interfaces. It’s therefore relatively easy to integrate a new business process once needed, because the governance process is centralized.

However when it comes to business processes spanning two or multiple organizations, things get very complicated for obvious reasons:

  • Independent organizations don’t trust each other,
  • There’s rarely a common standard over data and processes,
  • Governance process gets encapsulated into legal agreements,
  • Agreement over a set of common data requires either constant reconciliation or some trusted third parties.

Advent of DLT/blockchains brought a whole new angle to look at this problem. Blockchain’s core value is to create a network of mutually-distrusted peers that can come to agreement upon a current state of things without a trusted third party. Suddenly, there’s a way to automate inter-organizational processes in a decentralized way.

Digital contract lifecycle

Earlier we noted that one of the cornerstone of the legal definition of contract is an offer. In fact, the offer-acceptance pattern is very common in both B2B and B2C contexts:

  • a service company typically has a well-defined general terms and conditions and standardized statement of work for commonly-used services; together these constitute an offer,
  • a seller of large quantities of products tends to have standard offerings and standard terms with the quantities, prices, packaging, shipment, etc. — essentially, an offer

Following offer-acceptance pattern gives us the following generic digital contract lifecycle (here we use a digital licensing case as an example):

An initiating organization comes up with an offer, implemented as a digital contract. After checking and testing phases (which can bring additional implementation loops), the Offer digital contract is deployed on an offering side and is visible on a DLT/blockchain to other potentially interested parties.

Once an interested party finds an offer satisfying its requirements (via additional negotiation phase, which we omit here for clarity), this party accepts the Offer (via blockchain transaction call). This transaction begets a new digital contract, the Contract, which is a unique instance encapsulating specific agreement between the parties.

If accepting party satisfies required interfaces and data formats, the new Contract gets provisioned and integrated into its infrastructure. After that, parties can start using the contract protocol, extending and linking together their business processes. Every communication event within the contract protocol gets immutably recorded onto the underlying DLT/blockchain. As parties transact with each other, they change the state (the common data) related to their agreement and the Contract. The state cannot be unilaterally changed by just one of the parties, it requires consensus to be achieved between the nodes that are responsible for transaction validation.

As long as the parties are within the contract protocol, they can enjoy automation of certain contract logic with smart contract that can be deployed either on DLT/blockchain or off it. Either way, the result of the smart contract execution is validated by consensus and is written onto immutable ledger.

If something goes wrong (a deadline/checkpoint is missed, data is incorrect, etc.), the Contract transitions into the exception state, invoking exception protocol. Handling of exception protocol could be automated to some extent (e.g. alert messages could be sent, late fees calculated, etc.), however we envision that it will require significant amount of human interaction from both sides.

Exception stage can end by resolving situation via expected actions or via amending the Contract terms and conditions, or by premature termination. Any of those paths can involve legal governance as defined by the Contract.

Value of digital contracts

The problem of automation of inter-organizational processes is well-known and widely accepted. We argue that this complexity of automation grows faster than the accrued benefits with the growth of the number of transacting parties, causing the overall economic effect to decrease.

Digital contracts, deployed over the DLT/blockchain network linking transacting parties, make breakthrough in creating the business value. Applying Metcalfe’s Law [14], we argue that overall business value in such a network can grow quadratically with the growth of the network, driving the overall effect to grow.

Further directions

While we tried to cover all aspects of digital contract concept and how it applies to the enterprises, some aspects are quite complex are or being still researched / developed and therefore call for a separate post:

  • Using formal logic approaches to test the contract clauses for inconsistencies / conflicts,
  • Choosing the right DLT/blockchain to satisfy requirements of parties’ business relationships (privacy level, throughput, scalability, etc.)

Conclusion

We’ve studied relationships between the legal contracts and so-called smart contracts and came to a concept of digital contract that has a power to redefine and automate inter-organizational relationships in many industries and serve as a driver for business value growth. Distributed Ledger Technologies, or blockchains are the cornerstone for successful implementation of digital contracts.

Gartner believes that blockchain technology will create additional $176B of business value by 2025, and $3.1T — by 2030 [15]. We believe that digital contract is one of the key components of this value creation.

References

  1. Contract: History (https://en.wikipedia.org/wiki/Contract#History)
  2. GS1. The Global Language of Business (https://www.gs1.org)
  3. Formalizing and Securing Relationships on Public Networks (https://journals.uic.edu/ojs/index.php/fm/article/view/548/469)
  4. Bitcoin: A Peer-to-Peer Electronic Cash System (https://bitcoin.org/bitcoin.pdf)
  5. Ethereum: A Next-Generation Smart Contract and Decentralized Application Platform (https://github.com/ethereum/wiki/wiki/White-Paper)
  6. Contracts Ex Machina (https://papers.ssrn.com/sol3/papers.cfm?abstract_id=2936294)
  7. The Ricardian Contract (http://iang.org/papers/ricardian_contract.html)
  8. EOS: The most powerful infrastructure for decentralized applications (https://eos.io)
  9. R3 Corda (https://www.corda.net)
  10. Resource Description Framework (RDF) (https://www.w3.org/RDF/)
  11. CL: An Action-based Logic for Reasoning about Contracts (http://heim.ifi.uio.no/~gerardo/wollic09.pdf)
  12. Enterprise Service Bus (https://en.wikipedia.org/wiki/Enterprise_service_bus)
  13. Message Broker (https://en.wikipedia.org/wiki/Message_broker)
  14. Metcalfe’s Law (https://books.google.com/books?id=aE_J4Iv_PVEC&printsec=frontcover&dq=inauthor:shapiro+inauthor:varian#v=onepage&q&f=false)
  15. Gartner. Forecast: Blockchain Business Value, Worldwide, 2017–2030 (https://www.gartner.com/doc/3627117/forecast-blockchain-business-value-worldwide)

About the author

Leonid is a seasoned media executive, serial entrepreneur, passionate coder and lifelong learner. Being fascinated by blockchain technology, he is searching for its use cases that can create new value for people and enterprises alike.

Leonid’s most recent venture is JustUs (https://justusfilmhub.com) — a blockchain-based decentralized distribution platform for independent film industry. JustUs features an Ethereum side-chain for managing digital licenses and micro-payments.

Most recently Leonid has been involved in several enterprise blockchain applications, including ones in music industry. This led to creation of an enterprise product and services offering aimed at automation of inter-organizational business process.

Please don’t hesitate to clap and/or leave word if you find this post useful.