openmoney software specification


The term openmoney refers to any software supporting open money. The following is a minimal specification of the way in which any such software should operate.

The openmoney component is not intended to be complete and self-contained. Metasystemic components, whether technological, social or organizational, are required for any such tools to operate. Adaptive, resilient, co-evolving systems necessarily involve layers and appropriate extensions, with structure reviewed continually. The openmoney component is intended only to provide a recursively-nested ledger structure for REA accounting upon which much richer structures can be built.

Note: There is no obvious natural sequence in which the terms in this section can be defined. Most terms refer forward or backward to other terms within the section.



Pronouns: Since a user may be a person or an organization, or possibly a machine, the gender-neutral it and its are used below.

A registered user of any openmoney software can be any person or organization of persons that recognizes and accepts responsibility for:

To use open money is to mind your own business.

primary identity

secondary identity



namespaces enclosed entirely within one registry namespace

This section refers only to namespaces enclosed within the same registry namespace.

extending namespaces beyond a single registry namespace




names are reserved within a parent namespace for the four categories below: class of steward (as recognized within a particular namespace)
governing steward permitted user of space part user audit user
A steward with governance privileges on this namespace. A steward with normal access rights granted conditionally by a governance steward of this namespace. A steward with restricted access rights granted conditionally by a governance steward of this namespace. A steward with monitoring/audit privileges granted conditionally by a governance steward of this namespace.
namespaces Set this namespace as public/private Create, own and govern namespaces within this namespace if authorized by a governing steward.
Enable/disable transactions in this namespace.
Admit/deny applications by other stewards to create new namespaces within this namespace.
Enable, disable or delete stewards in this namespace.
currencies Set currencies within this namespace as public/private. Create, own and govern currencies within this namespace.
Enable/disable transactions using this currency.
Admit/deny applications by other stewards to create currencies within this namespace.
Enable, suspend or delete users of currencies namespace.
accounts Admit/deny applications by other stewards to create accounts within this namespace. Create, own and govern accounts within this namespace. Read specified account in this namespace.
Write to specified account in this namespace.
Read specified account in this namespace.
(name:currency) pairs Enable, suspend or delete users of currencies namespace.

More on terminology

The following terms are used below:

Configuration options

The following options are configured at the time of the initial setup according to policy:

relationships between named objects

recursive nesting of namespaces

The following diagram illustrates the recursive namespace structure.

Here the namespaces are labelled (untypically) in way convenient for identifying the depth of nesting from a root namespace.

At the top is a set of root namspaces (labelled "a1", "a2" ...).

Nested within these namespaces are more namespaces (labelled "b1.a1", "b2.a1", ... , "b3.a3", ...).

And so on.

This can be represented more compactly as a tree ...

... making it easier to visualize the recursive nesting of registry namespaces.

The coloured regions represent registry namespaces, which are equivalent to installations (not necessary implemented using the same technology, the only requirement being that they all conform to this very inclusive specification).

The recursively-nested structure mirrors that of the VSM. This is a natural design choice given that the REA system embodied is intended to support the viability of human-supporting systems.

Note: This approach to federation (across possibly very different implementations) requires little if any special provision. The mapping of a primary user identity in one registry to a secondary user identy can be achieved by extending the API (possibly with a single additional endpoint) to enable the mapping data to be transferred from one instance to another. Oauth2 may suffice for authentication across instances, although additional levels of security may be embodied in a simple supplementary protocol.

However, within the scope of a particular registry namespace (which is equivalent to a specific instance/installation), some of the many metasystemic tools can be integrated in a way that federated/clustered sets will not.


  1. open money

    The term open money (two words, lower case) is an aspect of free speech - it is a context (see REA), and open money can be called free money (as in free speech, not as in free beer/lunch/load/ride).

    The term openmoney (one word, lower case) refers to any software able to support the requirements of an open money implementation, operating in accordance with the principles and intellectual properties of the LETSystem Trust.

    For background information and history, see the collected links page.

    NB, open money is a special case of a broader concept: open metrics. The specification above generally applies to open metrics implementations as well.

  2. wider applicatiions

    Note: Although originally designed to support user-centred ledger systems (LETSystem model), a sufficiently secure implementation of software conforming to this specification could be be used as the ledger system underpinning any ledger-based service, including mutual credit services (such as LETSystems), loan-providing services (such as credit unions and CDFIs), energy-accounting systems, time banks or any other conceivable system recording events associated with resources and agents.

  3. key-pair generation

    The openmoney client implementation may make provision for the user's public and private key to be generated deterministically using its name and password.

  4. implementation

    At the time of the most recent update (see date below), the original Swagger 2.0 API definition is being updated and extended to create an OpenAPI 3.0 API definition. That will then be used to create a new set of consistent client and server stubs.

    * In the current test/development implementation the user logs in using a password instead.

  5. inter-registry authentication

  6. reference prototypes

    A minimal testing/demonstration implementation to illustrate and explore core principles was written by Dominique Legault, who also wrote the original draft of this specification in collaboration with Michael Linton.

    Terminology: Since every user of any openmoney software has the potentiality to be a steward, no distinction was made between these terms in earlier versions of this document. For the same reasons, the testing/demonstration implementation of the software treats all users with a login accounts as stewards.

  7. current root namespace limitation

    (In the current demonstration/test implementation, the only root namespace available is fixed as "cc" so every user is given the namespace "" upon registration.)

  8. collision-resistant names


    A name in a namespace that enables names to be allocated in a manner such that they are highly unlikely to collide with other names. Examples of collision-resistant namespaces include: Domain Names, Object Identifiers (OIDs) as defined in the ITU-T X.660 and X.670 Recommendation series, and Universally Unique IDentifiers (UUIDs) [RFC4122]. When using an administratively delegated namespace, the definer of a name needs to take reasonable precautions to ensure they are in control of the portion of the namespace they use to define the name.

Version 2.0.53 [Previous numbered version]

This document has been gradually expanded (in various stages between 2020-06-28 and 2020-08-14 by John Waters) from the earlier specification (written by Dominique Legault and Michael Linton) in order to incorporate additional notes, annotations, etc.

[The source for this page.]

Creative Commons Licence
This work is licensed under a Creative Commons Attribution-NoDerivatives 4.0 International License.