Local Currency - Rainbow - membership options

SEEDS Ecosystem
#1

I have been working on the “Rainbow” smart contract which supports “configurable money”, see How to deploy Rainbow Tokens - Google Docs .
Rainbow tokens can be used in a “closed” system for a village such that only enrolled members can use the currency. The social expectation is that in a small closed system it is easier to maintain trust, which supports more exploration with shared community resources based on the currency.
I’d like to toss out some ideas related to a “membership currency”.

  1. Enrollment. In this model, outsiders cannot hold the currency (they have no entry in the ledger). Once the organization has enrolled an individual as a member, they get an entry and are able to hold and trade currency. This is an “in or out” model and there is no simple way to put “out” someone who is “in”.
  2. Contingent membership. This model allows currency privileges to be turned on or off by the organization. It immediately raises questions of transparency and fairness in the decisions.
  3. Membership classes. In this model there could be two or more classes of membership with different behaviors. For example there might be a full membership (like the enrollment model) but also
  • a “provisional membership” for visitors or trial members which expires after 30 days or so. The provisional membership might have limitations on transaction volume
  • a “swap pool membership” used for “foreign exchange” with other local currencies or with “layer 2” regional currencies.

Reactions & expansions please!

1 Like
#2

Hi Chuck,
one thing that caught my attention immediately is the Contingent membership. being able to turn off privileges this way sounds a lot like social credit where an individual can find himself cut off of accessing his bank account or public transport.
I wonder what could be a better way to “include all” which better aligns with the values we try to promote here.

#3

Continuing to think about membership classes for “closed” community currencies…
A “visitor” would typically acquire local currency from a community “greeting office” website which comes with some orientation regarding how the currency works and expectations on behavior. (The newbie might have to click an “I agree” to get visitor status.) A visitor can send tokens to any full member but cannot send tokens to anyone else (e.g. another visitor). Thus the currency stays local.
I’m thinking

  1. It might be fine for full members to send tokens to visitors, or
  2. We might require visitors to always get new tokens from an authorized source, or
  3. Both of the above: “visitor I” and “visitor II” classes – maybe you automatically mature into visitor II after a certain amount of time or transactions.
1 Like