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.

  • A currency will have the following properties: nominal value in minutes*, 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 an account number of the member nominally responsible for it.
  • Accounts will be able to sign up to trade in many currencies and of course one currency will be tradable with many accounts.
  • 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.
  • 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.
  • Each currency will have minimum and maximum limits beyond which warnings will be issued and then trades will be disallowed. (See next page, limits)

*the nominal value in minutes is a way of making a currency exchangable in principle with other currencies, which is very important to Mary. 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. John suggests energy is more universal and he might be right. Trouble is, energy is hard to measure, especially mental energy and embodied energy.

John W Says: 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).

Matthew says John, in my understanding these interesting mechanisms all consititute unusual autopayment modules. You keep stressing the need not to define what a currency is, but we need some definition if this system is ever to be built, surely.

Auto-payment mechanisms

You're probably quite right, Matthew, in categorizing mechanization of the LEG "leakage functions" as "unusual autopayment modules". I just introduced this as an example to illustrate the need for flexibility (particularly since I don't yet know how flexible these might need to be).

Currency definition

Perhaps I haven't expressed my meaning clearly. It certainly wasn't my intention to "keep stressing the need not to define what a currency is" but rather to stress the need to avoid unnecessary constraints on the characteristics defining a particular currency.

In particular I want to make sure that all currencyies are not constrained to a particular value system.

The very first bullet point above states: "A currency will have the following properties: nominal value in minutes", and that is exactly the sort of prescriptive definition I would like to avoid.

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).

So all I'm really urging is that no constraints be built into the LoCuS specification that would more properly be built into the specification of a particular (currency) system type definition (such as LETSystem, TimeBank, timeLETS) which would provide a "configuration definition".

John :)