Requirements for The Ricardian Contract

This below seeks to lay down a foundational context of contracts, by describing the Ricardian Contract in terms of detailed and more formal requirements,

Originally this section was meant to be part of the paper on Ricardian Contracts but suffered the trauma of page limits [original]

Creating the Digital Contract

If a contract can be written in paper form, then it can be kept in digital form, simply as an electronic document on a computer.

And, once stored as a digital series of bytes, it can be signed using a digital signature system By using a cleartext form of digital signature, the digital form of writing can also carry signatures in a fashion that should not detract from readability.

Further, once locked down in a form suitable for signature preservation (termed canonicalisation), a signed contract can have a cryptographic message digest applied to it. This formula generates, by definition, a unique and unmistakable number that is one for one with the original document.

Application Requirements

Our analysis of contract requirements was not derived in a vacuum, but within the context of a payment system called Ricardo that sought to issue any form of value (stock, bonds, currencies). In general, we are seeking to meet the following goals.

• Encapsulate and show financial value,

• deliver a technical system that transacts in the value,

• not disenfranchise the non-technical world,

• especially, bring in the lawyers and judges, and,

• most importantly, do it cheaply.

Follows are the high level requirements imposed on the design of the Ricardian Contract by the application.

Ivan should be able to design and issue his own instrument [Ivan]. The scheme must leave ample room for the independant issuer to design his own instrument, without recourse to changes in software or to permission from some numbering authority. In essence this implies that the semantic meaning must be separated from the scheme of identification.

Any scheme should be self-administrating. The difficulty with a central number scheme is amply indicated by the ongoing debate on Internet administration: sooner or later, any successful system that relies on a central administration point will bog down at this single point due to politics and franchise disputes.

There should be no real limits on the space. Again, amply indicated by the IP numbering system, even large numbers can become congested as the system becomes more popular and the original management scenario fails to cope.

An instrument should be capable of expressing an arbitrarily complex agreement of value. We cannot predict how these instruments will evolve, but at a minimum we can list currencies, securities, derivatives and loyalty applications as instruments we wish to describe.

Alice must be able to control many different intruments, without recourse to complex database linking. With many instruments, some of similar nature and others of diverse nature, user software must be capable of efficiently presenting the user with information, and with managing the reception, storage and disbursment of diverse instruments easily.

The system should reduce costs. There should be no additional or unnecessary costs applied in the use of the system.

Design Requirements

Additionally, we impose design requirements that assist us in meeting the above application level requirements.

The scheme should reduce disputes and should reduce the costs of remaining disputes. Disputes are a huge cost that are asymetrical to use of the system - the costs fall on some parties very heavily, and others, not at all. Further, it is not clear that disputes can be efficiently resolved in an Internet context. Thus, we expect reduction of the gross number of disputes, ex ante, and the simplification of dispute resolution, ex post.

It must be readable by ordinary people. No special skills should be required to view and interpret the broad thrust and intent of the issuer. The contract needs to be readable by a wide range of readers, including users, the legal fraternity, and software. This imposes a great incentive towards a simple structure.

It must be displayable on screen. Users would generally view the contract within the context of a programmed presentation, for example, on a web site or by a PC program.

It must be printable on paper. The process of Dispute Resolution works with paper copies.

The form must not rely on special software. Distributing software is much harder than distributing files. If a special program is required to read the form, then it would be limited by its distribution.

There should be no hidden components. Much software for document preparation permits the addition of commentary, the hiding of portions from certain readers, the saving and unsaving of changes, and many other variations from the superficial content as displayed. The presence of such variations raise costs in resolution of disputes, and are therefore expressly eliminated.

Once issued, it is not changeable. Much fraud, and many disputes and thus costs, result from changes made to a contract after parties have started relying on an original document. Sometimes, these changes can be beneficial, but often, they are not.

The document can be securely identified. Any usage of the scheme by application software will need a unique, efficient identifier. It should be trivial to say that any event can be related exactly and reliably to a given, unique, contract. This identifier will need to easily fit in digital records, and be efficient enough, but unique enough, to meet, or at least not interfere with, the other objectives presented here. It also needs to be immune to attempts at perverting or forging the linkage.

Parsable by Software. The form of contract should include sufficient flexibility to permit some parsing by the software. This will permit the software to extract out sufficient essential details on the fly, so as to avoid the necessity for secondary stores.

Extensible into different instruments. The form should be capable of handling as many forms of financial contract as possible. For example, bonds and shares, currencies and loyalty systems, gambling chips, etc.

Choice of PKI - OpenPGP

When the Ricardian Contract was first designed, PGP was the only widely available digital signature technology. This then evolved into OpenPGP at around the same time as x.509 technologies became widely available [OpenPGP]. However, because it meets the below requirements, OpenPGP remains the only choice for a public key infrastructure (PKI) for Ricardian Contracts.

Signed with a Cleartext Signature form. As distribution of documents is a very frequent, and costly exercise, the signature has to be carried with the document. OpenPGP has the ability to create a cleartext signature that wraps around a document; this format also dictated the text file nature of the contract in its original design [x.509].

Supports Web of Trust. As this is a financial contract, the trust model needs to map to the way financial markets distribute trust. In finance, primary trust moves horizontally, from person to person, via networks of contacts. Vertical structure is only superficially used for trust. As OpenPGP supports the web of trust it is possible to use it for financially motivated applications [x.509.2].

Each element should be publically auditable. Cost reduction means that no standing reliable party can be employed. Thus, each and every element, every link in the chain, must assist the verification by being auditable by any and all users. The chain of integrity must be openly traceable from a transaction, to the contract, and up to the issuer.

The Contract Should Not Rely on Keeping Secrets. The Strength of the claims made in the contract should not be dependent on the technology, and in particular, should be resiliant to the loss of control of secret keys [later] This is met by use of the canonical hash, and the use of governance roles within a community in the wider scope. In short, the issuer simply repudiates any falsely signed contract.

The Rule of One Contract

Many of the above coalesce into one meta rule:

There must be One and Only One Contract. However the contract is considered, be it displayed, printed, emailed, disputed over or identified, there is one and only one representation, and it can be shown easily, unmistakably, in all views, to be one and the same.

This is the Rule of One Contract.

The rule means that any presentation that results in content-wise distinctions to the source contract is to be frowned upon. There should be no way in which one view of the contract can present different information to any other view.

Thus, the document is more or less forced to be an ASCII textual document that can be transmitted, printed and read over a wide variety of formats without change.

References