.

By Richard Stobbe

As we’ve reviewed before, the term “smart contract” is a misnomer. (For background, see Smart Contracts (Part 3): Opportunities & Limits of Smart Contracts.) The so-called smart contract isn’t really a “contract” at all : it’s the portion of the transaction that can be automated and executed through software code. Hence, we prefer the term “programmatically executed transactions” — not as catchy, but maybe more accurate.

The written legal prose, or what we might think of as a ‘traditional contract’, sets out a bunch of contract terms, usually in arcane legalese, that describe certain elements of the relationship. Parts of that ‘traditional contract’ can be automated and delegated to software. However, once concluded, the traditional legal contract usually sits in one silo, and the software code is developed and sits in another silo, completely divorced one from the other.

The evolution of research and software tools has permitted the so-called Ricardian contract to function as a bridge between these silos. Based on the work of Ian Grigg, a Ricardian contract is conceived as a single document that has a number of elements that permit it (1) to function as a “contract” in the way the law would recognize a contract, so the thing has legal integrity, (2) to be readable by humans, in legal prose, (3) to be readable by software, like software reads a database or a input fields, (4) to be signed digitally, and (5) to be integrated with cryptographic identifiers that imbue the transaction process with technical integrity and verifiability. This is where blockchain or distributed ledger technology comes in handy.

The document should be readable by both humans and machines. It integrates the ‘traditional contract’ with the ‘smart contract’, since the elements or parameters that can be automated and implemented by software are read into the code straight from the contract terms.

Can this form the basis for software developers and lawyers to play in the same sandbox?

There are a number of developments in this arena where “legal” and “software” overlap, and Ricardian contracts are merely one iteration of this concept: for more background, Meng Wong’s presentation on Computable Contracts is a must-see.  His Legalese contracts are intended to allow legal terms and conditions to be represented in machine-understandable way, with or without a blockchain deployment. OpenLaw is another version of this approach : blockchain-enabled contracts that delegate certain functions to software. There are a whole range of options and variations of this.

In theory, this sets up an “Internet of Agreements” system that is designed to execute deals and transactions automatically with distributed ledger ecommerce technology through interwoven contracts and software across disparate platforms.

How far away is this legal-techno-dream?

For some applications, particularly in financial services, it’s much closer. Versions of these technologies are being beta-tested and implemented by global banks.  Since many of these implementations will be between entities in back rooms of the financial services industry, they will be invisible to the average consumer.  For many sectors – let’s say for example, the development of a full-stack land transfer technology - where smart contracts have to interface with existing immovable legal or institutional structures, this is a long way off.

Calgary – 07:00