Local Currency Software Standard (LoCuS)

LoCuS is a flexible model for complementary currencies which aims to embrace many other systems. Intended for modelling in software, the parameters of the system are flexible enough to allow communities to experiment. LoCuS might stand for:

Local Currency System Support | Software | Standards.

Presented as a set of requirements, it extends the specification for a Universal Transaction Engine drafted originally by Mary Fee and other British activists.

LoCuS forms a collection of recommendations and standards to allow the construction of software to support more localised economies, (such as LETS, TimeBanks, Time Networks, "legal tender"), Later it could also support conjectural types (such as energy credit systems and all those which might be inferred from the various typologies/categorizations produced).

This document does not explain how community currencies work

Contents

Combining cc models

LoCuS incorporates a wide variety of types of currencies, and can be configured to work with one community trading one currency or for many independent communities trading multiple currencies.

Each system has a base currency which can be used directly, or multipled into different currencies. A system with more than one currency assumes that each currency can be expressed in terms of the base currency, but whether each currency can actually be exchanged is optional.

Each user account would have a maximum/minimum limit which is checked before each transaction is cleared. Currency is issued on spending. In some systems users do this but in other systems it is done centrally only.For this purpose each system has a balancing account which performs transactions when no other account can. This keeps the whole system at zero balance, but can be ignored. The balancing account can also be used for sending money between systems, rounding down currency conversions, or central funding.

Working within these parameters it should be possible to express many different currency designs in the one system, and by emphasising properties of currencies, several quite different currencies could run on one system, some of them exchangable. For example, Timebanks always the use a currency, called hours, a non-exchangable currency unit valued at 60 minutes, in which invited members are issued Hours from a central source and may not trade below zero.

Schemes wishing to use paper currencies could use LoCus system as a bank, using a cash account for all the unredeemed notes.

Later, there need to be protocols for transacting between instances of the software. Work has already been done on this, see Richard Kay's work on Multi Registry System Specification

Transactions

The transaction is the core part of LETS. It has a lot of properties and constraints.

1. There should be one way and two way transactions. Most transactions would need to be proposed by one member and confirmed by the other. It shouldn't matter which way around. Members would need special permissions to give or take currency without confirmation
2. Each transaction should include the last date it was changed, payer id, payee id, whether it was initiated by the payer or payee, whether or not it is complete, reason for its refusal, the currency, the quantity, the quality of transaction should be required from the payer, and comment saying what the payment was for. Transactions should be categorised, either by the user, or with keywords.
3. The payer should select a quality rating for what was paid for.
4. Transactions may be subject to leakage (see below). Users would be informed on the confirmation page, or the taxation costs of the transaction and given an opportunty to stop.

Leakage or Auto Payments

Sometimes there is a need for standing orders to be set up, for example as a membership fee, or a need to divert a fraction of a transaction or a period's trading to another account, for example tithing. There are various different mechanisms which need to be implemented independently.

A range of mechanisms is suggested below, each might be suitable for its own module. There are two basic types of auto-payment mechanisms, those which work periodically (the cron-mechanisms), and those which apply to individual transactions at the time. A hybrid is also possible, where the deductions are made periodically, from the total trading volume, say.

Every leakage mechanism would have the following properties. A name, an indication of value, a target account, a scope of people of transactions it applies to (this could be based on a filter), maximum / minimum quantities to divert. These objects would spawn instances. For example there could be a 5% per transaction payment to the community account for all transactions in currency1, and from the same mechanism but a different instance, I could tithe 10% per transaction to my great-aunt. Thus

5. The sysadmin / accountant can set up regular payments applying to groups of people or transactions within the system
6. Individual accounts can set up regular payments from them selves.
7. Every transaction, at its inception calculates the regular payments incurred and shows them in detail on the 'are you sure' page
8. The dependent transactions go into a pending state, until they are confirmed by the second party
9. On confirmation by the second party, the main transaction and its dependents all become marked as complete.
Comment: Hard limits may not be enough for all purposes. It may turn out that some systems designs may require support for a mechanism to allow the "resistance" to increase proportionally to commitment (analogously to a spring) or to have a leakage rate proportional to the absolute value of the member's account balance. An example is the LEG system I designed for exchange (but most definitely _not_ store-of-value) among SMEs and sole-traders, in which the an account leaks towards zero (if the balance is > 0) and towards minus infinity (if the balance is < 0).

examples of cron-based leakage.

• The simplest method is a monthly fee, which deducts from each applicable account a fixed amount every month.
• There should mechanisms for paying interest, such as in a bank account
• a more complex method is demurrage, which would tax periodicially in inverse proportion to the amount of trading. This should stimulate trading!
• a simple variation on demurrage is to penalise every month or week in which no trades occurred.

Leakage or even exemption, could apply to transactions according to many criteria. e.g. whether the member is in a particular group, which currency or currencies are used for the transaction, the category of transaction; members could set up their own personal mechanisms.

Currencies

Some systems will have one currency only, while others will have currencies created at will by any member. Time will tell the best models for currencies, and rules for creating them.

Limits

Many LETS schemes have come to grief because of people running up deficits without the apparent ability or willingness to repay them. The idea of different levels, where an accountant can set a warning or stop a cheque, and another level, where committee approval is needed so that a deficit becomes a formal loan, has also been suggested.

If detailed trading information is made accessible not only to the LETS accountant but also to members in the way implied by the original LETS design it might have the effects which were always claimed of the community keeping the trading in order, but while systems have not made this information visible, wildly fluctuating accounts have been a problem - the section on Management proposes expanding the information available to all members in the visible trading records to give a much better picture of what is happening.

Similarly, there are problems with members accruing excessive positive balances. While there are no economic benefits to hoarding money in a system that doesn't pay interest (indeed, in a demurrage system, they may even be charged interest on positive balances), it is in the interests of the system to encourage the currency to keep flowing.

user identity

Identity means how a person is known to the system; primarily what data is held on that person.

Creating an identity

The software should support some kind of vetting, tutorial, approval or mentoring procedure between members' applications to join and heir acceptance. Typically, new members may create an account online, but need some kind of approval before they can trade in curencies, post messages to the system, see other users' details. This could be expressed as there being a role of unapproved member.

Reputations

One of the problems of city-based LETS is the person who takes takes takes and then is never available to trade. Nobody quite knows who this person is, how they joined and when they leave, where did they go to. We hear stories of people who sign on to the LETS to trade, and when it comes to transacting, suddenly they want half cash or even total cash - and in an expensive service such as Feng Shui this can amount to hundreds of sterling. The worst story of this kind is a masseuse demanding cash with threats that she would accuse her client of misbehaving if he did not pay up on the spot. To think of the LETS being used in this way is horrifying. We believe these abuses are rare - the usual complaints are of people who didn't bother showing up to appointments or whose work was sub-standard. The commonsense way of dealing with these situations is to ask for references. Just because it's on LETS it doesn't mean this is a nice person. In a rural village people would know who you are, but in a city we don't. The wider system should therefore allow identity checks and support a reputation systems.

offers and wants directory

An intrinsic part of most trading systems will be a categorised directory of available and desired goods and services

Internal Communication

Aside from the structured system of offers and wants, Members should be able to communicate with one another personally and informally using normal social networking tools such as message boards, threaded discussions, internal mail, or chat.

Maps

The opportunity to use maps is just too good to pass up.

In radial communities, each user defines the radius around them which they consider accessible, and confine listings to members within that circle, this is explained elsewhere. But to do this meaningfully, and in a fun way, maps integration is needed.

Scalability

Three approaches have been identified towards homogenising and intertrading between all compliant systems. These three options range from the traditional one currency-one community approach, to a completely centralised single system with overlapping currencies and communities.

Model 1 (Linked schemes with interchangable currencies)
This represents the minimum that LETSlink UK wants to facilitate. Schemes will sign up to the national accreditation, and LETSlink UK will offer them software and probably hosting, or they can arrange their own as long as it meets the requirements. All currencies are convertible to minutes and therefore schemes can exchange currency, automatically if their software supports it. People wishing to work in hours will find this the hardest, and also individuals without a scheme in their area. Groups wanting to run multiple currencies can do so unless limited by software. MatsLETS was designed on this model.

Model 2 (Interchangable currencies managed by schemes)
This represents a shift in thinking where each currency has its own trading system, fees, rules, membership, and committee. Still the committee can be responsible for software, but LETSlink UK would provide hosting for the currencies and an interface that allows users to sign up to multiple currencies and and manage them through one login. A user would expect to be able to transfer funds between accounts, and this might happen so easily that all the currencies might be thought of as part of a universal system of exchange. That means all LETS traders should be on a single database, and when they log in they will see the news, notices, job postings, stats from the currencies to which they are signed up. It could be that cyclos' architecture is better suited to this model. cclite, also, although that software has a long way to go in terms of managing the rest of the community.

This model would also allow the exciting possibility of inter-radial communities mentioned above. It seems to me though that this model is merely the start of a slippery slope towards model 3 and beyond.

Model 3 (currencies as windows onto a universal time-based currency)
In this model there is almost no role for committees because all schemes are merged into one. Currencies may have local names, and rules, but they are so easy to intertrade they may as well all be hours. Individual currencies are a facade serving only to trading clusters, because it feels the same to trade within and accross currencies. Any idea of locality is done by inter-radial groups in which users define their own localities and interests. The software is rather complicated, but the fundamental model, of everyone trading hours, is much simpler.

filtering and search

When the system grows beyond a certain size, say 500 members, it will be helpful to set up filters to member lists, directory lists, and notices, to keep the results relevant. The search tool would operate within those filters

Filters

To allow a system to become large, and to feel smaller, there should be a number of run-time filters in the system. Ideally these would be enabled by admin, and perhaps configured by individual users for their own purposes.

This will provide users, or at least admins with a choice of which way to slice the bulk of accounts in the system for their own purposes. For example, some might want to look at local accounts for a cat feeder, while others might be looking to trade in a more esoteric currency, regardless of geography; still others will want to search the notices in a specific category. There also needs to be support for creating arbitrary groups. Each of these might make a good plug-in, filtering the accounts table before displaying members. And the system would work before most of them are written.

Examples of filters

Search tool

Security

As communities get larger and more anonymous, it becomes more important to make rules for who is allowed to do what and to see what. This is important for the security of both the system and the members.

Statistics

With all this currency going round, and so many members, logins, accounts, groups, people, offer-categories, transaction types, localities, there will need to be a sophisticated way of gathering statistics.

Offline Transactions

Systems should be constructed such that members can participate fully without internet access. Typically this means producing currency tokens for direct 'cash' trading or ensuring offline members have online partners who can enter transactions in their name, perhaps communicating them using cheques.