In the simplest possible terms, a Ricardian
Contract is a 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.

A Ricardian Contract is an ASCII
(or UTF-8 pending)
readable file using canonical conventions.
Lines should have no more than 80 columns,
and indeed should probably have less as modern
mailers truncate at around 65-70.
Lines are terminated by CR/NL or by NL,
and whitespace at the end of the line should not be present
(may be removed or ignored).

Whitespace is defined to be any unprintable character
or any character that may be suppressed in transmission.
Note that this is not a precise definition, and
contract writers should take care to have clean lines.

Comments are [;-#]
initiated,
and apply to a whole line only
(i.e., no end of line comments).

Note that the first line will be the signature header,
the last will be the signature trailer; the file
is signed under the OpenPGP ascii-armoured cleartext signature conventions
(so as to be compatible and readable by OpenPGP user clients).

Lines before the signature header and after the signature trailer
are not part of the contract (and may be stripped).

where name is a ascii word-chars string (i.e. [_a-zA-Z0-9]).
The following specific exclusions apply: a name may not start with
an underscore or a digit, and the class of names local_ is not legal
in a contract (.asc) file. See the .loc file description at the end.
The name should be 7 bit ASCII. The name is optionally prefixed
with the section name, as shown below.

Text is ascii text up to the end of line. Whitespace is stripped before
and after the name, the symbols ("=", "*", "{", "}"), and (total) text.
I.e., whitespace (spaces, tabs) is stripped from the end of each line,
but not from the beginning, in accordance with signing whitespace conventions.
Multiline fields are done by:

name = *
{
multiline text
...
}

An additional older format is:

name = 'multiline text...
...
'

Which has first appeared in SOX-2.
The former is preferred as it is clearer to the eye.

The message digest, or hash, of the file is taken
using a canonical form, in order to preserve the
value over different file storage forms.

The text stream is calculated similarly to the
clear text signature method of PGP:

Whitespace on the end of lines is ignored, and must be stripped.

Line endings CR/LN, LN, CR are converted logically
to CR/LN. The precise form of line ending should be determinable
by looking at the endings after the signature header.
Mixed endings within a file are invalid and may be rejected.

Lines before and after the signed block are ignored
and should be stripped.

If these conventions are not followed, the message digest
will not be equivalent.

Note.
OpenPGP also drops the line ending for the last line.
It is not clear if these are all dropped as yet.
As the signature code and digest code derive from
a common root, this standard should probably follow
suit, even though it is more complex.

Versions exist:

Version 3 should be as above.

Version 2 lacks whitspace trimming on the end of the line.

Version 1 would be the variant in older WebFunds.

The version can be specified in the
Local File
in order to force correct calculation.

This section is compulsory for all items that are managed
by issuer software (it is conceivable that a private contract
been two parties is not managed by an issuer, but we ignore
this case for now). Notwithstanding the above, its contents
do not appear to have a lot of importance.

The section refers to details about the item that keeps it running
as an Internet financial instrument. Here, the issuer refers
the technical manager of the item, not the entity that backs the value.

issue_operator
is the entity that runs the Issuer, a set of
Internet servers.

issue_email
where item technical support questions are posed

issue_type
is one of bond or share
or currency which specifies a following section.

issue_manager_name
name of the server_url manager (not necessarily the entity)

issue_contract_url
where the present contract and others are stored
by the legal issuer.

issue_fungible
identifies one amongst a series of fungible items
of the same symbol. Whether they enjoy fungibility
is not defined by the appearance of the version, rather,
it is a matter for the issuer to decide. This is a hint.

issue_power
With a decimal contract, this number represents the number
of digits after the decimal point from the unit of account.

For example, with a dollar currency denominated in cents,
the power would be two. Alternatively, if one is doing
a currency of spot trades in the dollar, the minimum spot
being one million dollars, the power would be -6.

As a custom that has arisen through experience, two
sections have been added that have no technical components.

The section [definitions]
includes terms and definitions that generally desire to be
defined in a contract. Following normal procedure
in english common law contracts, this section goes up front.

Later on (after the [entity] and [issue])
is added a [conditions] section. This includes the
meat of the contract in clauses. In general, there is little
in here for the program to read, its terms are for the human
reader.

Note that the existance of any keys in this section does
not by itself confirm the validity of the signature.
The security derives from the contract being signed with a
[contract] key
that is itself signed by the entity's [certification] key.

Then, security rests on knowing that the [certification] key
is valid, and ensuring a chain of signatures to the contract.
Understanding why the key included in the contract cannot be used
is left as an exercise to the reader.

Bond can be displayed as
entity_shortname bond_identity currency face.

Remember, the face amount of currency units is paid on the maturity date.
It is not necessarily the traded currency - that is up to the market.
The Zero contract is a one-cash-flow financial instrument, and is the
only contract that the market currently supports.

bond_contract = zero

bond_face
how much is paid on maturity date

bond_currency
in what currency is maturity settled, e.g. USD

bond_maturity_date
the date in Unix time (seconds since 00:00 01/01/70, GMT)

bond_issue_date
the nominal date that the placement was made (unix time again)

bond_total_issue_number
total number of issuer items (not value)

bond_contract_exceptions
any modifications to contract=zero go here

bond_identity
your internal name for this item, e.g. Month Year (8 chars max)

This section only included if type_of_issue == share.
Not much experience has been earnt with real shares as yet,
so this section is dynamic.

Share can be displayed simply as share_symbol and is therefore
required to be unique. It can be up to 8 characters.

There are few important details here, as just about all details
are changeable and non-standard. See entity_www for details
of the AGM, share_type rights, entity documents, share quantities,
annual reports, and the like.

share_type
some type, for example, A or B, or NV (non voting)

share_name
this is the long legal name of the company

share_symbol
this is the trading name (8 chars max), as it
might be displayed in a market contect, and should be unique
within some given market

A currency is a money item that is issued by a cash issuer.
It is often backed by deposits and "specie", or reserves, and redeemed
in some common value unit. However, this is not always the case, rather it
is a marketing decision by the issuer. For example, US dollars are
not redeemable in anything other than more dollars.

currency_triliteral,
currency_iso4217,
currency_tla
are all synonums for a three letter acronym,
modelled on the ISO-4217 standard name for currencies.
E.g., USD, AUG, PSE.

More formal nationally identified currencies might prefer to use
the first (currency_triliteral) or second
(currency_iso4217)
synonyms, whereas less formal community currencies
might prefer the last synonym (currency_tla).
Only one of these names should appear.

The field is expected to identify a fungible class
as a hint, not as a contractural promise.
An issue from one issuer should have similar value as another,
always supposing that both issues enjoy convertibility and
credibility.

currency_name
the normal in-use name for the currency, unique within issuer.
Technically known as the "unit of account", this is the name
used in normal conversation (e.g., dollars, not cents).

The name should be unique within the entity, so that the display,
below, is a valid unique name. One entity might issue several
different classes of the same currency (i.e. tla). For example,
rolling over one contract for dollars into another.

a small symbol used to indicate this currency, e.g. $.

Currency could be displayed as
entity_shortname currency_name or
currency_symbol where the former is unique,
the latter is generic.

A task is a future on the delivery of a project.
Tasks (or rather, task units) are sold when programmers offer to
sell futures, and essentially enter into a contract to supply the
underlying deliverable, if the market clears. Contributors
bid to buy task units, which return them futures unit on the
delivery of the project, if the market clears.

Whether the tasks have any value is not really defined, although
the task_ware variable, below, says something about value.

task_symbol
the normal in-use short name for the task.
The name should be unique within the market, so that the display,
below, is a valid unique name.

task_rights
describes the nature of the rights held by the instruments
when and if the underlying is delivered. Optional.
These conventions are suggested:

shareware - shareware is intended for free download and
later contributions as rewards for good software.
You are free to try, encouraged to buy.

freeware - software that is free to use, modify, sell, and
hide, as long as the copyright notice is maintained.
You are free to use.

copyleft - software that cannot be used unless it is
freely provided to all end users. A confused mixture of
dictatorship and liberty.
You will be free!

copyright - software that has rights attached, as
specified in the license. You must read the contract.

publicdomain - software that has no rights whatever attached.
You are free to abuse.

task_notify
is a list of email addresses (comma or space separated, according
to address conventions).
On clearance, the market might attempt to mail a standard message
to these addresses.

local_task_factor
As well as specifying the currency to trade this task
against, the unit size is specified by the market.
Thus, the unit of futures is specified and fixed for
this market.

This has the practical implication that
all contributions are in this unit. Importantly, for the
market, this sets the seller derivatives to the cash
units as a one-to-one relationship, which means that
settlement on clearance works.

For local management of Contracts, the following convention exists.
Along side the "name.asc" file holding the InfoFile,
place a "name.loc"
file with local additional information included.
This .loc file is not part of any contract, but refers to additional
conditions applicable on the local site.

It is not currently signed.

In the name.loc file, local_
fields are in a protected name space as they
cannot be valid in the name.asc file.
Other fields are incorporated
according to software conventions, and no priority is defined.

In a dynamic local file context, such as new items, setting
a field to <undef> will signal that this line
is now deleted.
This allows the contract reading classes *Info.pm to do field deletions
where refreshes are allowed.
This feature only makes sense in the local file.

local_server_file_url
This is an array of pointers to the SSD files.
Each element is a full URL that returns a further info format file,
the SOX Server Descriptor
that determines various hard-core server details
(including, for example, the location of the
server that accepts SOX instructions).

local_sox_server_name
is a special name for the SOX Server.
It is a hint to WebFunds to store or index
the SOX Server Descriptor using this name.
(This was deprecated as local_name
but is now brought back to life,
the SOX Server file also names itself.)

local_digest_type
Use this hash form to identify the contract in all communications,
by generating a
Canonical Digest.
Optional. The default is SHA.

local_digest_version
Indicates the version of calculation formula for the
Canonical Digest.
Optional. The default is currently 3.

local_errors
force errors on this
item. This is used for technically depracated items,
when the item format is historical, but the contract is
still contractually valid, and new items that are being
built up.

local_tla
is a primary currency of trade for the item.
Each item is traded by the market for an opposing currency.
Currencies can be grouped by a general class name,
known as their TLA, where this usually indicates
a physical fiat currency or a metal.

A primary currency is a major currency that is traded against
many others. Most currencies are secondary, and only trade
against one primary. The primary currency itself will not
specify a market unless it is traded against other primaries.
In most cases there is only one local_tla, but
there can be multiples.

The TLA may be the currency of the
face of the item, but don't bet on it (e.g., currency trading
and hyper-inflating bonds). Also, this is only the general
class and not an indication that a particular currency in
this class is accepted, see below.

local_currencies
comma separated hash list. (This should probably be
a line separated list within a multi-line part.)
This list of hashs is a hint as to what the market
might accept as payment for the item, each hash being one of
the currency class local_tla, above.
In general the market will accept anything that the issuer
declares as fungible (that is, the market is happy if the
issuer takes responsibility for solving the differences).

local_market_url
pointer to market server- a full URL that returns a further info
format file
(the SOX Server Descriptor)
that determines the hard-core market details.
In that file will be listed the server
that accepts SOX/Market instructions on this contract.

local_info_server
(Optional - not currently present)
pointer to market - a full URL that accesses the public info server

If not present, use the above local_market_url
to perform informational requests.
Note that this is here for documentation purposes, it is unlikely
to be implemented in the short term..

(Note that this *was* the admin server. This is now handled
by the order server, and a future change will be to set up
a new server with a new packet type handling item status requests.
This change is predicated by the need for separate machines.)

By default, the content of the text is 7 bit ASCII,
but UTF-8 may be used. UTF-8 is a 7 bit ASCII compatible
format that uses the sign bit to generate sequences up to
6 bytes long to encode a single character.

Latin, 8-bit ASCII, UTF-16 and any other format
is not supported.

Warning:
Embedded line ending characters may
challenge the definition of the canonical hash.
The OpenPGP format specifies that only space (0x20)
and tab (0x09) are to be stripped from the end of the lines.
Tabs are illegal in Ricardian Contracts.

Explanation.
UTF-8 was chosen because it is the emerging standard,
it is the OpenPGP cleartext signed format, and it is the
Java format.
Only limited experience with UTF-8 contracts has been had so far.

The Brit pound is an 8-bit char 0xA3.
In Unicode this is written \u00A3 or U+00A3,
which is hexadecimal 2 bytes (or UCS-2 as they call it).
In UTF-8, it expands to be 2 bytes 0x C2 A3.
Likewise, the Euro is \u20AC which expands to
be 3 bytes 0x E2 82 AC.