Complementary currencies for Drupal

This module is built around a local currency model called LETS devised by Michael Linton in the early 80s. Hundreds if not thousands of communities are trading using this model as a basis, though many have changed the rules.

THE RULES OF LETS:

* LETS is basically an IOU network, where the total balance in the closed system always adds up to zero.
* Only members of the system can hold money, and the money only exists within the system.
* Currency is issued as it is spent, and neutralised as it is earned.
* The average account balance will always be zero, so it is no shame to maintain a balance below zero. Rather, what should be avoided for the health of the system, is for members' balances not to stray too far from zero.
* It is considered healthy therefore to put a minimum and maxaimum balance limit on each account. LETS currencies are NOT a store of value, but a medium of exchange.
* Most LETS systems also provide a directory of offers and wants, to facilitate trade. There is often a committee member who's job is to facilitate trade. As with any form of money, the community benefits ultimately by the total transaction volume, not money created.
* The value of one unit of currency is arbitrary, and can be decided by the community. It is usually linked either to time, or to the national currency. However ultimately it is between the transactees how much is exchanged.

VARIATIONS ON THE RULES OF LETS AND SUPPORT FOR THEM IN THIS MODULE

Multiple currencies.
More recent thinking, notably on the part of Michael Linton, is leading towards the use of almost ad hoc currencies, where every might declare a currency as part of its identity. However this thinking is far beyond what most people are ready for, who believe that money is a concrete entity controlled by the government. Version 2.0 of this module will support multiple currencies on the same system. Not everyone will be obliged to trade in every currency, but there will be a kind of signup process.
- Some currencies will be exchangable for other currencies on the system. They will be valued against each other using an internal factor which will be called, for the sake of argument, minutes. Each currency will remain a closed system. To track money going in and out of the system there only needs to be a balancing account for each currency. However it should be considered that money in the balancing account is effectively 'out of the system'. If the balancing account, like any other account ,had a large credit or deficit it would affect the amount of credit in circulation in the rest of the system.
- Trading with neighbouring systems. The balancing account could also be used to trade with neighbouring systems as well as with neighbouring currencies on the same system. Again, there need to be rules about that account getting too far from zero. This facility however should enable people to migrate between systems and take their balances with them. As long as the systems recognises each other and a nominal exchange rate is agreed.

Gift Currencies
Some of the local currencies are not for trading at all. They are issued, rather, as recognition for work done or contributions. They take their value not from the fact they can be spent, but from the fact that the community values the people who hold them. They can be thought of as brownie points or karma points.
Full support for these gift currencies will come with multiple currencies. They will work not by adding up the value of each transaction, but by adding up the transactions themselves, each one having a value of zero. There will be rules about who can issue, or spend, these currencies, and negative balances won't be recorded, or at least displayed.
For now this can be done by creating a contentType with a user reference cck field. The user-reference module adds a section to the user profile called, awkwardly, related content which shows all the nodes which reference the user. I prefer to remove this section and use views instead.,

No limits on the system account spending.
One system in the UK has allowed it's system account unlimited spending and it now has a very large negative balance. There are concerns here about deflation and a 'run on the bank' is always possible. I watch these situations with interest and concern, but for now it works. This module allows any positive or negative limit which can be changed at any time. Transactions are disallowed if the resulting balance would be outside the account limits.

Leakage
Most systems require contributions from their members to cover administration costs and to allow the community to make contributions as a group. These contributions can be made through doing tasks in exchange for gifts, paying some local money into the central account, or through so-called harder currencies, which local money is not planning to replace any time soon. Support is planned for various leakage mechanisms, including:
- leakage on spending and earning
- periodical (e.g. monthly) or per transaction leakage
- fixed rate or variable leakage
- demurage
- system wide (taxation) or personal (tithing) leakage
None of these are yet supported.

Buying in.
Systems may wish to issue currency to their new members, either as a starting present, to encourage spending, or because members have paid some kind of joining fee. There are two ways of doing this. The proper way is to pay them from the system account, hence from the community. The other way is to pay them 20 credits from account 0, which isn't really an account at all.This would mean each member would start with, and have an average balance of 20 credits, which may as well be zero, except it is psychologically different. The only difference between 20 and 0 would be what balance was expected when people left the system.

People leaving the system with negative balance
If accounts become inactive with a negative balance, it is ultimately and obviously the rest of the community that covers the cost. The system should have contingency plans to get accounts back to zero, probably from a central fund. In practice however, this rarely happens!

Time banks
This is a different currency model designed by Edward Cahn specifically for inner city regeneration projects - but the context doesn't matter here. I believe this module will support the timebank model with small modifications, but I haven't had occasion to model those transactions.

Both transactions and offers & wants modules were intended to be used in tandem with the autocategorise module. However that's up to you.

OPTIONS

There are a few options available in the options pages, but more choices to be made on the site layout and what things are emphasised. Some arrangements will be better than others, and with each new implementation we gain more experience.
So saying, the options allow you to name the most terminological aspects of the site, to set the maximum and minimum balances of the member accounts, and to state the values and words for the transaction ratings.

ARCHITECTURE

Offers & wants, and transactions are two unconnected modules which do not communicate or depend on one another in any way. In a shop system you would expect items to have prices and a transaction would link a user to the item using a price. This is not a shop, this is a transaction engine. Each transaction has it's own field which describes what the transaction was about, and each transaction has it's own price decided by the participants. All transactions are extended nodes with the data stored in the cc_transactions table. The system calculates member balances by adding up all their transactions in that currency, ever. Therefore accounts which have traded even once cannot be removed from the system unless all those transactions are altered to be from some other account called 'expired member'.
Since balances are used regularly, and potentially processor intensive, they are stored in a table called cc_balance_cache. This table is exposed to views and can be added to tables.
The module provides two forms, the pre_transaction form and the transaction_node_form, the former is never processed, it just passes data into the latter which then acts as a confirmation form, or an edit form if permissions allow. Note that the pre_transaction form, (also available as a block to be shown on other users' pages) needs to know who the user is, who they are transacting with, which way the money is going, and whether the other person needs to confirm it. At the second stage this information becomes payer and payee IDs, with a flag as to whether or not the transaction is completed ($node->status is reused for this.)
The four types of transaction (2 in each direction, to go directly or to be confirmed by the other party) are enabled by naming them on the options page.

ROADMAP

We encourage each new scheme to contribute some of their budget towards development of new features. This section is for tracking the feature ideas.
*Leakage mechanism, typically as part of membership costs. Such a tool could get very elaborate enabling all sorts of gifting and taxing, with various triggers and algorythms.
*More languages - It takes around 2 hours to translate the module into a new language.
*Paypal subscription, to remind and collect members annual fees
*Paid offers/wants, for members who prefer to use official money, for the time being. (extra views will be needed, too)
*Improved printable pages
*Printable members directory
*Individualised min/max limits, for when the committee agrees an exceptional case. There could also be a payback period where the min/max is calculated on a daily basis as it returns to the norm.
*Transaction templates - a powerful alternative to the offer/want where partially completed transactions are designated templates. So for an offer, you would fill in the payee, a description of the offering, and maybe the price. This could later convert into a transaction by filling in a single field, the payer. This could further be improved by allowing multiple payers/payees, so that people could sign up to a transaction with limited participation, such as a dinner party
*More site layouts!