These contracts are the core idea behind the "value" axis managed by WebFunds. They are pervasive, being at the WebFunds level, not the Wallet level, and their architectural position within WebFunds is a strong statement as to their suitability to describe value even within wallets that have yet to be seen or incorporated.
In the simplest possible terms, a Ricardian Contract is an Ini-formatted document that is both human readable and program parsable. It identifies a Legal Issuer and an Issuance Server, and includes OpenPGP keys for those parties. The document is signed in OpenPGP cleartext form by the Legal Issuer's contract signing key.
A unique identifier is formed by a canonical message digest (hash) which provides an unforgeable link to the accounting system.
The mission of the Ricardian Contract is to provide a document that can be a primary contract for the issuance of a digital asset.
As a contract, parties to the contract must be identified, and signatures affixed. It should look and feel like a 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.
The document must describe the digital asset, and this must be parsable by programs.
Issuance implies that other parties, roles within the issuance, must be identified, and thus signatures and authentication must be included.
See below for more.
Documentation is a little scattered. Here's some from the various Systemics' sources:
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 requirements for a Ricardian Contract can be specified as
As a brief list. There doesn't appear to be a document that defines the Ricardian Contract, just documents on how to use them (above).
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 wallet, 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, DigiGold might be an instrument, a contract, and an item, depending on the context...
Up until recently, the idea of Ricardian Contracts has not been copied or independantly developed as far as we know. Even though the concept was announced as far back as 1996, and source code was made available in Feb of 1997, interest in applied Financial Cryptography, and how to describe real assets, has not arisen until lately.
One alternate development is the FlexTicket from NTT.
It was recently described in an Internet Drafts, Voucher definition published by Ko Fujimura < fujimura@isl.ntt.co.jp> and Masayuki Terada (both from NTT, Japan):
Title : XML Voucher: Generic Voucher Language
Author(s) : K. Fujimura
Filename : draft-ietf-trade-voucher-lang-00.txt
Pages : 8
Date : 21-Feb-01
This document specifies rules for defining voucher properties in
XML syntax. A voucher is a logical entity that represents a right
to claim goods or services. A voucher can be used to transfer a
wide-range of electronic-values, including coupons, tickets,
loyalty points, and gift certificates, which are often necessary to
process in the course of payment and/or delivery transactions.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-trade-voucher-lang-00.txt
This is part of a "generic value circulation system" that is further described in a set of requirements for Generic Voucher Trading:
Title : Requirements for Generic Voucher Trading
Author(s) : K. Fujimura
Filename : draft-ietf-trade-drt-requirements-02.txt
Pages : 11
Date : 15-Feb-01
In purchase and other trading transactions, it is often required to
credit loyalty points, collect digital coupons or gift certificates,
and so on. These activities can be generalized using the concept of
a 'voucher', which is a digital representation of the right to claim
goods or services.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-trade-drt-requirements-02.txt
The notion seems to have been introduced as far back as this 1998 Usenix paper, "General-purpose Digital Ticket Framework".
Their higher level requirements document for a voucher trading system is pretty much met by Ricardo already. As far as voucher trading goes, the requirements need not be as stringent as for money or asset systems, but the effective nature of the system is equivalent. Indeed, the Voucher ID mentions stocks and bonds at one place, so maybe the system is headed there.
Does the Voucher meet the requirements if the Ricardian Contract? In terms of the contrast between Ricardian Contracts and Fujimura/Terada Vouchers (what this page is more properly about), there appear to be these :
| Feature | Ricardian Contracts | Vouchers | Comments |
| Signature | OpenPGP cleartext | (external) | suggests XMLDSIG |
| PKI | OpenPGP | (external) | no requirements |
| Format | Ini/custom | XML | XML is much better |
| Identifies parties | yes | yes | Legal Issuer, Issuance Server |
| Extensible | yes | yes | Allows other types of instruments |
| Separates value from contract | yes | yes | Units are accounted for in parent Payment System |
| Provides Unique Identifier | yes | no | how to identify the document with no ambiguity and no change |
| program-parsable | yes | yes | |
| human-parsable | yes | maybe | can humans read the document without confusion? |
| Contractual | yes | no | lacks defined signature & PKI, human parsability, unique id |
| Implementation | yes | no |
As a contract in the terms that the Ricardian Contract attempts to meet, the Voucher might not succeed. That is somewhat unjust as there is no indication that the requirements of the Voucher are intended to be of a contractual form, merely that they are suitable for describing loyalty systems and ticketing and the like.
However, it may be that we can use the Voucher ID as the starting point for the future XML format for the Ricardian Contract.
A consortium has defined an eCheck format written in SGML (not quite XML) for the purposes of transmitting cheques between parties. These are definately banking cheques, not SOX cheques.
The Document Formatting Rules in the standard may be of interest. It describes characters, tags, lines, and whitespace, all pretty much as we do things.
The rest of the document is not so useful, it includes too many assumptions about cheques and protocols. It's also locked up in PDF and can't easily be worked with.