Where is Legalese Headed?

… before full DAOs, the blocking and tackling of encoding simple business contracts could be a good next step for smart contracts.

We’re building the Computational Legal tech stack. At the bottom, we’re contributing languages and compilers. At the top, we’re making apps.

  • v1 and v2 handle all paperwork needed for seed investments. v1 is ready – see Documentation. v2 will launch early 2017.
  • v3 is in research stage. We’re building L4, a Turing-complete language which satisfies the formalism requirements of Hvitved 2012.

Background and Context

Original Motivation

How did we get the idea to represent contracts as code? Once upon a time, a programmer received an investment contract containing the following text:

If the investment for the purpose of the Series B Funding is valued at not more than $32.5 Million, then the investors in the Note shall be entitled to convert the Note into Shares at a fixed valuation of $27.5 million.

If the investment for the purpose of the Series B Funding is valued at less than $40 million but not below $32.5 million, investors in the Convertible Note will be entitled to convert the Note into Shares at a 15% discount over the valuation of the Series B Funding (for instance, if the series B Funding is at a valuation of $35 million, then the investors in the Note shall be entitled to convert at a valuation of 35M less 15% discount);

If the investment for the purpose of the Series B Funding is valued at not less than $40 million but less than $47.06 million, investors in the Convertible Note will be entitled to convert the Note into Shares at a 15% discount over the valuation of the Series B Funding (for instance, if the series B Funding is at a valuation of $47.06 million, then the investors in the Note shall be entitled to convert at a pre-money valuation of 40M i.e. $47.06 million less 15% discount);

If the investment for the purpose of the Series B Funding is valued at not less than $47.06 million but less than $80 million, investors in the Convertible Note will be entitled to convert the Note into Shares at a fixed pre-money valuation of $40 million;

If the investment for the purpose of the Series B Funding is valued at not less than $80M but less than $100M, investors in the Convertible Note will be entitled to convert the Note into Shares at a fixed pre-money valuation of $45M; and

If the investment for the purpose of the Series B Funding is valued at not less than $100 million, investors in the Convertible Note will be entitled to convert the Note into Shares at a fixed pre-money valuation of $50 million.

Ten minutes and a strong cup of tea later, the notes in the margin read:

// why wasn't this just
if     ( seriesB < 32.5 )  { conversion = 27.5 }
else if( seriesB < 40 )    { conversion = seriesB * 0.85 }
else if( seriesB < 47.06 ) { conversion = seriesB * 0.85 } // then why the above line?
else if( seriesB < 80 )    { conversion = 40 }
else if( seriesB < 100 )   { conversion = 45 }
else                       { conversion = 50 }

What if contracts could be written in a formal language first, and then compiled to natural language? A simple but powerful idea. Imagine contracts in English, Spanish, French, German, Chinese – each translation provably identical to the others. Contracts amenable to testing and formal methods: static analysis can prove that a contract is internally consistent, free of contradiction, and complete. Contracts that self-execute in software, integrated with business processes, interacting with other contracts. Contracts that easily afford illustrations, use cases, and scenarios, for end-users to reason concretely over. This vision has been expressed by Nick Szabo (2002), by Harry Surden (2012), by Flood & Goodenough (2014), by Camilleri, Paganelli, & Schneider (2014), by Prisacariu & Schneider (2007).

Even lawyers feel the pain

Howard Darmstadter’s Precision’s Counterfeit: The Failures of Complex Documents, and Some Suggested Remedies, published in the American Bar Association’s Business Lawyer journal in 2010, reads like both a clarion call – “there’s got to be a better way!” – and a grope in the dark – “one possible idea: don’t repeat yourself” – by someone who, being a lawyer not a programmer, has no exposure to the disciplines and possibilities of software engineering and language design. Indeed, he talks about debugging contracts as programs; he talks about testing; he talks about using mathematical notation, even flowcharts, to improve clarity. But as a lawyer he doesn’t know where to go next with these ideas. Lawyers don’t get CLE credits for reading Steve McConnell. Lawyers haven’t heard of language-oriented programming or UML/BPML, whose history has much to teach. Yet contracts are, effectively, business process specifications, where they skip over the high-level modelling and go straight to writing a low-level runtime by hand … using a collaboration methodology that could only be described as pair programming by correspondence, the way chess used to be played during the Cold War.

So, even lawyers are begging for this stuff. Who better to give it to them than us computer scientists? After all, we already invented DRY; we have a moral obligation to help them avoid reinventing our wheels.

Besides, programmers know very well the XY problem: “newbies ask how to do Y, when they really want to achieve X, but Y was the first thing that came to mind.” Darmstadter describes the problem without knowing its name when he suggests that contracts should try to specify why before implementing how. Darmstadter alludes to literate programming, again without knowing its name, when he suggests that maybe contracts should include comments, or remarks, to help clarify the intent of a piece of code. The paper is a fun (and cringe-inducing) read.

Some legal thinkers have explored correspondences between law and software. These explorations are fruitful: in 2006 Henry Smith considered Modularity in Contracts: Boilerplate and Information Flow. In 2016 Primavera de Filippi and Samer Hassan wrote From code is law to law is code.

Explorations into other correspondences will prove equally fruitful.

BigLawKM has an essay touching on some of these points: Smart Contracts and the Role of Lawyers. More practically, thelawlab sketches the future study of law in The MIT School of Law? A Perspective on Legal Education in the 21st Century.

Premises and Postulates

  1. Consider what programmers do when they write programs. Consider what lawyers do when they write contracts.
  2. Each world is rich with its own body of practice and disciplines of thought. And the similarities are striking!
  3. What would it take to wrestle these worlds into conjunction?

How is this useful?

Example: conversion of debt

A startup raises Series A – yay! A stack of convertible notes had been signed a couple years ago, during the seed round. How do the notes convert to equity? What’s the conversion price? How many shares will be issued?

In the old days, a lawyer would read each agreement to answer those questions.

With Legalese, the convertible notes contain event handlers. Assuming the Series A is already parameterized in L4, we hand the Series A to the convertible note, and the callbacks automatically compute the share price and produce all the paperwork to effect the conversion.

Example: Vesting Redemption

A founder leaves a startup during the vesting period. The company has the right to buy back a number of unvested shares. How many? And at what price? And at what date? What does the cap table look like before and after?

In the old days, a lawyer would read the vesting agreement to answer those questions.

With Legalese, the vesting agreement contains event handlers. We call the appropriate callback with details of the departure, and Legalese generates all the paperwork needed to confirm the resignation.

What Legalese Will Never Do

Turing-Complete Contracts

The Legalese team has started work on L4, a (yet another) DSL for expressing regulations and contracts. This is a research project. Software eats law in a specific way: it gets Turing’d, by way of a domain-specific language. (Lawyers, don’t worry; you’ll keep your jobs.)

The goal? To enable a lawyer – better yet, a non-lawyer – to draft a contract more concisely and clearly than they could in a natural language, by writing what looks like computer code. The drafter gets to take advantage of all sorts of ideas from computer science: variables, functions, third-party libraries, syntax and type checking, unit testing, completeness, and consistency. And the drafting community can get ideas from software engineering, like collaborative version control and opensource community support practices. The contract can be tested by fuzzing against future scenarios of breaches, possible legal challenges, and simulated courtrooms.

As Frederik Pohl might put it, a good futurist predicts the car; a great futurist predicts the traffic jam. If the car is a formal language for contracts and agreements (maybe even legislation), then a taxi service might be smart contracts integrated with cryptocurrencies and wholly automated business processes, exposed through legally binding APIs. The traffic jam? Maybe that’s a DDOS in the form of micro-contract spam, a welter of frivolous lawsuits, or a zero-day exploit of an error enshrined in some old piece of paperwork that didn’t get patched with the latest service pack.

Some initiatives are aligned with this vision:

The Business Challenge

Very clever people have thought long and hard about a world in which computers execute contracts, where programs transfer money to people and people transfer money to programs, where decentralized cryptocurrencies disrupt banks and financial institutions. Very clever people will be involved in the effort to build a bridge between formal and natural languages. Many man-years will go into developing a Github/Wikipedia of legal templates that are freely available for all to use.

Legalese is clever in a different way. The business challenge of getting from the 20th-century status quo to the 21st-century promised land requires the ability to scout and climb a monotonically increasing path through multidimensional “value-proposition” space toward the global optimax. This is as much a logistical and business challenge as a computational linguistics challenge. That’s why we’ve chosen to start with spreadsheets: we optimize for the power user while building a painless onboarding pathway for first-timers.

You know how some extreme runners run fifty marathons in fifty consecutive days? Actually running the marathons is one kind of challenge. Arranging the flights, travel, and accommodation so the runner gets from finish line in one city to starting line in another, is a different kind of challenge. Developing a domain-specific language, or a library in which to model contracts, is the former kind of challenge. Making Legalese succeed as a business is the latter kind.

Natural Language Generation

Text planning and interaction effects are critical to contract generation. One part of a contract may affect another. Sometimes these interactions are simple, and can be represented by a DAG. Sometimes these interactions are, superficially and conventionally, cyclic, and need to be decomposed with some clarity. Metaprogramming helps to correctly represent these interactions. CoGenText is an example of an NLG company. See also GrammaticalFramework and Attempto English.

Social Implications of Agile Contracts

(Written as a response to a thread on HN.)

Today’s model of contracting is fire-and-regret: spec out as much as you can of the next five or ten years, and when the world changes, litigate. That’s not very agile. And unfortunately for the non-agiles, Hart and Holstrom won the 2016 Nobel in Economics for pointing out the futility of the idea of a complete contract.

What’s the alternative? Hirschman remarked that your voice sounds loudest when you are closest to exit. What if every contract had a maximum term of one year, one month, one day? What if we treated contracts as an iterated stream instead of an immutable invariant? For example, think about how “no-contract” phone plans have made the telco market more competitive, to the benefit of the consumer. Power imbalances might be reduced precisely because nobody’s locked in: it’s a lot easier to break up when you’re just dating. After the marriage you might let yourself go.

Software is eating law, but “law is code” is only the first step. Just as the historic transition from proprietary to opensource informs ideas like “Github for law”, the historic transition from waterfall to agile will find its analog in the legal and business domains by changing the way we develop and deploy contracts, ultimately driving changes in economic relations.

Think about how agile development means less software project failure, and less software project failure means less litigation between client and outsourced development vendor. That’s just one example. If better tools and languages mean that we can better transform our intent into specification, we might be forced to be clearer about what we actually do and don’t agree on, we might be more honest in our dealings, there might be an actual “meeting of minds”, and when things don’t turn out the way we expect, rather than blaming the other party, which seems dysfunctional, we embrace change together, and agree to consciously work on the relationship, to improve the next iteration of the contract … which is due to be revised and renewed anyway, next month, not next decade.

Amber fast-forwards through the dynamic chunks of the README—boring legal UML diagrams, mostly—soaking up the gist of the plan. Yemen is one of the few countries to implement traditional Sunni shari'a law and a limited liability company scam at the same time. Owning slaves is legal—the fiction is that the owner has an option hedged on the indentured laborer's future output, with interest payments that grow faster than the unfortunate victim can pay them off—and companies are legal entities. If Amber sells herself into slavery to this company, she will become a slave and the company will be legally liable for her actions and upkeep. The rest of the legal instrument—about ninety percent of it, in fact—is a set of self-modifying corporate mechanisms coded in a variety of jurisdictions that permit Turing-complete company constitutions, and which act as an ownership shell for the slavery contract. At the far end of the corporate shell game is a trust fund of which Amber is the prime beneficiary and shareholder. When she reaches the age of majority, she'll acquire total control over all the companies in the network and can dissolve her slave contract; until then, the trust fund (which she essentially owns) oversees the company that owns her (and keeps it safe from hostile takeover bids). Oh, and the company network is primed by an extraordinary general meeting that instructed it to move the trust's assets to Paris immediately. A one-way airline ticket is enclosed.
Accelerando, Charlie Stross