Help: This page shows how the referencing vocabulary definitions are maintained and interlinked for controlled consistency of documentation. Click on the hyperlinks to see how the terms are defined within the Askemos architecture. moreā€¦ Tip: Remember the back-button!

This page has three main sections. (Note that the listings could be empty.)

  1. The first item displays a term, URL, text or picture.
  2. Followed by a (still unordered) listing of statements about this subject. (for details follow ">"-link)
  3. Separated by a horizontal rule a "reverse" listing of statements referring to this item in object position.
1288 comment > Despite remarkable similarities between Askemos and Ricardo, neither work has influenced the other. The authors learned to know about the other project in 2012.
3137 comment >

For technical remarks see also: Triple Accounting.

1276 is a > bibliographic resource
1278 title > The Ricardian Contract
1281 creator (jur.) > Ian Grigg
1918 description >

3.1. Definition

A Ricardian Contract can be defined as a single document that is a) a contract offered by an issuer to holders, b) for a valuable right held by holders, and managed by the issuer, c) easily readable by people (like a contract on paper), d) readable by programs (parsable like a database), e) digitally signed, f) carries the keys and server information, and g) allied with a unique and secure identifier. In the simplest possible terms, a Ricardian Contract is a document defining a type of value for issuance over the Internet.

It identifies the Issuer, being the signatory, and any terms and clauses the Issuer sees fit to add in to make the document stand as a contract. The same document has to be both readable by people and parsable by programs.

The Ricardian Contract is formatted as a text file that can be easily read (displayed or printed), and programs can convert it into internal forms for searching for name-value pairs. It includes a special section for each type of contract, such as bond, share, currency, etc. Further sections within describe, in program-parsable terms, usage of decimal points, titles, and symbols.

3.2. Some Observations

The following observations highlight how strong the result is.

Hash Limits Frog-Boiling. A gradual change in contract by the stronger party over time is known as frog-boiling. The stronger party is generally the issuer, and can be expected to change the contract if there is a benefit. This is a frequent attack. One result of the use of the hash identifier is that neither party can change the contract arbitrarily or surreptitiously.

To see this is true, we need to examine the records that refer to the hash. An application can sign all important records (e.g., payments, tokens, receipts, balances), and these signed records include the hash of a Ricardian Contract. The hash within the record cannot be changed without losing its ability to pass a test of signature validity. Likewise, the contract cannot be changed without losing its relationship to records already signed and delivered. In other words, every record, held by every user, incorporates an unalterable copy of that hash. Any change to the contract creates a new hash, and that new hash is not the one which the users have or value.

This crystallises the contract for both parties, stopping the stronger party from modifying the contract subtly at some later stage. To some extent, this redresses the imbalance of power between provider and customer in the offering of a form contract. The lesser party has no option to negotiate, but neither has the greater party the option to claim a distinct contract at a later time. The limitation comes at some cost as it can be a nuisance for the support team of that financial instrument.

1283 kind/genre/type > Contract Type (Askemos)
1593 issued > 2004-07-06
1285 see URL >
3124 see URL >
3158 see URL >