Ricardian Contracts are really a stepping stone to Smart Contracts. They are a way to link a contract to another system, typically an accounting system. Ian Grigg came up with the Ricardian Contracts some time ago. He first published about it in Financial Cryptography in 7 Layers in 1998. Ricardian Contracts were initially used for Ricardo (hence their name), a bond platform.
They are a melding of a traditional contract with a contract that can be read and executed by machines. A Ricardian Contract can be defined as a single document that:
- is a contract offered by an issuer of some item of value (think of a bond, coin, token, currency, etc.) to a holder of such item;
- for a valuable right held by the holder, to be managed by the issuer;
- can be read in plain language by humans (so like a normal contract);
- can be read by programs (and is parsable like a database);
- digitally signed;
- carries the keys and server information; and
- is allied with a unique and secure identifier.
Generally a Ricardian Contract is one that is used to define a value for issuance and holding of something over the Internet. It sets forth the applicable terms and sets it in cryptographic stone, so everyone knows who signed it, and when and exactly what it said at that time. It automates the offer and acceptance of the agreement and ensures they are enforceable.
It removes a good deal of the typical contract dispute issues, but not all of them. Items such as what was the offer and whether it was accepted, who the parties are, what the terms of the contract are are greatly resolved. When you use natural language however, there are always items that may be ambiguous, or changes in the nature of the parties, the industry or the economy which can greatly change what parties expected in a contract (that’s assuming they both had the same expectations for all provisions in the contract – another thing that is usually not the case).
The Ricardian Contracts are a bit unique, and likely cannot be used for anything, as drafting these agreements which must include markup language to enable them to be read by computers is a bit different. They are also pretty versatile and can be strung together (usually transactions are more complicated than one agreement can cover).