The documents known as Ricardian contracts are the essential method to describe "value" in financial cryptography. The Ricardian contract is both a document that presents a form for a legal contract, and a design pattern to incorporate that document securely into an accounting system. When used properly, they are pervasive, being found in some sense from the client GUI layer down to the secure Internet protocol level.
Note, graphics 2,4,5,6 to the right are my annotations over a superb schema done by the OpenBazaar project, which is described a little in the Implementations page.
"O ye who believe! When ye deal with each other, in transactions involving future obligations in a fixed period of time, reduce them to writing."
-- Holy Quran, 2:282
In the simplest possible terms, a Ricardian contract is a document defining a valuable thing, such as the issuance of an asset over the Internet.
Our implementation is an Ini-formatted text file that is both human readable and program parsable. It identifies a Legal Issuer and includes all the clauses the Issuer sees fit to add in to make the document stand as a contract.
The document is signed in cleartext form by the Legal Issuer's contract signing key. The appropriate keys are included to verify the chain of integrity. Hence, the Ricardian contract is generally self-verifying.
A unique identifier is formed by a canonical message digest (hash) which provides a secure (unforgeable) identifier. This identifier is then placed in every transaction as the descriptor to the issuance or instrument, thus forming a secure link from the written contract to every transaction in the accounting system.
"Ignorance, the root and stem of all evil."
-- Plato
The original mission of the Ricardian contract was to provide a document that can be a primary contract for the issuance of a digital asset.
"Feels like a contract." As a contract, parties to the contract should be identified, and signatures affixed. It should look and feel like a contract.
"One Contract." There is no other document. A lawyer, judge or arbitrator can unambigiously work with the Ricardian contract in order to resolve disputes. As these parties prefer to work with the source document, it must be the primary.
"It's an Asset." The document must describe the digital asset, and this must be parsable by programs.
"Protection." Issuance implies that other parties, agents performing roles within the issuance, should be identified, and thus signatures and authentication should be included to point to them.
The ultimate test of our mission is if the legal profession can take a Ricardian contract and unambiguously decide points of dispute.
Note that other implementations have found other missions for the design pattern.
Documentation is a little scattered. Here's some from the various sources:
Mark Miller kindly presented the paper " The Ricardian Contract" to IEEE's Workshop on Electronic Contracting for me in my absence. There are some additional writings on Requirements which were culled from the original paper.
Some or many
Implementations of Ricardian contracts
are described, but this is more my notes than
an accurate index.
You can find some examples of Ricardian contracts on our site. WebFunds.org does not endorse these, so don't put your money where our mouth is.
The characteristics for a Ricardian contract can be listed loosely as
As a brief list. There doesn't appear to be a document that defines the Ricardian contract formally. There are some older requirements and many other documents on how to use them above.
Ricardian contracts are identified by a canonical hash. This hash results in a secure, distributed name space. In the framework of Zooko's Triangle, this makes Ricardian contract namespace a Type 3 (SOX nyms are also a Type 3 within that system).
However each name is non-understandable to humans, and thus the client software includes facilities to attach names to each contract, or to derive standard names from within the contract. This takes the client into Type 4 of Zooko's Triangle. (Server software does not have this facility because it does not talk to humans.) WebFunds-3G and XML-based clients likely have a fixed name system derived from the contract itself. Lucaya adds petnames to its management of naming.
Within the Ricardo world, there are several terms that are often used interchangeably:
item is a SOX value identifier (byte array), literally, the field in the SOX payment or the SOX sub account that identifies value type. As far as the SOX protocol is concerned, this can be anything; as far as the implementation goes, it has to be a Ricardian contract identifier, below.
contract is a Ricardian contract, the hash of which is used as an item (SHA1). WebFunds assumes that all value, regardless of the value manager, is identified by a Ricardian contract. So, if we were to add a form of value that was distinct, say, smart card money, then we may have to write some contract wrappers to keep WebFunds happy with its assumption.
Within the general term contract, we can talk about specific broad classes of contract:
where these are implemented by extending classes. Often, Currency is used where Contract is meant, as the current set of contracts envisage Currencies more than other potential Contracts.
So, a given Ricardian contract might be referred to as an instrument, a contract, and an item, depending on the context...
Ricardian contracts use a public key signature as well as the secure message digest. Both are tools of digital signing, and it is a singular observation that the hash provides more protective power in the technology, while the public key signature provides for more descriptive intent.
The debate over the efficacy of public key signatures continues to simmer. Ricardian contracts show how to do it in the narrow domain of a fixed, long-term reliable document. These techniques are not necessarily expandable to the wider domain of applying digsigs but we would argue that such a goal is futile anyway. So the Ricardian contract presents a perfect case study in how to do digital signing correctly - by concentrating on actual local and narrow requirements and avoiding all the digsig hype.
Ricardian contracts are signed in several components:
The issuer as signatory is identified in open text within the contract.
The issuer's signing public key is included within.
The issuer's top level key is included within, this one signs the signing key.
The contract is signed in cleartext form.
Ricardian contracts stand out as an internally-complete solution to authorisation and authentication using cryptography, but they do not depend or use in any form the classical PKI ideas or Certification Authorities. The reasons for this are severalfold:
Substantial steps were done in Kenya to remodel Ricardo to use a more layered signing model over people. However, the model used was a hybrid of CAcert.org Assurance and local savings groups.
(This section moved to Ricardian Implementations.)
Some miscellaneous resources:
The Financial Cryptography Blog often discusses Ricardian contracts, reflecting its importance in the governance layer of the FC7 model.
Attacks is just a starter page. Implementations of Ricardian Contracts records some notes on those other uses I have found out in the wild.
Also see the FC knowledge base which has a section on Governance. The FC knowledgebase is only a small section in the enhyper knowledge base below.
The Enhyper knowledge base has an additional page on Electronic Contracts has pointers to contract docs.
Check out Wikipedia on the Ricardian contract. Also, on contracts in general for an update on how the contract sits in law, and what it really is.
For the fullsome word on signing, you can't go past Stephen Mason QC's Electronic Signatures in Law (now in 3rd Edition). I've summarised it on FC in 2nd Ed. form at least. Also see an easy reading article Signatures on facsimile transmissions and e-mail by Stephen that lays out the essence of the topic.
Back to Ricardian Page and Guide Index.