Author: Richard Kay

0.1 Abstract

This document specifies messaging protocols and processing concerned with the implementation of multiple account-based community currencies using a distributed and networked systems architecture. It provides information to enable software designers to implement conforming and compatible systems. It is also intended to provide a baseline for further standardisation of message formats together with transaction, account verification, maintenance, operational and security protocols required for interoperation between independent implementations.

This specification is concerned with transactions between accounts and the associated administration, enquiries and reports. It is not concerned with off-line transactions involving tokens such as notes, coins or virtual equivalents enabling use of similar, different or same currencies by parties not holding accounts. This specification being concerned with core architecture does not address user-interface issues.

0.2 Caveat

In order to help enable implementation activities to proceed in parallel without undue delay, this document is likely to need releasing before it is sufficiently complete and accurate to ensure that all implementations of the programs specified are fully able to communicate or provide all required facilities. To the extent that the development and testing of such reveals ambiguities, omissions and inconsistencies in this document it is intended that this specification will be progressively revised.

0.3 Revision history

Version 2.0.0 released 27 August 1998
Version 2.0.1 December 1998 - redundant information removed from registry administration records as this is present in signature records.
Version 2.02 30 Jan 1999 - new balance added to ack4 record and other minor changes.


1.1 Contents

0.1 Abstract
0.2 Caveat
0.3 Revision history

1. Preface
1.1 Contents
1.2 Copyright, Distribution and Disclaimer
1.3 Definitions

2. Introduction to MRS architecture

3. Naming convention and services
3.1 Background
3.2 Registration and form of names
3.3 Name to address lookups
3.4 Form of server address
3.5 Form of server name
3.6 Contact names
3.7 Name service

4. Functional description of programs
4.1 MRS Transaction Server (MTS)
4.2 MRS User Client (MUC)
4.3 MRS Administration Client (MAC)
4.4 MRS Audit Server (MAS)
4.5 Recommended coding and licensing standards

5. Required message formats and content
5.1 Requirements common to all MRS messages
5.2 Acknowledgement records
5.3 Report request and delivery records
5.4 System audit request records
5.5 Registry administration records
5.6 System administration records

1.2 Copyright, Distribution and Disclaimer

Copyright (C) 1998 Richard Kay

This program specification is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version.

This program specification is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.

A copy of the GNU General Public License is available from the Free Software Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA, or from their website .

1.3 Definitions


Multi Registry System: MRS

An accounting system enabling transactions, reports and enquiries on a multi-currency database distributed over a network serving multiple users and user registration/administration nodes. This term is also used for an account-based currency system whose accounts are distributed over more than one administration node or registry.

Community and other currencies: LETS

A currency can be defined as a set of accounts and/or tokens which support transactions within a trading community using an agreed unit or denomination. A community currency differs from a conventional currency in the sense that the community using it is self-defining and users are considered to have choice over which currencies they elect to use. An account-based community currency is distinctive in that the agreement between users enabling operation and use of currency accounts defines their rights and responsibilities of association. A private currency is distinctive in the sense that it is issued in the business interests of one or more private parties who back it whilst its other users would normally have no involvement in the management of the currency system. The technical architecture and message formats described in this document are technically usable for recording transactions and accounts involving any accountable currency.

An accounting mechanism for multiple currencies may also be used for the recording and preparation of users' private accounts should they so wish, and for non-monetary accounting e.g. of the locations of items of equipment belonging to a community association or shared between members of such.

Registry: REGY

The organisation which issues a trading ID to users such that within a registry each user's trading ID is unique. This ID is used by the user in respect of one or more community currencies  or systems supported by the registry. The registry is also likely to have some involvement in the community currency accounting process in respect of accounts operated by that user.

A LETSystem Registry provides this service in accordance with the LETSystem Design Manual.

User identifier: ID

This will typically be a numeric or alphanumeric identifier uniquely identifying a user within a registry.

Global user identifier: ID@REGY

If REGY is the globally unique name for the registry it follows that string combinations such as ID@REGY (with @ being a delimiter within neither ID nor REGY ) uniquely identifies users globally across all registries.

System: SYSTEM

For the purposes of this document this term identifies the community or other currency consisting of a set of accounts between which transactions can occur. Note that to provide the choice inherent within the definition of Community Currency, MRS services will normally support multiple systems, even though the same architecture, software, facilities and protocols are capable of supporting mono-currency arrangements.


If ID@REGY is a globally unique name, it follows that an account on which transactions are performed and on which balance, turnover and statement reports can be made is uniquely identified by the combination of ID@REGY and SYSTEM.

MRS Transaction Server: MTS

i. The program which maintains account data and processes transactions on it within a MRS.

ii. A process i.e. the actions performed by a instance of this program operating on a set of input and account data and producing output.

A functional description of the MTS program is provided in section 4.1.

MTS Master Server: MMS

An instance of or the process performed by an MTS Server associated with the party to an acknowledgement who initiates the recording of such. Normally for payments originated by purchaser or payer this will be the MTS associated with the purchaser's registry. For direct debits originated by vendor or payee this will be the MTS associated with the vendor's registry .

MTS Slave Server: MSS

An instance of or the process performed by an MTS Server associated with the party to an acknowledgement who does not initiate the recording of such. Normally for payments originated by purchaser or payer the MSS will be the MTS associated with the vendor or payee registry. In a fully distributed system this is likely not to be the same MTS Server as the MMS for the same transaction.

MRS Audit Server: MAS

The server or process concerned with preparing and processing data needed to audit and report data concerning whole currency systems, the transaction processing of which may be carried out by very many MTSs maintaining accounts for users registered at very many separate registries.

A functional description of the MAS program is provided in section 4.4 .

MRS Clients: MAC and MUC

A program which assembles and requests transactions, reports or enquiries and sends these to one or more MRS servers and/or displays the responses from MRS servers. Various client programs may be used to support specialised requirements such as MRS administration (MAC) MRS user (MUC) point of sale terminals, currency exchange or tax accounting etc. This document includes initial minimum requirements for MAC and MUC client programs.

Functional descriptions are available for the  MAC program in section 4.3 and for the MUC program in section 4.2 .

Acknowledgement: ACK

An identifiable transaction involving payment of a given amount using a specified currency system from one account to another.

Debit limit: DL

A limit set on a particular system account such that a acknowledgement, (payment) which takes the account below that limit is invalid.

Domain Name Service: DNS

A service by which network names organised into domains and subdomains are allocated network addresses and by which addresses associated with particular names may be referenced. For an analogy, consider the manner by which a particular telephone number might be referenced, firstly by accessing an index of telephone directory libraries relating to countries, secondly by accessing the area directory within that country and finally by looking up the telephone number (network address) based on the users name and initials.  See also IETF RFC1035.

MRS Domain Name Service: MDNS

MRS version 2 will implement IETF compliant DNS domain names for systems, servers and registries but using static host routing tables on each working server, requiring that names be registered and this table distributed by a MRS Network Information Service naming authority (MNIS). It is anticipated that future MDNS implementations will involve a fully-distributed MDNS service with distributed domain name servers and delegated domain naming authority. The transition from use of a centrally compiled and distributed host table to a decentralised DNS service is thought likely to become feasible and necessary during the transition of a MRS network from between 100 to 1000 working MTS and MAS servers.

MRS Network Information Service: MNIS

This authority will be responsible for delegation of authority of global naming domains to appropriate domain name registries based on consensus within relevant user communities. Until this authority is delegated and distributed MDNS is established the MNIS will be responsible for compiling and distributing the name to address host lookup table.




a. The existence of choice within a proliferating and diversifying range of private and community currencies and arrangements such as community way charitable fundraising, customer loyalty points etc.

b. that the electronic and systems infrastructure needed to support such diverse currencies and arrangements will be expensive to develop, operate and maintain,

it follows that there exist evolutionary advantages to implementations which support multiple currency systems sharing the same network and administrative infrastructure, terminals and smart cards etc.

This infrastructure comprises distinct entities, but has no place for rigid boundaries except as may be determined by legal, ethical and practical constraints. This specification arises from the consideration that successful infrastructure will be based on the following principles:

* there will exist no single point of failure or control

* data processing and administration are decentralised as far as possible, consistent with cost, manageability and data integrity.

* Where hierarchically managed authority is unavoidable as with domain naming and the allocation of finite network address ranges this is delegated operationally to the most local level consistent with good working practices.

* scalability is unlimited technically except by the existence of finite network addressability and cost of access.

* initial processing nodes will be cheap enough so that anyone with the requisite technical knowledge to manage a reliable database service can set one up.

The initial working prototype (MRS version 1) was implemented on the Internet (which is itself based on the above architectural principles), however, as with the IETF Internet Protocols the MRS architecture is also capable of being implemented using separate private or public networks.

MRS transaction servers (MTSs) will support multiple currencies and some currencies will need support from multiple MTSs. To ensure wide area access, accounts need to be located on a server and transactions will be routed according to registry name. Hence there are routing advantages in transacting all accounts relating to a registry on the same named transaction server whichever currency system these accounts may be part of.

The fact that a particular MTS is likely to support all accounts for one or more registries also follows from the consideration that the registry must remain a point of contact with its users in order to create or maintain the necessary tokens, passwords or keys used for identification and authentication purposes, such that limits to the number of accounts serviced by a registry are likely to be imposed by human user-support considerations which determine a maximum registry capacity. At the time of writing this limit seems likely to be less than the carrying capacity of transaction servers or fault-tolerant, high-availability clusters responding to the same global name for transaction routing purposes. It also follows that with the likely carrying capacity of a server being greater than that of a registry, transaction servers will be expected to support multiple registries.

If the opposite were to become true, i.e. that a need were to emerge to support more named MTSs than administration centres issuing unique IDs, this difficulty could very easily be resolved (without breaking the proposed naming and routing architecture) by the registry splitting its list of IDs amongst a number of its own internally administered subdomains within the higher level registry name.

The alternative approach to architectural design of a multi- currency multi-registry network would be to associate (the processing of transactions and accounts concerning) particular currencies with particular servers. Consider the likely need to operate professionally-managed community currencies for city regions with millions of accounts carrying perhaps hundreds of millions of transactions daily (in addition to the parallel use of very many more much smaller user-managed currencies). The consequent association of single currencies with single server complexes as centralised economic failure points for whole regions would inevitably attract patterns of corporate management functionally and organisationally inconsistent with the design objectives stated above.

This architectural design is consequently based on the consideration that community currency users will primarily be serviced through multi-currency handling registries. It follows that network services will be registry centric as opposed to system centric.





3.1 Background

For the infrastructure supporting these to be shared, registries, systems and servers require globally unique names. Entities using a particular name will need their messages addressed and routed to an appropriate destination.

There is however no particular reason why registries, systems and servers need share the same namespace, so for example the same name might conveniently be used by a MTS, the registry it serves and the currency system used by all of its users for paying cost of registry service within the terms of its common members' agreement, though a resource conflict would occur if 2 systems or registries or servers attempted to share the same name.

3.2 Registration and form of names

To guarantee uniqueness, names must be registered. Operating this globally for very many users requires delegation of parts of the namespace. For example, by following the Internet DNS Domain Name System model, should the registration authority for the .uk (United Kingdom) domain decide following consultation with interested parties that work should be so delegated, this could be handled by maintaining separate registers for,,,,,, delegated domains for Southern, Midlands, and Northern English regions, London, Manchester, Wales and Scotland etc.

Names must comply with IETF RFC1035 to enable use of existing DNS server and resolver programs and libraries.

3.3 Name to address lookups

The following global lookups are needed (reason):

REGY --> MTS_ADDRESS (where to send local/remote acks etc.)
SYSTEM --> MAS_ADDRESS (where to send ack copies for audit)
MTS_ADDRESS --> MTS_CONTACT (who to inform if MTS not responding)
MAS_ADDRESS --> MAS_CONTACT (who to inform if MAS not responding)
DOMAIN --> MDNS_CONTACT (administrative contact for domain)
Global lookups will be maintained through the MDNS service.
Local lookups on MTS server (reason):

admin@REGY --> REGISTRY_CONTACT (regy contact/authentication)
id@REGY --> ONLINE_USER (online user contact/authentication)
REGY --> SYS1, SYS2 ... SYSN (list of systems for which registry services some or all accounts)
The list of systems and online user details are maintained by the registry administrator. The registry contact/authentication details are maintained by the MTS administrator.
Local lookups on MAS server (reason):

SYSTEM --> SYSTEM_CONTACT (system auditor or contact)
SYSTEM --> BLANKET_AUTHORISATION (blanket authorisation for system users)
SYSTEM --> REGY1, REGY2 ... REGYN (list of registries handling
                                   accounts for system)
The system auditor/contact data is maintained by the MAS administrator. The list of registries and blanket system user authorisation data are maintained by the system administrator. Blanket authorisations determine the level of data access by system users of each others' data. Values for authorisations are 0 - none, 1 - account balances only, 2 - balances and turnover data, 3 - all data.


This will take one of the following forms:

a. IP address

This requires registration of a well-known service and associated port number for the MRS client-server packets. (Not yet supported.)

b. IP_address:port_number (Not yet supported).

c. email_address

Forms a. and b. are commonly used for Internet client-server networked application bindings while form c. may be used for MRS implementations using email as the packet transport. This specification is intended for initial test implementation using form c.

3.5 Form of SERVER name

MTS and MAS server names will be as registered on the MDNS and will in all other respects adhere to IETF RFC standards. This allows for a more general implementation and caters for situations where MRS servers are located on non-Internet networks possibly with gateways between physical networks and also the situation where the same physical server supports multiple servers each with their own name.

3.6 Contact names

Error messages relating to any particular entity (registry, system or server) will be directed to the registered contact for that entity. The contact name will normally take the form of an email address.

3.7 Name service

In order to provide a small MRS network with less than say 300 servers, the use of static look-up data on the MTS and MAS servers distributed by a MNIS is considered practical. With a greater number of hosts or a large rate of change of lookup data use of a full blown distributed DNS type service is indicated. It is anticipated that separate instances of servers (MDNS) will be used from those DNS servers used for Internet name to address lookups to enable separate MRS namespaces.



4.1 MRS Transaction Server (MTS)

This program:

a. processes transactions involving payments into and out of accounts for registry users directly serviced. It either communicates with another MTS handling the account for the other party to a payment, or if both payer and payee accounts for a particular transaction are on the same MTS it processes both.

b. sends details of completed or failed transactions to the transaction initiator and MAS for the system.

c. handles administrative requests concerned with the creation and removal of user accounts and setting of debit limits on systems within which these are used.

d. responds to requests concerning account balances.

e. authenticates the originator of all such transactions and requests and verifies the validity of the request, or rejects such if invalid.

f. maintains account balance and turnover data, and other data as is required to maintain transactional integrity on account balance and turnover data and to authenticate and verify transactions and requests.

4.2 MRS User Client (MUC)

This program interfaces directly with currency users enabling them to make payments directly, and those whom currency users authorise to make payments on their behalf. MUCs may also be used for requesting payment verification data on particular accounts. It is anticipated that various MUC clients and user interfaces will be implemented on a variety of platforms and systems, some handling specialised requirements such as smart-card POS (Point of Sale), currency exchange dealing and tax accounting etc.

For the purposes of this specification, the minimum requirements are as follows:

a. ability to convey information identifying party requesting payment or information to a MTS or MAS and information authenticating this identity.

b. ability to request payment from payer (purchaser) to payee (vendor) on a given system to a MTS and receive responses indicating success or failure of such requests.

c. ability to request and receive payment verification data on a particular system account to a MTS. In the case of a LETSystem account this data will take the form of an account balance and turnover data. Note that such a request may be authenticated by a different MTS from that containing the requested data. In this event it will be forwarded from the authenticating MTS (which maintains the requesting users' account) to a authorising MTS (which maintains the requested data) and which responds directly to the requesting MUC.

d. ability to request audit information from MAS servers, (via authenticating MTS servers).

e. ability to display and/or print responses to the above requests.

4.3 MRS Administration Client (MAC)

4.3.1 MAC Registry administration

The following features of the MAC program will normally be used for the purpose of registry/MTS administration:

a. To carry out user registration work, creating user accounts for all systems to be used on the registry MTS.

b. To upload user authentication details such as passwords and public keys and on-line user return addresses to the MTS servers.

c. To enable users to authorise others to make payments from their accounts (e.g. in respect of direct debits or to enable their accountants or account managers to make payments on their behalf), by registering these authorisations with the MTS serving the registry.

d. The MAC will maintain a list of systems on the MTS for which the registry is willing and authorised to maintain accounts.

e. The MAC will also be able to display the responses from the MTS server indicating success or failure of these requests.

f. A MAC must also contain all of the features described in 4.2 for a MUC.

4.3.2 MAC system administration

The following features of the MAC program will normally be used for the purpose of system/MAS administration:

a. maintaining the list of registries on the MAS willing and authorised to service user accounts for each system.

4.4 MRS Audit Server (MAS)

While the MTS is designed for handling transactions on behalf of users of particular registries, the MAS is designed to help users manage the integrity of data and processes concerning particular systems or currencies. Users or auditors acting on their behalf wanting to obtain details for all accounts on a LETSystem or other account-based community currency, the transaction processing of which might be spread over very many MTSs, would obtain this information through a MAS.

The MAS will:

a. receive, secure, acknowledge receipt and verify data concerning all transactions on one or more serviced currency systems.

b. Compare both halves of each transaction to ensure MMS and MSS parts are consistent.

c. Inform the system contact in the event that inconsistencies are detected.

d. Provide reports containing details of all transactions and system summary data for audit purposes on request to authorised users.

In line with its audit function the MAS has no operational involvement over how individual acknowledgements are processed.

4.5 Recommended coding and licensing standards

Style: It is recommended that source code be well structured, adequately commented for other interested parties and non- cryptic.

Portability: Programs should be written portably, using standardised features of languages supported by multiple compilers, interpreters, platforms and vendors, in order to minimise the difficulties of porting code between different platforms.

Modularity: A modular approach should be adopted to standardise interfaces between core processes and different user interfaces and data transport protocols.

Reusability: Publication of source code ensures that software can be reused and avoids programmers having to redo what has already been done. Use of the GNU Public License (GPL)  is recommended for this purpose.

Security: Open peer group review of code security and integrity also requires publication of source code, see also .




5.1 Requirements common to all MRS messages and handlers

contents  encapsulation protocol_dependent plaintext_format signature handshake ping record_types

5.1.1 General

These message formats are described independently of the data transport mechanisms which might be used (e.g. UUCP, TCPIP sockets, SMTP email, HTTP etc.) to enable client and server software to be written compliant with this standard and able to process community currency transactions carried over various networks.

This specification provides the minimum data formats needed to ensure messaging integrity; i.e. to ensure that distributed transactions can be completed based on a known level of server and network availability. The requirement to ensure message authentication and confidentiality is however seen as changing, with very little security of these kinds needed in an experimental environment not currently exposed to technically sophisticated attack but where an increasing requirement exists as digital representations of increasing financial values are carried over the proposed network. This standard provides a framework for increasing levels of security to be implemented together with backwards compatibility to enable more and less technically developed parts of the proposed network to communicate with each other.

Where encryption is used to protect the confidentiality of data in transit this document currently describes the format of message contents prior to such encryption and following associated decryption. When confidentiality encryption standards are agreed this document will be extended to include relevant data exchange formats.

5.1.2 Data encapsulation

One or more encapsulation and encryption stages may be used prior to message transmission, with corresponding decryption and decapsulation stages following message receipt depending on factors including:

a. Whether encryption is carried out to ensure confidentiality,

b. the data transport protocol used, for example message contents may need to be delimited using start and end identifiers or tags from protocol or implementation specific data preceding or following the message body (e.g. email headers and footers).

c. whether message contents need checking against digital signatures or checksums.

In general tags and records used to control this encapsulation will precede or follow the information being encapsulated and will be removed prior to further processing on message receipt. This includes records containing data used to verify message contents which will be removed from the core contents prior to verification of such contents. For example a signature record containing a checksum is not considered part of the message content from which this checksum was calculated and which the checksum will be used to verify.

5.1.3 Protocol dependent tags and delimiters

EMAIL: where email is used as the message transport mechanism in connection with this specification, in order to distinguish message data from automatic email signatures, gateway and header information, plaintext messages described below will be preceded by a single text record containing the text:


and will be followed by a single text record containing the text:


Other message transport protocols: Not yet defined.

5.1.4 Plaintext message format and reserved characters

Message contents will consist of one or more text records each consisting of printable ASCII characters between start and end of message separated by newlines. The first field of a record is its record type. Records will contain one or more fields delimited by commas (,). The use of commas and newlines directly within fields is prohibited to simplify message parsing. Other reserved characters include at (@), colon (:), single quote('), double quote(") and backslash(\). These reserved characters may only be used within fields as specified. Such uses may include delimiting data within certain fields or in combination with other characters to encode prohibited or reserved characters which might in future require transmission within certain fields through the MRS for the purpose of data preparation, reporting or communication between other systems external to the MRS.e.g:

record_type_3,transmitting commas\c encoded as \c
record_type_4,transmitting newlines\n encoded as \n
record_type_5,transmitting backslashes\\ each encoded as \\

5.1.5 Signature records

This record type contains information used by message recipient to authenticate message originator and confirm that the message received is identical to that sent.

If present signature record(s) will precede the message body they are used to authenticate and will be processed in sequence starting with the first, each being removed in turn before being used to authenticate the rest of the message body from which they are removed, which will include any following signature records in the sequence not yet processed.

For the lowest level of authentication only the sender signature type is required in order to assert the identity of the message sender. As implementations of this standard are developed and new methods become available it is anticipated that definitions of signature methods and data will be included and refined within future revisions of this document.

The authentication methods used will depend upon the state of transaction server development and agreements between server operators, registries and users about authentication requirements. Providing for alternative authentication methods within message standards allows for the progressive upgrade of software with backwards compatibility between different versions.

Signature records will use the following format:


where "signature" is the record type,

method is a word referring to the authentication method used taken from the values: SENDER, CKSUM, CHKORIG, PASSWD ... etc. as described below, and data is a field containing the checksum, password, key requiring knowledge of password, or digital signature etc. depending on value of method. Data is not yet fully specified for all suggested methods; where unspecified a description of data purpose is given.

Authentication methods making use of this record may include:

CKSUM; This method involves use of a checksum transferred with message to validate that message contents as received were not accidentally corrupted.

E.G. signature,cksum,9762940

SENDER; This signature record is used to assert message sender and program type and by itself provides no security. Data consists of 3 fields:

i. SENDER TYPE which must be one of the following words: MUC, MAC, MTS, MAS and

ii. the sender identity, which will be of the form ID@REGISTRY in the case of type MUC, admin@REGISTRY or admin@SYSTEM for type MAC, NAME.OF.SERVER for types MTS and NAME.OF.SYSTEM for type MAS.

E.G.1 signature,sender,MUC,
E.G.2 signature,sender,MAS,

MSGID; This method is used to exchange a unique message ID which may be referred to later in handshake records required by the CHKORIG signature method.

CHKORIG; This method indexes a protocol dependent handshake method such as dialback, reverse DNS lookup etc, confirming connection is coming from a known originator address to determine message origin. CKSUM and MSGID signature records must precede this record if this method is used. If so further validation and processing of the message will be deferred until handshake records have been exchanged successfully with the message originator. The data related to this method is the name of the message transfer protocol to be used for exchanging handshake records, e.g. email, UUCP, dialback, IP socket etc which together with the sending_server MSGID data are used to reference a previously assigned network address or dialback number etc. with which to exchange handshake records.

PASSWD; The data used with this method is an unencrypted plaintext password. This provides an elementary degree of security within a network environment in which it can be assumed that messages are transported confidentially.

CRYPTKEY; This method is used to send a one-way encrypted key which can be calculated from message contents and a key known by message sender and receiver but not transmitted as part of the message. The message receiver will recalculate and compare this key and will only accept the message as valid if received and recalculated keys match. The data part of this method (key) is generated through use of a one-way function such as Unix crypt or similar on a string function combining checksum and password.

PK; This method involves the use of public-key encryption to create a digital signature transferred with messages which the signature is used to confirm. This method enables message senders to be authenticated without requiring transmission of any shared secrets. Full implementation of this method in an open-source context is dependent upon the availability of technically viable libraries with minimum licensing and other legal restrictions, see section 8 of the GNU task list .

5.1.6 Handshake records

Messages containing handshake records will contain only 1 record. Their purpose is to confirm that the sender, identity and contents of a message previously received are valid by contacting the message sender directly and receiving confirmation. Successful handshake involves looking up a previously registered network address for the message originator and protocol, sending CHECK and receiving CONFIRM handshake records.

The record format is as follows:



from_server is the DNS style name of the server sending the handshake record.

cksum is the validated checksum signature of message being checked, (see signature,CKSUM above).

msgid is the identity of message being checked or confirmed (see signature,MSGID above).

word is CHECK if this handshake is sent to check origin of a previous message, TRUE if sent to confirm a handshake CHECK record and FALSE if the CHECK record cannot be confirmed.

5.1.7 ping records

The purpose of this record is to assist with network and system testing and debugging activities, by enabling those testing configuration and operation of a MUC, MAC, MTS or MAS to check presence of application service at a particular address and bidirectional communication. If a ping record is present it will be the only record in a message following the signature,sender record . The record format is as follows:


Where stage can take values send and reply and timestamp is the number of seconds since 1 Jan 1970 as obtained using standard Perl and C libraries. Receipt of a ping,send record will be responded to using a ping,reply record.

5.1.8 record types and order

The following record types are defined:

General purpose: signature, handshake, ping

Acknowledgement: ack1, ack2, ack3, ack4, ackr2, ackr3

Request report: rqrp1, rqrp2, rqrp3, rqrp_error, balance, turnover, detail

Audit request: arq1, arq2, arq3, au_error, au_bal, au_turn, au_detail

Registry administration: add_acc, mod_acc, del_acc, rprt_acc1, rprt_acc2 add_ou, mod_ou, del_ou, rprt_ou1, rprt_ou2 add_auth, mod_auth, del_auth, rprt_auth1, rprt_auth2 add_sys, del_sys, rprt_sys1, rprt_sys2

System administration: add_regy, mod_regy, del_regy, rprt_regy1, rprt_regy2

Signature records will precede other records if present and will be in the order they are processed. A handshake or ping record if present will be the only record in the message. Other records will follow signature records. Header records (rqrp3 and arq3) will precede the other report records to which these refer, the number of which (num_recs) will be present as a field within the header record.

5.2 Acknowledgement records

contents  ack1  ack2 ack3 ack4  ackr2 ackr3

5.2.1 General

An acknowledgement most typically represents a statement by a user crediting another user with having provided goods and services to a stated value (or some other monetary transaction such as a gift), within a defined context provided by both users having accounts with the same community currency or system. In many cases the processing of this statement will be initiated by the purchaser or payer, or might otherwise be initiated by the payee or vendor, as authorised by purchaser to debit his or her account.

Fields common to more than one type of ack record include:

ack_id: a decimal sequence number identifying the acknowledgement in connection with the originating registry. e.g. 123456 . This number will be positive for a normal acknowledgement, the amount of which is added to aggregated turnover data for both payer and payee. However if a previously cleared acknowledgement is repudiated or reversed this will be achieved by resending it (from the server which originated the original transaction) with its ack_id number preceded by a minus sign and the original amount reversed and deducted from aggregated turnover data for both payer and payee. The need for a unique ack_id in connection with the originating registry implies a sequential allocation of ack_ids by the MMS process or thread for a particular registry.

from_registry and to_registry: are DNS style domain names uniquely identifying the originating and responding registries. e.g.

from_id + to_id: are alphanumeric identifiers uniquely identifying payer and payee within their respective registries. e.g. RIK

system: is A DNS style domain name uniquely identifying the currency or set of accounts between which direct transfers of funds is possible. e.g.

amount: is a decimal integer optionally preceded by a minus sign and optionally followed by a period followed by between 1 and 3 decimals.

date: is a date, format YYYY/MM/DD .

details: may be a text description of transaction or other data carried with the acknowledgement, e.g. a customer number used within a payee account-reconciliation system.

reason is a code indicating the reason for rejection. The following reason codes are suggested:

     1 to_id unknown here or has not opened account on system  
     2 to_registry unknown here
     3 system unknown here
     4 signature verification failure
     5 payment exceeds predefined limits
     6 invalid data
     7 unauthorised payment

5.2.2 ack1: Acknowledgement record stage 1

This record is used to transmit an acknowledgement or payment, typically a credit from MUC client program used by payer (purchaser) to the MTS used by payer's registry. If sent in opposite direction for a debit initiated by payee (initially to payee's registry MTS) amount is negative.

record format:

ack1,from_id,from_registry,to_id,to_registry,system, amount,details

5.2.3 ack2: Acknowledgement record stage 2

This record is used to transmit an acknowledgement or payment from the MTS Master Server (MMS) to the MTS Slave Server (MSS). This is typically a credit from MTS used by purchaser to MTS used by vendor. If initiated by vendor (or payee) for a direct debit type transaction the amount is negative. A copy of the ack2 record is also sent to the MAS for the system.

record format:

ack2,ack_id,from_id,from_registry,to_id,to_registry,system, amount,date,details

Note that ack_id and date are generated by the MMS sending this record.

In the event of intermittent server or network failures, identical ack2 records may need to be sent repeatedly in respect of the same acknowledgement until an ack3 record is received or the transaction is timed out, in which event it will need to be completed or rewound manually. The decision to time out is made by the ack3 sender.

Identical ack2 records may also need to be sent to the MAS for the system repeatedly until an ackr2 record is received or the effort to inform MAS is timed out, in which event the MTS operator and system contact will be informed.

5.2.4 ack3: Acknowledgement stage 3 record

This is sent by the MSS in response to an ack2 record to the ack2 sending MMS. A copy is also sent to the MAS for the system.


accept_or_reject contains the word accept or the word reject. reason will be OK for accepted records or the reason for rejection.

Identical ack3 records may need to be sent more than once in response to identical ack2 records in the event of intermittent network or server failures either until the ack3 is received by the MMS or until the MMS sending the ack2 records times the transaction out.

Identical ack3 records may also need to be sent to the MAS for the system repeatedly until an ackr3 record is received or the effort to inform MAS is timed out, in which event the MTS operator and system contact will be informed.

5.2.5 ack4: Acknowledgement record stage 4

This record is used to transmit results of an acknowledgement request from the MMS to the MUC originating it.

record format:

ack4,ack_id,from_id,from_registry,to_id,to_registry,system, amount,date,details,new_balance,accept_or_reject,reason

new_balance is the balance on the account after the acknowledgement has been accepted - in the case of ack4 rejects the value of this field is not used or meaningful. Accept or reject fields and reason codes for rejected acknowledgements are as for the ack3 record.

5.2.6 ackr2: Receipt for ack2 record from MAS

This record is sent by the MAS for the system as a receipt for the ack2 record copy received. It is sent to the MMS which sent the ack2 copy. In the event that identical ack2 records are received by the MAS identical ackr2 records will be sent.

record format:


5.2.7 ackr3: Receipt for ack3 record from MAS

This record is sent by the MAS for the system as a receipt for the ack3 record copy received. It is sent to the MSS which sent the ack3 copy. In the event that identical ack3 records are received by the MAS identical ackr3 records will be sent.

record format:


5.3 Report request and delivery records

contents  rqrp1  rqrp2 rqrp3 rqrp_error balance turnover detail

5.3.1 General

This facility is used to request and obtain balance, turnover and trading details (statement) data held for a user of a particular system, either:

a. by a user checking their own account and requesting a statement or balance data on one or more than one system,

b. or by another authorised user in connection with systems allowing such disclosure within their members' agreement in order to enable users to verify each others' accounts to promote appropriate use,

c. or by an accountant authorised by the user for the purpose of presenting accounts for tax or other reporting requirements.

The rqrp1 record requesting such data is sent from the MUC to the MTS for the user's registry able to authenticate the identity of the user requesting this data.

The MTS in receipt of the rqrp1 request will either allow or refuse it based on whether the identity of the user requesting this data can be correctly authenticated. If allowed further processing will be intermediated using data as specified in a rqrp2 record, either locally if the user about whom the request is made is local to the MTS or otherwise by sending this rqrp2 record to the MTS holding relevant balance, turnover and details data able to answer this request. (If authentication is not successful reasons for refusal will be communicated directly to the requester using a message containing a rqrp3 header and rqrp_error records).

The requester id and requester registry fields will be obtained from a signature,sender record contained within the message containing the received rqrp1 record. Requester address to which the rqrp3 response will later be communicated will be derived from requester id and requester registry. (This implicitly restricts balance data to be sent only to the address previously registered for requester in order to keep this enquiry more secure and straightforward. This restriction may at some stage need to be selectively lifted if demands arise which can justify greater flexibility. This would be achieved through use of a separate requester_address field within the rqrp1 record subsequently transmitted using the rqrp2 records.)

The MTS receiving or processing the rqrp2 request may also allow it or refuse it based on whether the (previously authenticated) party requesting data is authorised to obtain it, either as required by a members' agreement, or by the party whose balance/account information is requested.

This MTS will send data if authorised, or communicate reasons for refusal directly to the requester using a message containing a rqrp3 header record.

Field descriptions:

id,registry: the user and registry identifiers of the account about which information is requested.

system: On rqrp1 and rqrp2 records, where the system field is set to the reserved word "all", data for all systems used by this user is requested. On rqrp3 records, the value for system will be the system, report data concerning which is headed by same rqrp3 record.

level: indicates the level of information requested. Different systems will allow different levels of disclosure to account holders. The level field contains 3 characters each of which may either be a hyphen (meaning type of data not requested) or the letter b (for balance) t (turnover) or d (for details). E.G:

b--  - Balance only
bt-  - Balance and Turnover data
btd  - Balance, Turnover data and transaction Details
--d  - transaction Details only.

5.3.2 rqrp1: Request report stage 1

data format:

5.3.3 rqrp2: Request report stage 2 record

data format:

field descriptions:

rqr_id@rqr_regy: the user and registry identifiers of the party requesting information.

rqr_addr: information enabling transaction server to communicate requested data or reason for refusal of or inability to carry out request to party requesting data.

is_user: This field records whether or not the user requesting data is a user of the system relating to which data is requested. The MTS authenticating user requesting data may need to provide this information to the MTS authorising the request for the latter to be able to decide whether to honour it. Valid values are Y (yes) and N (no) .

5.3.4 rqrp3: Request report stage 3 header record

This record is used as a header to assist with processing of report data requested when received by the requester. This header record will be followed by one or more error, balance, turnover and transaction records. If data for more than one system is requested, data concerning each system reported upon will be headed by a separate rqrp3 record.

data format:

field description:
num_recs is the number of rqrp_error + balance + turnover + transaction records resulting from the enquiry relating to system immediately following the rqrp3 header record.

5.3.5 rqrp_status record

data format:

Reason is a short explanation of the reason for allowing or refusing the information request.

5.3.6 balance record

record format:

Field descriptions:

amount: is the current balance in the account.

allocated: is the amount allocated to transactions initiated but not yet fully cleared; when all this amount is cleared balance will be reduced by this number.

limit: is the limit set on this account such that a transaction taking the account below this will be rejected. The reserved word "none" is used for accounts on systems without limits processed automatically by the MTS servers.

5.3.7 turnover record

record format:

Field descriptions:

Periods are either date ranges (from_date-to_date) using format YYYY/MM/DD-YYYY/MM/DD relating to the period for which the turnover total is accumulated or 4 digit years e.g. 1999 is exactly equivalent to 1999/01/01-1999/12/31 , or the word: all indicating total turnover from
when account opened to current date.

total is the amount turned over, with receipts in and payments out both made positive and added to total. Repudiated/reversed transactions are removed from turnover data for the period in which the original transaction was recorded. The number of turnover records sent will be the number normally stored for the system or available for the user (e.g. members of a system might have an agreement limiting availability of turnover to the most recent 2 years plus from the date account opened to current date).

5.3.8 detail record

detail records may be sent either in respect of systems allowing this level of disclosure or to users requesting their own details, or to those authorised by users (e.g. their accountants) to access this data.

record format:

Field descriptions:

ack_id,amount and details: are the same as on the ack2 record.

date: is when the acknowledgement cleared (i.e. when ack3 record received and processed by MMS).

with: is the ID@REGY global identifier of the party with whom the acknowledgement occurred.

new_bal: is the balance recorded on the account following the acknowledgement as on the ack4 record.

5.4 System audit request records

contents  arq1  arq2 arq3 au_error au_bal au_turn au_detail

5.4.1 General

Section 5.4 concerns records sent from a MUC program to the MAS (via the MTS able to authenticate the online MUC user) resulting in a system summary or full report. This purpose of this audit function is to obtain data stored for all users of a system (who may be supported by many registries and MTS servers) as held on the audit server for that system.

The arq1 record is sent from the MUC to the MTS used to authenticate the online user making this request. This MTS either authenticates this user and sends a arq2 to the MAS for the system or fails to authenticate.

The MAS will either honor or refuse the request depending upon whether the user is authorised to see the level of data requested. The resulting report will be sent directly to the requesting user following an arq3 header record.

Fields used in more than one record:

system: the name of the system being audited

level: is the level of information requested. E.G:

b-- - balances only
bt- - balances and turnover records
btd - balances, turnover records and transaction details
--d - transaction details only

5.4.2 arq1 audit request record sent from MUC to MTS

record format:

5.4.3 arq2 audit request record sent from MTS to MAS

record format:

field descriptions:

rqr_id@rqr_regy: the user and registry identifiers of authenticated party requesting information.

rqr_address: information enabling transaction server to communicate requested data or reason for refusal of or inability to carry out request to party requesting data.

is_user: This field records whether or not the user requesting data is a user of the system about which data is requested. The MTS authenticating user requesting data may need to provide this information to the MAS authorising the request for the latter to be able to decide whether to honour it. Valid values are Y (yes) and N (no) .

5.4.4 arq3 audit report header sent from MAS to MUC

On receipt of a arq2 record the MAS will authorise or refuse it and communicate results to the requester. The arq3 record is used as a header to precede au_bal, au_turn and au_detail records or a arq_error record if unauthorised.

record format:

field descriptions:

date: is the date of the report in YYYY/MM/DD format

num_recs: is the number of au_bal, au_turnover and au_detail (or error) records in the report headed.

5.4.5 au_status audit request status record

If the user requesting data is not authorised to see it the arq3 header will be followed by an au_error record giving reason for refusal.

record format:

reason is a short description of the reason for refusal or acceptance of information request.

5.4.6 au_bal audit balance record

record format:


field descriptions:

amount: is the current balance in the account.

allocated: is the amount allocated to transactions initiated for which the MAS has received ack2 but not yet ack3 records (i.e. not yet fully cleared). When all the allocated amount is cleared balance will be reduced by this number.

limit: is the limit set on this account such that a transaction taking the account below this should be rejected by the MTS. The reserved word "none" is used for accounts on systems without limits processed automatically by the MTS servers, and "n/a" is used where this data is not present on the MAS.

5.4.7 au_turn audit turnover record

record format:


field descriptions:

date range is either from-to dates both in format YYYY/MM/DD relating to the period for which the turnover total is accumulated, or an entire years worth of data for year YYYY or the word all to indicate all turnover on account from date opened to current date.

amount is the amount turned over, with receipts in and payments out both made positive and added to total. Repudiated/reversed transactions are removed from turnover data for the period in which the original transaction was recorded. The number of turnover records sent will be the number normally stored for system audit purposes.

5.4.8 au_detail audit transaction detail record

au_detail records are sent to parties authorised to carry out a complete audit of a system who are given access to all data in order to help carry this out.

record format:

au_detail,ack_id,from_registry,from_id,to_registry,to_id,system, amount,date,details,new_bal

field descriptions:

Fields are the same as on the ack2 record except for record type and new_bal which is the balance recorded on the account following the acknowledgement.

5.5 Registry administration  records

contents  account records online_users authorisations system records

5.5.1 General

Section 5.5 concerns records sent from a MAC program used for registry administration to a MTS server storing and processing data for the registry users.

The term "registry administration" is used for adding, removing and modifying identification, authorisation and account facilities for registry users at the appropriate MTS server. These records will be preceded by the appropriate signature records used to authenticate the message originator.

Not all users for whom accounts are kept will be on-line. Those who are not on-line will authorise particular users who are on- line to carry out specific accesses to specific system accounts on their behalf. Return addresses and authentication keys will be maintained for on-line users. Account details and authorisations will be recorded for all users.

In order to help validate administrative requests, registry administrators will maintain a list of systems for which the registry is willing (and has been authorised by system management) to support user accounts.

5.5.2 Add, modify, delete and report account records

record formats:


del_acc records will only be processed if balance is 0.

rprt_acc1 records are sent by MAC to MTS and data for each user is returned with a rprt_acc2 record.

field descriptions:

id,system: identification of account being added, modified or deleted (together with registry for which MAC sender id is admin). For mod_acc and rprt_acc1 records a value of "all" for id is meaningful.  rprt_acc2 records use the full user identification id@registry.

init_bal: is the users initial balance. This will be 0 unless the user has traded on the system prior to transfer of system data to MRS. In other circumstances balance may only be modified through an acknowledgement.

limit: is the limit set on this account such that a transaction taking the account below this will be rejected. The reserved word "none" is used for accounts on systems without limits processed automatically by the MTS servers.

error: meaningful values for error currently understood to be either "none" or "user does not exist".

5.5.3 Add, modify, delete and report online users

These records are used to manage records maintaining authentication keys and return addresses of online users.
Record formats:
rprt_ou2 records will be returned for each online user referenced with full user identification (id@registry). Access details only need to be managed for users for whom direct MTS access facilities are provided (e.g. those with access to email or other supported messaging protocols as these are included). A user is assumed to require the use of one single key for data relating to all systems on the MRS which he or she is authorised to access.

field descriptions:

id: identity of online user whose access details being added, modified or deleted together with registry of admin user for MAC. For rprt_ou1 records a value of "all" for id is meaningful.

key: The password, encrypted password, public key or identity of public key used by MTS to authenticate user using the signature method which is agreed and operational.

address: protocol and address to which all communications to user will be addressed. Consists of a protocol followed by a colon followed by the address using protocol. Currently SMTP email is the only protocol supported e.g.

error: meaningful values for error currently understood to be either "none" or "key does not exist".

5.5.4 Add, modify, delete and report authorisation records

Record formats:
add_auth records add access, mod_auth can modify only the access level and del_auth records remove access. A rprt_auth1 record is used to obtain a report of authorisation recorded by the MTS and is responded to using one rprt_auth2 record to report each relevant user authority record held.

field descriptions:

id: identity of user authorising another to access his or her details relating to system (registry as for admin using MAC). For rprt_auth1 records reserved value of "all" for id is meaningful.

authid@regy: identity of user authorised to access details relating to system. For rprt_auth1 records reserved value of "all" for authid@regy is meaningful.

system: system for which access authority is granted. The reserved word "all" means all systems for which authorising user is currently registered now and in the future.

access: level of access authorised as follows;

read  - authid@regy may obtain details of account.
dd    - authid@regy may debit directly from account. 
write - authid@regy may make payments from accounts to any user
        of system on behalf of id@registry.
all   - authid@regy authorised to read, dd and write access
error: meaningful values for error currently understood to be
1 - none 
2 - id does not exist
3 - id has no account on system
4 - unknown access level

5.5.5 add,delete and report system records

The registry administrator maintains a list of systems for which this registry is willing (and authorised by system management) to service user accounts. This data will be (until this can be done securely through the MDNS) . An MTS will check validity of this data before attempting to complete an acknowledgement or other transaction involving a system for a registry user.
Record formats:
field descriptions:

system: is the unique global system name allocated to system. Use of the reserved word "all" for system is meaningful for rprt_sys1 which requests a report of systems. Each system for which a report is requested is responded to with a rprt_sys2 record.

auth: is the level of information all system users are authorised to access through members' agreement, without regard to other authorisations on individual accounts.

The following values for auth are defined:
0 - none
1 - balances only
2 - balances and turnover records
3 - balances, turnover records and all transaction details
4 - transaction details only
error: is returned to indicate an error condition in processing the rprt_sys1 request.
The following error codes are defined:
0 - no error
1 - system not recorded
Note that authorisation details may be transferred to the MDNS service when this is developed sufficiently such that this is not thought to introduce security holes in processing this field.

5.6 System administration records

contents  registry_records

5.6.1 General

Section 5.6 concerns records sent from a MAC program used for system administration to a MAS server storing and processing data for system audit purposes.

The term "system administration" is used here for maintaining the list of registries authorised to service a currency system which is audited using the MAS.

Records used for this will be preceded by the appropriate signature records to authenticate the message originator.

5.6.2 add, delete and report registry records

Record formats:
field descriptions:

system: is the global system name for which the registry list is being maintained. regy is the global name allocated to registry. rprt_regy1 requests a list of registries authorised to service system. The response to a rprt_regy1 record is headed by a rprt_regy2 record, with numrecs being the number of following regy records, each containing an authorised registry name.