LETS software requirements

Introduction

This is a collection of requirements to inform the construction of online local currency trading systems. It is anticipated that such a system would plug in to an existing community web site to enable exisiting communities to trade.

These requirements and recommendations extend the specification for a Universal Transaction Engine drafted originally by Mary Fee at https://www.letslink.org/wiki.

Combining community currency models

This document does not explain how community currencies work or why we value them. It describes a flexible currency and transaction model. This software model incorporates a wide variety of types of currencies, and can be configured to work with one community trading one curency or for many independent communities trading multiple currencies. 

LETS is a zero sum system in which currency is issued as it is spent. In Timebanks hours are issued centrally and reimbursed centrally. In our understanding, timebanks can be administered within a zero-sum framework, as can other currency models. More work needs to be done on properties of currencies to ensure that popular community currencies are not excluded from this requirements document.

There is wide range of ideas for currency models and this system will not be able to accommodate all of them. However the author understands that many different types of currency could be expressed within a multi-LETS framework. For example Timebanks always the use a currency, called hours, a non-exchangable currency unit valued at 60 minutes, in which members start by earning something from a central source and may not trade below zero.

This system should also work for members who do not have internet access or IT literacy and prefer to trade with checks.

Software Framework

This document does not seek to describe the implementation in any particular system, only to describe requirements.

The important thing is that the framework used should be

• open source, so as not to exclude any developers or schemes, especially in developing countries
• as standards compliant as possible
• modular, to enable innovation and for people to work separately

Glossary

An account is like a bank account such that normally there will be one member per account, but many members should be able to control an account and one member may have control over several acounts
A member is a person with a username and password to log into the system.

Requirements

Members / accounts / currencies

This document assumes that a membership framework is already in place. This member data may need to be extensible.

• Under most circumstances, and in a simpilified system, there would be one account per member. i.e. 
• Offers / wants / adverts will belong to a specific account.
• 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.
• It should be possible for admin or sometimes users to set up new currencies and invite members to trade in them.
• While logged on, users should be able to switch between accounts.
• All of this information will be visible and editable by the members themselves.
• In order to trade using a currency, members may need to be eligible, either by meeting some criteria, or by being invited. and people will be able to sign up for currencies for which they are eligible.
• The following information should belong to accounts
• their balance and trading history
• 'quality of trade' feedback from other members
• their offers and wants
• the categories in which they operate, etc.
• currencies enabled
• The following information should belong to either members or accounts
• who their buddies are
• messages posted
• internal mails sent
• complaints
• location on a map

Dependent / Auto Payments

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.

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. 

A range of mechanisms is suggested below.

Every autopayment 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

1. The system administrator / accountant should be able to set up regular payments applying to groups of people or transactions within the system
2. Individual accounts should be able to set up regular payments from themselves.
3. Every transaction, at its inception calculates the regular payments incurred and shows them in detail on the 'are you sure' page.
4. The dependent transactions go into a pending state along with the main transaction, until they are confirmed by the second party
5. If the system employs limits, the dependent payments should be factored in before the limits
6. On confirmation by the second party, the main transaction and its dependents all become marked as complete.

Here are some examples of cron-based mechanisms.

• The simplest method is a monthly fee, which deducts from each applicable account a fixed amount every month.
• a more complex method is demurrage, which would tax periodicially in inverse proportion to the amount of trading, or the level of balance
• a simple variation on demurrage is to penalise every month or week in which no trades occurred.

Here are some examples of transaction-based mechanisms

• Taxes can be applied according to group-membership, currency, or per-member basis. Later on it may be possible to apply the autopayments to certain job categories also. Perhaps each payment mechanism shouldhave a list of exempt accounts also.
• Another simple method is to deduct a proportion of each applicable transaction, or a fixed quantity, at transaction time. This would involve an additional section to the transaction confirm page, showing how much was being diverted, which mechanism was causing it, and to which account it was going. This tax can be applied to a payment or to a receipt.

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 but for now we need to be as flexible as possible.

• There will be a default currency in all systems, non-tradable, invisible, and with a value of one minute. All transactions will 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).
Comment: the nominal value in minutes is a way of making a currency exchangable in principle with other currencies. There is another currency property, 'whether or not it can be exchanged for other currencies' that determines its practical value. The nominal value in minutes also helps to account. You can assess member's 'total' balance only with reference to a common yardstick, which is important if the system needs to see who's pulling their weight.
• A currency should have the following properties: 
• nominal value in minutes
• name
• icon
• geographical scope (optional)- outside of which it may not flow.
• a description / purpose
• whether or not it can be exchanged for other currencies
• and maximum and minimum that can be held in one account
• account number of the member responsible for it.
• autopayment rules associated with it 
• Accounts will be able to sign up to trade in many currencies.
• The system should support different ways of joining a currency trading group. For example, sign-up-and-go, or 'request owner'.
• Whether the currency can be given without confirmation.
• If a currency has a value of 0 minutes then it will be possible to trade only one of these at a time. This will support the altruists' model of gifting. Transactions of currencies with a value of 0 should  not be added up like most, but should be counted instead.

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.

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 will be blocked if they put the balance of the account over the limit for the currency or the system. Spends will be restricted according to actual balance while receipts will 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 should appear as pending, but there should be no button to confirm it.

Maps

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

In radial member filters, 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 can be shown on a map
• If permissions allow, the member's photo can be included on the map
• It should be possible to click on members on the map to go to their profiles
• (optional) maps could show the boundaries of certain localities

Geographical distance between traders could also be used in attenuating the value of a currency passed from one to the other. It may be desirable to design a currency that encourages localisation of the economy and discourages exchanges conducted over a greater distance than necessary.

Offers, Wants & Notices

A crucial service that any software supporting online trading needs to offer, is a directory of offers, perhaps also of wants.

• Every offers / want / notice will retain the poster's id (by implication the posters location), time posted, a subset of currencies which the poster belongs to, a duration or expiry date
• offers, and wants or notices should be supported in different ways. For example offers might be presented in a yellow pages while wants might use a noticeboard metaphor.
• There may be a way of autocategorising items, based on keywords
• members will be able to edit their own offers / wants
• It will 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 should be possible for members with limited access to the internet to have printed lists of members and lists of offers.
• The system should support a difference in approach between offers and wants to prevent getting them mixed up. Offers are usually viewed in a categorised directory format, while wants may be mingled with offers, listed in separate directories, or expressed as general notices on a noticeboard.
• [for discussion] there may be a third category of want / offer, called notices.

Scalability

There seem to be three approaches which could be taken towards homogenising and intertrading between all compliant systems. These three options range from the one currency-one community approach of traditional LETS, to a centralised overlapping currencies / overlapping communities approach.

Model 1 (Linked schemes with interchangable currencies)  Each self-governing scheme manages one or more currencies on a system all of which are expressable as minutes. Schemes can exchange currency, through their balancing accounts - 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.

Model 2 (Interchangable currencies managed by schemes)Each currency on the system is it's own scheme, but members can join many schemes, and sometimes trade between them.Once the user can transfer funds between accounts, all the currencies might be thought of as part of a universal system of exchange; all LETS traders would 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 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, values and rules, but they would be so easy to intertrade they may as well all be the same. Individual currencies would be a facade for trading clusters, because it feels the same to trade within and accross currencies. 

Filters

To allow a system to become large, and to feel smaller, the system should support filtering of members by various means. The administrator of the system should install some filters, and expose some of them to the user to configure. This will provide users 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.

1. The choice of available filters will 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.
2. If any filters are available, users will choose which filter they want to apply to their listings.
3. 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...
4. 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.
5. Filters should work in a stack, so more than one can be applied.

Examples of filters

1. No filter - search the whole system. This will be the obvious choice for most small systems.
2. 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.
3. Localities - refers to a line in your address. Localities should 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
4. 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.
5. 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. Also the currency owner could say this currency will only be traded within a radius of a certain point.
6. 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.
7. Buddies / nonbuddies -Buddies are designated friends, or trusted people.
8. History- show only people with whom the user has already traded

Statistics, Reporting and Accounting

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.

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. In fact just about financial calculation will involve a complex query on the transactions table, linked to other tables, so robust handling of this will need to be built in from the ground.

• Headline statistics should chosen and shown on the front page of the web site by the content author
• There should be an administrative search toolkit which can search either transactions, members, accounts, offers / wants, groups, by almost any criteria they have. This search, saved, might form the basis for the headline statistics. Or, with a variable in it, might be used at various points within the system. There may be some kind of syntax evolve for a searching, and for xml feeds
• Search results should also need to be ranked according to various criteria. 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 in a certain locality
• The system requires a range of accounting tools yet to be thought about.
• Attractive charts should be generated. For example, I may want to view my balance history for each of my currencies on my profile page, or on the page that talks about my currency, I may want to generate a chart showing the trade-volume-history of that currency, or, as a offers directory manager, I may want to see volumes of trades in each category to inform my category-keyword choices, or to notice changes in patterns.
• It should also produce 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 https://www.esrad.org.uk/projects/LCS/ccs-indicators.html). 

Transactions

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

• There should be half duplex and full duplex transactions, depending on the currency properties and permissions to override these. This means that most transactions would need to be confirmed by both parties, but some currencies would allow giving without confirmation. Only the administrator would be able to take 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 expressed in minutes 
• the quality of transaction will be required from the payer, which will affect the payees personal rating.
• a comment saying what the payment was for. This is for the log, but it also allows the transaction to be categorised automatically.
• Transactions should be subject to dependent transactions. That means that before a transaction is proposed or confirmed, the system will have a chance to generate more transactions, which will affect the value of the original transaction. The dependent transactions would be shown alongside the original transaction and completed with it, then for the sake of history, they may be summarised into one line.
• Transactions should have other hooks available for prorammers to use.

Third-Party Processing

If a cheque or passbook is received by the LETS accountant, it implies that the two-way transaction has already taken place, ie someone has signed a cheque and the recipient has transmitted it to the accountant for payment. In printed cheques this acceptance could be done by a second dated signature indicating acceptance and the same in a passbook system - both members countersign each others records. The dates shown on the chequebook are both entered to complete the transaction and the automatically generated payment-date records the batch of work done on a particular date. The more promptly the accountant records trades the more finely tuned the system will be for members to see the progress of trading. We think there will always be a need for paper-based systems so we need to have the option of continuing an Accountant service as an over-ride version in a system which is basically set up for members to transact. Once it becomes the norm for members to transact, anyone finding difficulty with this would be paired up with a techno-buddy to give them computer access and technical support.

• The accountant role should be able to transact on behalf of other people
• The system should support members with limited access to it by allowing proxy members who can enter checks on behalf of others.