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.

Trust and Verification
On Contracts
Demo:Wallet FAQ