Ricardian Contracts

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.

Form

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.

Goal

The mission of the Ricardian Contract is to provide a document that can be a primary contract for the issuance of a digital asset.

See below for more.

Reading

Documentation is a little scattered. Here's some from the various Systemics' sources:

  1. Universal Value is a WIP on the nature of value within the FC domain.
  2. definition of formats describes the detail content of the current generation of contracts.
  3. issuance documentation describes the role of a contract within an issued instrument such as a currency. Read that section, but also skim the rest of the document.
  4. FC in 7 layers is a broad, sweeping architectural model that in one tiny section, discusses how contracts fit into the whole FC context. Read the full paper quickly, and concentrate on the Example's Value section and the next Static Governance subsection, about half way down.

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.

Requirements

The requirements for a Ricardian Contract can be specified as

  1. Human parsable
  2. Document is printable
  3. Program parsable
  4. All forms (displayed, printed, parsed) are manifestly equivalent
  5. Represents a legal contract
  6. Can be identified securely, where security means any attempt to pervert the linkage between a reference and the contract is impractical.
  7. Signed by Issuer
  8. All pertinant information in one single document, including signature and parties.
  9. Supported by financially capable PKI (such as OpenPGP)
  10. Extensible
  11. Identifies Legal Issuer (signer of contract)
  12. Identifies Issuance Server (accounter of contract)
  13. Unchangeable by Legal Issuer or other parties
  14. Supports content verifiability

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).

Terms

Within the Ricardo world, there are several terms that are often used interchangeably:

So, DigiGold might be an instrument, a contract, and an item, depending on the context...

Alternates

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.

Voucher Trading

Links

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".

Commentary

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.

Comparison

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.

FSML

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.




Copyright © 2001 Systemics Inc. All rights reserved
Mail us.