In attempt to simplify the provision of legal services, legal-tech startups have made much effort at automating the process of creating contracts and extracting document data. Many founders of these startups come from within law firms, where associates and paralegals have been tasked with wading through numerous forms to search for brackets and replace with client information, prepare signature pages, organize paper into industrial file accordions and page through banker’s boxes of documents. Most transactional associates have to start here, and often commiserate, “I went to law school to learn how to do this?”

Rising in seniority means that somebody else, somebody junior, is the one that gets to be in charge of maintaining the document and on whose desk the paper lives. So, eager associates hone their skills at Microsoft Word. Ctrl + F and Ctrl + H. Search for numbers with ^#. Copy and paste style. Alt release, O release, P release.

Attorneys and paralegals become proficient at most of the process. I once worked with a paralegal who was exceptional. It was a sight just to watch him process documents for the closing of a transaction — it was as if he were playing a video game using his keyboard, and the documents were the monsters to be obliterated by firing enough bullets at them.

But even with the proficiency and the division of labor, the process is not efficient. The client with the attorney’s help has finally settled on a term sheet. The client thinks, “Great, we’ve got the deal done. Let’s get back to running the business.”

Not so fast. If all goes well, the proficient team will take the term sheet, translate the terms into long-form legal documents and simultaneously deliver the first draft of the documents to the client and the other side. In less ideal circumstances, the associate or paralegal making the initial go of the drafting hasn’t been able to free up from some other higher ranking deal, and when he or she finally gets the initial draft, it’s late at night at the end of the week after the promised date. And, the initial draft probably isn’t done — maybe an old version of the deal model was used; maybe those latest terms from recent changes in the law or industry practice weren’t added; maybe the signature blocks weren’t appended; maybe the styling isn’t consistent; maybe some of the documents are missing. So, to fix it all, the reviewing attorney takes each of the documents and reads them carefully as he or she should. The problem is that the reviewing attorney is now doing a hand markup of the document: hand-writing the provisions from the last deal, drawing the signature blocks, writing in corrected numbers from the updated model. No Ctrl + F or Ctrl + H. No copy and paste. And, both the drafter and the reviewer have expended their limited mental attention on process, only to have to review the drafts for substance once again when their brains have recovered.

Then there is negotiation of finer points in the long-form documents. The drafting side is likely to serve up a version of the documents with all of such points weighing in favor of their client (anchoring), aptly expecting that the other side will also stake out a position in the opposite direction equally offset from the yet-unknown agreeable middle ground. After a few rounds of the dance, and perhaps conference calls, re-drafts, redlines and reply-all emails, the language is settled.

While these institutions do in fact reduce entropy, the costs in terms of professional bills, the number of human hours expended by all parties, the amount of time to complete the project and potentially failed deals, is more than seems sensible.

There has to be a better way.

So, every week, another enterprising startup enters the scene aiming to revolutionize the industry.

* * * * *

Innovators have taken a number of approaches to streamline negotiated transactions, ranging from using available tools to script out the logic for complex transactions, to building complex document automation tools, to attempting to eliminate documents altogether. I describe some of the most noteworthy and touch on the resulting data.

Who Not Just Use Mail Merge and a Spreadsheet?

Anybody that has ever done a mass mailing probably has used Microsoft Word’s mail merge tools with a Microsoft Excel file containing a list of recipients. For each recipient, the Excel file contains one row with the name, salutation, address and other simple information that needs to go into the merge file. The merge file is the Microsoft Word document with snippets of code inserted to indicate where the data is to be interleaved into the document. Running the merge outputs one letter for each recipient.

This works beautifully for simple, non-conditional, non-nested data, and a long list of recipients. It doesn’t, however, work for an individual form with optional language blocks, optional paragraphs, optional exhibits and embedded lists.

Wizard + Current Form + Detailed Instructions + Straight Document Generator

Wilson Sonsini made one of the first valiant efforts at automation with their term sheet generator. This might have been a bit of a brute-force approach, though. The subject of the tool was a term sheet for a venture financing, probably one of the more complicated of the routine deals done by transactional law firms, measured by number of negotiated points. The term sheet is meant to summarize all of the major terms of the transaction, so as to minimize negotiation and re-drafting of the more detailed language in the long-form documents. Wilson Sonsini’s term sheet generator carefully describes the deal points one-by-one, taking the user through a 49-step wizard (and page reloads), and outputs the 14-page Word document. While certainly a more efficient process, it still took me 45 minutes to get through the steps, even though I was just trying it out.

Wilson Sonsini term sheet generator.

A similar approach has been taken by a number of law firms aiming to create good will, lure founders and increase their internal efficiency. Tools such as Cooley’s COOLEY GO, Goodwin Procter’s Founders Workbench and Perkins Coie’s Startup Percolator, have been made available on the web and allow founders to generate and download documents, and in some cases, sign the documents electronically. Separate versions of the tools may also be used internally to cover a wider set of transactions. Typically, the data from the web versions is periodically wiped clean from the platforms; internally, the data may be stored for later potential unknown re-use, but typically is not added to on ongoing company model.

Super Simple Wizard + Simple Documents

Others have taken an ultra-consumer-focused approach. ShakeLaw and LegalZoom, for example, provide very simple forms of agreements through web and mobile apps, walking the user through bite-sized question-and-answer screens to complete the document. In some cases, such forms may be too simple for an attorney’s liking, but this process is effective at extending legal services to the “underserved,” whose preference is for the right type of agreement that is good enough rather than the perfect agreement.

Because many forms are meant to cover a variety of circumstances, automating a form with a simple merge tool may require rewriting the variations within the form to generalize the language, or creating a separate form for each of the principal variations. Consider that Y Combinator’s Simple Security for Future Equity (the SAFE), while a very short agreement, has four variations to pick from, notwithstanding that the content of each variation is probably 90% the same. Similarly, 500Startup’s Keep It Simple Security (KISS) has two variations. Both the SAFE and the KISS are frequently made available with simple automation tools.

Web Forms

Some documents, such as nondisclosure agreements, may be simple enough that only a few pieces of information need to be inserted into the document — the party names, the date, a dollar amount, etc. Convert the document to HTML, make inputs for the data points, positioned directly on the web document, allow the user to enter the data in place, and then export the merged document. Docracy is probably the leading solution at this approach. Docracy also has a deeper level of flexibility, however, allowing the form to be edited inline, and providing an open history of inline edits using proprietary redlining/diffing algorithms — sort of a Wikipedia of legal documents.

Contract Construction

Not all types of contractual relationships have been reduced to fill-in-the-blank documents. While the direction given to many young startups is that, in the words of Chris Dixon, a veteran entrepreneur and general partner at the venture capital firm Andreessen Horowitz, “… your deal terms should be plain vanilla. Etc. These things are time tested and you are far more likely to screw things up than create value by tinkering with them,” other transactions place significant weight on unique terms underscored by significant dollar magnitudes. There may be no choice here but to piece together a transaction document for something that may never have been seen before: Find a starting point somewhere for the deal point — maybe an old transaction, maybe a contracts database, maybe a contracts-clause database; drop the clause into the document; clean up the style; and look for and correct defined terms and references to the parties of the agreements.

Two applications developed by Paper Software, Turner for Mac and Contract Tools for Word on Windows PCs, are designed to import and manipulate contracts in various formats (e.g., DOCX, EDGAR HTML, PDF, RTF and TXT) in an editor environment. The tools offer a broad set of functionality, such as web-like navigation, navigation history, term autocompletion and enhanced search, and their ability to automatically detect structure, catalogue defined terms, flag misuses and alter formatting enable the user to more efficiently build an internally coherent and consistent document. The result can then be exported as a native Word document as well as or other relevant formats.

Other approaches of constructing contracts involve breaking contracts into modular pieces, and providing workflows for piecing together a custom agreement. In this broad category, Common.Form and CommonAccord aim to build repositories of interchangeable contract clauses, and provide compiler tools to build a coherent contract.

Mature Contracts

Industries may slowly move together to agree on some common terms. And, once there is agreement on the terms, the forms can follow. Over time, the form may get rewritten so many times that transaction-specific data moves its way to the first page of the document or to a schedule of “riders”, while the language of the contract is generalized to reference the data and to cover as many situations as possible. Software developers in a similar fashion improve their applications to make the code more flexible and to cover as many likely situations as possible by refactoring the code and creating a well-documented API (application program interface).

This maturing process may be driven by an industry coalition, such as the ISDA with respect to the ISDA Master Agreement, or an intermediary seeking to reduce friction and increase transaction flow, such as securities exchanges. In the venture industry, Fenwick’s well-known Series Seed documents, while purposely eliminating more complicated market terms, have come a long ways towards reducing the need for inline changes by moving inputs to the front page.

Contract Data

The process of completing an automated document typically involves entering data into some form, which from the very start is a structured format. This set of data is really only part of the information in and surrounding the contract that is interesting to the various users.

When a company is sold to another, the purchasing company runs a “diligence” process of reviewing all of the target company’s contracts. In addition to understanding the amounts of the target company’s rights and obligations — the kind of information that may be structured during contract drafting — the purchasing company is particularly interested in clauses in a contract that may not have been part of the automated variables and thus not structured initially. Typically, such sections would include indemnity clauses (language about which party bears the costs of improbable risks), termination clauses (language that may allow one party of the contract to terminate the contract in circumstances such as selling the company), noncompete and nonsolicit obligations (language limiting the target company, and by extension, the purchasing company, from conducting some businesses), etc. Capturing this type of data typically is done manually, but automated tools such as eBrevia and kira, have been making progress with the help of natural language processing, machine learning and alternative intelligence generally, to efficiently gather the information from archives of executed contracts.

Probabilistic tools like these typically provide users with a cafeteria-style menu of types of unstructured data the software can extract, however the concept is formulated and wherever it is buried in the document. For example, if the user selects “Change of Control,” the software would identify the concept expressed directly as “change of control” or in other language such as “assignment by operation of law” or “sale of all or substantially all of the company’s assets.” Having in advance the menu of concepts that would be needed later, one wonders why the original templates of the contract shouldn’t address the points within the contract in structured format from the start. Perhaps inline tagging or embedded diligence metadata in the template could increase the probability of correct answers.

Other relevant data includes the activity of the parties to the contract when entering into the contract and events occurring after the contract is in place. Who signed, with what authority, at what time, along with corroborating information on identity (user account information, IP address, the versions of the user’s browser and operating system, the content of a drawn signature, etc.) and intent to be bound (language used to direct the user to authenticate a document, language consenting to the process, evidence of the contract being displayed and reviewed, etc.) — this set of data is the expertise of electronic signature solutions such as HelloSign. Further, knowing about the lapse of time and occurrence of other events during the life of the contract are often necessary to understand the legal effect of the agreement. Contract life cycle platforms, such as Ironclad and Concord focus on keeping track of deadlines and workflows for managing a body of contracts within an organization.

Cap Tables

A capitalization table (or cap table) is a ledger of share and debt issuances, option and warrant grants and associated vesting schedules. All data that goes into these cap tables comes from long-form legal contracts and events occurring under the contracts (e.g., the termination of an employee resulting in no further vesting of an option and the start of a period after which the option expires). The cap table allows the company’s CFO to have a high-level picture at any time of the ownership of the company.

Traditional spreadsheet capitalization table.

As the data that goes into venture financing documents often comes from the cap table (e.g., the company’s representation as to the number of shares outstanding), shouldn’t the data from the cap table also be used to generate the contracts?

By its historical nature, the cap table is a summarization of the legal documents and contains less information than the source legal documents.

Picture the legal documents as highly structured data such as might be found on schema.org. Running a query against a set of legal documents (or their blockchain counterparts as detailed below) should be able to provide all of the economic data that we currently think of as the cap table. In this world, the cap table and the legal documents are not separate. The cap table would not be the economic data, but rather the charts, graphs and analytics component of the documents.

Not surprisingly, cap table solutions are also very interested in the integration with the legal documents. eShares, for example, allows for an upload of the legal documents supporting each transaction. eShares has also favored the approach of rewriting legal documents to conform to the data structure of the cap table.

In an ideal world, everything becomes data and is interconnected in a system smart enough to guide the user through the processes in the company’s life cycle and provide management, shareholders, employees, potential investors and other stakeholders snapshot information relevant to their purpose at any point in time. While most companies focus on a smaller domain, a few others have focused on weaving together the pieces. Notably, Gust has tightly coupled or integrated in its platform incorporation, cap table, stock option valuation and expensing, bookkeeping, accounting, tax preparation, pitch decks and investor matching, for early stage companies. Similarly, Shoobx brings together document automation, cap table, stock option valuation and expensing, and transaction modelling. See also the more theoretical concept of an “Automated Credit Union for Digital Assets.”

PART II — OPEN SOURCE

Open Source and Industry Source

How do the forms become forms in the first place? Bob Gunderson, founding partner of Gunderson Dettmer, was the principal creator of one of the best-known and widely-used sets of forms in the venture industry. As a young associate, Bob took upon himself the task of gathering together many different versions of past contracts, cutting up copies of the paper documents with scissors, and laying the pieces out in a conference room, like a game of memory. This was at a time when, as attorneys remember ambivalently, circulating documents involved waiting by fax machines and redlining meant using a red pencil to strike through unwanted language when negotiating a document. Bob pulled together the best provisions and compiled them into “forms.” Together with his mentor from the law firm Cooley at the time, Bob presented the forms at a continuing legal education seminar and provided them to the audience. They also set out to formally publish them as “Venture Capital & Public Offering Negotiation,” which is still available for attorneys through Wolters Kluwer.

While most forms probably don’t have such a systematic, ground-floor approach as Bob Gunderson’s, most forms are undoubtedly an aggregation of provisions from numerous transactions and conceptually drafted by the entire industry. Just that every firm maintains its own version. The forms are like Wikipedia pages on the same subject being maintained in parallel, all being updated when one takes the initiative of entering a new provision, for example, to create the contractual private-law alternative to the most recent legislation.

Every attorney in transactional practice has to have a starting point for doing transactions, and is left with little choice but to maintain his or her own version of documents and try to be as up to date as possible with the forms. Furthermore, there is significant subtlety to the language of the contract, the final formulation of which may have taken tremendous energy to arrive at and, for the advocate, is far from unimportant. One alternative is to subscribe to a forms database, such as offered by Practical Law Company, which hires bright attorneys out of practice at leading law firms to build and maintain annotated forms for attorneys to reference and draft from. Another is to work from a set of open documents, like Series Seed, or even better known, the National Venture Capital Association’s (NVCA) Model Legal Documents.

The NVCA, a consortium of venture capital firms, corporate venture groups and their law firms, undertook the task of creating a set of industry-agreed venture financing forms. The result of the project is a very comprehensive set of transaction documents, containing many alternative formulations and rich annotations. The documents are considered heavy — lots of rights favorable to investors and burdensome for the company. Accordingly, the documents in their official form are used mostly as a reference when drafting or negotiating transactions. NVCA-lite forms, or simplified, more-balanced versions of the forms, are sometimes maintained privately and used for transactions. Analogizing to the use of source control tools in software development (“git”), it is the branches rather than the master that are actually used for the designed purpose.

Open Sourcing Automated Forms

As they currently exist, forms attempt to provide alternative formulations so the attorney can quickly move through a document using Microsoft Word, delete brackets and remove unwanted alternatives. What does it mean for a form to be automated? Quickly:

Places where data is to be inserted within the document are set as variables. Variables are named. Alternative sections of a document are also named and set as interchangeable variables. Sections that are conditional are also named as variables and can be removed if turned off.

Once the template is set up, data can be applied (often by filling out a web form), and a completed document is spit out. The work of generating the document is then limited to gathering and entering the data, the input of which may also be automated to limit data entry to only those fields that would end up being used in the template.

Templating Languages

Many web developers spend their entire careers working with templating languages, such as Mustache, HandleBars and ERB, writing code that will dynamically generate HTML to support a database-backed website. So why haven’t they borrowed these efforts to generate the XML (eXtensible Markup Language) underlying Microsoft Word in which forms are maintained?

In some cases, developers have added documents in XML form to their code repositories and used a templating language to rewrite the XML with the data of their choosing. The process tends to be more complicated, however, than writing HTML for a few reasons. First, the XML underlying Microsoft Word is also a domain-specific implementation of XML — its own language — that needs to be learned and manipulated. Second, Microsoft Word allows the user to iteratively change the style, layering in one style … over another … over another, using “WYSIWYG” (what you see is what you get) tools to generate the underlying XML. This also means that, even for the trained eye, the underlying XML often is a mangled mess and requires separate parsers to perform any manipulation. Third, the parsers that are specially designed to manipulate the XML underlying Microsoft Word, are written for … wait for it … Microsoft-based systems. This is no-go for most open-source developers (“How would I even start trying to run Windows software on my web app? Would I have to set up a separate Microsoft server as a microservice and access it over an API?”). Finally, adding the templated documents to the code repository also requires the web application to be tested and redeployed. This may put significant delay time (weeks, if not months) before the document can be used through the web application.

Why Microsoft Word?

With all this hassle, one wonders why we use Microsoft Word in the first place. At one point, Microsoft Word was the risky new word processor, and those abandoning Word Perfect for Microsoft Word were seen as mavericks. I’m not sure I actually know the answer, other than that Microsoft Word is, despite the bad mouthing, a well-developed, powerful, well-maintained, widely adopted piece of software, and to beg the question, because it is so entrenched. Ask an attorney how he or she responds if another attorney sends a PDF of a document being negotiated. The answer is always to send it back and ask for the document in Word, or to send it to the law firm’s specialized doc services team and ask them to convert the document to Word. It’s also not just the format of the document; attorneys (as do most people in non-legal contexts) care a lot about the style of the document. Times New Roman. 12 pt font. Fully justified. Document title is centered and in bold.

In-Word Templating Languages

Given that the end product of a draft almost always has to be Word, automation tools go to great lengths to integrate with Word. The most common approach is to create a Word plug-in to manipulate the underlying XML. The code references are visible in the document, but have a “magic,” “black-box” feel to them — the fields are given a gray background, and special functionality pops up when clicked.

Documents encoded with one or these tools theoretically could be open-sourced, but it seems the open-appeal of the encoding is lost. Picture these documents as open-source projects on GitHub, probably the best-known web-based repository hosting service for source code. The document itself is binary, so the text is not actually displayed in a GitHub repository, rather a “View Raw” link is displayed to download the document. Would the document be converted to a displayable version, such as markdown, and put alongside the binary in the repository? It probably would have to be, but then the magic code references are gone. Or, the document could be stored as XML, and the open-sourcing occurs at the XML level. Again, the XML is not likely to be an ideal level of “source” as detailed previously, and everybody except hard-core XML developers and the most technical lawyer is out of the project at this point.

Series Seed legal document on Github showing version diff.

Text Scripting

One open-source approach attempting to balancing the interests of the potential users is to include the automation code directly in the Word document as text and rely on a parser to handle the XML separately. In the approach developed by the author (bias warning — that’s me), variables are written in plain English, separated with underscores and namespaced by preceding each variable with “v_field_”. An example of a variable with obvious effect might be, “v_field_use_an_arbitration_clause_applicability.” The principal benefits are that the code is readable and is used to create labels for the data-entry process, the code is self-documenting, and the code is in the open for everybody to see. Importantly, the style built into a Word document remains to be applied to the result of the code. And, finally, the code does not actually depend on Word — the script is written exactly the same and can be fully executed whether the document is maintained in Word or in some other text format (assuming the Word styling machine is not an objective), giving the logic a more lasting application. And, the effort of open sourcing the document shifts toward the logic and alternatives of the document language and descriptive labels, away from the more technical aspects.

PART III — SMART CONTRACTS

Smart Contracts

The concept of the “smart contract” has taken hold and is becoming increasingly the focus of legal technology groups, such as the Computable Contracts Initiative at Stanford Law School’s CodeX, Cardozo Law School’s Tech Startup Clinic, New York Law School’s Center for Business and Financial Law, law.MIT.edu, and Computational Legal Studies.

The principal aim of the smart contract is a tamper-proof, unambiguous, computable contractual relationship whose payout (or other outcome) automatically occurs after some pre-specified event and that once started cannot be stopped, even by injunction.

The concept of an automated contract is not new. An option to purchase IBM stock at $100 on December 1 will result in an automatic payout on the contract calculated on the actual trading price of the stock on that date, is automated, but not novel. What is new and interesting with smart contracts is the attempt to generalize the concept for a wider class of contracts and to use a newer set of technologies, such as decentralized blockchains and oracles, to strictly enforce the contracts.

Data in JSON format constituting a Blockchain transaction. After reading about the SHA256 of this paper below, look for “vout,”, then the first “scriptPubKey”, then “asm” and then the digits following OP_RETURN to find the merkle root mentioned below.

The blockchain in itself is a very promising set of technologies. In very broad strokes, the blockchain is a growing sequential list of data entries that is available for anyone to copy and maintain (i.e., redundant and distributed). The patterns and computational rules for adding new entries to the list allow anyone running the software to update the list quickly and openly, with efficient and immediate mechanisms for resolving conflicting updates.

The data entries in the various blockchains range from transfer and ownership information of cryptocurrencies such as Bitcoin, to “Hello World” statements by developers playing around. Another example more relevant to contracts generally is to enter the hash or digest of a contract into a small data section (OP_RETURN) of a non-spendable transaction and then record the transaction in the Bitcoin blockchain. Because the data of the transaction shows up on every server or computer maintaining a copy of the blockchain, the contract participants can point to the blockchain to prove the existence of the content of the contract at the time stamped in the blockchain.

This hash or digest can be easily obtained (or verified) by running the electronic file of the contract through a hashing algorithm, and if the content of the file were to change in any way, the resulting hash would no longer match. This is much more easily understood by seeing it, rather than reading about it and trying to imagine what the outcome looks like — drag a file onto valcu.co/validate to see what the resulting hash looks like. Running an early draft of this article through the SHA256 algorithm resulted in the hash

faa66d25ae2d28afe73a315533cbb9401ece09cf9f0d11be3ef394782475e3d5

(When combined into a merkle tree with right proof

dad926c28eae563edfaee352091768f56ebf6d8847443e4c8df32f54be581872

the merkle root

6a880dfc2c87f7d03d0d0040ca63dc0e827ac7ebcc151f02f287067d067585b7

was pushed to the Bitcoin blockchain, the transaction of which can be viewed nicely formatted on a blockchain explorer site, or by looking at the picture of the Blockchain transaction above.)

Resulting digests for early version of the file of this paper.

Evidence of a contract on a blockchain doesn’t make the contract “smart,” however. For a contract to be “smart,” an automated change or event must be triggerable after the recording of the data and contract rules — a payment made upon completion of delivery; a legal notice transmitted after a default; title to property transferred upon ascertainable breach, etc. Setting up the smart contract requires reducing the rules to computable scripts, connecting the scripts to receive reliable sources of data or events, connecting the scripts to other external mechanisms for transmitting or effecting the change of rights, and giving life to the scripts by keeping them computing on a platform or service. The platform or service running the scripts ideally should be decentralized, and not be controlled or alterable[1] by a small group of people (e.g., Ethereum, a blockchain designed with the aim of enabling the compute necessary for smart contracts). The connectivity from the scripts to inbound data or outbound payment mechanisms can be facilitated through “oracles,” services connected to a blockchain that can handle expensive computations and maintain private data and credentials, such as provided by SmartContract.

Contract to Smart Contract

Lawyers generally think of a contact as the Word document that they drafted, sent to the other side, finalized and then was ultimately signed and scanned in, and that they could present to a judge for reading. What would need to happen to coerce the lawyer’s contract, say an offer letter for example, into a “smart contract?” It would seem odd to think that the blockchain would have anything to do with an employee showing up to work and managing a workload. In a simple offer letter, the data may include the name, title and address of the employee, the annual salary, the title of the supervisor, the start date, a statement that the employment relationship is “at-will”, affirmative confidentiality and inventions assignment obligations and a few other “boilerplate” clauses. Certainly, the final version of the letter could be hashed, with the hash added to the blockchain. Perhaps, the entire offer letter (in encrypted form) could be stored in the blockchain. The evidence of entering into the contract — for electronic signature, the IP address and user agent of the signer, the date and time stamp, the account identifier, the viewing history and a hash of a recorded signature — could be entered into the blockchain. Perhaps payroll could be tied to a smart contract on the blockchain to determine the amount of the direct deposit. More relevant, if there were a commission promised to a customer support employee based on number of calls handled in a call center, a smart contract could be set to automatically calculate call volume by the employee, reference the commission rate in the blockchain and issue the wire.

These examples are each a tiny slice of the legal employment relationship. It would seem more appropriate to apply a handful of “smart contracts” to what the lawyer thinks of as a contract. In the above example, individual smart contracts could also be applied to vesting terms, bonuses, technology transfer, annual notices and termination rights.

By extension, smart contract events should easily connect to the broader world of automation (think internet of things), though perhaps after carefully considering possible outcomes and selectively determining where it is cost-effective and beneficial to remove human judgment. In the context of the employment contract, triggering a termination event could, among other things, trigger cutting off the employee’s access rights to employer systems. (See whitepaper from the Digital Chamber of Commerce on smart contract use cases.)

Contract as Automaton

Mark Flood at the Office of Financial Research at the U.S. Department of the Treasury and Oliver Goodenough at Vermont Law School have focused their research on developing a theoretical modeling technique for asset backed securities and other historically opaque agreements. Mark and Oliver have applied the theory of the “deterministic finite automata” (or DFAs) to describe a contract model as the combination of finite states, transition rules and events. For a loan contract, potential states might include: initially delivered; principal disbursed; maturity reached; repayment not duly made; notice of default given; in default, etc. Reducing the contract to these pieces increases computability and the ability to leverage existing tools in other disciplines to measure and understand contractual relationships. The results of formalizing contracts as DFAs would include not only the above benefits mentioned with respect to contract data and smart contracts, but perhaps new information about risk at the individual contract level and in the aggregate over many contracts.

* * * * *

Where does the contract world end up? Lawyers in practice for several decades will tell you that the rate of contracting has increased significantly with the pressure to “churn out” contracts. Certainly, with automated generation of contracts, the friction of contracting will be reduced and the rate will increase even more dramatically. The data that makes up a contract will routinely be extracted, or structured from the outset, re-used in per-transaction models, or in some cases, aggregated into industry or macro models. For the U.S. Treasury, this will mean a clearer measure of systemic risk. Finally, the terms of contracts will likely be written in part to reduce ambiguity and to increase the ability to self-execute, resulting in increasingly granular contracts and perhaps accelerated contracting. And, of course, to get there the language, methods and models for working with the contracts, the underlying data and even the contracts themselves, will increasingly be formalized, standardized and brought to the mainstream.

Should we embrace the technological changes? No doubt, we should minimize process by unifying form maintenance efforts through open sourcing, organizing data to be entered only once and minimizing the amount of time taken to reach final terms. We should further enhance the usefulness of the contracts we enter into by creating greater transparency in the terms of the individual contract as well as contracts in the aggregate, integrating contract data with other systems and increasing certainty that the outcome of the agreement will occur. Further, we may have no choice but to respond to the unending demand for cheaper, faster, better.

If the transaction costs come down, do the lawyers earn less? Will higher transaction volume offset lower transaction costs? It’s not clear to me what the effect would be, but it is clear that lawyers will continually change the way they spend their time by moving upstream in the value chain where human judgment is critical, and perhaps how they measure and charge for the value that they uniquely provide to the client. Further, lawyers and other legal providers will likely develop an expertise around, and become stewards of, emerging legal tools, gaining higher productivity, leverage and competitive advantage.

[1] Much debate has been made over implications of the hard fork opted by the Ethereum community after hackers were able to exploit vulnerabilities of the DAO and steal roughly $50 million worth of funds.

* * * * *

Mark Oblad has held various legal and operations positions, and has coded a number of tools for automating transactions.

Special thanks to the following individuals for insight, comments and corrections Robert V. Gunderson, Jr. of Gunderson Dettmer Stough Villeneuve Franklin & Hachigian, Greg Raiten of FirstMark Capital, Matt Hall of Docracy, David Rose of Gust, Ned Gannon of eBrevia, Ben Whetsell of Paper Software, Kyle Mitchell of Common Form, Sergey Nazarov of smartcontract.com, Jasmine Castro-Torres of HelloSign, and Jason Boehmig of Ironclad and Series Seed.

This piece original appeared as a five-part interview with Mary Juetten on Forbes.com, linked below. Special thanks to Mary Juetten.

Legal Technology and Smart Contracts: