Ricardian contracts: A smarter way to do smart contracts?

Smart contracts – self-executing pieces of computer code recorded on a blockchain – have been accused of being neither smart nor contracts. Ricardian contracts revisit contract automation from a different angle, potentially benefiting issuers of financial instruments, parties to derivatives and banks, while eventually transforming the practice of law.

A contract created by this contract assembly technique is thus readable by both humans and machines. A Ricardian contract should generally be legally enforceable, but will also lend itself to analysis by and interaction with software.¹ On the technical side, most implementations envisage that parties enter into a Ricardian contract by applying their cryptographic signatures, after which the contract is recorded on a blockchain (although this is not strictly necessary) and assigned an automatically generated unique number (hash), ensuring that the document so deployed represents "the single version of the truth."²

Why "Ricardian" contract?

• Named by Ian Grigg, the computer scientist who first proposed the concept in the 90s, after Ricardo, a system for trading financial securities developed at Systemics and co-designed by Grigg.
• The Ricardo system was in turn named after David Ricardo, a 19th century British economist known for his contributions to international trade theory.³

Sounds great, but why bother?

From dead paper to Contract-as-Software: use cases and benefits of the Ricardian approach⁴

1. (Semi-)automated execution / on-click performance of obligations:

• the contract is directly connected to and can manipulate (i) enterprise software controlling payments and accounting; (ii) banks' payment systems; and (iii) asset title and commercial registers (e.g. land registry, companies registry, securities depository)
• the loan contract repays itself (under normal conditions), periodically drawing upon data from the repayment schedule and base interest rate external data feed ("oracle") to calculate the margin

2. Streamlined contract management / parties know what to do at any point of the contract's lifecycle:

• the contract is not (only) a written document, but a software application with user interface for execution, performance, administration and interpretation ("Contract-as-Software") 
• the contract alerts parties ahead of transactional milestones or deadlines
• selective permissions for users to interact (only) with certain provisions can be assigned in line with the organisational structure (read-only to full admin privileges); each user's action is recorded on a shared ledger
• the signing phase is automated; so is the validation of signatory's authority – e.g. the CEO's credentials are cross-referenced with the companies register to ascertain the authority to sign on behalf of the company; the system can disallow execution of the contract if the check returns negative

3. Easier interpretation / ask the contract what it means:

• a user can ask a contract to create its lifecycle timeline, identify all possible scenarios (a scenario tree), create lists (e.g. "list all conditions precedent", "show all documents required at closing"), etc.
• interconnection with other Ricardian contracts: highlighting conflicting provisions within the organisation's contract portfolio
• streamlined due diligence / big data analysis – large-scale document analysis produces more relevant insights faster, since provisions are recorded in machine-readable language and/or tagged with metadata ("show me the percentage of contracts with change of control provisions / governed by non-domestic law"); could improve accuracy of artificial intelligence-powered document review solutions if these are trained to recognise Ricardian syntax
• hovering over a definition instantly reveals its meaning

4. Simplified compliance / contract interacts with legislation, courts and regulators:

• the contract can be plugged into regulators' systems for regulatory reporting obligations or to monitor compliance in real time
• courts can be granted "judicial override" over the contract, enabling them to reverse transactions or void the contract entirely – "Ricardian judgments"
• interconnection with "Ricardian legislation" – contractual provisions adapt on the fly if relevant legislation changes

All the above may in turn result in reduced administration, compliance, performance, interpretation and enforcement costs and increased transaction security.

2. Smart contracts vs. Ricardian contracts

For clarity, this article distinguishes between the concepts of Ricardian and smart contracts and considers the latter a computer code deployed on a blockchain which performs a predetermined action upon the satisfaction of predetermined conditions.⁵ The most commonly known instance of the latter are smart contracts running on the Ethereum platform. This is a simplification, of course, and the term smart contract is often used broadly to cover Ricardian documents as well. The definition nevertheless seems to correspond to the common understanding of the smart contract in the blockchain / developer community, and is thus adopted here. What, then, makes a Ricardian contract different from a smart contract?   

2.1 Are smart contracts smart?

Smart contracts are – at least in technical circles – sometimes perceived as superior to the old-fashioned paper variety because they are

• immutable: contractual terms cannot be changed once the contract deploys on a blockchain, meaning that a party cannot falsify the terms to defraud the other party (high fraud resistance); and
• self-executable: contract performance is automated (pre-programmed). The contract performs what it was told to do when it was drafted (e.g. sends funds to an address on a specified date) without the need for any human action.

Among lawyers, however, these features are bound to raise eyebrows. Immutability indeed makes the contractual provisions (or rather, the code) tamper-proof (although business lawyers may be excused if they fail to see sophisticated parties forging contractual documentation as a pervasive problem).⁶ However, if parties wish to terminate their commercial relationship at some point, they will not appreciate their now obsolete smart contract remaining operational on a blockchain, possibly forever. Arguably, this downside to the immutability of smart contracts can be addressed by coding them with a self-destruct function (a kind of programmatic "long-stop date").

Self-executability sits much less comfortably with the commercial reality. Sophisticated legal contracts indeed attempt to regulate for many different fact patterns which may affect the transaction or a contractual relationship post-signing, but can never hope to address all of them.⁷ Instead, lawyers use behavioural principles or references to legal standards, refined through centuries of legal precedent and theory, to strike a balance between predictability of counterparty performance and flexibility in scenarios which are not explicitly anticipated in the contract negotiation phase.⁸

Smart contracts, on the other hand, will only self-execute in a manner which was coded into them at their inception, and are able to do so only in accordance with unambiguous formal logic, i.e. if X, do Y, where X and Y can only be objective, pre-defined, digitally manifested events or actions. As with regular contracts, anticipating (and regulating for) all possible states of the world relevant for a particular contractual lifecycle remains unfeasible.⁹ Much less does the current state of technology allow smart contracts to reliably execute clauses requiring prior interpretation of non-deterministic provisions, such as "best effort" obligations, performance of "good faith determination" or decisions whether counterparty's consent to a certain request was "unreasonably withheld." These terms may irritate coders for their slipperiness, but in fact serve societally beneficial purposes,¹⁰ especially in so-called relational contractual relationships,¹¹ where the subject of regulation is the parties' long-term relationship and not a one-off transaction. If one party insisted on determining every detail of the relationship up front, there may not be an agreement at all. In another instance, a party may – contrary to the ruthless logic of self-executability – refrain from enforcing a particular contractual term, perhaps in the interest of preserving the relationship.¹²

These considerations remain beyond the reach of the current conception of smart contracts.¹³ Therefore, they remain limited to a very narrow set of use cases, where the performance is subject to purely deterministic conditions. One example is parametric crop insurance, where a smart contract policy automatically pays out policyholders in case official rainfall data for the region turn out to be below the defined threshold.

Smart contract vs. escrow agreement

The operation of a blockchain-enabled smart contract can be roughly compared to a real-world escrow agreement commonly used in share purchase transactions. A notary, bank or securities depository acting as an escrow agent will agree to perform a very straightforward set of "if-then" instructions, e.g. "upon receipt of a completion notice signed by both parties, simultaneously release funds to the seller and effect the transfer of shares to the buyer." Typically, an escrow agent will not undertake to legally interpret semantically ambiguous non-operational clauses, such as "if, in the reasonable view of the escrow agent, the seller has procured best efforts to deliver sufficient evidence of the satisfaction of condition precedent under clause XY, the escrow agent shall release the purchase price to the seller's bank account and transfer the securities to the buyer's securities account." By the same token, a smart contract will not be useful to execute this kind of instructions.

2.2 How are Ricardian contracts smarter?

In the words of Ian Grigg, the Ricardian approach has its cake and eats it too.¹⁴ A commercial contract will usually contain both purely deterministic provisions, as well as the fuzzy catch-all clauses beloved by lawyers. In a Ricardian document, the former are expressed through formal logic and are thus machine-parsable (yielding themselves to manipulation by software), while the latter can remain in their natural language form to be interpreted and acted upon by humans as needed. The drafter can thus apply just the right degree of automation appropriate for the contractual term in question:  

• some (possibly few) clauses may be drafted as self-executing¹⁵ (maybe taking data from an oracle data feed), and will automatically perform a default action (e.g. repay a loan) unless overridden; these clauses behave rather like a smart contract as defined here¹⁶
• other clauses will require humans to interpret and act upon them, but their performance may still be digitised (on-click)¹⁷
• all clauses, however, can be equipped with tags and metadata, which will enable the machine to tell the human what these terms are and what and when they should do something about them, at individual document level or at scale ("show me all forum selection clauses in all agreements my company is a party to")   

In short, the Ricardian approach demonstrates that contracts can benefit from automation without simultaneously being reduced to blindly executing pre-defined instructions. Self-executability is not a necessary (or the singular) feature of contract automation, as shown by the list of potential use cases in section 1 above.

Ricardian or Ricardian-like projects under development

• ISDA's digital representation of Common Domain Model (CDM),¹⁸ "a standard digital representation of events and actions that occur during the life of a derivatives trade, expressed in a machine-readable format;" link to ISDA's demo video  
• Barclays' Smart Contract Template on R3's Corda shared ledger platform¹⁹ – link to demo video
• CommonAccord, "an initiative to create global codes of legal transacting by codifying and automating legal documents, including contracts, permits, organisational documents, and consents"
• Legalese, "deep-tech" start-up developing "domain specific language (DSL)", to eventually support a computational law ecosystem
• EOSIO, "blockchain architecture designed to enable vertical and horizontal scaling of decentralised applications" plans to enable Ricardian contracts on its platform
• OpenBazaar, a decentralised blockchain-supported marketplace, uses Ricardian contracts to memorialise transactions between parties
• SmaRT, RegTech-oriented Ricardian solution ("Ricardian regulation")    

3. Looking ahead

Ricardian contracts, while showing promise, face two key challenges for widespread adoption:

• Need for standards and infrastructure
  • The development of a standardised legal mark-up language or controlled legal natural language²⁰ (i.e. formalised language which ideally would be easy enough for lawyers to use but also deterministic enough to be readable by software – somewhere between Solidity, the programming language used for writing smart contracts on the Ethereum platform, and legalese) will likely be crucial for the widespread adoption of the concept. Getting the standard language right will also be key in bridging the "translation problem" – the risk of inconsistency between the natural language and machine-readable parts of a Ricardian document.²¹
  • For the Ricardisation of the existing contractual templates to make sense, a wide array of commercial actors as well as governmental entities (such as banks, securities depositories, land registries and companies registries) will need to make their systems and infrastructure interoperable and compatible with contract automation tools and standards.
• Acceptance by courts and legislation
  • Human readability is at the core of the Ricardian concept. In terms of enforceability this should mean that the courts should treat them no differently than standard textual plain-text contracts. Whether this in fact proves to be the case will largely depend on implementation. The translation problem (i.e. the discrepancy between human and machine renderings of the contracts) may pose additional interpretational difficulties.
  • The corollary of the digital infrastructure needed to support Ricardian features is the corresponding legal infrastructure. In many jurisdictions, the legislation already equates digital representation of legal documents with physical form under certain conditions, and provides a legal framework for the use of e-signatures. However, additional legislative action will likely be needed to explicitly provide for the legal validity of the Ricardian contracts' interactions with government-run systems (e.g. that the parties can consummate the real estate sale transaction by directly plugging their agreement to the land title register)

4. References and sources (all links as available on 19 January 2019)

The prose (natural language) version of the document shown in the example in section 1 is available here and the structured language version (machine-readable syntax) is available here. Both originate from CommonAccord's library of prose objects.

The author would like to thank Irene Ng Šega and Derrick Ng for their helpful feedback to the first draft of the article.