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.
About Demo:Wallet
1819 container member > The Wallet is an open source application for creating private currencies. Anyone can create an account, and issue units to it as they wish. The script guarantees that transfers between accounts are always correct (no account can have a negative balance).
1820 container member >

The Stone Age Accounting Demo

The purpose of this demo is to sketch out how a payment system may be implemented in an Askemos network. Account owners may order transfer of value from their funds and accept incoming payments. Since it starts empty, account owners must first create their own assets (a.k.a. issue payment instruments). This is shown in the demo by a fictional example: the Flintstones dating, splitting up and eventually founding a family. The reader is taken from nothing to three shares of a home owned by three accounts.

The intent is to keep the demo as simple as possible but not simpler. A payment is here the coordinated and agreed transfer of value in units of some asset from a sender's account to a receiver's account. Such a transfer is done by the exchange of two documents, an order and a receipt. A well defined set of chosen peers, termed notaries, audits and backs up the process (discussed in the following sections). Note that the transfered value itself is completely anonymous, as it ought to be the case for real money.

The whole demo lives in a Merkle tree. There are three accounts ("wallets"): Wilma, Fred and Bamm-Bamm. You may log in these wallets using "public" as password when asked to " login if you can". All other documents are static and immutable (look for comments relating to "public-place").

There is a second, simpler and more trade oriented demo. See also "access control" below: these accounts communicate using private orders and receipts. Visiting the transferable link results in a very nasty formatted "access denied" message. The Butcher and the Merchant.

Right now the demo is not pretty. I'm soliciting all feedback, questions and suggestion.

Note that most peers participating in this demo (and serving the website) run from plug computers at various homes. Please adjust your expectations wrt. performance and reliability accordingly!

1821 container member >


Here we cover only the basics, find more details in the wallet howto here.

Creating Assets

It all starts out by issuing a payment instrument in the form of a Ricardian Contract. (The reader should be familiar with the idea here, that personal credits or invoices are a payment instrument, not only "real money".) The account owner must fill in the form titled Claim:

  • An amount of units
  • A title
  • Terms&Conditions expressing the intent

For technical reasons there is a second step to book the resulting OID into the account. The user is given a chance to add some "pet name" or comment for internal reference.

As a result the inventory listing contains an entry for the amount and a link under the given pet-name referencing the XHTML document by OID (hash) which defines the issued instrument.

When accounting is checked in the form, a fresh wallet can be attached to the payment instrument. This is how new accounts are created. The purpose of the new account should be clearly stated in the terms and conditions attached to the asset.

Sending Payments

To pay (or send an invoice, which is the same at this level of detail), the sending account files a message with the notaries. The user needs to select a receiving account, an amount and the asset – optionally adding a title (recommended) and a free text message – and sign the payment. This will result in a new transaction listed in the Ledger marked outgoing (and later sent) and the amount is counted against the senders balance.

Important: The identifier (or – more practically often – the link in the column labeled "##" – without the quotation marks) must be transfered to the receiver "manually". Use any channel deemed appropriate wrt. your privacy, e.g., mail, chat or cut&paste. The demo manages only the "registered messages", not the message transfer.

The transferable identifier/link refers to the XHTML document with the order. Again in both human and machine readable form. See also "access control".

For the purpose of the demo we are free to choose the encoding. To keep the demo code (a single script) simple, we embed in a to be refined way. (Currently as illegal attributes of the html element, to be turned into meta elements.) For a production system an appropriate standard should be selected.

Receiving Side

The receiving account needs to put that into the field *get satisfaction* and push Go. The payment will be read from the receiving account and the user given a chance to verify it. The user may select a title for unknown payment instruments, add a note and optional message and sign the receipt. At this time the amount is added to the receiver's balance.

The user may alternatively choose to reject the offer (for dislike of terms) and sign a return receipt instead (which than has to be transfered back to the sender to receive the value back.

Technical remark: the amount and payment instrument are taken from the incoming order, not the user's input. This is why we need a machine readable format: we can not trust the user to specify the correct amount. Since all the commissioned notaries are listed in the receipt, we know that at the time of issuing the receipt (as included in the receipt) there was a qualified majority of them convinced that the order is pristine.

Other Forms

See the wallet howto here for lifetime management of wallets, access control, commissioning notaries customization and advanced usage.

1822 container member >

Why Trust It?


The wallet code is written in BAIL and runs on BALL. We discuss the verification strategy for those in the next section. Assuming those working "good enough" the wallet code must not fail wrt. these bullet points:

  • Every "wallet" is a (sqlite) database holding a balance table of two columns: amount and currency. (Together with some user interface.)
  • Users can create orders (documents) to transfer some amount to some other wallet. The receiver can either accept or reject.
  • Users may change their notaries. Restrictions apply when orders are transfered: the receiving and sending wallet must share at least half the notaries with the Ricardian contract. (Intermediary wallets acting like a bank are required to transfer values between wallets lacking such "common trust" .)
  • Irrelevant here is all the code to maintain per account nick names for wallets, notaries, currencies etc.

The wallet code make sure that it no order exceeds the senders balance and no receiver can accept the same order twice.

A well defined set of chosen peers, termed notaries, audits and backs up the process ensuring important properties: A) They verify the users signature at transfer time, sign a verification record strongly linked to the document and archive the record together with the document. This is a refined form of a signature, which we term booked multivalent (or multi-party) signature. Such a signature is more reliable in the long term than signatures schemes secured by secrets under control of the signatory. B) They replicate the calculation according to the contract, thereby tolerating byzantine faults to counter both dishonest accounting and failing devices. C) Preserve the privacy: the ledger is shared only among the notaries entrusted by the sender and receiver.

The full audit trail of all transactions relating to an account is available from the respective account until the user expunges the listing. The "notaries" actively verify that no account will create orders exceeding the balance and no payment is recorded twice.

Verification Strategy


  • The wallet code (a.k.a. contract, application): "probably" correct. Intended to express the correct meaning. In case of dispute verbatim linked. Self-contained, intended to be stable over long periods of time.
  • BAIL, BALL, Operating System, Hardware: The implementation assumed to be too complex to verify formally. Bugs to be changed even if they break backward compatibility. Instead of verification of these layers, we resort to "observational correct" at time of use plus a dispute policy: "pull the plug". (See also social support contract in the next section.)

Threat Model

It is the duty of the receiver to verify that an incoming payment originates from a trustworthy source and decide whether or not to accept a payment. Nevertheless this responsibility goes only so far. If an attacker could provide a pristine looking order, we could not blame the receiver.

How could we inject a fake payment? This would require to inject it into the network of notaries. The payment document is required to be available from a qualified majority of the notaries for a transaction to commence. However peers (notaries) check incoming document with the list of commissioned notaries of the Ricardian contract. (See "Using Notaries" in the Howto.) The document is deemed acceptable only if the majority of those peers confirms that the hash references a document available in the local archive of this notary (plus the hash is correct wrt. the document content itself).

Therefore: an attacker needs to circumvent the host security of the majority of a known set of peers (no Sybil attack) and fabricate a fake payment. This would be enough to fool the receiver.

Further note that in normal use, user would not run their account entirely from external peers as the demo does. They want to make sure to have their own peer device commissioned as a notary (and keep it off when not in use). Sudden updates from the network to their own account would be rejected, triggering a dispute and manual audit.

Thus the attacker is back at the problem: how to insert a fake node into a Merkle tree without breaking the hash tree's consistency. This given the additional complication that not all copies are within reach to clean the trace of the attack.

Dispute Policy

An important part of any payment system is a dispute policy in case of doubt. TBD: In case of dispute, the user may set an anonymous access code with permissions to only explore the account. No modifications will be possible using this code. (That's the "public" password, which lets you log into the examples.)


I know: everyone can design a system, which they can't break. Naturally I don't know how to break this. If you got a better idea, please let me know!

1823 container member >

How To Go Productive

Some notes what should taken care off before going production.

  • The user interface is too basic.
  • There needs to be a way get rid of accounts.
  • Web developer's groundwork. See below under "Accessibility".
  • Select a standard encoding according to your needs; see "Standards".
  • Use an appropriate set of notaries, where all peers are operated by different humans.


The demo leans towards minimalcode. This may result in arguments like this from Ian Grigg:

The document that would be something that I would say a judge cannot read without a HTML parser. When I clicked on it, my Mac opened it up in Xcode. I had to point my browser at it to read it in display form.

This was due to an artifact from forwarding the document instead of the OID per mail. We handle this by the "holder statement" having a clause to agree to the format as long as there are two independent ways documented how to display the document.

IanG: What happens if the document was presented in Firefox which failed to show the "sign-your-life-away" clause to the user?

You may want to double check using a known-to-be-good client.

Otherwise: we take great pains to assert that there is no so called active content in the documents.


Standard is better than better. The nice thing about them is: there are so many to choose from.

For the demo we chose to embed in XHTML.

XML/XHTML/style etc is wonderful for web devs but pretty much unintelligible for everyone else. I think in due course some > judges will accept it ... but in the first instances they should reject it for its lack of transparency.

Production systems will certainly need to comply to other standards. This will not effect the logic.

1870 container member >

Topic Of Interest

Observe that instruments, notaries and counterparties (may) go by different names for different accounts. Note that there is no central database.

Note that the transfered value itself is completely anonymous. There is a full audit trail for every transfer kept with every account (thus readable only by the notaries) linking receipts to payments. But there is no link between an outgoing unit of payment to the receipt confirming the unit's arrival before.

The tree includes all the code and data required to audit it for consistency, including the source of the accounting code – (beware: the latter is useful only in white space preserving source code view!), necessarily down to a license. (It's just impossible to break the logic. The license is required to establish rules how to use and modify the source code.)

Comparison To Bitcoin's Blockchain

Bitcoin's Blockchain and Askemos's places (be they agents or immutable objects) both form Merkle trees from signatures to prove correctness. At this point one may understand the links going to OID's as browsing the "block chain" in the browser.

The difference is how the systems verify veracity of peers. Bitcoin deploys an "open join", public network. The final decision on the proof is left to 51% of anonymous peers. With Askemos the proof may be broken only if 67% of the commissioned notaries as chosen for the the agent conspire. It's also much faster, since it does not required a proof of work to mitigate Sybil attacks (which may succeed on small Bitcoin style networks).

Another difference is in how payment instruments are issued. With Bitcoin there is a fixed policy: Minting happens in a lottery as a side effect of the Sybil attack mitigation. This demo takes the traditional way of users entering into contracts among each other.

Relationship To Registered e-Mail

There are services like "De-Mail" providing registered e-Mail. These services accept a signed message, decrypt, time stamp and virus check the message. Then it's kept for the receiver to retrieve. The demo does similar, except instead of virus checking it checks correct accounting. Safeguarding that no value is double-spend.

The difference lies in trustworthiness: those services usually rely on a provider users must trust. A rough provider can suppress messages or create fakes. Here we use group of independent notaries instead. This results in a) more independent assertions b) each less likely under surveillance or coerced into cheating. See below on "how to break it".

If secrecy wrt. the transfered message is required, there would have to be a encryption on top. But note: the accounting info can never be encrypted, since it must be available to the notaries for fact checking.

Similarly also: It's not reasonable to assume everyone to check some rarely used mailbox. Therefore one would phone the receiver to make sure the registered messages arrives.

1879 container member >

Demo:Wallet FAQ

Q: Is this a cryptographic currency?

A: No. This is a "traditional" payment system based on contracts. Those contracts and related orders however are signed using cryptographic encoding and consensus protocols in the process.

Q: Why do use so many notaries? I'd rather trust a smaller number of peers.

A: Less than five peers are hard to use and will eventually need manual conflict resolution.

This minimum is caused by the byzantine consensus protocol, which tolerates less than 1/3rd of faulty peer. Four peers are the minimum to tolerate one fault for within one round. While one peer is left behind, the remaining three could succeed at further rounds. If any more fails at this point, the group locks up at no simple majority. The wallet is lost (until one peer is manually updated to the latest version). Five do better.

3911 container member >

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.

1818 is a > sequence
1856 is a > urn:about:/presentable/gallery
1857 title > Demo:Wallet