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
Combining cc modelsTransactionsLeakage or Auto PaymentsCurrenciesLimitsUser identityReputationsOffers and wants directoryInternal CommunicationMapsScalabilityFiltering and searchSecurityStatisticsOffline Transactions
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
The transaction is the core part of LETS. It has a lot of properties and constraints.
- 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
- 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.
- The payer should select a quality rating for what was paid for.
- 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
- The sysadmin / accountant can set up regular payments applying to groups of people or transactions within the system
- Individual accounts can set up regular payments from them selves.
- Every transaction, at its inception calculates the regular payments incurred and shows them in detail on the 'are you sure' page
- The dependent transactions go into a pending state, until they are confirmed by the second party
- On confirmation by the second party, the main transaction and its dependents all become marked as complete.
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.
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.
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.
There should be a many to many relationships between currencies and accounts.
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.
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.
It should be possible to set up arbitrary currencies if the system settings allow
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.
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.
The system should be able, by calculating the balance in Minuites, to assess someone's overall credit/debit level.
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.
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
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.
Identity means how a person is known to the system; primarily what data is held on that person.
Every identified person should be signed up to the system as a member
Under most circumstances, there will be one account per member.
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.
Each account should be associated with a member or members and have a registered address
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.
Offers / wants / adverts should belong to a specific account.
All of this information should be visible and editable by the members themselves.
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.
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.
To support timebanks, the system should have a way for members to represent their availability throughout a typical week.
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.
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.
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.
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
Offers and wants should be the same type but different objects, such that they can be disabled and skinned independently.
Every offer/want should retain the owner's id, time created.
Members should be able to edit their own offers / wants
Optional: to improve consistency and simplify things for users, offers and wants should be autocategorised
The administrator should be able to reconfigure the offer/want category definitions at any time to allow continuous improvement.
Optional: offers and wants should apply to specific currencies, such that there would be a different directory for each currency traded.
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.
It would be appropriate to publish these lists as xml feeds or print them onto paper
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.
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.
Members should be able to put messages onto the system and read messages according to the filters.
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.
There should be some Calendar functionality and the ability for certain roles to post events
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.
Any search or filter for members should be viewable on a map
Maps should support boundary drawing
It should be possible to filter members based on their geo, proximity, or whether they fall within certain boundaries.
It should be possible to customise how members appear on maps
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
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
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.
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.
If any filters are available, users will choose which filter they want to apply to their listings.
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...
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
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.
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
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.
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.
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.
Buddies / nonbuddies -Buddies are designated friends, or trusted people.
No filter - search the whole system. This should be the obvious choice for most small systems.
Myself - show only transactions / messages whatever in which the current account participated.
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.
Search should be performed within the context of the currently selected filter
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.
The system will provide a fixed set of permissions, such as edit web page, delete transaction, create currency, change account owner, view member addresses.
There should be roles in the system, created at setup, where each role has a set of permissions.
It should be possible to delegate control of certain permissions to sub-administrators
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.
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.
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.
There should be a way of visualising balance histories and trading volumes using the above query language and the built in filters
Widgets should be available to produce live headline statistics using the above query language and the built in filters
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.
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).
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.
the system should support the printing out of member lists and offer/want directories.