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.

User Story: transaction Joe wants to pay his neighbour Bill, for mowing the lawn. He goes to Bill's profile page where there is a form to initiate a transaction with Bill. He chooses 'offer', 12 henteeth, 'mowing my lawn' and submits the form. He sees a confirmation page which says. Do you want to offer Bill 15 henteeth for 'mowing my lawn'?. Please choose the quality of the transaction. This transaction will trigger another 2 hentooth to the dental account for insurance, and 1 henteeth to the central maintenance account for VAT. Joe selects 'satisfactory' and submits. Bill and Joes pending balances are updated. Next time Bill logs on, he is alerted to this incomplete transaction, he goes it and reads, Joe has offered you 12 henteeth for 'mowing my lawn'. The transaction was 'satisfactory'. 1 hentooth will go to central maintenance account for Income tax. Do you accept? Bill clicks yes and the transaction is complete and the balances are updated.

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.

10. A currency should have the following properties: nominal value, name, icon, whether or not it can be exchanged for other currencies, and maximum and minimum that can be held in one account. It will have taxation rules associated with it (see elsewhere), a description, and an optional geographical scope - outside of which it may not flow. It will have a member nominally responsible for it.
11. There should be a many to many relationships between currencies and accounts.
12. There should be a default currency in all systems, non-tradable, invisible, and with a value of one. For convenience this shall be known as a Minute. All transactions should be stored in Minutes.
Comment: It certainly makes sense to use time as the measure for certain types of currency (particularly those involving human activity and the allocation of time-shared resources), but for store-of-value systems a more fundamental unit for many purposes would be energy (kWh, Joules, GeV, Ergs, etc.) and for stable exchange currencies at the very local level, a more fundamental measure might be that of staple food (as the price loaf of bread was in the past - or as the price of an omelette is, or at least was, the standard by which to compare the relative prices across the menus in French eating places).
13. In a multi-currency system members should subscribe to currencies before being allowed to trade in them, either by meeting some criteria, or by being invited. and people should be able to sign up for currencies for which they are eligible.
14. It should be possible to set up arbitrary currencies if the system settings allow
Comment:
• individuals might want to form (semi-)private/closed trading groups rather than having their presence made know to all site visitors.
• individuals might want to be members of more than one such group
• each group might be identified by a corresponding (set of) role(s)
• access to the directory/accounting areas available to each role could be controlled by (for example) "nodeaccess"
• the privileges within each role could also be distinguished using the same mechanism.
15. If a currency has a value of 0 Minutes then it should be possible to trade only one of these at a time. This will support the altruists' model of gifting.
16. If a currency is 'exchangable' then members should be able to trade with the balancing account and change it for other currencies at an exchange rate based on the Minute value of each currency.
17. The system should be able, by calculating the balance in Minuites, to assess someone's overall credit/debit level.

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.

18. transactions should be blocked if they put the balance of the account over the limit for the currency or the system. Spends should be restricted according to actual balance while receipts should be restricted according to pending balances
19. balances are checked for both parties at both the creation and confirmation of the transaction. If a transaction becomes illegal between creation and confirmation, it will appear as pending, but there should be no button to confirm it.

user identity

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

20. Every identified person should be signed up to the system as a member
21. Under most circumstances, there will be one account per member.
22. However there should be a many to many relationship between accounts and members enabling shared accounts, or the separation of work/life accounts by individual users.
23. Each account should be associated with a member or members and have a registered address
24. Each account should be associated with a subset of the available currencies, some of which may be open only to those who meet specific eligibility criteria.
25. Offers / wants / adverts should belong to a specific account.
26. All of this information should be visible and editable by the members themselves.
27. The system should have extensible member profiles to store arbitrary information about members, such as a scan of a members proof of identity (e.g. birth certificate, passport, driving licence) or audio introduction, or geo-coordinates.
28. Each user should have a role in the system, and each account should have a transaction history, messages posted, 'quality of trade' feedback from members, support for 'buddies', offers and wants, a list of categories in which they operate, etc.
29. To support timebanks, the system should have a way for members to represent their availability throughout a typical week.
Comment: It is common practice in LETS schemes for members to have an account number, reminiscent of a bank account. Commonly they are only known to other members by their first name (or in some cases a nickname or alias. But often at joining meetings they even introduce themselves by their first name and account number.

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.

Comment: Users should be able to log in unambiguously using either membership number or username
Comment: Within any "local cluster" it would be helpful to allow for the unique identification of a account|currency|system triplet (where "system" means the name of the LCS organization, which may provide multiple currency support, or the name of a branch within that LCS organization); following the conventions of *nix style addressing (which is what we have in the form of email addresses, URLs, user IDs, etc.) we define any user uniquely.

Furthermore we can define arbitrary "mapping functions" or "exchange functions" between currencies, e.g.
F[%hours@piglets.org,%joules@clun.energy.org.uk]

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.

30. Each transaction will have a quality score, to be filled in by the payer. This will work on creation of the transaction, for payment-led transactions, or on the confirmation for invoice driven transactions.
31. This score will be aggregated and become a property of each member

offers and wants directory

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

32. Offers and wants should be the same type but different objects, such that they can be disabled and skinned independently.
33. Every offer/want should retain the owner's id, time created.
34. Members should be able to edit their own offers / wants
35. Optional: to improve consistency and simplify things for users, offers and wants should be autocategorised
36. The administrator should be able to reconfigure the offer/want category definitions at any time to allow continuous improvement.
37. Optional: offers and wants should apply to specific currencies, such that there would be a different directory for each currency traded.
38. Optional: it should be possible for a member to view offers / wants aggregated for all the currencies they subscribe to, or filtered by currency, or filtered by locality / region.
39. It would be appropriate to publish these lists as xml feeds or print them onto paper
40. While offers are usually viewed in a directory format, wants are sometimes mingled with offers, sometimes separated and sometimes expressed as general notices, i.e. regarded completely differently. The system must support the viewing of offers and wants as filtered listings of many kinds.

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.

41. Members should be able to put messages onto the system and read messages according to the filters.
42. Notices which are neither offers nor wants should have expiry dates, and should be able to be withdrawn by their authors before the expiry date.
43. There should be some Calendar functionality and the ability for certain roles to post events
Comment: As many communication channels as possible should be allowed, including (with decreasing channel capacity), >web interface (browser), email (using an autoresponder system and defined formats), XML streams (including Jabber), SMS

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.

44. Any search or filter for members should be viewable on a map
45. Maps should support boundary drawing
46. It should be possible to filter members based on their geo, proximity, or whether they fall within certain boundaries.
47. It should be possible to customise how members appear on maps
48. There should be support for the geographical subdividing of schemes into hierarchical localities, bounded by polygons which correspond to words in members' addresses. These hierarchies should be independent of currencies and will allow some devolution of responsibility for larger schemes

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.

49. The choice of available filters should be set up at runtime. Some filters may be applied by the system, for example so that people trading in different currencies might never see each other.
50. If any filters are available, users will choose which filter they want to apply to their listings.
51. Listings include: directory listings of people or skills belonging to people, listings of messages, listings of trades, any statistics/reporting widgets such as top ten earners...
52. The concept could be extended so that when a user looks at an account history, even that is just a filter. Though this might not be an intuitive way to design the Graphic User Interface.

Examples of filters

53. Currencies - membership is restricted according to criteria defined by the currency creator. In order to transact, both people need to have accounts in a common currency. Membership to currencies can be restricted by some other dimensions, though it should be mostly open.
54. Localities - refers to a line in your address. Localities nest, so that by being a member of Brixton locality, I am automatically a member of South London locality. Membership of localities is involuntary, and depends on your address. This is good for caring structures, and for easily finding trading partners within an accessible distance in a spread out scheme. Each locality, for the purpose of mapping, would have a centre and a radius
55. Groups - can be created arbitrarily. We don't have a meaning for them yet. We don't know what membership criteria might be. For example, this might be the way to have an invitation-only dimension. This dimension should cover all other dimensions needed but not built in to the system.
56. Radial - this is just an idea at the moment, but based on postcodes and therefore geo-coordinates, people could make their own localities based on distance from them. This would better serve people living on the borders of localities. Membership would be according to the distance between the person who's radius it is, and everyone else. Typically members would save their preferred radius and view directory listings or maps accordingly.
57. Offer-categories - there are opportunities to create spontaneous communities amongst, say, all the caterers in a system, by regarding offer-categories as a dimension. membership would depend on what skills and services a person was offering, and which categories they fell into. Example, I might be clearing out my garden shed, and I might want to email all the gardeners within five miles to see who needs any tools.
58. Languages
59. Buddies / nonbuddies -Buddies are designated friends, or trusted people.
60. No filter - search the whole system. This should be the obvious choice for most small systems.
61. Myself - show only transactions / messages whatever in which the current account participated.
User Story showing filters Peter is a handyman who travels by bicycle. He likes to socialise with other members, particularly those who cook. On his account he has enabled a 10km radial filter, and limited the categories to 'DIY', 'garden', and 'food'. When browses the directories, all the categories are available, but the offers are from within 10km. But when he scans the noticeboard, he sees only items in his chosen categories. When he joins the philosopy discussion group, and he adds a new filter so he can track those people even if they live outside the system. His filters are now wet up thus: (within:10km AND in categories: DIY OR Garden OR food) or in group:Philosophy

Search tool

62. A quick keyword search will search offers / wants, personal descriptions and perhaps previous transactions (if the user has permission to see them) on the basis of keyword. This might be the only way the user can see beyond the groups, currencies and localities of which he or she is a member.
63. Search should be performed within the context of the currently selected filter

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.

64. The system will provide a fixed set of permissions, such as edit web page, delete transaction, create currency, change account owner, view member addresses.
65. There should be roles in the system, created at setup, where each role has a set of permissions.
66. It should be possible to delegate control of certain permissions to sub-administrators
67. For members there should be three privacy levels, defined at setup of the system, called anonymous, member, and buddies. Members will nominate people to be their buddies and to see all their account information, whereas in a large system some members might not want some information visible to members they don't know.

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.

68. There should be some kind of query language to generate stats for these widgets. For example we might want the top five traders in currency A in the last month, by volume, or by number of transactions. Or the top ten most indebted people within a certain locality. This may be integrated with the filters.
69. There should be a way of visualising balance histories and trading volumes using the above query language and the built in filters
70. Widgets should be available to produce live headline statistics using the above query language and the built in filters
71. Statistical data should be generated from transaction records. Traditionally this has simply been recorded as "balance" and "turnover", but for most people this is a little obscure. This system will provide feedback direct to members by showing a list of trades with running statistics, such as: [number of trades, total income, average income, total expenditure, average expenditure], within a given period, e.g. for the past month, and for the past year.
72. Optional: There should also be visual indicators to show skew/bias (i.e. the extent to which a particular currency favours one group of individuals over another), connectivity, clustering, etc. (see for example ccs-indicators).

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.

73. the system should support the printing out of member lists and offer/want directories.