############################################################ # # Standard Definitions for Ricardian Contracts # $Id: 56c72cb7b1fe56ccc5b69fb0a7b129544144cbfa,v 1.1 2005/03/01 00:12:06 iang Exp $ # # A Ricardian Contract may incorporate these standard # definitions by including in section [definitions]: # # definitions_include = # # where hash is defined below/ # # For location of the latest version of this file, see: # # # # Replace 'standard.txt' with the hash to acquire the version # referenced in any given contract. Make sure you cache the # exact version used on your contract publication page under # the name of the hash. # definitions_ricardian_contract = * { This form of agreement is sometimes known as a Ricardian Contract, a form developed by Systemics to provide a mechanism to accurately express any form of contractual value suitable for Internet payments. More information about Ricardian contracts can be found at and this published academic paper } definitions_standard_terms = * { These standard terms and conditions are supplied where they are likely to be the same for all contracts. They include definitions and terms that explain and rely on the technology. Where a clause in these standard terms and conditions disagrees with a clause in the enclosing signed contract, the term in the enclosing signed contract rules. } definitions_comment = * { Ricardian Contracts include comments which are lines that begin with '#' or with ';' as seen at the top of this file. Comments are for explanatory purpose only and are not intended to form part of the clauses of the contract. Where a clause disagrees with a comment, the clause rules. } definitions_5PM = * { The five parties model ("5PM") is a model of governance for payment systems designed to protect the value of the units issued. The five Roles consists of Issuer, Operator, Mint, Manager and User. In 5PM, the Operator, Mint, and Manager are roles that are appointed by the Issuer to fulfill the governance tasks. The User is encouraged to audit and vet the governance of the issue, including the actions of the roles. In the case where there are reserves as well as digital balances to protect, there may be two separate but parallel 5PMs. In this case, the Issuer and the User is the same in both models. In the case of reserves, the Operator would more properly be termed the Repository, and the Mint might be termed the co-signatory or custodian. This and other clauses below explain but do not oblige the 5PM. The Issuer may outline his committment to the 5PM in the contract. } definitions_issuer = * { The Issuer is the legal signatory to the master contract. His digital signature is affixed to the bottom of the contract in OpenPGP form (and not on this file). The Issuer is ultimately responsible for the performance of the contract. The Issuer is responsible for appointing the governance roles of Mint, Operator, Manager, Repository, Co-signatory and others. The Issuer is identified in the [entity] section. } definitions_persons = * { Following conventions of financial cryptography, the Issuer is sometimes known as Ivan, and is written in the masculine. The User is sometimes known as Alice, and is written in the feminine. These conventions should be read as being inclusive of gender. Additional users may include Bob and Carol. } definitions_user = * { The User is the holder of units of a contract. The User becomes legal signatory to a contract when she adds the contract to her account or accounts or when she accepts or makes a payment in this contract. Her digital signature is provided to the Operator in a transaction facilitated by her software. } # # Such software programs are WebFunds and Pumphouse which # can be downloaded for free from a number of sites including # # definitions_operator = * { The Operator is responsible for the technical hosting and management of the Ricardian Issuance Server, which manages the accounting of the Users' units, as directed by signed requests from the Users. The Operator is also responsible for enabling the Mint account, under instruction from the Issuer. } definitions_mint = * { The Mint consists of a special account that may create value where before there was none, and a person, natural or legal, who is responsible for that account. The Mint is appointed by the Issuer, and is bound to only create value under instruction by the Issuer, and in accordance with the terms of the contract. Value is created by the Mint and generally sent to the Manager. Value returned by the Manager to the Mint should be deposited into the Mint accoung and thus reduce the float by that amount. } definitions_units_of_issue = * { Ricardian Contracts are generally issued with two forms of units, being Units of Account and Units of Contract. Units of Contract are the underlying numbers in which accounting is conducted. Within the low level accounting, all calculations are done in units of contract. Units of Account are the high level numbers that the user is familiar with. All presentation of information should be done in Units of Account. The User's software will convert between the two forms automatically. The [unit] section describes the relationship between them. Generally, a currency contract would express its units in common decimal form, with Units of Account like dollars and Units of Contract like cents, but this is by no means required. } definitions_float = * { Float is the total quantity of units outstanding, and is created by the Mint account (which account is specially enabled by the Operator and only as instructed by the Issuer). } definitions_manager = * { A Manager is appointed by the Issuer to control issued but undisbursed value. This value is transferred to the Manager's account from the Mint account, or is returned by Users. The Manager holds day-to-day balances of value. } definitions_backing = * { "Backing" is defined as the sum total of assets that make units of this contract valuable to Users. Any given issue may include more or less elements that add up to give an issue backing. Anything of value, including intangibles, may be considered to be an element of backing. See [conditions] for details of a given issue's backing. } definitions_reserves = * { "Reserves" are defined as underlying assets that have the same or similar denomination and value as the digital issue, and are escrowed for the sole purpose of maintaining the value of the digital issue. Reserves are an element of backing. Any given issue may or may not include reserves, as defined in [conditions]. } definitions_date = * { The date of this contract between the Issuer and the user is that date upon which the user received each unit of the contract. } definitions_hash = * { The identifier of the contract is calculated using the Ricardian Canonical Message Digest ("hash"). This is defined as a cryptographic message digest calculated over text with no trailing-whitespace and with line endings set as \r\n. Commonly, SHA1 is used, but others are envisaged for the future. A Unix approximate calculation is: sed -e 's/[ ]$//g' -e 's/$/^M/' standard.txt | openssl sha1 (note space and tab are stripped.) More information on the hash and Ricardian Contracts is found at http://www.systemics.com/docs/ricardo/issuer/ This file of standard clauses is identified by the same calculation. } definitions_contract_url = * { The Issuer should maintain a "Contract Publication Page" that is used for publication of any important notices that effect the contract, as well as the contract itself and any other information relevent to it. This page is identified in the entity section. } conditions_privacy = * { The following is a pro-forma privacy statement. Look in the contract for any overriding clauses: The settlement of transactions in a Ricardian Contract is normally done with confidentiality. The routine exception to confidentiality is the ongoing publication of balances, as duly designated by the Issuer to provide users with confirmation that these balances are being maintained. A rare exception to confidentiality is when due process is served by a court of competent jurisdiction. } # # This is the end of the Standard Conditions $version: $ # ############################################################