Ricardian contract

A Ricardian contract can be defined as a single document that is[1]

a) a contract offered by an issuer to holders,
b) for a valuable right held by holders, and managed by the issuer,
c) easily readable (like a contract on paper),
d) readable by programs (parsable like a database),
e) digitally signed,
f) carrying the keys and server information, and

g) allied with a unique and secure identifier

The Ricardian contract separates the agreement of parties across time and domain. On the left of the "Bowtie" representation, the negotiation and formation of a legally binding contract leads to a single parent document that defines all of the intent of that agreement. On the right, the performance of that agreement might involve many transactions to be accounted for, logically separated from the meaning of the issue.[7] The join between the legal world and the accounting world is formed by the hash — each transaction locks in the terms and conditions of the precise deal of the parties by including the hash of the contract in every relevant transaction record, yet the operation of the transactions and the issuance of the contract are cleanly separated and thus perverse incentives are eliminated.[8]

BowTie diagram of Ricardian contract elements & generatives

The role of the Ricardian contract is to capture the contractual relationship between contracting parties to assist later performance of that contract by programs.[9] In its contractual form, it is the recording of an offer from an issuer to a holder. The offer is signed digitally within the format by the offerer, typically using a plaintext digital signature such as provided by OpenPGP.

The acceptance of the contract is typically formed by signing/agreeing to a transaction that refers to the hash of that contract. Within the context of a high-performance payment system, a secure payment will cite the hash of the contract of the instrument being paid, as well as paying and payee parties and a quantity of units.[10] In a smart contracts system, the acceptance would be performed by operating the contract's code to move the state of the agreement forward.

As a pattern in design, the Ricardian contract is like a reference – object tuple from the tradition of object-oriented programming. The reference is a cryptographic hash function, and the object is formed by writing classes that handle the type of contract needed; a factory would typically read enough of the text of the document to figure out which class type is involved, and then construct an object of that specific class over the text.

Once an object is constructed, it can be interrogated for contents: the hash, name of issuer, nature of issue, keys and signature status.

If the agreement is more complicated than a single document can describe, the documents can be chained: An acceptance of an offer can be a Ricardian dontract that includes the hash of the offer, or the acceptance can include the entire contents of the earlier phase, a design pattern known as Russian dolls[12] used by both OpenTransactions and OpenBazaar. These referral patterns can be conducted multiple times to create a chain or hierarchy of elements.

A relevant decision is choosing a representation of the text such that markup can be included to assist the software agent while maintaining readability.[13] To be a Ricardian contract, it has to be parsable both by the program and by a human reader.[14]

"Readability" is necessarily defined relative to some viewing interface. Embedded markup systems such as XML are commonly viewed not as "raw source", but with much richer formatting applied. Jurists need not view "raw" JSON, LaTeX, or XML any more than Web users must view raw HTML or hexadecimal PNG images. Some visually impaired readers necessarily use very different interfaces. Even "plain text" editors differ in the treatment of [character sets] and [character encodings], OS-specific line-ends, fonts, tabs, wrapping of long lines, etc. Even a simple text editor can be hacked to mis-display text in a desired way, just like any other software can. But with standard, non-binary data representations underneath users can compare multiple viewing solutions, and with text-based representations as opposed to binary files it is practical to check the source document directly when desired (or, as commonly done, to view fully-formatted and raw views simultaneously).

An ideal document format should also support a canonical form hash (cryptographic hash function), that is, have a way of delivering a hash over contents that does not change due to common serialisation and transmission artifacts. LaTeX and XML are suitable because their source is generally readable by humans, and they have widely-available renderers. XML also has a standardized Canonical XML form which is specifically designed to facilitate cryptographic hashing, and neutralizes minor syntactic variations such as insignificant whitespace, platform-specific line-ends, order of attributes, etc.

Popular formats such as JSON and Semantic Web formats are often, though not always, much less readable in raw form to non-programmers such as jurists, and much more subject to unbounded syntactic but not semantic variation.[15][9]

Smart contracts, as defined in the work of Nick Szabo are an abstract concept relating to the automated performance of an already agreed contract,[16] whereas the Ricardian contract is a design pattern to capture the intent of the agreement of the parties, before its performance.[17]

By means of hashes within as references or links to external documents, above, the Ricardian contract form easily extends to refer to code.[3][18] The explicit referral to the code can pass legitimacy from overarching legal prose to the code, thus implementing the concept of the smart contract.[19]

Refactoring to describe blockchains and to integrate references to smart contract logic created a hybrid version of the Ricardian contract.[18][20] This form proposes a tuple of {prose, parameters, code} where the parameters can particularise or specialise the legal prose and the computer code in order to create a single deal out of a template or library of components.[3] Also known as a Ricardian triple, it can describe blockchains, smart contracts, IoT devices and persons.

There are several explicit extant implementations of the Ricardian contract design pattern and there are some projects which do so implicitly and others which are heading in that direction.[15] Amongst those explicitly using the pattern are:

The Ricardian contract is free of any intellectual property restrictions, other than the request that any implementations cite the author and link to the paper.[30] It was fully published as design and implementation in 1996, and was described in an academic paper presented in 2004. No patent or other intellectual property mechanism was ever asserted by its inventor, Ian Grigg nor by Systemics.