What if we developed legal contracts like we developed software applications?

Development of code-based contract development application and execution of code created contracts as ‘smart documents’

This article discusses two separate, but inherently related, concepts. The first is the development of a platform that lawyers can use to generate legal contracts based on code-based principles (e.g., object oriented design patterns). This should not be confused with historical attempts to develop automated document generators. The later approach has generally relied upon the creation of a Word or PDF template document that has tags or other meta-data within it where user provided information is then used to populate those tags with deal specific information. The author of this article believes that contracts can (and should) be constructed using many of the same principles used by software engineers in developing software applications. As used in this article, the phrase “contract code” refers to the output of the proposed platform that is in a machine readable format (e.g., a JSON object).

The second concept is a system that permits the integration of the contract code distilled from a traditional “paper contract” with the blockchain. With the growing popularity of cryptocurrencies, and more importantly, blockchain technology, the notion of a ‘trustless’ and automated peer-to-peer transaction seems more like an imminent revolution rather than a techy alternative. These ‘smart contracts’ will transform the concept of contract performance — complex transactions uploaded onto the blockchain will have the ability to set off a host of automated contingencies, requiring significantly less human input and oversight. But in order to maximize this potential, the way lawyers and clients approach contractual relationships and how they view contracts will need to change in several important ways. This article proposes an open source and transparent platform that can be used as a starting point for a new approach to contracts and contract drafting.

In sum, this article will discuss the development of a coding platform that will generate traditional contracts and smart documents — fusing the contracts of today with the contracts of tomorrow. There has been much written about the application of the blockchain to contracts and the development of smart documents. In fact, a tremendous amount of actual development is now taking place to make these tools available to lawyers and others, some of which — in the case of Ethereum, Consensys and others — is groundbreaking. The goal of contractCode is to advance the foundation others have laid and continue to build, and hopefully, nudge the legal profession closer to truly leveraging technologies that have already disrupted virtually every other industry. The author of this article is an avid full-stack software developer, blockchain enthusiast and aspiring Solidity programmer. The author has also practiced transactional finance law for eighteen (18) years and continues to do so as a partner at a large, AmLaw 100 law firm. The author has spent the last several years developing web applications tailored to his practice. These applications have improved efficiency and the quality of the product provided to clients. The author believes the legal industry is ripe for more systemic change and that a paradigm shift is in progress. Hopefully, this effort will contribute to that change.

Computational Law: Inspiration from Object Oriented Programming (OOP).

During the last few years, there has been a growing chorus of individuals, mostly in the academic setting, advancing various theories of computational law. This is an attractive approach to building legal contracts. At their most basic level, contracts are after all simply the embodiment of agreed upon logic between two or more people. If X happens (you tender title to your car to me), then Y happens (I will pay you $10,000). Conceptually, software applications are no different. If X happens (the user presses the return key), then Y happens (a line break occurs). Ultimately, computers understand only a series of 1s and 0s or two states, ‘on’ and ‘off’. As a result, applications created for computers are nothing more than logic rules articulated in a language more easily understood by humans. It should therefore not be surprising that many of the concepts from software engineering are equally applicable to traditional contract drafting or at least effective contract drafting.

There are many different types of programming languages, some of which are considered ‘procedural’ languages and others considered ‘object oriented’. Many of the concepts that underpin our proposed platform are rooted in themes derived from object oriented programming. For those who are not familiar with object oriented programming, the term refers to a programming language that follows a design pattern that is built with objects, which objects can store properties (often referred to as ‘attributes’) and that can be manipulated by the use of methods that can be called upon those properties. Objects could range from a digital representation of a car, a credit card or a human being. One of the primary benefits of OOP is that objects can easily be recycled throughout a program; thereby, reducing the overall amount of code.

Some Basic Characteristics of Objects:

1. Data attributes and properties. Objects hold information in variables called attributes or properties. For example, a car object could have attributes such as make, model and year manufactured. Or a credit card could be represented by an object having the following attributes: cardholder name, card number, expiration date and CSV code. Users generally have the ability to ‘set’ values for each of these attributes and to also ‘get’ or retrieve the values programmatically.
2. Executing Functions or Methods on Objects. In addition to properties, objects can have functions or methods that can act on the object, including manipulating its properties. For example, our car object could have ‘setter’ and ‘getter’ methods in order to set and retrieve the make of each car object and print the result to the user’s console.
3. An incredibly useful aspect of object oriented programming is the ability to create “prototype” or “classes” of objects from which we can create new objects. This saves considerable time in coding by reducing the amount of code that must be drafted in order to achieve the same level of functionality. This ability to “inherit” attributes and methods from a prototype or parent class is similar to incorporating all of the terms and conditions of a credit agreement into a promissory note, where the promissory note is a new object that inherits all of the properties of its parent class, the credit agreement.

Similarities between OOP and Drafting Contracts.

Like objects in programming, clauses or other snippets of contract language can be abstracted into properties and methods. For example, a promise to pay (the heart of a promissory note) could be constructed as the following object in JavaScript:

var promisePay= {
text: ‘hereby promises to pay to the order of’,
call: function (maker, payee) {
var reply = maker + ‘ ‘ + this.text + ‘ ‘ + payee;
return reply;
}
};

This basic object in JavaScript has one property and one function that takes two arguments, a maker and a payee. If you call the function and provide a maker and a payee, the object will return the text “{Maker} promises to pay to the order of {Payee}”. So, the following line of code: ‘promisePay.call(‘Bob’, ‘John’);’, will return the following to the user: “Bob hereby promises to pay to the order of John”. This is a very simple pattern, but the same pattern can be duplicated for more complicated contract clauses. Objects can manipulate their internal state and can act on and pass information to other objects. These basic characteristics enable object oriented patterns to be incredibly powerful for creating contracts.

For our work, we have chosen to code in JavaScript. We made this decision for three reasons. First, as the language of the web, it is easy to link web-based forms to back-end models. This also allows us to build out the platform using Node.js (through the use of the Meteor framework), which utilizes Javascript for the UI and server side coding. Node.js has several native Ethereum packages and solidity packages (more on solidity later) that allow for the easy integration of everything you need to build a decentralized blockchain application (also known in shorthand as Dapp). For example, the development company Blockapps maintains a Node.js package (blockapps-js) that allows a developer to instantly integrate all of the tools you need to spin up a Dapp with one line of code. Second, JavaScript is a fairly easy language to learn for beginner programmers and will be fairly easy to follow for novices. While low level languages, like C++, have many advantages in terms of speed and efficiency, those benefits are not particularly useful for a project of this type. In addition, low level languages are often more daunting for beginner programmers. As time goes on, and as needed, we can expand various parts of the project to other languages. For example, if compilers become necessary to bridge our contract code with that of a blockchain platform, those can be built in a low level language like C++ if that provides better performance. Finally, the most prominent Ethereum language is Solidity, which is similar in syntax and structure to Javascript. Notwithstanding our use of Javascript, we anticipate other programming languages being useful and contributing to our efforts. Ultimately, this platform, like many similar endeavors, will be language agnostic with respect to the end user’s client (in the computer sense not legal consumer), whether through the use of language specific APIs or DDPs — more on this later.

Code Based Contracts.

At its core, our vision of code based contracts are objects that hold all of the material logic of a contractual relationship — a definition within which a traditional contract could fit. A code based contract, however, would be distilled to the core logic and coded in one or more predefined patterns and syntaxes. Unfortunately, our current system of transactional practice has very few universally accepted syntax for drafting contracts. As any veteran transactional lawyer knows, there are almost an infinite number of ways to draft certain types of contracts. Some ways are better than others and some ways are more appropriate depending on the circumstances — but, ultimately, outside of a few areas of practice (such as derivatives contracts), there is little consensus among practitioners.

Maybe the most obvious benefit of code based contracts is the transactional efficiency of being able to automatically generate contracts based on agreed-upon patterns and syntax. Not only does this reduce overall drafting time and negotiation, but it’s the first step towards a world in which many routine legal documents could be autonomously created with little, or in some cases, no human involvement. For example, we already have examples of high-frequency trading platforms that operate virtually computer-to-computer in managing a large portion of the securities settlements every day. Current systems, however, still rely on one or more layers of third party intermediaries (i.e., trusted parties) to ultimately settle each transaction. The blockchain has the potential to eliminate the ‘trusted parties’ and allow computers to execute these transactions autonomously without much human interaction.

Maybe even more beneficial than the efficiencies gained by automation, code based legal documents would be capable of debugging themselves. In other words, a code based legal document platform would spot errors and inconsistencies within a legal document through machine logic. For example, if a contract contains an object of logic which provides that the contract is between two parties, but the contract’s execution contemplates the signature of more than two parties, an exception would be thrown by the program and the coder alerted to the inconsistency. That’s an obvious example that even the least capable drafter would certainly spot. More difficult issues, however, would also be capable of prevention. The platform could spot more nuanced inconsistencies — such as an object requiring one party to provide insurance, while another object provides for something inconsistent with that logic (e.g., the risk of loss being borne by the party not maintaining the insurance). As discussed below, advances in artificial intelligence will soon allow machines to understand more and more complex logic, and ultimately, be capable of alerting a coder to inconsistencies that often go unnoticed by human drafters. In addition, the speed at which these errors could be spotted by a computer are exponentially faster than that of a human lawyer. What would take 3 hours of human time could be done by a computer in one second. Even if you take a very conservative approach in insisting that any legal document be reviewed by an actual human lawyer (which is currently a good idea), applying a second machine review will undoubtedly catch errors missed by humans — and thus, the ultimate product provided to the client improved.

Another benefit would be the ability to code into the platform regulatory and other compliance logic. For example, if a coder is generating a promissory note where the governing law is a state whose maximum permitted rate of interest is 25%, then if the coder attempts to add an interest object with an interest rate of 26%, an error will be thrown. The ability to have a machine apply this sort of compliance logic would save certain industries an almost immeasurable amount of money and resources, including the financial and securities sectors and other highly regulated industries. For example, most U.S. banks spend a considerable amount of resources on compliance departments whose job it is to try and ensure that each transaction entered into by the bank is in full compliance with all state and Federal laws. This is a very labor intensive process and costs associated with these compliance requirements ultimately reduce overall profitability and increase consumer pricing. There is no reason that all of these compliance requirements can not be distilled into machine logic which can be easily applied to legal documents — provided those legal documents are in a format that can be easily understood by the machine.

Currently, a large numbers of people do not have effective access to the legal system because they cannot afford the services of a private lawyer. While government programs and pro bono efforts help mitigate this problem, these efforts fall short of providing universal access to the legal profession. By significantly reducing the cost of providing legal services, contractCode would allow large swaths of the population to have access to quality legal advice that they would otherwise not be able to afford. While other companies, like LegalZoom, have done an admirable job making available certain legal documents, such as wills, to the broader population at a price that most can afford. These sorts of applications have limits in terms of the nature of legal needs they can serve. Because the ultimate goal of contractCode is to produce applications that reduce the cost to practice law more generally, these overall reductions in cost will result in more affordable legal services being available to consumers across the board.

Another efficiency to code based legal documents is that they will incentivize the profession to uniformity in contract logic. This alone would be an amazing accomplishment that would save economies hundred of millions or even billions of dollars in wasted transactional costs. There is likely no other profession or industry that reinvents the wheel more often than the legal profession. In addition, there will be pressure to reduce the amount of data that must be maintained on the blockchain in order to effectuate smart documents. As a blockchain grows in size, efficiency dictates that the less information that must be stored directly on the blockchain the better. As a result, many smart documents might take the form of a designated form (for example, an ISDA swap confirmation form), coupled with a coded object that contains the data necessary to complete the ISDA form into a completed confirmation. With this approach, you do not need to waste space on the blockchain by storing the text of the ISDA form on the blockchain each time an ISDA swap confirmation is effectuated on the blockchain. Instead, the final smart document embodying this transaction will include a reference to the ISDA swap confirmation form (and not the form itself), together with the code object that, when added to the form, will produce a completed trade confirmation.

Artificial Intelligence / Machine Learning.

We’ve already touched on some of the applications for artificial intelligence (including machine learning) in the context of legal documents. Artificial intelligence is still in its infancy, but progress is growing exponentially. We can expect that AI-technology will touch on a much broader range of subjects and tasks — with increasing capacity for more and more sophisticated logic and human like learning. Set forth below is just a brief outline of possibilities — each of which could be the basis of entire bodies of research.

Negotiation:

1. Core economic principles can be implemented with machine logic:

a. price theory

b. game theory

c. law and economics integrated into the process

2. Learning capabilities to improve overall platform

3. Ability to modify form contract database by constantly scanning public domain contracts, such as EDGAR filed contracts.

4. Ability to identify similar contracts

5. Implement similar “market” changes to form contracts

6. Ability to learn from human corrections to automated changes that are determined inappropriate.

7. For example, an algorithm that can search existing databases of contracts (such as EDGAR) and determine when there are changes in “market” provisions found in certain types of contracts. The machine can then implement those changes in a company’s own form contracts. The machine learning code would need to be able to distinguish between different types of contracts (e.g., this is a credit agreement) and learn from human corrections that override its automated changes. For example, if the machine believes that a certain type of provision is being added to credit agreements and recommends adding the same provision to the company’s form, then the machine would learn from the human operator when it tells the machine that it is not appropriate to add in this case because that clause was in response to a law not in effect in the jurisdiction within which the company does business.

Ultimately, the machine could even learn how the various provisions in a contract work together, so that if a change is made to one provision, the machine could alert the drafter to changes that should be made to other provisions on the contract.

Avoiding Disputes and Preventative Enhancements.

Blockchain technology, especially within the context of decentralized autonomous organizations (DAOs), could potentially result in more innovative and cost-effective dispute resolution procedures. Again, in order to advantage of these possible efficiencies our traditional legal contracts need to be in a form that is easily implementable within these environments.

Enterprise Tracking.

With legal contracts distilled to electronic logic, enterprises who may have hundreds, thousands or hundreds of thousands of executory contracts (think of Apple, Amazon, ExxonMobil) would be able to establish automated systems plugged into their database of electronic contracts. In other words, they would no longer need to have hundreds or thousands of individuals responsible for managing these contracts. In addition to massive cost savings, the quality of management would likely increase due to the lack of human error.

It is important to appreciate that the benefits described above are only made possible by the conversion of traditionally drafted contracts into code based legal documents that are machine readable and subject to machine learning. These technologies are unique and extend far beyond the capabilities of simple language recognition technology and other similar advancements. With code based legal documents, we will for the first time be able to communicate with our contracts.

Electronic Signatures.

With the exception of a limited number of legal documents, both Federal and state laws permit contracts to be executed (including notarizations) with an electronic signature in lieu of a “wet” signature. Due to superior security and identity verification (which is improving every day), industries are steadily adopting electronic signatures (especially those based on PKI). Innovative platforms like uPort (build for the Ethereum blockchain) are making it possible for individuals to have digital identities that will drastically reduce identity theft, while empowering individuals with greater control over their identities than ever before; while at the same time, improving our ability to implement KYC (know your customer) and AML (anti-money laundering) requirements. The improvements possible in this area will increase efficiency, while reducing overall transaction costs.

Implementation of Code Based Contracts on the Blockchain.

For purposes of implementing contractCode, we have initially chosen Ethereum’s Homestead release as our blockchain platform. Rather than lay out the details of Homestead in this article, we would highly recommend readers to read the overview of Homestead provided on the Ethereum website. Homestead is the second release of Ethereum’s platform. We have chosen Homestead as the platform to work with because it is without question the most advanced blockchain platform for enabling the execution of smart documents. Ethereum’s strong financial backing and incredible development team also makes them a logical leader in this space in the future. In addition, their platform is open source and capable of being used by developers with intermediate coding skills, which means a broader swath of developers and/or amateur coding lawyers will be able to utilize this platform and contribute to projects like contractCode.

Notwithstanding that our primary focus will be on the Ethereum platform, we will also be testing concepts with the Bitcoin protocol as well. As such, we welcome any insight or contributions even if they relate to the application of smart documents on the Bitcoin protocol. There are also several development teams currently developing “sidechains” built on the Bitcoin protocol. These platforms intend to provide all of the advantages of Ethereum’s virtual machine concept, but within the Bitcoin protocol. Ultimately, only time will tell which platforms will become the dominant technology or if there will exist numerous variations. As such, our efforts will be as blockchain agnostic as possible, and ultimately, our goal is to develop a platform that can be usable with virtually any blockchain.

It is our intention that this project will start with basic functionality, which may even look and feel like existing document automation systems. But piece by piece, our intention is to implement the concepts touched upon in this article. As time goes on, the capabilities will increase and more sophisticated tools, such as machine learning, will be added.

Executing Code Based Contracts as Smart Documents.

In its current version (0.0.1), contractCode provides a handful of simple, yet frequently used forms. The application allows a user to provide the information necessary to complete the form for a deal specific use; and thereafter, convert the form and information provided into a very basic Javascript object (often referred to herein as a contractCode Object). The application can then convert that contractCode Object into binary code that can reside on the Ethereum blockchain. For users who simply want to play around with the technology or just simply want to use the application to generate traditional paper documents, we hope you will find the application easy to use. For users wanting to load smart documents onto the Ethereum blockchain, we will include the ability for users to supply ether (the cryptocurrency that pays for the transactional costs to upload smart contracts onto the Ethereum blockchain) and convert their traditional contract into a smart document and upload that smart document onto Ethereum’s blockchain. For those individuals who want to venture into uncharted territory and actually upload smart documents, we highly recommend you read the Ethereum Guide, which will provide useful information on how to perform basic actions within the Ethereum environment.

As we build our library of smart documents, our initial contracts will likely fall into one or more of the following categories:

1. Traditional credit documents (commercial bank loans).
2. Multi-signature contracts.
3. Internet of Things (IoT) applications.
4. Digital services for digital payment.

We are particularly excited about the possibility of combining the power of smart documents with the IoT revolution. As more and more everyday objects, from our clothing to our cars, become networked, our ability to manage our contractual relationships with smart documents will only increase exponentially.

Implementation.

The functionality of our initial implementation of contractCode will be limited. As noted above, the initial implementations will have the look and feel of traditional document automation applications rather than a command line interface from which you can actually code contracts. But under the hood, contractCode will, even in its first iteration, be extracting contract logic and converting that logic into data structures (i.e., JSON objects). The first iteration will also allow its users to upload those data structures to the blockchain in a secure manner and allow individuals with authorization (i.e., people who hold private keys) to retrieve those legal contracts from the blockchain. This first iteration will also incorporate a built in electronic signature function that complies with the requirements of the Federal E-Sign Act and most state statutes governing electronic signatures. In addition to greater signature integrity, these early implementations will also result in legal documents that are tamper proof. In other words, once loaded to the blockchain, the record of the legal document becomes immutable.

While many large financial institutions and others are investing significant resources into developing blockchain based technology, the reality is that the ability to implement this technology in most industries is very limited today. First, most IT, security and compliance departments do not have a sufficient understanding of the underlying technology, which is to be expected at this stage of development. Second, most companies, including law firms, do not have the resources available to invest in personnel who do sufficiently understand this technology so as to be able to implement it in most enterprise settings. Third, the technology itself is still being refined, and as such, it is prudent for most companies to wait longer before expending significant resources in any particular blockchain infrastructure. Finally, there is not enough real world feedback yet to truly establish “best practices” and there are certain areas, such as key management (i.e., controlling access to specific blockchain accounts) in the enterprise setting that still need much consideration.

For the above reasons, our approach initially will be to implement a barebones platform as described above, which will also provide users with the ability to “parallel close” transactions, meaning that the documents will exist both in their more traditional written form using natural language, but also exist in parallel on the blockchain. While some might find this inefficient, we believe that this approach will ultimately lead to greater and faster adoption of this technology in the long road. The most important benefit of this approach is that it allows developers, law firms and companies (eg., banks) to be immediately exposed to the benefits of blockchain technology. The sooner everyone in a law firm and a bank understand what a blockchain is, the sooner they can start taking steps to implement the technology in more meaningful ways. In addition, even these limited implementations can provide immediate, meaningful benefits to clients. For example, a bank who implements this platform with parallel closings will benefit from even the most basic error checking and compliance modules (e.g., Regulation B logic) and reduce the effectiveness of later claims by a borrower that a document was forged or that it was tampered with after execution. At the same time, however, because the more traditional written documentation will also exist, the level of push back based on the fear of the unknown is dramatically lower. Simply put, this approach will allow us to begin implementing this platform with companies, such as banks, and law firms immediately.

As time goes on, the underlying technology will mature and become better understood by people. In addition, through limited implementation today in the real world, we will immediately begin to receive feedback that will be helpful in truly determining in which capacities these technologies offer the greatest efficiencies, and hopefully, lead us to discovering use cases not even considered today. This sort of real-time feedback from applications being put to use in the outside world provides useful information that can’t be replicated in the lab setting.

The ‘TODOS”

Interactive Front-End Interfaces for Different Transaction Types.

The ultimate goal of contractCode is to develop the underlying technology that other developers can use to develop software applications that can be used by law firms and others to implement this technology in a more user friendly environment. We feel this mission is best left to private market competition, which will ultimately produce the best and most cost effective interfaces for lawyers and others to tap the power of the underlying technology. While we provide basic input forms and a simple UI for people to use, we ultimately hope that implementations of contractCode will include far more robust user interfaces than those we are capable of providing.

Enterprise Management of Private Keys.

This is an area where tremendous resources are currently being applied in search of best practices for the management of private keys (i.e., the digital code that unlocks things) in an enterprise setting. PKI encryption and similar cryptographic systems rely on the person authorized to access or open something having possession of the private key that is necessary to cryptographically sign for a transaction. Without the private key, you can not access what you want. These systems provide incredible security. The downside is that if you lose the private key, it is lost forever. You do not get a second chance or have the ability to press a “Forgot password” button. Simply put, whatever you had is lost forever. These and other issues will require workable enterprise solutions that balance security with usability, with each enterprise needing to make decisions about how their system balances those two competing interests. For our purposes, the parallel close approach eliminates the need for a perfect enterprise solution. Even if a bank or its lawyers lost all the private keys necessary to access the electronic documents on the blockchain, the bank still has a complete set of traditional loan documents in its physical possession that it can enforce. In other words, for as long as we keep the training wheels on the bike, we don’t need to be expert cyclists. We fully expect that there will be many workable and strong enterprise solutions in the near future, at which point, the training wheels can finally come off.

Feel free to visit our site to learn more, contractcode.io. Be warned, like most things in my life, it’s usually not working…