This page has three main sections. (Note that the listings could be empty.) moreā€¦ Tip: Remember the back-button! And don't click the number on the left.

  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.
1763 comment >

Point raised during the review of the Stone Age Accounting demo.

  1. a token of agreement. AKA a signature. There needs to be some convention that indicates the offerer's intent to offer and the acceptor's intent to accept. These don't have to be 'strong' just memorable and customary.

This would be "send payment" and "accept payment" buttons to push? Those create yet another document, signed by the sender/receiver.

This is where it gets messy. Signing is the act of adding a token of agreement. What is that token? With a pen it is a recognisable squirl. With crypto it is the digsig appended to a document.

So, in a payment, we should see a sig at the end of the record, and display software could (or should) say "signed by Bob". With the Ricardian Contract, the signature is appended in (approximately) OpenPGP cleartext form.

See booked signature and multivalent signature. We opted to not break the integrity of the original contract by modifying it in any way. Instead we demonstrate linking the original contract (identified by it's hash) into a fresh document, the refined signature.

Those account representing our agents however are do just the opposite: those update their current state with information taken from the transaction.

3907 comment >

Contracts in A-Coin wallets

Askemos uses contracts to share understanding between users. The contracts in Askemos can be seen as agreements between users that are legally enforceable, but are also more than that because they instruct the agent to execute actions.

To issue a payment instrument (a.k.a asset) the user capture assets in the form of a Ricardian Contract as described in the usage section and in more detail in the Wallet Howto. Asset could be anything, for example this license to a photo .

Ricardian Contracts

Ricardian Contracts define a financial instrument, a set of rules human agents shall follow. They also define the minimum script necessary to allow programs to interpret the contract as financial unit of accounting: they provide a hash for an identifier, and fields to hold issuer names, titles etc.

Smart Contracts

The concept of having code as part of a contract is sometimes called a smart contract. As envisaged by Szabo, and as implemented by Bitcoin and other systems, a smart contract is machine executable, and has little or none of the agreement or text that forms classical legal contracts.

Askemos' Contracts

Our contracts are somewhere between Ricardian Contracts and smart contracts, incorporating both.

As with Ricardian Contracts, our contracts should contain legal terms, and should define an asset. They go further than Ricardian Contracts and more towards smart contracts by containing script code defining the "due" process for agents to follow, i.e., execute.

However the assets defined by Askemos' contracts may or may not represent a financial unit. A non-financial asset here is the wallet itself.

The wallet's code is a contract (script) which defines how to maintain the database containing values and assets (in the form of Ricardian Contracts). The contracts code ensures that no party can forge transactions or otherwise inflate payment instruments.

Social Support Contracts

In yet another "recursive" similarity the whole BALL code is part of another social support contract among users to keep the network up and running.

The whole thing would not work, if there where no notary devices. Those are owned by humans and operated according to the BALL source code by intensionally executing it on devices they control. Users will protect the integrity of their own device to whatever extend they find reasonable. A license to use a particular notary and the protection it receives are provided by the contract identified by the publicOID of the device.

The contract among these users is to ensure the true state of affairs and back up each other. As with any social contract: peers are free to join and leave the contract any time. Doing so does not harm the global state due to the consensus protocol. It does however damage the reliability, creditability or value seen in a particular notary or user.


The wallet demo originated from the desire to better understand the relationship between Ricardian Contracts and contracts in BALL. It's also a first step towards a payment system as imagined last year.

I'm grateful to Ian Grigg for his extensive comments and critique.

1756 is a > issue
1759 title > Comparison to Triple Accounting and Ricardian Contracts
1761 state > shelling comment
issue container member