Lecture
Ricardian contract, invented by Ian Grigg in 1996, is a way of recording a document as a contract in law and securely linking it to other systems, such as accounting, by treating the contract as an issuance of value. It is robust through the use of identification by means of a cryptographic hash function, transparent through the use of readable text for the legal prose, and efficient through the use of a markup language for extracting important information.
A Ricardian contract places the defining elements of a legal agreement into a format that can be expressed and implemented in software. The key is to make the format both machine-readable, so that it can be easily extracted for computational purposes, and readable as an ordinary text document, so that lawyers and contracting parties can conveniently read the main provisions of the contract.
From a legal point of view, the use of a markup language embedded within a predominantly legal prose document leads to lower transaction costs, faster dispute resolution, better enforcement and greater transparency. From a computing point of view, a Ricardian contract represents a software design pattern for digitizing documents and their participation in financial transactions, such as payments, without losing the richness of the tradition of contract drafting. Publishing content and referencing it by means of a unique cryptographic message digest rules out fraud based on multiple presentations.
This method arose from the work of Ian Grigg, completed in the mid-1990s, as a contribution to Ricardo, an asset-transfer system that was built in 1995–1996 by Systemics and incorporated a template. The system and the design pattern were named after David Ricardo in honor of his seminal contribution to the theory of international trade.
Ricardian contracts make it possible to use smart-contract technology in business, for concluding legally binding agreements of any type.
A Ricardian contract can be defined as a single document that is
Diagram of a typical Ricardian contract (GRIGG, 2004). This type of electronic document can be used for several purposes, for example, to replace bidding and auction documents, financial instruments and ordinary contracts
In a number of respects, Ricardian contracts are superior to smart contracts:
Legal aspect
A smart contract is not a legally binding document; a Ricardian contract is legally binding in nature.
Purpose of the agreement
A smart contract automatically executes the terms of an already concluded agreement; a Ricardian contract, in the form of a legal document, sets out the intentions of the parties to the agreement and the actions of the parties that will take place in the future.
Flexibility
A smart contract cannot function as a Ricardian contract, which can also be a smart contract, automating actions through blockchain applications.
Accessibility
A smart contract is readable only by machines; a Ricardian contract is readable by both people and machines.
Scope of application
A smart contract is limited to a simple use case (financial transactions); a Ricardian contract can be used to conclude legally binding agreements of any type.
A Ricardian contract separates the parties' agreement in time and in space. To the left of the «Bowtie» representation [ clarification needed ] negotiation and the formation of a legally binding contract lead to a single parent document that defines all the intentions of that agreement. To the right, executing this agreement may require accounting for a multitude of transactions, logically separated from the meaning of the issue. The connection between the legal world and the accounting world is formed by the hash — each transaction is tied to the terms of a specific deal of the parties by including the contract's hash code in each corresponding transaction record, but at the same time the transaction operations and the issuance of contracts are clearly separated, and thus perverse incentives are eliminated.
The role of the Ricardian contract is to record the contractual relationship between the contracting parties, so as to facilitate the subsequent execution of that contract by programs. In contractual form, this is a record of an offer from the issuer to the holder. The offer is digitally signed by the offeror, usually using a digital signature in plaintext format, such as that provided by OpenPGP .
Acceptance of the contract is usually formed by signing / agreeing to a transaction that references the hash of that contract. In the context of a high-performance payment system, a secure payment will reference the contract's hash code for the instrument being paid, as well as the payer and payee parties and the number of units. In a smart-contract system, acceptance will be carried out by means of the contract code, in order to advance the state of the agreement.
Typically, signing of the contract by either party is done openly using a private key. The signature of the initial offeror is usually located above the original document, and is then added to form a fully binding, readable offer for the assets described in the document.
The subsequent participation of the parties in the contract, such as payments or the execution of a smart contract, is usually signed with a hash identifier (generated by a cryptographic hash function) over the signed original document. Unlike the initial signature, the use of the contract's hash in subsequent transactions also signals intentions and forms a hidden signature over the contract. Although private-key signatures are well studied and fall under legal frameworks such as the European Digital Signature Directive, Grigg suggests that a trail of hashes — entanglement — forms more effective evidence of intent , than a private-key signature.
As a design pattern, a Ricardian contract is similar to the 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 required type of contract; a factory, generally, needs only to read the text of the document to determine which class type is involved, and then construct an object of that specific class over the text.
Once the object is created, it can be queried for its contents: the hash code, the issuer's name, the nature of the issue, keys, and signature status.
If the agreement is more complex than a single document can describe, documents can be linked into a chain: acceptance of an offer can be a Ricardian contract that includes the hash of the offer, or the acceptance can include all the contents of an earlier phase, a design pattern known as Russian dolls , used by both OpenTransactions and OpenBazaar . These forwarding patterns can be used multiple times to create a chain or hierarchy of elements.
A suitable solution is to choose a text representation such that markup can be included to help the program agent while preserving readability. [13] For a contract to be Ricardian, it must be parseable both by a program and by a human reader.
"Readability" is necessarily defined relative to some viewing interface. Embedded markup systems, such as XML, are usually viewed not as "raw source" but with the application of richer formatting. Lawyers do not need to view "raw" JSON, LaTeX, or XML files, just as internet users do not need to view raw HTML images or hexadecimal PNGs. Some readers with impaired vision necessarily use very different interfaces. Even "text" editors differ in their handling of [character sets] and [character encodings], OS-specific line endings, fonts, tabs, long-line wrapping, and so on. Even a simple text editor can be hacked to fail to display text in the desired way, just like any other software. But with standard, non-binary data representations underneath, users can compare multiple viewing solutions, and it is practical to check the source document directly when necessary (or, as is commonly done, to view fully formatted and raw representations simultaneously).
An ideal document format should also support a canonical-form hash function (a cryptographic hash function), that is, it should have a way of producing a hash code for content that does not change due to common artifacts of serialization and transmission. LaTeX and XML are suitable because their source code is typically human-readable and there are widely available rendering tools for them. 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-dependent line endings, attribute order, and so on.
Popular formats such as JSON and semantic-web formats are often, though not always, far less human-readable in raw form for non-programmers such as lawyers, and are much more susceptible to unrestricted syntactic, but not semantic, variation.
Smart contracts, as defined in Nick Szabo's work, represent an abstract concept relating to the automatic execution of an already agreed contract, [ whereas a Ricardian contract is a design template reflecting the intent of the parties' agreement prior to its execution. representation.
By means of hashes inside as links or references to external documents, the Ricardian contract form described above is easily extended to reference code. An explicit reference to code can transfer the legitimacy of comprehensive legal prose to the code, thereby realizing the concept of a smart contract.
Refactoring to describe blockchains and integrating references to smart contract logic has created a hybrid version of the Ricardian contract. This form proposes a tuple {prose, parameters, code}, where the parameters can concretize or specialize the legal prose and the computer code so as to create a single transaction from a template or a library of components. Also known as the Ricardian triple, it can describe blockchains, smart contracts, Internet-of-Things devices, and people.
There are several explicit existing implementations of the Ricardian contract design template, and there are some projects that do this implicitly, while others are moving in this direction. Among those explicitly using this template:
| Project | Comment | Project Lead |
|---|---|---|
| Ricardo | An early payment system using a cryptographically signed tree of transactions, which was the first implementation of «triple-entry accounting». Ricardo was originally developed by Systemics Ltd. using SOX (Systemics Open Transactions) technology. Early applications included DigiGold, an online payment system 100% backed by gold. | Ian Grigg |
| Open Transactions | «Open-Transactions implements financial instruments in the form of Ricardian contracts, which are contracts that can be understood by people and can also be manipulated by software». Like Pretty Good Privacy, Open-Transactions protects financial transactions using several cryptographic algorithms. | Chris Odom |
| OpenBazaar | «A Ricardian contract is a means of tracking the liability of one party to another when goods are sold to each other on OpenBazaar. In essence, the contract represents a single unit of a good or service. Ricardian contracts should be used on OpenBazaar because they are a means of effectively tracking legally signed agreements between two parties that cannot be forged after the contract is signed. Ricardian contracts use a digitally signed chain of contracts and checksum hashing to create an immutable record of an agreement for exchange over a peer-to-peer network". «Trades on the OpenBazaar network are based on Ricardian contracts, i.e., an electronic document defining the terms of trade so that it can be read by both computers and people and carries a cryptographic signature. Besides selling physical and digital products, OpenBazaar can also be used to trade speculative contracts, which can easily be represented by Ricardian contracts» | Washington Sanchez |
| Monax Legal Markdown | Allows dual integration of smart contract code and prose contract language. Monax uses a beacon — or agreement beacon — as the smart contract in the Monax Digital Agreement platform. This allows users to manage and automate business obligations, tasks, and procedures associated with digital contracts in real time. | Nina Kilbride, Casey Kuhlman |
| Askemos | Ricardian contracts are described as a reification of the Askemos class. Askemos uses a set of collaborating «notaries», or nodes, to securely exchange information. These notaries can operate an autonomous «agent». An agent is an operation performed by each notary based on consensus. A user's personal notary can sign their information before passing it on to other users for reconciliation. The representation of the information can be regarded as a Ricardian contract. | Jörg Wittenburg |
| Barclays' Smart Contract Templates | Ricardian contracts are described as the foundation of «an agreement whose performance can be automated and enforced». Further information can be found in Smart Contract Templates: essentials, design landscape and research directions |
Dr. Lee Braine |
| R3's Corda | «Corda is a distributed ledger platform designed and built from the ground up to record and automate legal agreements between identifiable parties. It is heavily influenced by the requirements of the financial industry, but we believe the community will find the underlying architecture suitable for a wide range of applications". Corda combines the Ricardian contract with the smart contract. Unlike bitcoin, access to Corda blockchain data is restricted. It was designed for the financial world to handle securities, derivatives, and payment contracts. |
Richard Gendal Brown |
| LTO Network | «A Live Contract fits the definition of a Ricardian contract. In particular, it is easily read by both people and programs. This is an inherent property of the Live Contract, which results from the way it is defined. There is no separate natural-language version for legal purposes and a coded version for program execution". LegalThings One Live Contracts were renamed LTO Network in September 2018. LTO Network is a production-ready blockchain that digitally verifies digital assets, enabling collaboration using decentralized workflows. | Arnold Daniels |
| Mattereum | «Mattereum will create a set of accessible natural-language contracts and corresponding smart contracts to facilitate common legal tasks such as the purchase, auction, and rental of physical property, the licensing and transfer of intellectual property, and the conclusion of contracts for professional services». Mattereum will act simultaneously as a provider of smart contract templates and as an arbiter in dispute resolution and edge cases. | Vinay Gupta |
| Chamapesa | A chama (investment), or group micro-savings scheme, is an informal community savings circle used in East Africa, primarily Kenya. Chamas allow community members to save money and invest in local entrepreneurial ventures. The Chamapesa app connects existing chamas, built on social relationships, with an immutable ledger for digitized bookkeeping, improved security, and reduced fraud. Chamapesa CEO Ken Griffith extended the Ricardian contract by inventing the «distributed Ricardian contract» to offer a «decentralized, asset-backed digital currency». | Ian Grigg, Ken Griffith |
| Tokenized | «Our smart contracts are a comprehensive form of Ricardian contracts, which allow for machine-readable/enforceable terms alongside human-readable prose». Tokenized helps people write, manage, deliver, and trade various smart contracts from the start to the end of the commercial lifecycle. | James Belding |
The Ricardian contract is free of any intellectual property restrictions, other than the requirement that any implementations cite the author and reference the paper. [47] It was fully published as a project and implementation in 1996 and was described in an academic paper presented in 2004. Neither its inventor, Ian Grigg, nor Systemics has ever claimed any patents or other intellectual property mechanisms.
Comments